diff --git a/.changeset/seven-poems-punch.md b/.changeset/seven-poems-punch.md
new file mode 100644
index 00000000000..a19d6a75a10
--- /dev/null
+++ b/.changeset/seven-poems-punch.md
@@ -0,0 +1,5 @@
+---
+"@hashintel/petrinaut": patch
+---
+
+Add an interactive-tool extension point to the AI assistant panel: hosts can register app-level tools whose calls render as interactive widgets in the conversation, including tools that suspend the turn until the user responds.
diff --git a/.github/actions/prune-repository/prune.py b/.github/actions/prune-repository/prune.py
index e1eca864964..400859f7b6b 100644
--- a/.github/actions/prune-repository/prune.py
+++ b/.github/actions/prune-repository/prune.py
@@ -6,6 +6,7 @@
 
 import argparse
 import json
+import shutil
 import subprocess
 from collections.abc import Iterable
 from glob import glob
@@ -18,7 +19,8 @@
 # ---------------------------------------------------------------------------
 
 # If any of these packages appear in the dependency closure, add the
-# corresponding extra packages to the scope.
+# corresponding extra packages to the scope. Triggers use prefix matching
+# so a family root can pull its children (e.g. darwin-kperf).
 EXTRA_DEPENDENCIES: dict[str, list[str]] = {
     # Cyclic: hashql crates need compiletest
     "@rust/hashql-ast": ["@rust/hashql-compiletest"],
@@ -38,6 +40,27 @@
     "@rust/hash-graph-types": ["@rust/hash-graph-test-data"],
 }
 
+# Extras that must not fire on a transitive or prefix match. Brunch core's
+# architecture tests need the app and context root, but a job whose requested
+# scope is only a sibling or a consumer of core must not pull that fixture.
+REQUESTED_DEPENDENCIES: dict[str, list[str]] = {
+    "@hashintel/brunch-agent": ["@apps/brunch-agent"],
+}
+
+# Non-workspace paths required by packages in the *requested* scope.
+# `turbo prune` copies workspace directories and root manifests only.
+REQUESTED_PATHS: dict[str, list[str]] = {
+    # The Brunch context root is deliberately not a workspace, but the
+    # architecture tests in packages/core read its docs, scripts, and agent
+    # contract files
+    "@hashintel/brunch-agent": [
+        "libs/@hashintel/brunch-agent/AGENTS.md",
+        "libs/@hashintel/brunch-agent/CONTEXT.md",
+        "libs/@hashintel/brunch-agent/docs",
+        "libs/@hashintel/brunch-agent/scripts",
+    ],
+}
+
 TURBO_QUERY = """
     query {
       packages {
@@ -73,6 +96,31 @@ def turbo_dependency_map() -> dict[str, frozenset[str]]:
     return dep_map
 
 
+def extras_for_requested(requested: Iterable[str]) -> frozenset[str]:
+    """Return extras implied by the job's requested scopes only.
+
+    Exact identity: a name that is a prefix of its siblings must not match them.
+    """
+
+    names = set(requested)
+    extras: set[str] = set()
+    for trigger, additions in REQUESTED_DEPENDENCIES.items():
+        if trigger in names:
+            extras.update(additions)
+    return frozenset(extras)
+
+
+def extra_paths_for_requested(requested: Iterable[str]) -> list[str]:
+    """Return non-workspace paths implied by the job's requested scopes only."""
+
+    names = set(requested)
+    paths: list[str] = []
+    for trigger, trigger_paths in REQUESTED_PATHS.items():
+        if trigger in names:
+            paths.extend(trigger_paths)
+    return paths
+
+
 def expand_scopes(dependencies: Iterable[str]) -> frozenset[str]:
     """Return extra scopes implied by the dependency names.
 
@@ -121,6 +169,29 @@ def turbo_prune(scopes: Iterable[str], *, dry_run: bool = False) -> None:
     subprocess.run(args, check=True)
 
 
+def copy_extra_paths(scopes: Iterable[str], *, dry_run: bool = False) -> None:
+    """Copy non-workspace paths that `turbo prune` cannot include."""
+
+    for path in extra_paths_for_requested(scopes):
+        source = Path(path)
+        if not source.exists():
+            msg = f"REQUESTED_PATHS names {source}, which does not exist"
+            raise FileNotFoundError(msg)
+
+        destination = Path("out") / source
+
+        if dry_run:
+            print(f"[dry-run] Would copy: {source} -> {destination}")
+            continue
+
+        print(f"Copying extra path: {source} -> {destination}")
+        if source.is_dir():
+            shutil.copytree(source, destination, dirs_exist_ok=True)
+        else:
+            destination.parent.mkdir(parents=True, exist_ok=True)
+            shutil.copy2(source, destination)
+
+
 def resolve_workspace_members() -> list[Path]:
     """Read workspace members from Cargo.toml and resolve globs to Cargo.toml paths."""
 
@@ -192,8 +263,9 @@ def main(argv: list[str] | None = None) -> None:
     }
 
     dependencies = turbo_dependency_map()
-    scopes = fixpoint_expand(initial, dependencies)
+    scopes = fixpoint_expand(initial | extras_for_requested(initial), dependencies)
     turbo_prune(scopes, dry_run=args.dry_run)
+    copy_extra_paths(initial, dry_run=args.dry_run)
     stub_missing_members(dry_run=args.dry_run)
 
 
diff --git a/.github/actions/prune-repository/prune_test.py b/.github/actions/prune-repository/prune_test.py
new file mode 100644
index 00000000000..8e2722cb52a
--- /dev/null
+++ b/.github/actions/prune-repository/prune_test.py
@@ -0,0 +1,66 @@
+#!/usr/bin/env python3
+"""Hermetic oracles for prune extra-scope rules. Does not run turbo prune."""
+
+from __future__ import annotations
+
+import unittest
+
+from prune import (
+    expand_scopes,
+    extra_paths_for_requested,
+    extras_for_requested,
+    fixpoint_expand,
+)
+
+CORE = "@hashintel/brunch-agent"
+TRANSPORT = "@hashintel/brunch-agent-transport-aisdk"
+APP = "@apps/brunch-agent"
+WEBSITE = "@apps/petrinaut-website"
+
+
+class BrunchRequestedExtras(unittest.TestCase):
+    def test_core_job_adds_the_app_and_context_paths(self) -> None:
+        self.assertEqual(extras_for_requested({CORE}), frozenset({APP}))
+        self.assertIn(
+            APP,
+            fixpoint_expand(
+                {CORE} | extras_for_requested({CORE}),
+                {CORE: frozenset(), APP: frozenset({CORE})},
+            ),
+        )
+        self.assertEqual(
+            extra_paths_for_requested({CORE}),
+            [
+                "libs/@hashintel/brunch-agent/AGENTS.md",
+                "libs/@hashintel/brunch-agent/CONTEXT.md",
+                "libs/@hashintel/brunch-agent/docs",
+                "libs/@hashintel/brunch-agent/scripts",
+            ],
+        )
+
+    def test_sibling_or_website_job_does_not_add_brunch_extras(self) -> None:
+        self.assertEqual(extras_for_requested({TRANSPORT}), frozenset())
+        self.assertEqual(extras_for_requested({WEBSITE}), frozenset())
+        self.assertEqual(extra_paths_for_requested({TRANSPORT}), [])
+        self.assertEqual(extra_paths_for_requested({WEBSITE}), [])
+
+    def test_transitive_core_in_the_closure_does_not_add_the_app(self) -> None:
+        dependencies = {
+            WEBSITE: frozenset({TRANSPORT}),
+            TRANSPORT: frozenset({CORE}),
+            CORE: frozenset(),
+        }
+        expanded = fixpoint_expand({WEBSITE}, dependencies)
+        self.assertNotIn(APP, expanded)
+        self.assertEqual(extras_for_requested({WEBSITE}), frozenset())
+
+
+class DarwinPrefix(unittest.TestCase):
+    def test_child_crate_still_triggers_the_prefix_family(self) -> None:
+        extras = expand_scopes({"@rust/darwin-kperf-sys"})
+        self.assertIn("@rust/darwin-kperf-sys", extras)
+        self.assertIn("@rust/darwin-kperf-events", extras)
+
+
+if __name__ == "__main__":
+    unittest.main()
diff --git a/.markdownlint-cli2.jsonc b/.markdownlint-cli2.jsonc
index 908fbb21ec6..2d47e9c6681 100644
--- a/.markdownlint-cli2.jsonc
+++ b/.markdownlint-cli2.jsonc
@@ -35,6 +35,7 @@
     "**/_ai/**",
     "**/.cursor/plans/**",
     "libs/@hashintel/ds-components/**",
-    "libs/@hashintel/ds-helpers/**"
+    "libs/@hashintel/ds-helpers/**",
+    "libs/@hashintel/brunch-agent/docs/**"
   ]
 }
diff --git a/apps/brunch-agent/.gitignore b/apps/brunch-agent/.gitignore
new file mode 100644
index 00000000000..e941ebb524d
--- /dev/null
+++ b/apps/brunch-agent/.gitignore
@@ -0,0 +1,2 @@
+.data-wipe-me/
+.flue/
diff --git a/apps/brunch-agent/AGENTS.md b/apps/brunch-agent/AGENTS.md
new file mode 100644
index 00000000000..90c05dde6d5
--- /dev/null
+++ b/apps/brunch-agent/AGENTS.md
@@ -0,0 +1,9 @@
+# Brunch agent application
+
+This application belongs to the Brunch context rooted at
+`../../libs/@hashintel/brunch-agent/`. Read that context's `AGENTS.md`, `CONTEXT.md`, and relevant
+ADRs before changing this application. HASH root guidance takes precedence.
+
+The application composes the Brunch packages, Flue runtime, HTTP routes, and local diagnostics. It
+must remain independent of Petrinaut implementation packages; `apps/petrinaut-website` meets it
+through the AI SDK/HTTP transport.
diff --git a/apps/brunch-agent/CLAUDE.md b/apps/brunch-agent/CLAUDE.md
new file mode 120000
index 00000000000..47dc3e3d863
--- /dev/null
+++ b/apps/brunch-agent/CLAUDE.md
@@ -0,0 +1 @@
+AGENTS.md
\ No newline at end of file
diff --git a/apps/brunch-agent/LICENSE.md b/apps/brunch-agent/LICENSE.md
new file mode 100644
index 00000000000..c7d627721e2
--- /dev/null
+++ b/apps/brunch-agent/LICENSE.md
@@ -0,0 +1,607 @@
+GNU Affero General Public License
+=================================
+
+_Version 3, 19 November 2007_
+_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+## Preamble
+
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+Developers that use our General Public Licenses protect your rights
+with two steps: **(1)** assert copyright on the software, and **(2)** offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+The precise terms and conditions for copying, distribution and
+modification follow.
+
+## TERMS AND CONDITIONS
+
+### 0. Definitions
+
+“This License” refers to version 3 of the GNU Affero General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as “you”.  “Licensees” and
+“recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a “modified version” of the
+earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based
+on the Program.
+
+To “propagate” a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices”
+to the extent that it includes a convenient and prominently visible
+feature that **(1)** displays an appropriate copyright notice, and **(2)**
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+### 1. Source Code
+
+The “source code” for a work means the preferred form of the work
+for making modifications to it.  “Object code” means any non-source
+form of a work.
+
+A “Standard Interface” means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other
+than the work as a whole, that **(a)** is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and **(b)** serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+“Major Component”, in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+The Corresponding Source for a work in source code form is that
+same work.
+
+### 2. Basic Permissions
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+### 3. Protecting Users' Legal Rights From Anti-Circumvention Law
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+### 4. Conveying Verbatim Copies
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+### 5. Conveying Modified Source Versions
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+* **a)** The work must carry prominent notices stating that you modified
+it, and giving a relevant date.
+* **b)** The work must carry prominent notices stating that it is
+released under this License and any conditions added under section 7.
+This requirement modifies the requirement in section 4 to
+“keep intact all notices”.
+* **c)** You must license the entire work, as a whole, under this
+License to anyone who comes into possession of a copy.  This
+License will therefore apply, along with any applicable section 7
+additional terms, to the whole of the work, and all its parts,
+regardless of how they are packaged.  This License gives no
+permission to license the work in any other way, but it does not
+invalidate such permission if you have separately received it.
+* **d)** If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your
+work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+“aggregate” if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+### 6. Conveying Non-Source Forms
+
+You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+* **a)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium
+customarily used for software interchange.
+* **b)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a
+written offer, valid for at least three years and valid for as
+long as you offer spare parts or customer support for that product
+model, to give anyone who possesses the object code either **(1)** a
+copy of the Corresponding Source for all the software in the
+product that is covered by this License, on a durable physical
+medium customarily used for software interchange, for a price no
+more than your reasonable cost of physically performing this
+conveying of source, or **(2)** access to copy the
+Corresponding Source from a network server at no charge.
+* **c)** Convey individual copies of the object code with a copy of the
+written offer to provide the Corresponding Source.  This
+alternative is allowed only occasionally and noncommercially, and
+only if you received the object code with such an offer, in accord
+with subsection 6b.
+* **d)** Convey the object code by offering access from a designated
+place (gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to
+copy the object code is a network server, the Corresponding Source
+may be on a different server (operated by you or a third party)
+that supports equivalent copying facilities, provided you maintain
+clear directions next to the object code saying where to find the
+Corresponding Source.  Regardless of what server hosts the
+Corresponding Source, you remain obligated to ensure that it is
+available for as long as needed to satisfy these requirements.
+* **e)** Convey the object code using peer-to-peer transmission, provided
+you inform other peers where the object code and Corresponding
+Source of the work are being offered to the general public at no
+charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A “User Product” is either **(1)** a “consumer product”, which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or **(2)** anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, “normally used” refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+### 7. Additional Terms
+
+“Additional permissions” are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+* **a)** Disclaiming warranty or limiting liability differently from the
+terms of sections 15 and 16 of this License; or
+* **b)** Requiring preservation of specified reasonable legal notices or
+author attributions in that material or in the Appropriate Legal
+Notices displayed by works containing it; or
+* **c)** Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+* **d)** Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+* **e)** Declining to grant rights under trademark law for use of some
+trade names, trademarks, or service marks; or
+* **f)** Requiring indemnification of licensors and authors of that
+material by anyone who conveys the material (or modified versions of
+it) with contractual assumptions of liability to the recipient, for
+any liability that these contractual assumptions directly impose on
+those licensors and authors.
+
+All other non-permissive additional terms are considered “further
+restrictions” within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+### 8. Termination
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated **(a)**
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and **(b)** permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+### 9. Acceptance Not Required for Having Copies
+
+You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+### 10. Automatic Licensing of Downstream Recipients
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+### 11. Patents
+
+A “contributor” is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, “control” includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To “grant” such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either **(1)** cause the Corresponding Source to be so
+available, or **(2)** arrange to deprive yourself of the benefit of the
+patent license for this particular work, or **(3)** arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  “Knowingly relying” means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is “discriminatory” if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license **(a)** in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or **(b)** primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+### 12. No Surrender of Others' Freedom
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+### 13. Remote Network Interaction; Use with the GNU General Public License
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+### 14. Revised Versions of this License
+
+The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License “or any later version” applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+### 15. Disclaimer of Warranty
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+### 16. Limitation of Liability
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+### 17. Interpretation of Sections 15 and 16
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
diff --git a/apps/brunch-agent/flue.config.ts b/apps/brunch-agent/flue.config.ts
new file mode 100644
index 00000000000..829f8e06779
--- /dev/null
+++ b/apps/brunch-agent/flue.config.ts
@@ -0,0 +1,8 @@
+import { defineConfig } from "@flue/runtime/config";
+
+export default defineConfig({
+  target: "node",
+  // Exhaustive, so a typo'd provider fails at resolution instead of reaching
+  // the network (Flue patterns audit, 2026-08-17).
+  providers: ["anthropic"],
+});
diff --git a/apps/brunch-agent/index.html b/apps/brunch-agent/index.html
new file mode 100644
index 00000000000..0b84eae229a
--- /dev/null
+++ b/apps/brunch-agent/index.html
@@ -0,0 +1,12 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>Elicitation harness — dev app</title>
+  </head>
+  <body>
+    <div id="root"></div>
+    <script type="module" src="/src/ui/main.tsx"></script>
+  </body>
+</html>
diff --git a/apps/brunch-agent/package.json b/apps/brunch-agent/package.json
new file mode 100644
index 00000000000..fc199cec26f
--- /dev/null
+++ b/apps/brunch-agent/package.json
@@ -0,0 +1,42 @@
+{
+  "name": "@apps/brunch-agent",
+  "version": "0.0.0-private",
+  "private": true,
+  "description": "Remote Brunch server, local development loop, target gallery, and diagnostic probe surface.",
+  "license": "AGPL-3.0",
+  "type": "module",
+  "scripts": {
+    "build": "vite build && vite build --config vite.client.config.ts",
+    "dev": "vite dev",
+    "fix:eslint": "oxlint --fix --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:eslint": "oxlint --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:tsc": "tsgo --noEmit",
+    "petrinaut:dev": "vite dev --config petrinaut-local.vite.config.ts",
+    "test:unit": "vitest run --config vitest.config.ts"
+  },
+  "dependencies": {
+    "@flue/react": "2.0.3",
+    "@flue/runtime": "2.0.3",
+    "@flue/sdk": "2.0.3",
+    "@hashintel/brunch-agent": "workspace:*",
+    "@hashintel/brunch-agent-binding-flue": "workspace:*",
+    "@hashintel/brunch-agent-plugin-gherkin": "workspace:*",
+    "@hashintel/brunch-agent-transport-aisdk": "workspace:*",
+    "hono": "4.13.2",
+    "react": "19.2.6",
+    "react-dom": "19.2.6",
+    "valibot": "1.4.2"
+  },
+  "devDependencies": {
+    "@earendil-works/pi-ai": "0.83.0",
+    "@flue/vite": "2.0.3",
+    "@types/node": "22.18.13",
+    "@types/react": "19.2.14",
+    "@types/react-dom": "19.2.3",
+    "@typescript/native-preview": "7.0.0-dev.20260511.1",
+    "oxlint": "1.63.0",
+    "oxlint-tsgolint": "0.22.1",
+    "vite": "8.1.0",
+    "vitest": "4.1.10"
+  }
+}
diff --git a/apps/brunch-agent/petrinaut-local.vite.config.ts b/apps/brunch-agent/petrinaut-local.vite.config.ts
new file mode 100644
index 00000000000..249686c8498
--- /dev/null
+++ b/apps/brunch-agent/petrinaut-local.vite.config.ts
@@ -0,0 +1,72 @@
+/**
+ * Local FE-1436 panel launcher.
+ *
+ * Loads the real hash Petrinaut website config, removes only its incumbent
+ * `/api/chat` dev handler, and sends that same-origin route to brunch's
+ * committed application server. The real panel, wrappers, and editor stay untouched;
+ * hash's tracked checkout stays clean.
+ */
+
+import { join, resolve } from "node:path";
+
+import {
+  defineConfig,
+  loadConfigFromFile,
+  mergeConfig,
+  type PluginOption,
+} from "vite";
+
+import {
+  defaultChatOrigin,
+  petrinautLocalServer,
+} from "./src/local-dev-origins.ts";
+
+const withoutIncumbentChatHandler = (
+  plugins: readonly PluginOption[],
+): PluginOption[] =>
+  plugins.filter((plugin) => {
+    if (
+      plugin === false ||
+      plugin === null ||
+      plugin === undefined ||
+      Array.isArray(plugin) ||
+      typeof plugin !== "object" ||
+      !("name" in plugin)
+    ) {
+      return true;
+    }
+    return plugin.name !== "petrinaut-api-dev";
+  });
+
+export default defineConfig(async (environment) => {
+  const websiteRoot = process.env.PETRINAUT_WEBSITE_ROOT;
+  if (!websiteRoot) {
+    throw new Error(
+      "PETRINAUT_WEBSITE_ROOT must point at hash/apps/petrinaut-website for the real-panel run.",
+    );
+  }
+  const root = resolve(websiteRoot);
+  // Babel resolves the React compiler plugin from the launched project's cwd,
+  // not from the imported config file. Match a native hash launch before the
+  // plugin begins transforming the real panel source.
+  process.chdir(root);
+  const loaded = await loadConfigFromFile(
+    environment,
+    join(root, "vite.config.ts"),
+    root,
+  );
+  if (!loaded)
+    throw new Error(`Could not load Petrinaut's Vite config from ${root}.`);
+
+  const chatOrigin = process.env.BRUNCH_CHAT_ORIGIN ?? defaultChatOrigin;
+  return mergeConfig(
+    {
+      ...loaded.config,
+      plugins: withoutIncumbentChatHandler(loaded.config.plugins ?? []),
+    },
+    {
+      root,
+      server: petrinautLocalServer(chatOrigin),
+    },
+  );
+});
diff --git a/apps/brunch-agent/src/agents/gherkin-elicitor.ts b/apps/brunch-agent/src/agents/gherkin-elicitor.ts
new file mode 100644
index 00000000000..a6bbc6d387d
--- /dev/null
+++ b/apps/brunch-agent/src/agents/gherkin-elicitor.ts
@@ -0,0 +1,73 @@
+"use agent";
+/**
+ * The gherkin elicitor (spec §12.5: one agent per target).
+ *
+ * Named as a noun — the thing, not the act — and read target-first, so the
+ * family sorts together as targets multiply: `gherkin-elicitor`,
+ * `assurance-elicitor`.
+ *
+ * The product is the harness library in a thin host-authored agent — Flue's
+ * build-time scan makes the alternative structurally unavailable, since a
+ * library cannot ship a pre-registered agent (spec §12.1). So this module is
+ * deliberately thin: it mounts harness capability and holds no elicitation
+ * semantics of its own.
+ *
+ * Three recorded Flue constraints are honoured here by construction (spec §10):
+ * the `'use agent'` directive is the file's first statement; `agentName` is a
+ * pinned string literal, because conversation storage keys on it; and the tool
+ * set is static, because prompt-cache economics forbid per-question tool
+ * swapping.
+ */
+
+import { useInitialData, useModel, type AgentProps } from "@flue/runtime";
+import * as v from "valibot";
+
+import { useElicitation } from "@hashintel/brunch-agent-binding-flue";
+import { gherkin } from "@hashintel/brunch-agent-plugin-gherkin";
+
+import { createGherkinElicitationSession } from "../elicitation-session.ts";
+
+/**
+ * One definition for the agent and the faux provider alike: the two must name
+ * the same model id, and drift fails at resolution only if both sides resolve
+ * the same string (Flue patterns audit, 2026-08-17).
+ */
+export const GHERKIN_MODEL_ID = "claude-haiku-4-5";
+
+export function GherkinElicitor(props: AgentProps) {
+  useModel(`anthropic/${GHERKIN_MODEL_ID}`);
+  const initialData = useInitialData<{ targetDocumentId: string }>();
+  return useElicitation(
+    gherkin,
+    createGherkinElicitationSession(props.id, initialData.targetDocumentId),
+  );
+}
+
+/**
+ * Pinned, and never to be edited: conversation storage keys on this literal,
+ * so changing it orphans every existing conversation. Flue requires a string
+ * literal here because build targets derive durable identifiers from it before
+ * any user code runs.
+ *
+ * Product-prefixed on purpose, and this is the one place the prefix is not
+ * cosmetic. Agent identities are global per application, and the September
+ * demo shell is chartered to mount this library alongside the Petrinaut
+ * libraries — a bare `gherkin-elicitor` could collide with another library's
+ * agent, and the collision would land on durable conversation storage.
+ *
+ * The exported symbol stays the shorter `GherkinElicitor` because it reads
+ * better at the mount site; `agentName` exists precisely to let durable
+ * identity and source-level name differ.
+ */
+GherkinElicitor.agentName = "brunch-gherkin-elicitor";
+
+/**
+ * Session→document binding (spec §9.1, adjudication L4): a new session's
+ * `initialData` carries the target-document id, validated once at creation and
+ * immutable thereafter — Flue's own lane for a target descriptor. Dispatching
+ * to an existing conversation id resumes that session against the current state
+ * of its target-document.
+ */
+GherkinElicitor.initialData = v.object({
+  targetDocumentId: v.pipe(v.string(), v.nonEmpty()),
+});
diff --git a/apps/brunch-agent/src/app.ts b/apps/brunch-agent/src/app.ts
new file mode 100644
index 00000000000..6ce50876433
--- /dev/null
+++ b/apps/brunch-agent/src/app.ts
@@ -0,0 +1,57 @@
+/**
+ * The dev app's route map — the "mount" half of the thin host (spec §12.1).
+ *
+ * The dev app is chartered with three roles, none of them "the product"
+ * (spec §12.5): the local dev loop against every plugin, the colleague-facing
+ * target-gallery demo, and the diagnostic probe surface. Milestone one keeps
+ * affordance renderers here rather than in a ui package.
+ */
+
+import { readFile } from "node:fs/promises";
+
+import { createAgentRouter } from "@flue/runtime/routing";
+import { Hono } from "hono";
+
+import { GherkinElicitor } from "./agents/gherkin-elicitor.ts";
+import { assetHandler } from "./assets.ts";
+import { petrinautChatHandler } from "./petrinaut-chat.ts";
+import { GHERKIN_AGENT_ROUTE, PETRINAUT_CHAT_ROUTE } from "./routes.ts";
+
+const app = new Hono();
+
+// One route per target agent. The gallery grows an entry per plugin; gherkin
+// is the tracer that wires end-to-end first (spec §13). The browser and mount
+// share the route constant; Flue still keys storage on the agent's independent,
+// pinned identity.
+app.route(`/agents/${GHERKIN_AGENT_ROUTE}`, createAgentRouter(GherkinElicitor));
+
+// The application owns the HTTP mount; transport-aisdk owns only request validation
+// and AI SDK stream encoding. No parallel conversation renderer is introduced.
+app.on(["POST", "OPTIONS"], PETRINAUT_CHAT_ROUTE, (c) =>
+  petrinautChatHandler(c.req.raw),
+);
+
+// The flue dev controller owns the whole request space — no fall-through to
+// vite's html serving — so the ui is app-served, in dev and in production
+// alike (spec §10, recorded facts).
+//
+// Two different files, because two different builds produce them: in dev, the
+// source `index.html` whose script tag vite resolves live; in production, the
+// client build's emitted `index.html`, whose script tag points at a real
+// bundled asset. `@flue/vite` emits the server environment only, so that
+// client build is a second, plain vite build — without it the ui tree would
+// have no build coverage at all.
+const uiRoot = new URL(
+  import.meta.env?.DEV === false ? "./client/" : "../",
+  import.meta.url,
+);
+
+app.get("/", async (c) =>
+  c.html(await readFile(new URL("index.html", uiRoot), "utf8")),
+);
+
+// Production only: in dev, vite serves the module graph under /src. A
+// wildcard, not `:file` — bundlers may emit nested asset paths.
+app.get("/assets/*", assetHandler(uiRoot));
+
+export default app;
diff --git a/apps/brunch-agent/src/assets.ts b/apps/brunch-agent/src/assets.ts
new file mode 100644
index 00000000000..044eb140c32
--- /dev/null
+++ b/apps/brunch-agent/src/assets.ts
@@ -0,0 +1,106 @@
+/**
+ * Production asset serving — everything the client build emits, not an
+ * extension allowlist and not a filename grammar.
+ *
+ * The FE-1361 review verified the failure the old inline route carried: it
+ * allowlisted `js|css|map` and read hits as UTF-8, so the first font or image
+ * the client build emitted would 404 in production while vite dev served it
+ * fine — and widening the allowlist without dropping the UTF-8 read would
+ * have corrupted binary bytes instead. So: any safe file name serves, read as
+ * bytes; the content-type comes from hono's own MIME table and fails open to
+ * `application/octet-stream` rather than failing the asset.
+ *
+ * What counts as safe is a property of the path, not a pattern the emitted
+ * names are assumed to follow. `[name]` in a bundler's `assetFileNames` is the
+ * source basename, so spaces, parentheses, accents, `+`, `,`, `'`, `#` and `?`
+ * are all legal output, and a grammar narrower than the producer's is a
+ * production-only 404 waiting for the first asset that uses one.
+ *
+ * Mounted as a wildcard (`/assets/*`) rather than `:file`, because a `:file`
+ * param cannot match the nested paths bundlers emit (`assets/fonts/x.woff2`).
+ */
+
+import { readFile } from "node:fs/promises";
+
+import { getMimeType } from "hono/utils/mime";
+
+import type { Context } from "hono";
+
+/**
+ * Read failures that mean "no file at this path, and none can be": absent,
+ * reached through a file, a directory rather than a file, or too long to name
+ * one. Every other failure — a permission problem, a symlink cycle, an I/O
+ * error — is a fault to surface, because a 404 would report a broken build tree
+ * as an asset that was simply never emitted.
+ */
+const ABSENT_PATH_CODES = new Set([
+  "ENOENT",
+  "ENOTDIR",
+  "EISDIR",
+  "ENAMETOOLONG",
+]);
+
+const isAbsentPath = (error: unknown): boolean =>
+  error instanceof Error &&
+  "code" in error &&
+  ABSENT_PATH_CODES.has((error as NodeJS.ErrnoException).code ?? "");
+
+/**
+ * Whether a decoded path is safe to look up under the asset root: at least one
+ * segment, none empty, none dot-led — which is what keeps `..` traversal and
+ * hidden files out — no nul byte, which `readFile` rejects with a `TypeError`
+ * rather than an errno, and an extension on the last segment.
+ */
+const isSafeAssetPath = (file: string): boolean => {
+  if (file.includes("\0")) return false;
+  const segments = file.split("/");
+  return (
+    segments.every(
+      (segment) => segment.length > 0 && !segment.startsWith("."),
+    ) && /\.[^./]+$/.test(segments.at(-1) ?? "")
+  );
+};
+
+/** Serve `assets/*` from the client build rooted at `uiRoot`. */
+export function assetHandler(uiRoot: URL): (c: Context) => Promise<Response> {
+  return async (c) => {
+    // The raw wildcard remainder, decoded here because hono decodes params
+    // but not the path — an undecodable escape is a 404, not a crash.
+    let file: string;
+    try {
+      file = decodeURIComponent(c.req.path.replace(/^\/assets\//, ""));
+    } catch (error) {
+      if (error instanceof URIError) return c.notFound();
+      throw error;
+    }
+    if (!isSafeAssetPath(file)) return c.notFound();
+    // Re-encoded segment by segment on the way into the URL: to the URL parser
+    // `#` opens a fragment and `?` a query, and under the file: scheme a
+    // backslash is a path separator, so a name carrying any of them addresses
+    // some other file — `..\` addresses one outside the asset root entirely.
+    const path = new URL(
+      `assets/${file
+        .split("/")
+        .map((segment) => encodeURIComponent(segment))
+        .join("/")}`,
+      uiRoot,
+    );
+    // Served as read, with no intermediate copy. The cast is a type gap, not a
+    // conversion: `readFile` is typed to admit a SharedArrayBuffer-backed view,
+    // which hono's body type excludes, while the value it returns always owns
+    // its own ArrayBuffer.
+    let bytes: Uint8Array<ArrayBuffer>;
+    try {
+      bytes = (await readFile(path)) as Uint8Array<ArrayBuffer>;
+    } catch (error) {
+      if (isAbsentPath(error)) return c.notFound();
+      throw error;
+    }
+    // Fail open on the content-type, never on the bytes: an extension the
+    // table does not know degrades to a pickier content-type, not to a
+    // production-only 404.
+    return c.body(bytes, 200, {
+      "content-type": getMimeType(file) ?? "application/octet-stream",
+    });
+  };
+}
diff --git a/apps/brunch-agent/src/db-path.ts b/apps/brunch-agent/src/db-path.ts
new file mode 100644
index 00000000000..faaec3fcec7
--- /dev/null
+++ b/apps/brunch-agent/src/db-path.ts
@@ -0,0 +1,27 @@
+/**
+ * Where the conversation store lives, resolved before the adapter opens it.
+ *
+ * Anchored to this module's location — the way `app.ts` anchors `uiRoot` —
+ * never to the launch directory: a cwd-relative default silently creates a
+ * fresh empty database when the app is launched from anywhere else, which is
+ * the exact restart-durability failure `db.ts` exists to prevent. From `src/`
+ * and from the emitted `dist/` bundle alike, `../.data-wipe-me/` resolves to
+ * the package directory.
+ *
+ * Kept apart from `db.ts` so path policy stays importable without loading the
+ * Flue Node runtime and SQLite adapter.
+ */
+
+import { fileURLToPath } from "node:url";
+
+export function conversationDbPath(): string {
+  // Truthiness, not nullish, on purpose: a set-but-empty override would pass
+  // '' through to sqlite(), which opens an anonymous temporary database
+  // deleted on close — silently non-durable again.
+  const override = process.env.BRUNCH_DEV_DB_PATH;
+  return override
+    ? override
+    : fileURLToPath(
+        new URL("../.data-wipe-me/conversations.db", import.meta.url),
+      );
+}
diff --git a/apps/brunch-agent/src/db.ts b/apps/brunch-agent/src/db.ts
new file mode 100644
index 00000000000..a63b9680437
--- /dev/null
+++ b/apps/brunch-agent/src/db.ts
@@ -0,0 +1,19 @@
+/**
+ * The substrate's conversation storage — host-authored because Flue requires
+ * it of the consuming app (spec §9.6, adjudication C1).
+ *
+ * Not to be confused with the capture store: that is the harness's storage
+ * port, harness-defined and implemented in `@hashintel/brunch-agent-binding-flue`, and plugins are
+ * blind to both. This file holds only the live transport copy of conversations.
+ * The provenance record is the target-document's own session-log archive.
+ *
+ * Without this file conversations are process-memory and a restart loses them
+ * (recorded Flue fact, spec §10). Restart durability of the full stack is an
+ * open verification item (spec §14.5) that this file exists to make testable.
+ */
+
+import { sqlite } from "@flue/runtime/node";
+
+import { conversationDbPath } from "./db-path.ts";
+
+export default sqlite(conversationDbPath());
diff --git a/apps/brunch-agent/src/elicitation-session.ts b/apps/brunch-agent/src/elicitation-session.ts
new file mode 100644
index 00000000000..ae7a9753668
--- /dev/null
+++ b/apps/brunch-agent/src/elicitation-session.ts
@@ -0,0 +1,34 @@
+/** Host-owned wiring for the local Flue binding's history transport and store. */
+
+import {
+  createFlueHistoryReader,
+  createLocalCaptureStore,
+  type ElicitationSession,
+} from "@hashintel/brunch-agent-binding-flue";
+
+import { GHERKIN_AGENT_ROUTE } from "./routes.ts";
+import { targetDocumentPath } from "./target-document-path.ts";
+
+const appTransport = (async (input: RequestInfo | URL, init?: RequestInit) => {
+  const { default: app } = await import("./app.ts");
+  return app.fetch(input instanceof Request ? input : new Request(input, init));
+}) as typeof fetch;
+
+export const createGherkinElicitationSession = (
+  sessionId: string,
+  targetDocumentId: string,
+): ElicitationSession => {
+  const captureStore = createLocalCaptureStore(
+    targetDocumentPath(targetDocumentId),
+  );
+  return {
+    sessionId,
+    captureStore,
+    historyReader: createFlueHistoryReader({
+      resolveConversationUrl: (id) =>
+        `http://brunch.local/agents/${GHERKIN_AGENT_ROUTE}/${id}`,
+      transport: appTransport,
+      archive: captureStore,
+    }),
+  };
+};
diff --git a/apps/brunch-agent/src/local-dev-origins.ts b/apps/brunch-agent/src/local-dev-origins.ts
new file mode 100644
index 00000000000..797fc52b346
--- /dev/null
+++ b/apps/brunch-agent/src/local-dev-origins.ts
@@ -0,0 +1,30 @@
+/** Listen addresses the local Brunch↔Petrinaut pair must emit and assume. */
+
+export const localChatListen = {
+  host: "127.0.0.1",
+  port: 4321,
+  strictPort: true,
+} as const;
+
+export const localPanelListen = {
+  host: "127.0.0.1",
+  port: 4915,
+  strictPort: true,
+} as const;
+
+export const defaultChatOrigin = `http://${localChatListen.host}:${localChatListen.port}`;
+
+export const defaultPanelOrigins = [
+  `http://${localPanelListen.host}:${localPanelListen.port}`,
+  `http://localhost:${localPanelListen.port}`,
+] as const;
+
+export const petrinautLocalServer = (chatOrigin: string) => ({
+  ...localPanelListen,
+  proxy: {
+    "/api/chat": {
+      target: chatOrigin,
+      changeOrigin: true,
+    },
+  },
+});
diff --git a/apps/brunch-agent/src/petrinaut-chat.ts b/apps/brunch-agent/src/petrinaut-chat.ts
new file mode 100644
index 00000000000..9480653f56d
--- /dev/null
+++ b/apps/brunch-agent/src/petrinaut-chat.ts
@@ -0,0 +1,94 @@
+/** Application composition for Petrinaut's stock AI SDK chat transport. */
+
+import { init } from "@flue/runtime";
+
+import {
+  decideAskReplyAdmission,
+  pendingAskAffordanceId,
+} from "@hashintel/brunch-agent";
+import {
+  createFlueReplyProjector,
+  projectFlueHistoryForSweep,
+} from "@hashintel/brunch-agent-binding-flue";
+import {
+  createAiSdkChatHandler,
+  type HarnessReplyEvent,
+  type TransportInspectionEvent,
+} from "@hashintel/brunch-agent-transport-aisdk";
+
+import { GherkinElicitor } from "./agents/gherkin-elicitor.ts";
+import { createGherkinElicitationSession } from "./elicitation-session.ts";
+import { defaultPanelOrigins } from "./local-dev-origins.ts";
+
+const inspect =
+  process.env.BRUNCH_TRANSPORT_AISDK_INSPECT === "1"
+    ? (event: TransportInspectionEvent): void => {
+        // This is an opt-in shell diagnostic stream. It is never dispatched
+        // into Flue and therefore cannot become elicitation evidence.
+        console.log(`TRANSPORT_AISDK ${JSON.stringify(event)}`);
+      }
+    : undefined;
+
+// FE-1439 replaces this local one-conversation/one-document identity
+// with principal-owned private session lookup. Keep it opaque here.
+const targetDocumentIdFor = (conversationId: string): string =>
+  `petrinaut-local:${conversationId}`;
+
+const streamElicitorTurn = async (
+  conversationId: string,
+  dispatch: { readonly message: string; readonly idempotencyKey: string },
+  emit: (event: HarnessReplyEvent) => void,
+): Promise<void> => {
+  const agent = init(GherkinElicitor, { id: conversationId });
+  const receipt = await agent.dispatch({
+    ...dispatch,
+    initialData: { targetDocumentId: targetDocumentIdFor(conversationId) },
+  });
+  const projector = createFlueReplyProjector({
+    submissionId: receipt.submissionId,
+    emit,
+  });
+  await agent.read(receipt, { onEvent: (chunk) => projector.accept(chunk) });
+};
+
+export const petrinautChatHandler = createAiSdkChatHandler({
+  allowedOrigins: (
+    process.env.BRUNCH_PETRINAUT_ORIGINS ?? defaultPanelOrigins.join(",")
+  )
+    .split(",")
+    .map((origin) => origin.trim())
+    .filter((origin) => origin.length > 0),
+  inspect,
+  runTurn: (input, emit) =>
+    streamElicitorTurn(
+      input.conversationId,
+      { message: input.userMessage.text, idempotencyKey: input.idempotencyKey },
+      emit,
+    ),
+  askReply: {
+    // Admission consults durable Flue history, not request-shaped claims: the
+    // submission resumes the conversation only when its tool-call id
+    // correlates with the one ask still awaiting a reply.
+    async admit(input) {
+      const session = createGherkinElicitationSession(
+        input.conversationId,
+        targetDocumentIdFor(input.conversationId),
+      );
+      const entries = projectFlueHistoryForSweep(
+        await session.historyReader.peek(input.conversationId),
+      );
+      return decideAskReplyAdmission(
+        pendingAskAffordanceId(entries),
+        input.ask.toolCallId,
+      );
+    },
+    // The admitted answer is a fresh user dispatch (spec §7.4); the binding
+    // binds it to the pending affordance, making it the user-affordance reply.
+    run: (input, emit) =>
+      streamElicitorTurn(
+        input.conversationId,
+        { message: input.ask.answer, idempotencyKey: input.idempotencyKey },
+        emit,
+      ),
+  },
+});
diff --git a/apps/brunch-agent/src/routes.ts b/apps/brunch-agent/src/routes.ts
new file mode 100644
index 00000000000..739c6323023
--- /dev/null
+++ b/apps/brunch-agent/src/routes.ts
@@ -0,0 +1,5 @@
+/** Browser-facing route segment; conversation identity remains the agent's pinned `agentName`. */
+export const GHERKIN_AGENT_ROUTE = "gherkin";
+
+/** Stock `DefaultChatTransport` endpoint used by Petrinaut's local panel. */
+export const PETRINAUT_CHAT_ROUTE = "/api/chat";
diff --git a/apps/brunch-agent/src/target-document-path.ts b/apps/brunch-agent/src/target-document-path.ts
new file mode 100644
index 00000000000..a2939f7ee7b
--- /dev/null
+++ b/apps/brunch-agent/src/target-document-path.ts
@@ -0,0 +1,17 @@
+/** Resolve one target-document's local binding store without trusting its id as a path. */
+
+import { createHash } from "node:crypto";
+import { join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const defaultDirectory = (): string =>
+  fileURLToPath(new URL("../.data-wipe-me/target-documents/", import.meta.url));
+
+export function targetDocumentPath(targetDocumentId: string): string {
+  if (targetDocumentId.length === 0)
+    throw new TypeError("A target-document id cannot be empty.");
+  const directory =
+    process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR || defaultDirectory();
+  const identity = createHash("sha256").update(targetDocumentId).digest("hex");
+  return join(directory, `${identity}.json`);
+}
diff --git a/apps/brunch-agent/src/ui/chat.tsx b/apps/brunch-agent/src/ui/chat.tsx
new file mode 100644
index 00000000000..ea9d6dd2f59
--- /dev/null
+++ b/apps/brunch-agent/src/ui/chat.tsx
@@ -0,0 +1,143 @@
+import { useFlueAgent } from "@flue/react";
+import { createFlueClient, type FlueConversationMessage } from "@flue/sdk";
+import { useEffect, useMemo, useRef, useState, type FormEvent } from "react";
+import * as v from "valibot";
+
+import { FreeTextAffordance } from "@hashintel/brunch-agent";
+
+import { GHERKIN_AGENT_ROUTE } from "../routes.ts";
+
+const conversationId = crypto.randomUUID();
+
+function VisibleMessage({ message }: { message: FlueConversationMessage }) {
+  if (
+    message.display !== "visible" ||
+    (message.purpose !== "user" && message.purpose !== "assistant")
+  ) {
+    return null;
+  }
+
+  return (
+    <article className={`message message--${message.role}`}>
+      <p className="message__role">
+        {message.role === "user" ? "You" : "Interviewer"}
+      </p>
+      {message.parts.map((part, index) => {
+        if (part.type === "text") {
+          return (
+            <p className="message__text" key={index}>
+              {part.text}
+            </p>
+          );
+        }
+        if (part.type === "data-affordance") {
+          const affordance = v.safeParse(FreeTextAffordance, part.data);
+          if (!affordance.success) return null;
+          return (
+            <section className="question" key={affordance.output.id}>
+              <span className="question__index">Question</span>
+              <p className="question__markdown">{affordance.output.markdown}</p>
+              <span className="question__hint">
+                Reply in your own words below.
+              </span>
+            </section>
+          );
+        }
+        return null;
+      })}
+    </article>
+  );
+}
+
+export function Chat() {
+  const [input, setInput] = useState("");
+  const [bootstrapping, setBootstrapping] = useState(true);
+  const [startupError, setStartupError] = useState<string>();
+  const started = useRef(false);
+  const client = useMemo(
+    () =>
+      createFlueClient({
+        url: `/agents/${GHERKIN_AGENT_ROUTE}/${conversationId}`,
+      }),
+    [],
+  );
+  const agent = useFlueAgent({ client });
+
+  useEffect(() => {
+    if (!agent.historyReady || agent.messages.length > 0 || started.current)
+      return;
+    started.current = true;
+
+    void (async () => {
+      try {
+        const admission = await client.send({
+          message: { kind: "user", body: "Begin the interview." },
+          initialData: { targetDocumentId: `dev-${conversationId}` },
+        });
+        await client.wait(admission);
+        agent.refresh();
+      } catch (error: unknown) {
+        setStartupError(
+          error instanceof Error
+            ? error.message
+            : "The interview could not start.",
+        );
+      } finally {
+        setBootstrapping(false);
+      }
+    })();
+  }, [agent, client]);
+
+  const busy =
+    bootstrapping ||
+    agent.status === "connecting" ||
+    agent.status === "submitted" ||
+    agent.status === "streaming";
+
+  function submit(event: FormEvent<HTMLFormElement>): void {
+    event.preventDefault();
+    const reply = input.trim();
+    if (!reply || busy) return;
+    setInput("");
+    void agent.sendMessage(reply);
+  }
+
+  return (
+    <main className="shell">
+      <header className="masthead">
+        <div>
+          <p className="eyebrow">Brunch / elicitation field notes</p>
+          <h1>Tell me how it should behave.</h1>
+        </div>
+        <span className={`status status--${agent.status}`}>{agent.status}</span>
+      </header>
+
+      <section className="transcript" aria-live="polite" aria-busy={busy}>
+        {agent.messages.map((message) => (
+          <VisibleMessage key={message.id} message={message} />
+        ))}
+        {agent.messages.length === 0 && !startupError ? (
+          <p className="opening">Opening a fresh interview…</p>
+        ) : null}
+        {startupError ? <p className="error">{startupError}</p> : null}
+        {agent.error ? <p className="error">{agent.error.message}</p> : null}
+      </section>
+
+      <form className="composer" onSubmit={submit}>
+        <label htmlFor="reply">Your reply</label>
+        <div className="composer__row">
+          <textarea
+            id="reply"
+            value={input}
+            onChange={(event) => setInput(event.target.value)}
+            placeholder="Write what you know; uncertainty is useful too."
+            rows={3}
+          />
+          <button type="submit" disabled={busy || input.trim().length === 0}>
+            Send
+          </button>
+        </div>
+      </form>
+    </main>
+  );
+}
diff --git a/apps/brunch-agent/src/ui/main.tsx b/apps/brunch-agent/src/ui/main.tsx
new file mode 100644
index 00000000000..53d51ea6552
--- /dev/null
+++ b/apps/brunch-agent/src/ui/main.tsx
@@ -0,0 +1,22 @@
+/**
+ * The dev app's ui entry.
+ *
+ * The ui shell renders parts and transports replies; it owns no elicitation
+ * semantics (spec §4). A dedicated ui-affordance package is named and deferred
+ * — milestone one keeps renderers here (spec §12.5).
+ *
+ * The chat surface itself lands with the walking skeleton. Note what does and
+ * does not cover this file: `@flue/vite` builds the server environment only,
+ * so `vite build` never transforms it — `tsc` and `vite dev` are its whole
+ * safety net until a client build exists.
+ */
+
+import { createRoot } from "react-dom/client";
+
+import { Chat } from "./chat.tsx";
+import "./styles.css";
+
+const container = document.getElementById("root");
+if (!container) throw new Error("index.html is missing its #root container");
+
+createRoot(container).render(<Chat />);
diff --git a/apps/brunch-agent/src/ui/styles.css b/apps/brunch-agent/src/ui/styles.css
new file mode 100644
index 00000000000..8de4856c387
--- /dev/null
+++ b/apps/brunch-agent/src/ui/styles.css
@@ -0,0 +1,251 @@
+:root {
+  color: #29271f;
+  background: #eee9dc;
+  font-family: Georgia, "Times New Roman", serif;
+  font-synthesis: none;
+}
+
+* {
+  box-sizing: border-box;
+}
+
+body {
+  margin: 0;
+  min-width: 320px;
+  min-height: 100vh;
+  background:
+    linear-gradient(rgb(77 70 49 / 7%) 1px, transparent 1px) 0 7.5rem / 100%
+      1.75rem,
+    #eee9dc;
+}
+
+button,
+textarea {
+  font: inherit;
+}
+
+.shell {
+  width: min(52rem, calc(100% - 2rem));
+  min-height: 100vh;
+  margin: 0 auto;
+  padding: 3.5rem 0 2rem;
+}
+
+.masthead {
+  display: flex;
+  align-items: start;
+  justify-content: space-between;
+  gap: 2rem;
+  padding-bottom: 1.5rem;
+  border-bottom: 2px solid #29271f;
+}
+
+.eyebrow,
+.message__role,
+.question__index,
+.question__hint,
+.status,
+.composer label {
+  font-family: ui-monospace, "SFMono-Regular", Menlo, monospace;
+  font-size: 0.72rem;
+  letter-spacing: 0.09em;
+  text-transform: uppercase;
+}
+
+.eyebrow {
+  margin: 0 0 0.65rem;
+  color: #766e56;
+}
+
+h1 {
+  max-width: 11ch;
+  margin: 0;
+  font-size: clamp(2.5rem, 7vw, 5rem);
+  font-weight: 400;
+  line-height: 0.93;
+  letter-spacing: -0.045em;
+}
+
+.status {
+  display: inline-flex;
+  align-items: center;
+  gap: 0.45rem;
+  margin-top: 0.35rem;
+  color: #766e56;
+}
+
+.status::before {
+  width: 0.55rem;
+  height: 0.55rem;
+  border-radius: 50%;
+  background: #ba5a36;
+  content: "";
+}
+
+.status--streaming::before,
+.status--submitted::before {
+  animation: pulse 1.2s ease-in-out infinite;
+}
+
+.status--idle::before {
+  background: #607557;
+}
+
+.transcript {
+  display: grid;
+  gap: 1.25rem;
+  padding: 2rem 0 12rem;
+}
+
+.message {
+  max-width: 86%;
+}
+
+.message--user {
+  justify-self: end;
+  padding-left: 2rem;
+  text-align: right;
+}
+
+.message__role {
+  margin: 0 0 0.4rem;
+  color: #766e56;
+}
+
+.message__text {
+  margin: 0;
+  font-size: 1.05rem;
+  line-height: 1.55;
+  white-space: pre-wrap;
+}
+
+.question {
+  position: relative;
+  padding: 1.4rem 1.5rem 1.2rem;
+  border: 1px solid #29271f;
+  background: #f7f3e9;
+  box-shadow: 0.45rem 0.45rem 0 #c8bfa7;
+}
+
+.question__index {
+  color: #ba5a36;
+}
+
+.question__markdown {
+  margin: 1rem 0 1.4rem;
+  font-size: clamp(1.5rem, 4vw, 2.25rem);
+  line-height: 1.08;
+  white-space: pre-wrap;
+}
+
+.question__hint {
+  color: #766e56;
+  text-transform: none;
+}
+
+.opening,
+.error {
+  color: #766e56;
+  font-style: italic;
+}
+
+.error {
+  color: #9c3f28;
+}
+
+.composer {
+  position: fixed;
+  bottom: 0;
+  left: 50%;
+  z-index: 1;
+  width: min(54rem, 100%);
+  padding: 1rem;
+  border-top: 1px solid #29271f;
+  background: rgb(238 233 220 / 96%);
+  transform: translateX(-50%);
+  backdrop-filter: blur(8px);
+}
+
+.composer label {
+  display: block;
+  margin-bottom: 0.5rem;
+}
+
+.composer__row {
+  display: grid;
+  grid-template-columns: 1fr auto;
+  gap: 0.75rem;
+}
+
+textarea {
+  width: 100%;
+  resize: vertical;
+  padding: 0.85rem 1rem;
+  border: 1px solid #29271f;
+  border-radius: 0;
+  outline: none;
+  color: inherit;
+  background: #f7f3e9;
+  line-height: 1.4;
+}
+
+textarea:focus {
+  box-shadow: 0 0 0 3px #ba5a36;
+}
+
+button {
+  align-self: stretch;
+  min-width: 6rem;
+  border: 1px solid #29271f;
+  color: #f7f3e9;
+  background: #29271f;
+  cursor: pointer;
+}
+
+button:hover:not(:disabled) {
+  background: #ba5a36;
+}
+
+button:focus-visible {
+  outline: 3px solid #ba5a36;
+  outline-offset: 3px;
+}
+
+button:disabled {
+  cursor: not-allowed;
+  opacity: 0.45;
+}
+
+@keyframes pulse {
+  50% {
+    opacity: 0.25;
+  }
+}
+
+@media (max-width: 36rem) {
+  .shell {
+    padding-top: 2rem;
+  }
+
+  .masthead {
+    display: grid;
+  }
+
+  .message {
+    max-width: 100%;
+  }
+
+  .composer__row {
+    grid-template-columns: 1fr;
+  }
+
+  button {
+    min-height: 2.75rem;
+  }
+}
+
+@media (prefers-reduced-motion: reduce) {
+  .status::before {
+    animation: none;
+  }
+}
diff --git a/apps/brunch-agent/test/assets.test.ts b/apps/brunch-agent/test/assets.test.ts
new file mode 100644
index 00000000000..33b92ccedfe
--- /dev/null
+++ b/apps/brunch-agent/test/assets.test.ts
@@ -0,0 +1,204 @@
+/**
+ * The production asset route, driven as a real Hono route over a real
+ * directory. In dev, vite serves the module graph and this route is never
+ * hit — so nothing else exercises it, and a gap here is production-only
+ * by construction (the FE-1361 review's verified finding: the old
+ * js|css|map allowlist 404'd the first font or image the client build
+ * emitted, and its UTF-8 read would have corrupted the bytes had the
+ * allowlist merely grown).
+ *
+ * Tested against the handler module rather than the emitted server bundle so
+ * this contract remains isolated from the Flue Node runtime and SQLite.
+ */
+
+import {
+  mkdirSync,
+  mkdtempSync,
+  rmSync,
+  symlinkSync,
+  writeFileSync,
+} from "node:fs";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+import { pathToFileURL } from "node:url";
+
+import { Hono } from "hono";
+import { afterAll, describe, expect, test } from "vitest";
+
+import { assetHandler } from "../src/assets";
+
+const uiRoot = mkdtempSync(join(tmpdir(), "brunch-assets-"));
+const BINARY_BYTES = Uint8Array.from({ length: 256 }, (_, i) => i);
+
+/**
+ * Names a bundler can legally emit, because `[name]` in `assetFileNames` is the
+ * source basename and neither vite nor rollup reduces it to `[\w.-]`. Each file
+ * holds its own name as its body, so serving the wrong file is a failure rather
+ * than a coincidental pass.
+ */
+const PRODUCER_PUNCTUATION = [
+  "logo (1).png",
+  "café.woff2",
+  "a+b,c'd.js",
+  "x#y.js",
+  "q?z.js",
+  "@scope~thing.js",
+] as const;
+
+mkdirSync(join(uiRoot, "assets/fonts"), { recursive: true });
+// A directory whose name looks like an asset: reading it is EISDIR, which is an
+// expected absence rather than a fault.
+mkdirSync(join(uiRoot, "assets/legacy.js"), { recursive: true });
+writeFileSync(join(uiRoot, "assets/index.js"), "export {};\n");
+writeFileSync(join(uiRoot, "assets/index.css"), "body {}\n");
+writeFileSync(join(uiRoot, "assets/brand.woff2"), BINARY_BYTES);
+writeFileSync(join(uiRoot, "assets/Logo.PNG"), BINARY_BYTES);
+writeFileSync(join(uiRoot, "assets/blob.dat"), BINARY_BYTES);
+writeFileSync(join(uiRoot, "assets/fonts/nested.woff2"), BINARY_BYTES);
+for (const name of PRODUCER_PUNCTUATION)
+  writeFileSync(join(uiRoot, `assets/${name}`), name);
+// Outside `assets/`, so a traversal that escapes has something to find: a 404
+// on a path that leads nowhere proves nothing about refusal.
+writeFileSync(join(uiRoot, "secret.js"), "SECRET\n");
+// A symlink to itself: reading it is ELOOP, a broken tree rather than a missing
+// file, and nothing about it should read as "this asset was never emitted".
+symlinkSync("loop.js", join(uiRoot, "assets/loop.js"));
+
+afterAll(() => rmSync(uiRoot, { recursive: true, force: true }));
+
+const app = new Hono();
+app.get("/assets/*", assetHandler(pathToFileURL(`${uiRoot}/`)));
+
+describe("the production asset route", () => {
+  test("serves the build outputs with their types", async () => {
+    for (const [file, type] of [
+      ["index.js", "text/javascript; charset=utf-8"],
+      ["index.css", "text/css; charset=utf-8"],
+    ] as const) {
+      const response = await app.request(`/assets/${file}`);
+      expect({
+        file,
+        status: response.status,
+        type: response.headers.get("content-type"),
+      }).toEqual({ file, status: 200, type });
+    }
+  });
+
+  test("serves a nested asset path", async () => {
+    // Bundlers emit nested paths (assets/fonts/…); the old `:file` param
+    // could never match one, so nesting was a production-only 404.
+    const response = await app.request("/assets/fonts/nested.woff2");
+    expect(response.status).toBe(200);
+    expect(response.headers.get("content-type")).toBe("font/woff2");
+    expect(new Uint8Array(await response.arrayBuffer())).toEqual(BINARY_BYTES);
+  });
+
+  test("serves a binary asset byte-for-byte", async () => {
+    // Bytes 0..255 include invalid UTF-8 sequences on purpose: a decode-then-
+    // reencode anywhere on the path corrupts them, and this catches it.
+    const response = await app.request("/assets/brand.woff2");
+    expect(response.status).toBe(200);
+    expect(response.headers.get("content-type")).toBe("font/woff2");
+    expect(new Uint8Array(await response.arrayBuffer())).toEqual(BINARY_BYTES);
+  });
+
+  test("extension case does not decide servability", async () => {
+    // Bundlers preserve source-file case in emitted names, so `Logo.PNG` is a
+    // real production shape, not a hypothetical.
+    const response = await app.request("/assets/Logo.PNG");
+    expect(response.status).toBe(200);
+    expect(response.headers.get("content-type")).toBe("image/png");
+  });
+
+  test("an asset type nobody anticipated still serves, as octet-stream", async () => {
+    // Fail open on the content-type, never on the bytes: an unknown extension
+    // must not reintroduce the 404-in-production-only failure.
+    const response = await app.request("/assets/blob.dat");
+    expect(response.status).toBe(200);
+    expect(response.headers.get("content-type")).toBe(
+      "application/octet-stream",
+    );
+    expect(new Uint8Array(await response.arrayBuffer())).toEqual(BINARY_BYTES);
+  });
+
+  test("every name the producer can legally emit serves, punctuation and all", async () => {
+    // The old grammar accepted only `[\w.-]`, so each of these 404'd in
+    // production while vite dev served it — and `#` and `?` additionally break
+    // the URL the handler builds, silently addressing a different file.
+    for (const name of PRODUCER_PUNCTUATION) {
+      const response = await app.request(`/assets/${encodeURIComponent(name)}`);
+      expect({
+        name,
+        status: response.status,
+        body: await response.text(),
+      }).toEqual({
+        name,
+        status: 200,
+        body: name,
+      });
+    }
+  });
+
+  test("refuses traversal, hidden files, extensionless names, and nul bytes", async () => {
+    for (const path of [
+      "/assets/..%2Fsecret.js",
+      "/assets/%2e%2e%2fsecret.js",
+      "/assets/../secret.js",
+      "/assets/fonts/../../secret.js",
+      // A backslash is a path separator to the URL parser under the file:
+      // scheme, so this escapes `assets/` if the path reaches the URL raw.
+      "/assets/..%5Csecret.js",
+      "/assets/..%5C..%5Csecret.js",
+      "/assets/.env",
+      "/assets/fonts/.hidden.js",
+      "/assets/noextension",
+      // Refused before the filesystem sees it: a nul byte is a TypeError from
+      // readFile, not an errno, so translating it would mean catching broadly.
+      "/assets/a%00b.js",
+    ]) {
+      const response = await app.request(path);
+      expect({
+        path,
+        status: response.status,
+        leaked: (await response.text()).includes("SECRET"),
+      }).toEqual({ path, status: 404, leaked: false });
+    }
+  });
+
+  test("every way a path can be absent is a 404, not a crash", async () => {
+    for (const [path, reason] of [
+      ["/assets/never-emitted.js", "ENOENT — no such file"],
+      ["/assets/index.js/nested.js", "ENOTDIR — a file used as a directory"],
+      ["/assets/legacy.js", "EISDIR — a directory shaped like an asset"],
+      [
+        `/assets/${"x".repeat(400)}.js`,
+        "ENAMETOOLONG — no file can carry this name",
+      ],
+    ] as const) {
+      const response = await app.request(path);
+      expect({ reason, status: response.status }).toEqual({
+        reason,
+        status: 404,
+      });
+    }
+  });
+
+  test("an unexpected filesystem failure propagates instead of reading as absence", async () => {
+    // The broad catch this replaces turned every read failure into `notFound`,
+    // so a broken build tree served a clean 404 and looked like an asset the
+    // build had simply never emitted.
+    let propagated: unknown;
+    const guarded = new Hono();
+    guarded.onError((error, c) => {
+      propagated = error;
+      return c.text("propagated", 500);
+    });
+    guarded.get("/assets/*", assetHandler(pathToFileURL(`${uiRoot}/`)));
+
+    const response = await guarded.request("/assets/loop.js");
+    expect({
+      status: response.status,
+      code: (propagated as NodeJS.ErrnoException | undefined)?.code,
+    }).toEqual({ status: 500, code: "ELOOP" });
+  });
+});
diff --git a/apps/brunch-agent/test/build-artifact.test.ts b/apps/brunch-agent/test/build-artifact.test.ts
new file mode 100644
index 00000000000..ad9f51dd136
--- /dev/null
+++ b/apps/brunch-agent/test/build-artifact.test.ts
@@ -0,0 +1,135 @@
+/**
+ * What the build actually emitted — checked against the artifact, not the source.
+ *
+ * `test/boundaries.test.ts` catches a misplaced `'use agent'` directive by
+ * reading the source. This checks the same property from the other end: that
+ * the agent really is registered in the emitted bundle. The distinction earns
+ * its keep because the failure mode here is silent — `@flue/vite` drops a
+ * module that stops looking like an agent module and the build stays green, so
+ * "it compiled" says nothing about whether the app has any agents in it.
+ *
+ * Any future change that quietly stops an agent, its route, or the conversation
+ * store from reaching the bundle fails here, whatever the cause: a directive
+ * moved, a config path changed, an entry dropped from the scan glob.
+ */
+
+import { existsSync, readdirSync, readFileSync } from "node:fs";
+import { join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+import { beforeAll, describe, expect, test } from "vitest";
+
+const DEV_APP = fileURLToPath(new URL("..", import.meta.url)).replace(
+  /[/\\]$/u,
+  "",
+);
+const DIST = join(DEV_APP, "dist");
+const CLIENT = join(DIST, "client");
+
+/** Everything the server build emitted, concatenated. */
+let bundle = "";
+
+beforeAll(() => {
+  // `test:unit` depends on the app's build in `turbo.json`; the test inspects
+  // that graph-owned artifact rather than hiding a nested build invocation.
+  bundle = readdirSync(DIST)
+    .filter((entry) => entry.endsWith(".mjs"))
+    .map((entry) => readFileSync(join(DIST, entry), "utf8"))
+    .join("\n");
+});
+
+/** The pinned identity of every agent module in the app, read from source. */
+function declaredAgentIdentities(): string[] {
+  const agentSource = readFileSync(
+    join(DEV_APP, "src/agents/gherkin-elicitor.ts"),
+    "utf8",
+  );
+  return [
+    ...agentSource.matchAll(/\w+\.agentName\s*=\s*(["'])([^"']+)\1/gu),
+  ].map((match) => match[2]!);
+}
+
+describe("the emitted server bundle", () => {
+  test("exists", () => {
+    expect(existsSync(DIST)).toBe(true);
+    expect(bundle.length).toBeGreaterThan(0);
+  });
+
+  test("registers every declared agent under its pinned identity", () => {
+    // The check that matters. A `'use agent'` directive that is not the first
+    // statement builds green and simply never registers — the app boots with no
+    // agents and nothing says so until a conversation fails to start.
+    //
+    // Asserted against the emitted `__flueBindAgentModule(Fn, { identity })`
+    // call rather than the bare string, because the string survives that
+    // failure: the `agentName` assignment is still in the bundle as ordinary
+    // dead code once the module stops being scanned as an agent.
+    const bound = new Set(
+      [
+        ...bundle.matchAll(
+          /__flueBindAgentModule\([^)]*identity:\s*["']([^"']+)["']/g,
+        ),
+      ].map((match) => match[1]!),
+    );
+    const identities = declaredAgentIdentities();
+    expect(identities.length).toBeGreaterThan(0);
+    for (const identity of identities) {
+      expect({ identity, bound: bound.has(identity) }).toEqual({
+        identity,
+        bound: true,
+      });
+    }
+  });
+
+  test("mounts the agent router and wires the conversation store", () => {
+    // Without db.ts reaching the bundle, conversations are process-memory and a
+    // restart loses them — a difference invisible until something restarts.
+    //
+    // Witnessed by strings that exist only in the app's own modules. The
+    // obvious witnesses are vacuous: `createAgentRouter` survives in a
+    // bootstrap JSDoc comment and `sqlite` in the bootstrap's unconditional
+    // default-adapter fallback, so both match even when the mount or db.ts
+    // never reach the bundle. (Bare `/agents/` is no better — a bundler
+    // region comment for `src/agents/` carries it.)
+    expect(bundle).toContain("route(`/agents/"); // app.ts's mount call
+    expect(bundle).toContain("BRUNCH_DEV_DB_PATH"); // db.ts's env override
+    expect(bundle).toContain(".data-wipe-me"); // db.ts's default store path
+  });
+
+  test("carries no model key", () => {
+    const modelKey = new RegExp(
+      `${"ANTHROPIC"}_${"API"}_${"KEY"}\\s*[:=]\\s*['"][^'"]+['"]`,
+      "u",
+    );
+    expect(bundle).not.toMatch(modelKey);
+  });
+});
+
+describe("the emitted client bundle", () => {
+  // `@flue/vite` emits the server environment only, so the ui tree is built by
+  // a second plain vite config. Without these, a client-side break would be
+  // invisible to CI — the Flue build would go green having never transformed a
+  // line of it.
+  test("emits html and a bundled entry", () => {
+    expect(existsSync(join(CLIENT, "index.html"))).toBe(true);
+    expect(existsSync(join(CLIENT, "assets/index.js"))).toBe(true);
+  });
+
+  test("the emitted html points at the built asset, not at source", () => {
+    // The failure this catches: shipping the source index.html, whose script
+    // tag names a .tsx module nothing serves in production.
+    const html = readFileSync(join(CLIENT, "index.html"), "utf8");
+    expect(html).toContain("/assets/index.js");
+    expect(html).not.toContain(".tsx");
+  });
+
+  test("the entry really bundled its dependencies", () => {
+    // A near-empty chunk would mean the entry resolved to nothing.
+    const entry = readFileSync(join(CLIENT, "assets/index.js"), "utf8");
+    expect(entry.length).toBeGreaterThan(10_000);
+  });
+});
+
+// The production asset route is tested in `apps/brunch-agent/test/assets.test.ts`,
+// against the handler module directly: the emitted server bundle targets
+// Node (`node:sqlite`), so the handler test isolates the asset policy.
diff --git a/apps/brunch-agent/test/db-path.test.ts b/apps/brunch-agent/test/db-path.test.ts
new file mode 100644
index 00000000000..a9452c15c17
--- /dev/null
+++ b/apps/brunch-agent/test/db-path.test.ts
@@ -0,0 +1,82 @@
+/**
+ * The conversation store's default path must not depend on the launch
+ * directory. The failure this pins down: a cwd-relative default meant
+ * launching the app from anywhere but the package directory silently created
+ * a fresh empty database — the restart-durability failure the store exists
+ * to prevent, invisible until something restarted.
+ *
+ * Tested against `db-path.ts` rather than `db.ts` so path policy remains
+ * isolated from the Flue Node runtime and SQLite (the same seam as
+ * `assets.test.ts`).
+ */
+
+import { tmpdir } from "node:os";
+import { dirname, isAbsolute, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+import { afterEach, describe, expect, test } from "vitest";
+
+import { conversationDbPath } from "../src/db-path";
+import { targetDocumentPath } from "../src/target-document-path";
+
+const appDir = fileURLToPath(new URL("..", import.meta.url));
+
+describe("the conversation store path", () => {
+  const originalCwd = process.cwd();
+  const originalOverride = process.env.BRUNCH_DEV_DB_PATH;
+
+  afterEach(() => {
+    process.chdir(originalCwd);
+    if (originalOverride === undefined) delete process.env.BRUNCH_DEV_DB_PATH;
+    else process.env.BRUNCH_DEV_DB_PATH = originalOverride;
+  });
+
+  test("is anchored to the package, wherever the process was launched from", () => {
+    delete process.env.BRUNCH_DEV_DB_PATH;
+    const fromRepo = conversationDbPath();
+    process.chdir(tmpdir());
+    const fromElsewhere = conversationDbPath();
+
+    expect(isAbsolute(fromRepo)).toBe(true);
+    expect(fromElsewhere).toBe(fromRepo);
+    expect(fromRepo).toBe(join(appDir, ".data-wipe-me", "conversations.db"));
+  });
+
+  test("the env override wins untouched", () => {
+    process.env.BRUNCH_DEV_DB_PATH = "./relative/on-purpose.db";
+    expect(conversationDbPath()).toBe("./relative/on-purpose.db");
+  });
+
+  test("a set-but-empty override falls back to the anchored default", () => {
+    // sqlite('') would open an anonymous temporary database deleted on close
+    // — non-durable with no error, which is this module's one job to prevent.
+    process.env.BRUNCH_DEV_DB_PATH = "";
+    expect(conversationDbPath()).toBe(
+      join(appDir, ".data-wipe-me", "conversations.db"),
+    );
+  });
+});
+
+describe("the target-document store path", () => {
+  const originalOverride = process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR;
+
+  afterEach(() => {
+    if (originalOverride === undefined)
+      delete process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR;
+    else process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR = originalOverride;
+  });
+
+  test("uses a stable opaque filename below the host-selected directory", () => {
+    process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR =
+      "/tmp/brunch-target-documents-test";
+    const first = targetDocumentPath("../shared-target");
+
+    expect(first).toBe(targetDocumentPath("../shared-target"));
+    expect(dirname(first)).toBe("/tmp/brunch-target-documents-test");
+    expect(first).not.toContain("shared-target");
+  });
+
+  test("refuses an empty target-document identity", () => {
+    expect(() => targetDocumentPath("")).toThrow("cannot be empty");
+  });
+});
diff --git a/apps/brunch-agent/test/local-dev-origins.test.ts b/apps/brunch-agent/test/local-dev-origins.test.ts
new file mode 100644
index 00000000000..26eec099d35
--- /dev/null
+++ b/apps/brunch-agent/test/local-dev-origins.test.ts
@@ -0,0 +1,49 @@
+import { readFileSync } from "node:fs";
+
+import { expect, test } from "vitest";
+
+import {
+  defaultChatOrigin,
+  defaultPanelOrigins,
+  localChatListen,
+  localPanelListen,
+  petrinautLocalServer,
+} from "../src/local-dev-origins.ts";
+
+const readAppFile = (relativePath: string): string =>
+  readFileSync(new URL(`../${relativePath}`, import.meta.url), "utf8");
+
+test("dev listens on the chat origin the panel proxy already assumes", () => {
+  expect(defaultChatOrigin).toBe("http://127.0.0.1:4321");
+  expect(localChatListen).toEqual({
+    host: "127.0.0.1",
+    port: 4321,
+    strictPort: true,
+  });
+  expect(readAppFile("vite.config.ts")).toContain("localChatListen");
+});
+
+test("petrinaut:dev listens on the panel origin chat CORS already assumes", () => {
+  expect(defaultPanelOrigins).toEqual([
+    "http://127.0.0.1:4915",
+    "http://localhost:4915",
+  ]);
+  expect(localPanelListen).toEqual({
+    host: "127.0.0.1",
+    port: 4915,
+    strictPort: true,
+  });
+  expect(petrinautLocalServer(defaultChatOrigin)).toEqual({
+    ...localPanelListen,
+    proxy: {
+      "/api/chat": {
+        target: defaultChatOrigin,
+        changeOrigin: true,
+      },
+    },
+  });
+  expect(readAppFile("petrinaut-local.vite.config.ts")).toContain(
+    "petrinautLocalServer",
+  );
+  expect(readAppFile("src/petrinaut-chat.ts")).toContain("defaultPanelOrigins");
+});
diff --git a/apps/brunch-agent/test/petrinaut-ask.integration.ts b/apps/brunch-agent/test/petrinaut-ask.integration.ts
new file mode 100644
index 00000000000..558e280b624
--- /dev/null
+++ b/apps/brunch-agent/test/petrinaut-ask.integration.ts
@@ -0,0 +1,152 @@
+/**
+ * FE-1449 end-to-end proof over the committed application route: the actual
+ * elicitor invokes `brunch_ask`, the wire holds the ask open as an awaiting
+ * client tool, the correlated return POST resumes the same Flue conversation
+ * and produces the next visible turn — and a duplicate of that submission is
+ * refused before any dispatch.
+ */
+
+import { mkdtemp, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import {
+  fauxAssistantMessage,
+  fauxProvider,
+  fauxText,
+  fauxThinking,
+  fauxToolCall,
+} from "@earendil-works/pi-ai";
+import { start } from "@flue/runtime/node";
+
+import {
+  GHERKIN_MODEL_ID,
+  GherkinElicitor,
+} from "../src/agents/gherkin-elicitor.ts";
+
+const targetDirectory = await mkdtemp(join(tmpdir(), "brunch-petrinaut-ask-"));
+process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR = targetDirectory;
+process.env.BRUNCH_TRANSPORT_AISDK_INSPECT = "1";
+
+const faux = fauxProvider({
+  provider: "anthropic",
+  models: [{ id: GHERKIN_MODEL_ID, reasoning: true }],
+});
+faux.setResponses([
+  fauxAssistantMessage(
+    [
+      fauxThinking("One question at a time; suspend for the answer."),
+      fauxToolCall(
+        "brunch_ask",
+        { question: "What outcome should this process reliably produce?" },
+        { id: "toolu_fe1449_ask" },
+      ),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  fauxAssistantMessage([
+    fauxThinking("The reply is mechanically bound to the pending affordance."),
+    fauxText("Payment settled — who initiates the checkout?"),
+  ]),
+  // The settlement check nudges one more turn after the answered ask.
+  fauxAssistantMessage([
+    fauxText("The settled prefix is captured; nothing further to sweep."),
+  ]),
+]);
+
+const flue = await start({
+  agents: [GherkinElicitor],
+  providers: [faux.provider],
+});
+
+type StreamChunk = Record<string, unknown> & { readonly type: string };
+
+const chunksFrom = (body: string): StreamChunk[] =>
+  body
+    .trim()
+    .split("\n\n")
+    .slice(0, -1)
+    .map((frame) => JSON.parse(frame.slice("data: ".length)) as StreamChunk);
+
+try {
+  const { default: app } = await import("../src/app.ts");
+  const postChat = async (
+    requestId: string,
+    body: unknown,
+  ): Promise<Response> =>
+    app.fetch(
+      new Request("http://brunch.test/api/chat", {
+        method: "POST",
+        headers: {
+          "content-type": "application/json",
+          "x-request-id": requestId,
+        },
+        body: JSON.stringify(body),
+      }),
+    );
+
+  const conversationId = "conversation-fe1449-ask";
+  const initial = await postChat("request-fe1449-initial", {
+    id: conversationId,
+    trigger: "submit-message",
+    messages: [
+      {
+        id: "user-fe1449-1",
+        role: "user",
+        parts: [{ type: "text", text: "Help me model checkout." }],
+      },
+    ],
+  });
+  const initialChunks = chunksFrom(await initial.text());
+  const askCall = initialChunks.find(
+    (chunk) => chunk.type === "tool-input-available",
+  );
+
+  const returnBody = {
+    id: conversationId,
+    trigger: "submit-message",
+    messageId: "assistant-fe1449-panel",
+    messages: [
+      {
+        id: "assistant-fe1449-panel",
+        role: "assistant",
+        parts: [
+          {
+            type: "dynamic-tool",
+            toolName: "brunch_ask",
+            toolCallId: askCall?.toolCallId,
+            state: "output-available",
+            input: askCall?.input,
+            output: { answer: "A confirmed order with payment settled." },
+          },
+        ],
+      },
+    ],
+  };
+  const resumed = await postChat("request-fe1449-return", returnBody);
+  const resumedChunks = chunksFrom(await resumed.text());
+
+  const duplicate = await postChat("request-fe1449-duplicate", returnBody);
+
+  console.log(
+    `PETRINAUT_ASK_RESULT ${JSON.stringify({
+      initialStatus: initial.status,
+      askCall,
+      initialToolOutputs: initialChunks.filter(
+        (chunk) => chunk.type === "tool-output-available",
+      ),
+      initialFinish: initialChunks.at(-1),
+      resumedStatus: resumed.status,
+      resumedText: resumedChunks
+        .filter((chunk) => chunk.type === "text-delta")
+        .map((chunk) => chunk.delta)
+        .join(""),
+      resumedFinish: resumedChunks.at(-1),
+      duplicateStatus: duplicate.status,
+      duplicateBody: await duplicate.json(),
+    })}`,
+  );
+} finally {
+  await flue.stop();
+  await rm(targetDirectory, { recursive: true, force: true });
+}
diff --git a/apps/brunch-agent/test/petrinaut-ask.test.ts b/apps/brunch-agent/test/petrinaut-ask.test.ts
new file mode 100644
index 00000000000..3d987b46e79
--- /dev/null
+++ b/apps/brunch-agent/test/petrinaut-ask.test.ts
@@ -0,0 +1,89 @@
+import { join } from "node:path";
+
+import { expect, test } from "vitest";
+
+import { runNodeScript } from "./run-node-script";
+
+type StreamChunk = Record<string, unknown> & { readonly type: string };
+const testDirectory = import.meta.dirname;
+
+test("a structured ask suspends over the wire and its correlated submission resumes the conversation", async () => {
+  const { exitCode, stdout, stderr } = await runNodeScript(
+    join(testDirectory, "petrinaut-ask.integration.ts"),
+    join(testDirectory, "../../.."),
+  );
+
+  expect(exitCode, stderr || stdout).toBe(0);
+  const resultLine = stdout
+    .split("\n")
+    .find((line) => line.startsWith("PETRINAUT_ASK_RESULT "));
+  expect(resultLine, stdout).toBeDefined();
+  const result = JSON.parse(
+    resultLine!.slice("PETRINAUT_ASK_RESULT ".length),
+  ) as {
+    initialStatus: number;
+    askCall: StreamChunk | undefined;
+    initialToolOutputs: StreamChunk[];
+    initialFinish: StreamChunk;
+    resumedStatus: number;
+    resumedText: string;
+    resumedFinish: StreamChunk;
+    duplicateStatus: number;
+    duplicateBody: unknown;
+  };
+
+  // Suspension: the ask leaves the server as an awaiting client tool with a
+  // stable call id; the harness's minted affordance never reaches the wire.
+  expect(result.initialStatus).toBe(200);
+  expect(result.askCall).toMatchObject({
+    type: "tool-input-available",
+    toolName: "brunch_ask",
+    input: { question: "What outcome should this process reliably produce?" },
+  });
+  expect(typeof result.askCall?.toolCallId).toBe("string");
+  expect(result.initialToolOutputs).toEqual([]);
+  expect(result.initialFinish).toMatchObject({ type: "finish" });
+
+  // Resumption: the correlated submission becomes the user-affordance reply
+  // and the same conversation produces the next visible turn.
+  expect(result.resumedStatus).toBe(200);
+  // The response carries the answer turn and then the settlement-check turn,
+  // exactly as the FE-1436 application golden streams its second step.
+  expect(
+    result.resumedText.startsWith(
+      "Payment settled — who initiates the checkout?",
+    ),
+  ).toBe(true);
+  expect(result.resumedFinish).toEqual({
+    type: "finish",
+    finishReason: "stop",
+  });
+
+  // Provenance: replaying the same submission finds no pending ask and is
+  // refused at the wire boundary, before any dispatch.
+  expect(result.duplicateStatus).toBe(409);
+  expect(result.duplicateBody).toEqual({ error: "ask_not_pending" });
+
+  const inspections = stdout
+    .split("\n")
+    .filter((line) => line.startsWith("TRANSPORT_AISDK "))
+    .map(
+      (line) =>
+        JSON.parse(line.slice("TRANSPORT_AISDK ".length)) as StreamChunk,
+    );
+  expect(inspections.some((event) => event.type === "ask-await")).toBe(true);
+  expect(inspections.some((event) => event.type === "ask-reply-admitted")).toBe(
+    true,
+  );
+  expect(
+    inspections.filter((event) => event.type === "ask-reply-refused"),
+  ).toEqual([
+    {
+      type: "ask-reply-refused",
+      requestId: "request-fe1449-duplicate",
+      conversationId: "conversation-fe1449-ask",
+      toolCallId: result.askCall?.toolCallId,
+      reason: "no-pending-ask",
+    },
+  ]);
+});
diff --git a/apps/brunch-agent/test/petrinaut-chat.integration.ts b/apps/brunch-agent/test/petrinaut-chat.integration.ts
new file mode 100644
index 00000000000..cf04e8a757b
--- /dev/null
+++ b/apps/brunch-agent/test/petrinaut-chat.integration.ts
@@ -0,0 +1,102 @@
+import { mkdtemp, readFile, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+import {
+  fauxAssistantMessage,
+  fauxProvider,
+  fauxText,
+  fauxThinking,
+} from "@earendil-works/pi-ai";
+import { start } from "@flue/runtime/node";
+
+import {
+  GHERKIN_MODEL_ID,
+  GherkinElicitor,
+} from "../src/agents/gherkin-elicitor.ts";
+
+const targetDirectory = await mkdtemp(join(tmpdir(), "brunch-petrinaut-chat-"));
+process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR = targetDirectory;
+process.env.BRUNCH_TRANSPORT_AISDK_INSPECT = "1";
+
+const faux = fauxProvider({
+  provider: "anthropic",
+  models: [{ id: GHERKIN_MODEL_ID, reasoning: true }],
+});
+faux.setResponses([
+  fauxAssistantMessage([
+    fauxThinking(
+      "I should establish the process outcome before proposing structure.",
+    ),
+    fauxText("What outcome should this process reliably produce?"),
+  ]),
+  fauxAssistantMessage([
+    fauxThinking("The settlement check does not add user evidence."),
+    fauxText(
+      "We can start with the outcome and then work backward through the process.",
+    ),
+  ]),
+]);
+
+const flue = await start({
+  agents: [GherkinElicitor],
+  providers: [faux.provider],
+});
+
+try {
+  const { default: app } = await import("../src/app.ts");
+  const fixturePath = fileURLToPath(
+    new URL(
+      "../../../libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.post.json",
+      import.meta.url,
+    ),
+  );
+  const response = await app.fetch(
+    new Request("http://brunch.test/api/chat", {
+      method: "POST",
+      headers: {
+        "content-type": "application/json",
+        "x-request-id": "request-fe1436-application",
+      },
+      body: await readFile(fixturePath, "utf8"),
+    }),
+  );
+  const body = await response.text();
+  const chunks = body
+    .trim()
+    .split("\n\n")
+    .slice(0, -1)
+    .map(
+      (frame) =>
+        JSON.parse(frame.slice("data: ".length)) as Record<string, unknown>,
+    );
+  const startChunk = chunks.find((chunk) => chunk.type === "start");
+  const partIds = chunks
+    .filter(
+      (chunk) =>
+        chunk.type === "reasoning-start" || chunk.type === "text-start",
+    )
+    .map((chunk) => chunk.id);
+
+  console.log(
+    `PETRINAUT_CHAT_RESULT ${JSON.stringify({
+      status: response.status,
+      messageId: startChunk?.messageId,
+      partIds,
+      reasoning: chunks
+        .filter((chunk) => chunk.type === "reasoning-delta")
+        .map((chunk) => chunk.delta)
+        .join(""),
+      text: chunks
+        .filter((chunk) => chunk.type === "text-delta")
+        .map((chunk) => chunk.delta)
+        .join(""),
+      finish: chunks.at(-1),
+      chunks,
+    })}`,
+  );
+} finally {
+  await flue.stop();
+  await rm(targetDirectory, { recursive: true, force: true });
+}
diff --git a/apps/brunch-agent/test/petrinaut-chat.test.ts b/apps/brunch-agent/test/petrinaut-chat.test.ts
new file mode 100644
index 00000000000..5d6be446944
--- /dev/null
+++ b/apps/brunch-agent/test/petrinaut-chat.test.ts
@@ -0,0 +1,104 @@
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { expect, test } from "vitest";
+
+import { runNodeScript } from "./run-node-script";
+
+type StreamChunk = Record<string, unknown> & { readonly type: string };
+const testDirectory = import.meta.dirname;
+
+const normalizedChunk = (
+  chunk: StreamChunk,
+  messageId: string,
+): StreamChunk => {
+  const normalized = { ...chunk };
+  if (normalized.messageId === messageId) normalized.messageId = "$message";
+  if (typeof normalized.id === "string")
+    normalized.id = normalized.id.replace(messageId, "$message");
+  return normalized;
+};
+
+const normalizedChunks = (
+  chunks: readonly StreamChunk[],
+  messageId: string,
+): StreamChunk[] =>
+  chunks.reduce<StreamChunk[]>((normalized, chunk) => {
+    const current = normalizedChunk(chunk, messageId);
+    const previous = normalized.at(-1);
+    if (
+      current.type.endsWith("-delta") &&
+      previous?.type === current.type &&
+      previous.id === current.id &&
+      typeof previous.delta === "string" &&
+      typeof current.delta === "string"
+    ) {
+      previous.delta += current.delta;
+      return normalized;
+    }
+    normalized.push(current);
+    return normalized;
+  }, []);
+
+test("the committed application route drives the actual elicitor for reasoning and text", async () => {
+  const { exitCode, stdout, stderr } = await runNodeScript(
+    join(testDirectory, "petrinaut-chat.integration.ts"),
+    join(testDirectory, "../../.."),
+  );
+
+  expect(exitCode, stderr || stdout).toBe(0);
+  const inspectionLines = stdout
+    .split("\n")
+    .filter((line) => line.startsWith("TRANSPORT_AISDK "))
+    .map(
+      (line) =>
+        JSON.parse(line.slice("TRANSPORT_AISDK ".length)) as Record<
+          string,
+          unknown
+        >,
+    );
+  const resultLine = stdout
+    .split("\n")
+    .find((line) => line.startsWith("PETRINAUT_CHAT_RESULT "));
+  expect(resultLine, stdout).toBeDefined();
+  const result = JSON.parse(
+    resultLine!.slice("PETRINAUT_CHAT_RESULT ".length),
+  ) as {
+    status: number;
+    messageId: string;
+    partIds: string[];
+    reasoning: string;
+    text: string;
+    finish: unknown;
+    chunks: StreamChunk[];
+  };
+
+  expect(result.status).toBe(200);
+  expect(result.messageId.length).toBeGreaterThan(0);
+  expect(
+    result.partIds.every((partId) => partId.startsWith(`${result.messageId}:`)),
+  ).toBe(true);
+  expect(result.reasoning).toContain("establish the process outcome");
+  expect(result.text).toContain(
+    "What outcome should this process reliably produce?",
+  );
+  expect(result.finish).toEqual({ type: "finish", finishReason: "stop" });
+  const golden = JSON.parse(
+    readFileSync(
+      join(
+        testDirectory,
+        "../../../libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/elicitor-initial.normalized.json",
+      ),
+      "utf8",
+    ),
+  ) as StreamChunk[];
+  expect(normalizedChunks(result.chunks, result.messageId)).toEqual(golden);
+  expect(inspectionLines[0]).toMatchObject({
+    type: "request-start",
+    requestId: "request-fe1436-application",
+  });
+  expect(inspectionLines.at(-1)).toMatchObject({
+    type: "request-finish",
+    terminalState: "completed",
+  });
+});
diff --git a/apps/brunch-agent/test/run-node-script.ts b/apps/brunch-agent/test/run-node-script.ts
new file mode 100644
index 00000000000..4ef2e623d99
--- /dev/null
+++ b/apps/brunch-agent/test/run-node-script.ts
@@ -0,0 +1,35 @@
+import { spawn } from "node:child_process";
+
+interface NodeScriptResult {
+  readonly exitCode: number | null;
+  readonly stderr: string;
+  readonly stdout: string;
+}
+
+export const runNodeScript = async (
+  scriptPath: string,
+  cwd: string,
+): Promise<NodeScriptResult> =>
+  new Promise((resolve, reject) => {
+    const child = spawn(
+      process.execPath,
+      ["--experimental-strip-types", scriptPath],
+      {
+        cwd,
+        stdio: ["ignore", "pipe", "pipe"],
+      },
+    );
+
+    let stderr = "";
+    let stdout = "";
+    child.stderr.setEncoding("utf8").on("data", (chunk: string) => {
+      stderr += chunk;
+    });
+    child.stdout.setEncoding("utf8").on("data", (chunk: string) => {
+      stdout += chunk;
+    });
+    child.once("error", reject);
+    child.once("close", (exitCode) => {
+      resolve({ exitCode, stderr, stdout });
+    });
+  });
diff --git a/apps/brunch-agent/test/transport-aisdk-server.test.ts b/apps/brunch-agent/test/transport-aisdk-server.test.ts
new file mode 100644
index 00000000000..1c1523b7d3e
--- /dev/null
+++ b/apps/brunch-agent/test/transport-aisdk-server.test.ts
@@ -0,0 +1,433 @@
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, test } from "vitest";
+
+import { createFlueReplyProjector } from "@hashintel/brunch-agent-binding-flue";
+import {
+  createAiSdkChatHandler,
+  type HarnessReplyEvent,
+  type TransportInspectionEvent,
+} from "@hashintel/brunch-agent-transport-aisdk";
+
+type GoldenChunk = Record<string, unknown> & { readonly type: string };
+
+const FIXTURES = join(
+  import.meta.dirname,
+  "../../../libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures",
+);
+
+const fixture = (name: string): string =>
+  readFileSync(join(FIXTURES, name), "utf8");
+
+const responseChunks = async (
+  response: Response,
+): Promise<readonly GoldenChunk[]> =>
+  (await response.text())
+    .trim()
+    .split("\n\n")
+    .slice(0, -1)
+    .map((frame) => JSON.parse(frame.slice("data: ".length)) as GoldenChunk);
+
+const panelInitialHarnessEvents: readonly HarnessReplyEvent[] = [
+  { type: "response-start", messageId: "assistant-fe1435-1" },
+  { type: "turn-start", turnId: "turn-fe1435-1" },
+  { type: "part-start", kind: "reasoning", partId: "reasoning-fe1435-1" },
+  {
+    type: "part-delta",
+    kind: "reasoning",
+    partId: "reasoning-fe1435-1",
+    delta:
+      "**Checking the wire seam**\n\nThe harness stream is translating reasoning parts.",
+  },
+  {
+    type: "part-delta",
+    kind: "reasoning",
+    partId: "reasoning-fe1435-1",
+    delta: " It will now drive both server and browser tools.",
+  },
+  { type: "part-end", kind: "reasoning", partId: "reasoning-fe1435-1" },
+  { type: "part-start", kind: "text", partId: "text-fe1435-1" },
+  {
+    type: "part-delta",
+    kind: "text",
+    partId: "text-fe1435-1",
+    delta: "Harness-streamed text reached Petrinaut before tool execution.",
+  },
+  { type: "part-end", kind: "text", partId: "text-fe1435-1" },
+  {
+    type: "tool-input",
+    toolCallId: "tool-server-fe1435",
+    toolName: "serverProbe",
+    input: { scope: "real-panel" },
+    execution: "server",
+  },
+  {
+    type: "tool-output",
+    toolCallId: "tool-server-fe1435",
+    output: { ok: true, source: "fake-harness-loop" },
+    execution: "server",
+  },
+  {
+    type: "tool-input",
+    toolCallId: "tool-place-fe1435",
+    toolName: "addPlace",
+    input: {
+      id: "place__fe1435_buffer",
+      name: "SpikeBuffer",
+      colorId: null,
+      dynamicsEnabled: false,
+      differentialEquationId: null,
+      showAsInitialState: true,
+      x: 180,
+      y: 140,
+    },
+    execution: "client",
+  },
+  {
+    type: "tool-input",
+    toolCallId: "tool-transition-fe1435",
+    toolName: "addTransition",
+    input: {
+      id: "transition__fe1435_dispatch",
+      name: "Spike dispatch",
+      inputArcs: [],
+      outputArcs: [],
+      lambdaType: "predicate",
+      lambdaCode: "export const Lambda = () => true;",
+      transitionKernelCode: "export const TransitionKernel = () => ({});",
+      x: 420,
+      y: 140,
+    },
+    execution: "client",
+  },
+  { type: "turn-finish", turnId: "turn-fe1435-1" },
+  {
+    type: "response-finish",
+    finishReason: "tool-calls",
+    terminalState: "completed",
+  },
+];
+
+describe("FE-1436 Petrinaut wire server", () => {
+  test("refuses malformed JSON values at the transport boundary", async () => {
+    let dispatched = false;
+    const handler = createAiSdkChatHandler({
+      async runTurn() {
+        dispatched = true;
+      },
+    });
+
+    for (const body of [
+      null,
+      [],
+      "not-an-object",
+      1436,
+      { messages: [null] },
+    ]) {
+      const response = await handler(
+        new Request("http://brunch.test/api/petrinaut/chat", {
+          method: "POST",
+          headers: { "content-type": "application/json" },
+          body: JSON.stringify(body),
+        }),
+      );
+
+      expect({
+        body,
+        status: response.status,
+        refusal: await response.json(),
+      }).toEqual({
+        body,
+        status: 400,
+        refusal: { error: "invalid_chat_request" },
+      });
+    }
+    expect(dispatched).toBe(false);
+  });
+
+  test("emits one truthful terminal sequence for failed and aborted settlements", async () => {
+    for (const terminalState of ["failed", "aborted"] as const) {
+      const inspections: TransportInspectionEvent[] = [];
+      const handler = createAiSdkChatHandler({
+        inspect: (event) => inspections.push(event),
+        async runTurn(_input, emit) {
+          const submissionId = `submission-${terminalState}`;
+          const projector = createFlueReplyProjector({ submissionId, emit });
+          projector.accept({
+            type: "message-started",
+            conversationId: `conversation-${terminalState}`,
+            submissionId,
+            messageId: `message-${terminalState}`,
+            turnId: `turn-${terminalState}`,
+            position: { batch: 1, index: 0 },
+          });
+          projector.accept({
+            type: "submission-settled",
+            conversationId: `conversation-${terminalState}`,
+            submissionId,
+            outcome: terminalState,
+            position: { batch: 1, index: 1 },
+          });
+          // Flue's read API rejects after delivering a failed/aborted settlement.
+          throw new Error(`${terminalState} settlement`);
+        },
+      });
+
+      const response = await handler(
+        new Request("http://brunch.test/api/petrinaut/chat", {
+          method: "POST",
+          headers: { "content-type": "application/json" },
+          body: JSON.stringify({
+            id: `conversation-${terminalState}`,
+            trigger: "submit-message",
+            messages: [
+              {
+                id: `user-${terminalState}`,
+                role: "user",
+                parts: [{ type: "text", text: "Go" }],
+              },
+            ],
+          }),
+        }),
+      );
+      const chunks = await responseChunks(response);
+      const terminalChunkTypes = chunks
+        .map((chunk) => chunk.type)
+        .filter(
+          (type) => type === "finish" || type === "abort" || type === "error",
+        );
+
+      expect({ terminalState, terminalChunkTypes }).toEqual({
+        terminalState,
+        terminalChunkTypes: [terminalState === "failed" ? "error" : "abort"],
+      });
+      expect(
+        inspections.filter((event) => event.type === "request-finish"),
+      ).toEqual([
+        {
+          type: "request-finish",
+          requestId: expect.any(String),
+          terminalState,
+          finishReason: "error",
+        },
+      ]);
+      expect(inspections.find((event) => event.type === "turn-finish")).toEqual(
+        {
+          type: "turn-finish",
+          requestId: expect.any(String),
+          turnId: `turn-${terminalState}`,
+        },
+      );
+    }
+  });
+
+  test("streams a failed server tool outcome before settling the failed turn", async () => {
+    const handler = createAiSdkChatHandler({
+      async runTurn(_input, emit) {
+        emit({ type: "response-start", messageId: "message-tool-failed" });
+        emit({ type: "turn-start", turnId: "turn-tool-failed" });
+        emit({
+          type: "tool-input",
+          toolCallId: "tool-failed",
+          toolName: "bl_sweep",
+          input: {},
+          execution: "server",
+        });
+        emit({
+          type: "tool-output-error",
+          toolCallId: "tool-failed",
+          errorText: "Sweep persistence failed.",
+          execution: "server",
+        });
+        emit({ type: "turn-finish", turnId: "turn-tool-failed" });
+        emit({
+          type: "response-finish",
+          terminalState: "failed",
+          finishReason: "error",
+        });
+      },
+    });
+
+    const response = await handler(
+      new Request("http://brunch.test/api/petrinaut/chat", {
+        method: "POST",
+        headers: { "content-type": "application/json" },
+        body: JSON.stringify({
+          id: "conversation-tool-failed",
+          trigger: "submit-message",
+          messages: [
+            {
+              id: "user-tool-failed",
+              role: "user",
+              parts: [{ type: "text", text: "Go" }],
+            },
+          ],
+        }),
+      }),
+    );
+
+    expect(await responseChunks(response)).toEqual([
+      { type: "start", messageId: "message-tool-failed" },
+      { type: "start-step" },
+      {
+        type: "tool-input-available",
+        toolCallId: "tool-failed",
+        toolName: "bl_sweep",
+        input: {},
+        providerExecuted: true,
+      },
+      {
+        type: "tool-output-error",
+        toolCallId: "tool-failed",
+        errorText: "Sweep persistence failed.",
+        providerExecuted: true,
+      },
+      { type: "finish-step" },
+      { type: "error", errorText: "The elicitor turn failed." },
+    ]);
+  });
+
+  test("answers an allowlisted panel preflight without opening every origin", async () => {
+    const handler = createAiSdkChatHandler({
+      allowedOrigins: ["http://127.0.0.1:4915"],
+      async runTurn() {},
+    });
+
+    const allowed = await handler(
+      new Request("http://brunch.test/api/petrinaut/chat", {
+        method: "OPTIONS",
+        headers: { origin: "http://127.0.0.1:4915" },
+      }),
+    );
+    expect(allowed.status).toBe(204);
+    expect(allowed.headers.get("access-control-allow-origin")).toBe(
+      "http://127.0.0.1:4915",
+    );
+    expect(allowed.headers.get("access-control-allow-methods")).toBe(
+      "POST, OPTIONS",
+    );
+
+    const refused = await handler(
+      new Request("http://brunch.test/api/petrinaut/chat", {
+        method: "OPTIONS",
+        headers: { origin: "https://untrusted.example" },
+      }),
+    );
+    expect(refused.status).toBe(403);
+    expect(refused.headers.get("access-control-allow-origin")).toBeNull();
+  });
+
+  test("encodes fixed harness events as the real-panel golden SSE", async () => {
+    const inspections: TransportInspectionEvent[] = [];
+    const handler = createAiSdkChatHandler({
+      inspect: (event) => inspections.push(event),
+      async runTurn(input, emit) {
+        expect(input).toEqual({
+          conversationId: "m5z0GU9KJPzhOTlx",
+          idempotencyKey: "m5z0GU9KJPzhOTlx:6ddgGkjhSxGjOtiv",
+          userMessage: {
+            id: "6ddgGkjhSxGjOtiv",
+            text: "Run the FE-1435 transport probe.",
+          },
+        });
+        for (const event of panelInitialHarnessEvents) emit(event);
+      },
+    });
+
+    const response = await handler(
+      new Request("http://brunch.test/api/petrinaut/chat", {
+        method: "POST",
+        headers: {
+          "content-type": "application/json",
+          "x-request-id": "request-fe1436-contract",
+        },
+        body: fixture("panel-initial.post.json"),
+      }),
+    );
+
+    expect(response.status).toBe(200);
+    expect(response.headers.get("x-vercel-ai-ui-message-stream")).toBe("v1");
+    expect((await response.text()).trimEnd()).toBe(
+      fixture("panel-initial.sse").trimEnd(),
+    );
+    expect(inspections[0]).toEqual({
+      type: "request-start",
+      requestId: "request-fe1436-contract",
+      conversationId: "m5z0GU9KJPzhOTlx",
+      userMessageId: "6ddgGkjhSxGjOtiv",
+    });
+    expect(
+      inspections
+        .filter((event) => event.type === "part-emitted")
+        .map((event) => ({
+          kind: event.kind,
+          partId: event.partId,
+          toolCallId: event.toolCallId,
+        })),
+    ).toEqual([
+      {
+        kind: "reasoning",
+        partId: "reasoning-fe1435-1",
+        toolCallId: undefined,
+      },
+      { kind: "text", partId: "text-fe1435-1", toolCallId: undefined },
+      {
+        kind: "tool-input",
+        partId: undefined,
+        toolCallId: "tool-server-fe1435",
+      },
+      {
+        kind: "tool-output",
+        partId: undefined,
+        toolCallId: "tool-server-fe1435",
+      },
+      {
+        kind: "tool-input",
+        partId: undefined,
+        toolCallId: "tool-place-fe1435",
+      },
+      {
+        kind: "tool-input",
+        partId: undefined,
+        toolCallId: "tool-transition-fe1435",
+      },
+    ]);
+    expect(inspections.at(-1)).toEqual({
+      type: "request-finish",
+      requestId: "request-fe1436-contract",
+      terminalState: "completed",
+      finishReason: "tool-calls",
+    });
+  });
+
+  test("refuses the frozen tool-result follow-up without dispatching diagnostics as user evidence", async () => {
+    let dispatched = false;
+    const handler = createAiSdkChatHandler({
+      allowedOrigins: ["http://127.0.0.1:4915"],
+      async runTurn() {
+        dispatched = true;
+      },
+    });
+
+    const response = await handler(
+      new Request("http://brunch.test/api/petrinaut/chat", {
+        method: "POST",
+        headers: {
+          "content-type": "application/json",
+          origin: "http://127.0.0.1:4915",
+        },
+        body: fixture("panel-tool-results.post.json"),
+      }),
+    );
+
+    expect(response.status).toBe(422);
+    expect(response.headers.get("access-control-allow-origin")).toBe(
+      "http://127.0.0.1:4915",
+    );
+    expect(await response.json()).toEqual({
+      error: "tool_result_follow_up_not_supported",
+    });
+    expect(dispatched).toBe(false);
+  });
+});
diff --git a/apps/brunch-agent/test/walking-skeleton.integration.ts b/apps/brunch-agent/test/walking-skeleton.integration.ts
new file mode 100644
index 00000000000..66f85667a46
--- /dev/null
+++ b/apps/brunch-agent/test/walking-skeleton.integration.ts
@@ -0,0 +1,334 @@
+import { mkdtemp, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+// One of the substrate integration entry points reviewed in
+// test/boundaries.test.ts, which is where the permission lives — this comment
+// does not grant it.
+import {
+  fauxAssistantMessage,
+  fauxProvider,
+  fauxToolCall,
+  type Context,
+} from "@earendil-works/pi-ai";
+import { start } from "@flue/runtime/node";
+import { createFlueClient } from "@flue/sdk";
+
+import { toolName } from "@hashintel/brunch-agent";
+import {
+  createFlueHistoryReader,
+  createLocalCaptureStore,
+} from "@hashintel/brunch-agent-binding-flue";
+
+import {
+  GHERKIN_MODEL_ID,
+  GherkinElicitor,
+} from "../src/agents/gherkin-elicitor.ts";
+import app from "../src/app.ts";
+import { GHERKIN_AGENT_ROUTE } from "../src/routes.ts";
+import { targetDocumentPath } from "../src/target-document-path.ts";
+
+const ask = toolName("ask");
+const sweep = toolName("sweep");
+const omittedQuote = "A shopper completes checkout.";
+const newlyCapturedQuote = "Payment is authorized before fulfillment.";
+const repairedQuote = "Refunds require approval.";
+const missingQuote = "This quote is not in the conversation.";
+const statementNoted = (quote: string) => ({
+  evidence: [{ excerpt: quote }],
+  epistemicStatus: "explicit" as const,
+  confidence: "firm" as const,
+  content: {
+    value: {
+      type: "statement-noted" as const,
+      interior: { verbatim: quote },
+    },
+  },
+});
+const faux = fauxProvider({
+  provider: "anthropic",
+  models: [{ id: GHERKIN_MODEL_ID }],
+});
+
+let replyContext: Context | undefined;
+faux.setResponses([
+  fauxAssistantMessage(
+    [
+      fauxToolCall(ask, {
+        question: "What outcome should the scenario describe?",
+      }),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  (context) => {
+    replyContext = context;
+    return fauxAssistantMessage(
+      [fauxToolCall(ask, { question: "Who initiates that outcome?" })],
+      {
+        stopReason: "toolUse",
+      },
+    );
+  },
+  fauxAssistantMessage(
+    [
+      fauxToolCall(ask, { question: "What happens first?" }),
+      fauxToolCall(ask, { question: "What happens second?" }),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  fauxAssistantMessage("Waiting for the accepted question to be answered."),
+  fauxAssistantMessage("That closes the payment topic."),
+  fauxAssistantMessage([fauxToolCall(sweep, {})], { stopReason: "toolUse" }),
+  fauxAssistantMessage(
+    [
+      fauxToolCall("finish", {
+        proposals: [statementNoted(newlyCapturedQuote)],
+      }),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  fauxAssistantMessage([fauxToolCall(sweep, {})], { stopReason: "toolUse" }),
+  fauxAssistantMessage(
+    [
+      fauxToolCall("finish", {
+        proposals: [
+          statementNoted(newlyCapturedQuote),
+          statementNoted(omittedQuote),
+        ],
+      }),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  fauxAssistantMessage("The settled statements are captured."),
+  fauxAssistantMessage("That closes the refund topic."),
+  fauxAssistantMessage([fauxToolCall(sweep, {})], { stopReason: "toolUse" }),
+  fauxAssistantMessage(
+    [fauxToolCall("finish", { proposals: [statementNoted(missingQuote)] })],
+    {
+      stopReason: "toolUse",
+    },
+  ),
+  fauxAssistantMessage("The refused sweep needs repair."),
+  fauxAssistantMessage("I am stopping on the repair continuation."),
+  fauxAssistantMessage([fauxToolCall(sweep, {})], { stopReason: "toolUse" }),
+  fauxAssistantMessage(
+    [
+      fauxToolCall("finish", {
+        proposals: [
+          statementNoted(newlyCapturedQuote),
+          statementNoted(omittedQuote),
+          statementNoted(repairedQuote),
+        ],
+      }),
+    ],
+    { stopReason: "toolUse" },
+  ),
+  fauxAssistantMessage("The repaired sweep is captured."),
+]);
+
+const flue = await start({
+  agents: [GherkinElicitor],
+  providers: [faux.provider],
+});
+const targetDirectory = await mkdtemp(
+  join(tmpdir(), "brunch-walking-skeleton-"),
+);
+
+try {
+  process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR = targetDirectory;
+  const fetchApp = ((input: RequestInfo | URL, init?: RequestInit) =>
+    Promise.resolve(
+      app.fetch(input instanceof Request ? input : new Request(input, init)),
+    )) as typeof fetch;
+  const conversationId = `walking-skeleton-${crypto.randomUUID()}`;
+  const targetDocumentId = "walking-skeleton-test";
+  const captureStore = createLocalCaptureStore(
+    targetDocumentPath(targetDocumentId),
+  );
+  const historyReader = createFlueHistoryReader({
+    resolveConversationUrl: (sessionId) =>
+      `http://brunch.test/agents/${GHERKIN_AGENT_ROUTE}/${sessionId}`,
+    transport: fetchApp,
+    archive: captureStore,
+  });
+  const client = createFlueClient({
+    url: `http://brunch.test/agents/${GHERKIN_AGENT_ROUTE}/${conversationId}`,
+    fetch: fetchApp,
+  });
+
+  const kickoff = await client.send({
+    message: { kind: "user", body: "Begin the interview." },
+    initialData: { targetDocumentId },
+  });
+  await client.wait(kickoff);
+
+  const firstHistory = await historyReader.read(conversationId);
+  const previousArchive = await captureStore.readArchivedEntries({
+    sessionId: conversationId,
+    entryStart: 1,
+    entryEnd: firstHistory.messages.length,
+  });
+  const quoteAbsentFromPreviousArchive =
+    !JSON.stringify(previousArchive).includes(newlyCapturedQuote);
+  const firstParts = firstHistory.messages.flatMap((message) => message.parts);
+  const firstAsk = firstParts.find(
+    (part) =>
+      part.type === "dynamic-tool" &&
+      part.toolName === ask &&
+      part.state === "output-available",
+  );
+  const firstAskOutput =
+    firstAsk?.type === "dynamic-tool" && firstAsk.state === "output-available"
+      ? firstAsk.output
+      : undefined;
+
+  const answer = await client.send({
+    message: { kind: "user", body: omittedQuote },
+  });
+  await client.wait(answer);
+
+  const secondAnswer = await client.send({
+    message: { kind: "user", body: "The shopper initiates it." },
+  });
+  await client.wait(secondAnswer);
+
+  const thirdAnswer = await client.send({
+    message: { kind: "user", body: newlyCapturedQuote },
+  });
+  await client.wait(thirdAnswer);
+
+  const fourthAnswer = await client.send({
+    message: { kind: "user", body: repairedQuote },
+  });
+  await client.wait(fourthAnswer);
+
+  const history = await historyReader.peek(conversationId);
+  const repeatedAskAssistant = [...history.messages]
+    .reverse()
+    .find(
+      (message) =>
+        message.role === "assistant" &&
+        message.parts.filter(
+          (part) => part.type === "dynamic-tool" && part.toolName === ask,
+        ).length >= 2,
+    );
+  const finalAskParts =
+    repeatedAskAssistant?.parts.filter(
+      (part) => part.type === "dynamic-tool" && part.toolName === ask,
+    ) ?? [];
+  const captured = await captureStore.read();
+  let archivePointerResolved = false;
+  let affordanceReplyClassified = false;
+  const capture = captured.captures.find(
+    (candidate) =>
+      "evidence" in candidate &&
+      candidate.evidence.some(
+        (evidence) => evidence.excerpt === newlyCapturedQuote,
+      ),
+  );
+  if (capture && "evidence" in capture) {
+    affordanceReplyClassified =
+      capture.evidence[0]?.source === "user-affordance-payload";
+    const [archived] = await captureStore.readArchivedEntries(
+      capture.evidence[0]!.pointer,
+    );
+    archivePointerResolved =
+      archived?.versions.at(-1)?.text === newlyCapturedQuote;
+  }
+  const settlementChecks = history.messages.filter(
+    (message) => message.signal?.tagName === "settlement-check",
+  );
+  const repairSignals = history.messages.filter(
+    (message) => message.signal?.tagName === "sweep-repair",
+  );
+  const sweepOutputs = history.messages
+    .flatMap((message) => message.parts)
+    .flatMap((part) =>
+      part.type === "dynamic-tool" &&
+      part.toolName === sweep &&
+      part.state === "output-available" &&
+      typeof part.output === "object" &&
+      part.output !== null
+        ? [part.output]
+        : [],
+    );
+  const appliedSweepOutputs = sweepOutputs.filter(
+    (output): output is Record<string, unknown> =>
+      "status" in output && output.status === "applied",
+  );
+  const replayOutput = appliedSweepOutputs[1];
+  const capturesStayAtVerbatimFloor = captured.captures.every((candidate) => {
+    if (!("evidence" in candidate) || !("value" in candidate.content))
+      return false;
+    const serializedValue = JSON.stringify(candidate.content.value);
+    return candidate.evidence.some(
+      (evidence) =>
+        serializedValue ===
+        JSON.stringify({
+          type: "statement-noted",
+          interior: { verbatim: evidence.excerpt },
+        }),
+    );
+  });
+  const serializedReplyContext =
+    replyContext === undefined ? undefined : JSON.stringify(replyContext);
+
+  console.log(
+    `WALKING_SKELETON_RESULT ${JSON.stringify({
+      affordanceReplyClassified,
+      archivePointerResolved,
+      captureStoredThroughSweep: captured.captures.length === 3,
+      capturesStayAtVerbatimFloor,
+      boundReplyReachedModel:
+        serializedReplyContext?.includes("A shopper completes checkout.") ===
+          true && serializedReplyContext.includes("affordance-reply-bound"),
+      durableOutput:
+        JSON.stringify(firstAskOutput).includes(
+          "What outcome should the scenario describe?",
+        ) && JSON.stringify(firstAskOutput).includes('"form":"free-text"'),
+      markdownFloor: firstParts.some(
+        (part) =>
+          part.type === "data-affordance" &&
+          JSON.stringify(part.data).includes(
+            "What outcome should the scenario describe?",
+          ),
+      ),
+      noInstructionWake: !JSON.stringify(history.messages)
+        .toLowerCase()
+        .includes("instructions updated"),
+      pendingAskSuppressedSettlement: !firstHistory.messages.some(
+        (message) => message.signal?.tagName === "settlement-check",
+      ),
+      quoteAbsentFromPreviousArchive,
+      refusalStopReopenedRange:
+        sweepOutputs.some(
+          (output) => "status" in output && output.status === "refused",
+        ) &&
+        repairSignals.length === 1 &&
+        settlementChecks.length === 3,
+      replayRepairedOmission:
+        replayOutput !== undefined &&
+        Array.isArray(replayOutput.appliedCaptureIds) &&
+        replayOutput.appliedCaptureIds.length === 1 &&
+        Array.isArray(replayOutput.skippedDedupKeys) &&
+        replayOutput.skippedDedupKeys.length === 1,
+      secondAskRejected:
+        finalAskParts.filter(
+          (part) =>
+            part.type === "dynamic-tool" && part.state === "output-available",
+        ).length === 1 &&
+        finalAskParts.filter(
+          (part) =>
+            part.type === "dynamic-tool" && part.state === "output-error",
+        ).length === 1,
+      settlementNudgedAtEachFrontier: settlementChecks.length >= 2,
+      unaccountedAskAdvisory: appliedSweepOutputs.some((output) =>
+        JSON.stringify(output.advisories).includes("unaccounted-ask"),
+      ),
+    })}`,
+  );
+} finally {
+  delete process.env.BRUNCH_DEV_TARGET_DOCUMENT_DIR;
+  await flue.stop();
+  await rm(targetDirectory, { recursive: true });
+}
diff --git a/apps/brunch-agent/test/walking-skeleton.test.ts b/apps/brunch-agent/test/walking-skeleton.test.ts
new file mode 100644
index 00000000000..c40650f227c
--- /dev/null
+++ b/apps/brunch-agent/test/walking-skeleton.test.ts
@@ -0,0 +1,40 @@
+import { join } from "node:path";
+
+import { expect, test } from "vitest";
+
+import { runNodeScript } from "./run-node-script";
+
+test("the dev app suspends for free-text replies without instruction wakes", async () => {
+  // Spec §7.4 and §14.5's wake-wart item: the one instruction-state write path
+  // that exists must not re-trigger an advisory wake.
+  const testDirectory = import.meta.dirname;
+  const { exitCode, stdout, stderr } = await runNodeScript(
+    join(testDirectory, "walking-skeleton.integration.ts"),
+    join(testDirectory, "../../.."),
+  );
+
+  expect(exitCode, stderr || stdout).toBe(0);
+  const resultLine = stdout
+    .split("\n")
+    .find((line) => line.startsWith("WALKING_SKELETON_RESULT "));
+  expect(resultLine, stdout).toBeDefined();
+  expect(
+    JSON.parse(resultLine!.slice("WALKING_SKELETON_RESULT ".length)),
+  ).toEqual({
+    affordanceReplyClassified: true,
+    archivePointerResolved: true,
+    boundReplyReachedModel: true,
+    captureStoredThroughSweep: true,
+    capturesStayAtVerbatimFloor: true,
+    durableOutput: true,
+    markdownFloor: true,
+    noInstructionWake: true,
+    pendingAskSuppressedSettlement: true,
+    quoteAbsentFromPreviousArchive: true,
+    refusalStopReopenedRange: true,
+    replayRepairedOmission: true,
+    secondAskRejected: true,
+    settlementNudgedAtEachFrontier: true,
+    unaccountedAskAdvisory: true,
+  });
+});
diff --git a/apps/brunch-agent/tsconfig.json b/apps/brunch-agent/tsconfig.json
new file mode 100644
index 00000000000..1f44fa66022
--- /dev/null
+++ b/apps/brunch-agent/tsconfig.json
@@ -0,0 +1,21 @@
+{
+  "compilerOptions": {
+    "jsx": "react-jsx",
+    "target": "es2024",
+    "lib": ["DOM", "DOM.Iterable", "ESNext"],
+    "types": ["node", "vite/client"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "allowImportingTsExtensions": true,
+    "strict": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedIndexedAccess": true,
+    "resolveJsonModule": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "isolatedModules": true
+  },
+  "include": ["src", "test", "*.config.ts"]
+}
diff --git a/apps/brunch-agent/turbo.json b/apps/brunch-agent/turbo.json
new file mode 100644
index 00000000000..5587a8d0535
--- /dev/null
+++ b/apps/brunch-agent/turbo.json
@@ -0,0 +1,32 @@
+{
+  "extends": ["//"],
+  "tasks": {
+    "build": {
+      "dependsOn": ["^build"],
+      "outputs": ["dist/**"],
+      "cache": false
+    },
+    "dev": {
+      "dependsOn": ["^build"],
+      "cache": false,
+      "persistent": true,
+      "passThroughEnv": [
+        "ANTHROPIC_API_KEY",
+        "BRUNCH_DEV_DB_PATH",
+        "BRUNCH_DEV_TARGET_DOCUMENT_DIR",
+        "BRUNCH_PETRINAUT_ORIGINS",
+        "BRUNCH_TRANSPORT_AISDK_INSPECT"
+      ]
+    },
+    "petrinaut:dev": {
+      "dependsOn": ["^build"],
+      "cache": false,
+      "persistent": true,
+      "passThroughEnv": ["BRUNCH_CHAT_ORIGIN", "PETRINAUT_WEBSITE_ROOT"]
+    },
+    "test:unit": {
+      "dependsOn": ["build", "codegen", "^build"],
+      "env": ["TEST_COVERAGE"]
+    }
+  }
+}
diff --git a/apps/brunch-agent/vite.client.config.ts b/apps/brunch-agent/vite.client.config.ts
new file mode 100644
index 00000000000..24e399214ab
--- /dev/null
+++ b/apps/brunch-agent/vite.client.config.ts
@@ -0,0 +1,30 @@
+import { defineConfig } from "vite";
+
+/**
+ * The client build — a second, plain Vite build alongside the Flue one.
+ *
+ * `@flue/vite` forces `build.ssr` with its own fixed inputs, so the main build
+ * emits the server and nothing else: `index.html` and everything it pulls in
+ * are never transformed by it. Without this config the ui tree has no build
+ * coverage at all, and a client-side break stays invisible until someone opens
+ * the page in `vite dev`.
+ *
+ * Deliberately not the flue plugin: in dev the flue controller owns the whole
+ * request space and serves the ui itself, so this config exists only to
+ * produce — and thereby typecheck-and-bundle — the production client.
+ */
+export default defineConfig({
+  build: {
+    outDir: "dist/client",
+    emptyOutDir: true,
+    // Referenced by app.ts when serving the built ui; a hashed filename would
+    // have to be looked up through the manifest for no gain at this size.
+    rollupOptions: {
+      output: {
+        entryFileNames: "assets/[name].js",
+        chunkFileNames: "assets/[name].js",
+        assetFileNames: "assets/[name][extname]",
+      },
+    },
+  },
+});
diff --git a/apps/brunch-agent/vite.config.ts b/apps/brunch-agent/vite.config.ts
new file mode 100644
index 00000000000..e5d3a94ef1b
--- /dev/null
+++ b/apps/brunch-agent/vite.config.ts
@@ -0,0 +1,14 @@
+import { flue } from "@flue/vite";
+import { defineConfig } from "vite";
+
+import { localChatListen } from "./src/local-dev-origins.ts";
+
+// No @vitejs/plugin-react: the flue plugin's dev controller owns the whole
+// request space and hands every request to app.ts, with no fall-through to
+// vite's html middleware — so index.html is app-served and react-refresh's
+// preamble injection would never run (recorded Flue fact, spec §10). Vite's
+// core esbuild transform still compiles the .tsx modules.
+export default defineConfig({
+  plugins: [flue()],
+  server: localChatListen,
+});
diff --git a/apps/brunch-agent/vitest.config.ts b/apps/brunch-agent/vitest.config.ts
new file mode 100644
index 00000000000..8b5840acac7
--- /dev/null
+++ b/apps/brunch-agent/vitest.config.ts
@@ -0,0 +1,7 @@
+import { defineConfig } from "vitest/config";
+
+export default defineConfig({
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/apps/petrinaut-website/package.json b/apps/petrinaut-website/package.json
index 1f2f0ff519a..46e48eeb96f 100644
--- a/apps/petrinaut-website/package.json
+++ b/apps/petrinaut-website/package.json
@@ -17,6 +17,7 @@
   },
   "dependencies": {
     "@ai-sdk/openai": "3.0.63",
+    "@hashintel/brunch-agent-transport-aisdk": "workspace:*",
     "@hashintel/ds-components": "workspace:*",
     "@hashintel/ds-helpers": "workspace:*",
     "@hashintel/petrinaut": "workspace:*",
diff --git a/apps/petrinaut-website/src/main/app/local-storage-demo/brunch-ask-interactive-tool.tsx b/apps/petrinaut-website/src/main/app/local-storage-demo/brunch-ask-interactive-tool.tsx
new file mode 100644
index 00000000000..f5bee1aa485
--- /dev/null
+++ b/apps/petrinaut-website/src/main/app/local-storage-demo/brunch-ask-interactive-tool.tsx
@@ -0,0 +1,149 @@
+import { type FormEvent, useId, useState } from "react";
+
+import {
+  ASK_TOOL_NAME,
+  type BrunchAskInput,
+  type BrunchAskOutput,
+  parseBrunchAskInput,
+  parseBrunchAskOutput,
+} from "@hashintel/brunch-agent-transport-aisdk/client-tools";
+import { css } from "@hashintel/ds-helpers/css";
+import {
+  definePetrinautAiInteractiveTool,
+  type InteractiveToolWidgetProps,
+} from "@hashintel/petrinaut/ui";
+
+const containerStyle = css({
+  display: "flex",
+  flexDirection: "column",
+  gap: "2",
+  padding: "3",
+  borderWidth: "thin",
+  borderStyle: "solid",
+  borderColor: "blue.a30",
+  borderRadius: "lg",
+  backgroundColor: "blue.a10",
+});
+
+const questionStyle = css({
+  color: "neutral.s100",
+  fontSize: "sm",
+  fontWeight: "medium",
+  lineHeight: "relaxed",
+});
+
+const formStyle = css({
+  display: "flex",
+  flexDirection: "column",
+  gap: "2",
+});
+
+const labelStyle = css({
+  color: "neutral.s90",
+  fontSize: "xs",
+  fontWeight: "medium",
+});
+
+const textareaStyle = css({
+  width: "full",
+  minHeight: "20",
+  padding: "2",
+  borderWidth: "thin",
+  borderStyle: "solid",
+  borderColor: "neutral.a30",
+  borderRadius: "md",
+  backgroundColor: "neutral.s00",
+  color: "neutral.s100",
+  fontSize: "sm",
+  resize: "vertical",
+  _focusVisible: {
+    borderColor: "blue.a70",
+    outline: "2px solid",
+    outlineColor: "blue.a30",
+    outlineOffset: "[1px]",
+  },
+});
+
+const submitButtonStyle = css({
+  alignSelf: "flex-end",
+  paddingX: "3",
+  paddingY: "2",
+  borderRadius: "md",
+  backgroundColor: "blue.a85",
+  color: "white",
+  cursor: "pointer",
+  fontSize: "sm",
+  fontWeight: "medium",
+  _hover: {
+    backgroundColor: "blue.a100",
+  },
+  _disabled: {
+    cursor: "not-allowed",
+    opacity: 0.45,
+  },
+});
+
+const answerStyle = css({
+  padding: "2",
+  borderRadius: "md",
+  backgroundColor: "neutral.s00",
+  color: "neutral.s90",
+  fontSize: "sm",
+});
+
+const BrunchAskWidget = ({
+  input,
+  state,
+  submit,
+  submittedOutput,
+}: InteractiveToolWidgetProps<BrunchAskInput, BrunchAskOutput>) => {
+  const answerId = useId();
+  const [answer, setAnswer] = useState("");
+
+  const onSubmit = (event: FormEvent<HTMLFormElement>) => {
+    event.preventDefault();
+    const trimmedAnswer = answer.trim();
+    if (!trimmedAnswer) {
+      return;
+    }
+    submit({ answer: trimmedAnswer });
+  };
+
+  return (
+    <section className={containerStyle}>
+      <p className={questionStyle}>{input.question}</p>
+      {state === "submitted" ? (
+        <p className={answerStyle}>{submittedOutput?.answer}</p>
+      ) : (
+        <form className={formStyle} onSubmit={onSubmit}>
+          <label className={labelStyle} htmlFor={answerId}>
+            Your answer
+          </label>
+          <textarea
+            className={textareaStyle}
+            id={answerId}
+            onChange={(event) => setAnswer(event.target.value)}
+            placeholder="Write what you know; uncertainty is useful too."
+            rows={3}
+            value={answer}
+          />
+          <button
+            className={submitButtonStyle}
+            disabled={answer.trim().length === 0}
+            type="submit"
+          >
+            Send answer
+          </button>
+        </form>
+      )}
+    </section>
+  );
+};
+
+export const brunchAskInteractiveTool = definePetrinautAiInteractiveTool({
+  toolName: ASK_TOOL_NAME,
+  shouldHandle: () => true,
+  parseInput: parseBrunchAskInput,
+  parseOutput: parseBrunchAskOutput,
+  Widget: BrunchAskWidget,
+});
diff --git a/apps/petrinaut-website/src/main/app/local-storage-demo/local-storage-demo-app.tsx b/apps/petrinaut-website/src/main/app/local-storage-demo/local-storage-demo-app.tsx
index 87ceda4feb8..6f770fc9602 100644
--- a/apps/petrinaut-website/src/main/app/local-storage-demo/local-storage-demo-app.tsx
+++ b/apps/petrinaut-website/src/main/app/local-storage-demo/local-storage-demo-app.tsx
@@ -17,6 +17,7 @@ import {
 } from "@hashintel/petrinaut/ui";
 
 import { useSentryFeedbackAction } from "../sentry-feedback-button";
+import { brunchAskInteractiveTool } from "./brunch-ask-interactive-tool";
 import { useLocalStorageAiMessages } from "./use-local-storage-ai-messages";
 import {
   type SDCPNInLocalStorage,
@@ -256,6 +257,7 @@ export const LocalStorageDemoApp = () => {
 
   const aiAssistant = useMemo(
     () => ({
+      interactiveTools: [brunchAskInteractiveTool],
       transport: petrinautAiChatTransport,
       messages: currentNetId ? aiMessagesByNetId[currentNetId] : undefined,
       onMessages: (messages: PetrinautAiMessage[]) => {
diff --git a/libs/@hashintel/brunch-agent/.agents/skills/arc-close/SKILL.md b/libs/@hashintel/brunch-agent/.agents/skills/arc-close/SKILL.md
new file mode 100644
index 00000000000..d8e12c92901
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/.agents/skills/arc-close/SKILL.md
@@ -0,0 +1,8 @@
+---
+name: arc-close
+description: Runs the mandatory Brunch arc-close control pass before a branch closes a work arc.
+---
+
+Read `docs/agents/arc-close.md` from the Brunch context root and execute its five steps in order.
+This wrapper carries no duplicate procedure. Report the required checks and whether each
+conditional control surface changed; never persist a no-op evaluation.
diff --git a/libs/@hashintel/brunch-agent/.claude/skills/arc-close/SKILL.md b/libs/@hashintel/brunch-agent/.claude/skills/arc-close/SKILL.md
new file mode 100644
index 00000000000..d8e12c92901
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/.claude/skills/arc-close/SKILL.md
@@ -0,0 +1,8 @@
+---
+name: arc-close
+description: Runs the mandatory Brunch arc-close control pass before a branch closes a work arc.
+---
+
+Read `docs/agents/arc-close.md` from the Brunch context root and execute its five steps in order.
+This wrapper carries no duplicate procedure. Report the required checks and whether each
+conditional control surface changed; never persist a no-op evaluation.
diff --git a/libs/@hashintel/brunch-agent/.gitignore b/libs/@hashintel/brunch-agent/.gitignore
new file mode 100644
index 00000000000..200a359c9f1
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/.gitignore
@@ -0,0 +1 @@
+**/drafts/
diff --git a/libs/@hashintel/brunch-agent/AGENTS.md b/libs/@hashintel/brunch-agent/AGENTS.md
new file mode 100644
index 00000000000..f38e3481753
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/AGENTS.md
@@ -0,0 +1,48 @@
+# Brunch agent
+
+This directory is the Brunch context and agent-session root inside `hashintel/hash`. HASH root
+guidance always wins where it conflicts with this file.
+
+## Scope
+
+- `packages/core`: substrate- and renderer-independent harness and plugin SDK.
+- `packages/binding-*`: substrate bindings; each depends inward on the harness.
+- `packages/transport-*`: wire transports; none may depend on a binding.
+- `packages/plugin-*`: target plugins; each depends only on the harness.
+- `../../../apps/brunch-agent`: remote server, application composition, and local diagnostics.
+
+The context root is not a package-manager root. Do not add a `package.json`, lockfile, nested
+workspace configuration, or standalone CI here. Run package tasks through HASH's root Yarn/Turbo
+workspace.
+
+## Before changing Brunch
+
+1. Read `CONTEXT.md` and the relevant decision under `docs/adr/`.
+2. Read the protocol under `docs/agents/` that corresponds to the operation.
+3. Preserve the executable package-direction, Flue entrypoint, bundle, and hermetic-runtime gates.
+
+## Working methods
+
+- Use Graphite (`gt`) for stack operations; do not use `gh stack` in HASH.
+- Issues live in Linear team `FE`, project `brunch-agent`.
+- Keep the human-owned issue contract separate from collapsed `🏗️ Agent notes`; see
+  `docs/agents/issue-writing.md`.
+- Maintain the glossary in `CONTEXT.md` and context decisions in `docs/adr/`; see
+  `docs/agents/domain.md`.
+- Keep `docs/INDEX.md` complete and follow `docs/agents/documentation.md`.
+- Before closing a Brunch work arc, run the context-local `arc-close` skill and its canonical
+  procedure in `docs/agents/arc-close.md`.
+- At design moments involving Flue, follow `docs/agents/flue-routing.md`.
+
+The complete protocol set is:
+
+- `docs/agents/arc-close.md`
+- `docs/agents/documentation.md`
+- `docs/agents/domain.md`
+- `docs/agents/flue-routing.md`
+- `docs/agents/git-workflow.md`
+- `docs/agents/issue-tracker.md`
+- `docs/agents/issue-writing.md`
+- `docs/agents/legibility.md`
+- `docs/agents/posture.md`
+- `docs/agents/triage-labels.md`
diff --git a/libs/@hashintel/brunch-agent/CLAUDE.md b/libs/@hashintel/brunch-agent/CLAUDE.md
new file mode 120000
index 00000000000..47dc3e3d863
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/CLAUDE.md
@@ -0,0 +1 @@
+AGENTS.md
\ No newline at end of file
diff --git a/libs/@hashintel/brunch-agent/CONTEXT.md b/libs/@hashintel/brunch-agent/CONTEXT.md
new file mode 100644
index 00000000000..2dfdb637fde
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/CONTEXT.md
@@ -0,0 +1,156 @@
+# Brunch — domain language
+
+Vocabulary for the brunch elicitation system: an architecture generalizing agentic interviewing against pluggable elicitation targets. Hardened during the elicitation-kernel effort (whose spec settled 2026-08-10) and now governing this repo's implementation and the live process-model-elicitation effort alike. (The old title "Elicitation Kernel" fell to the glossary's own rule: "kernel" is a retired shell name.)
+
+## Language
+
+### Shells
+
+**Substrate**:
+The agent framework the system is built on — the Pi family, Flue — including the embedding environment's concerns: deploy target, storage-port implementation, artifact delivery, model/provider. (The retired term "host" silently bundled these with interface concerns; they split into substrate and UI. The charter non-goal "harness-agnostic core" predates this glossary and reads "substrate-agnostic".)
+_Avoid_: harness (for Pi/Flue), platform, host (for the embedding environment)
+
+**UI**:
+The interface shell: whatever affords user interaction — rendering, input, reply transport. Not bound to GUI or TUI; a chat channel qualifies.
+_Avoid_: host, host-interface, frontend, client
+
+**Harness**:
+The middle shell and the essence of the effort: the generic capability layer of the elicitation system — mechanism and orchestration (the conversation loop, the `ask` API, capture envelope, issue queue, sweep bookkeeping). Injected into plugins as a narrow context; never owned by them.
+_Avoid_: kernel, core, elicitor (as a shell name — "elicitor" may name the whole system). Exempt compound: **kernel card** (below). Exempt name: the package `packages/core` (spec §12.2) — the avoidance applies to "core" as a prose shell name, not to the package path. "Kernel invariants" renamed **harness invariants** (spec §14.1).
+
+**Plugin**:
+The innermost shell: target-defining policy. Declares packs, forms, and validators; composes at authoring time; receives harness capabilities by injection. Mostly policy — mechanism stays in the harness.
+_Avoid_: extension, pack (a pack is a unit _within_ a plugin)
+
+**Binding**:
+The substrate-facing adapter between harness and substrate: implements the harness's named substrate-capability list (tool registration, instruction assembly, persistent state, affordance emission, suspend-for-reply, private model call) in one substrate's dialect. One per substrate; the harness imports no substrate, a binding imports both. Bindings vary in size — each absorbs what its substrate lacks or forbids.
+_Avoid_: adapter (generic), integration, wrapper
+
+### Sessions & durability
+
+**Target-domain**:
+The artifact family being elicited — what a plugin defines (gherkin scenarios, assurance arguments, BPMN). The family half of the former bare "target".
+_Avoid_: target-paradigm; bare "target" where family/instance is ambiguous
+
+**Target-document**:
+The durable unit sessions attach to: one target-domain, its capture store, and its session history. Named by its purpose — its authoritative state is the capture store plus session logs, never the rendered artifact (renders are derived, cacheable, disposable). Endures independently of any session; never locks — completion is a derived status, not a write gate.
+_Avoid_: spec (as the unit name), workpiece, case, target-output
+
+**Session**:
+One substrate conversation — the full log of entries (user, agent, tool calls, injected state messages), matching Pi's session model. Per-session state is exactly: the evidence log, the swept high-water mark, the pending-affordance slot. Sessions go quiet rather than close; any session is resumable against the current state of its target-document.
+_Avoid_: sitting, conversation (as a distinct concept)
+
+**Capture store**:
+The durable, session-independent truth of a target-document: captures, issues, events. Written only by atomic sweep application (serialized); statuses and projections derive from it at read time.
+
+**Re-entry briefing**:
+The state message the harness injects when a session resumes after the world moved: computed facts only — unswept tail, world-moved delta, open issues, pending affordance. Authored on behalf of the user in the transcript (Pi's custom-entry convention) but distinguished from true user entries in the data model, and never citable as capture evidence.
+_Avoid_: sync message, forced re-sweep
+
+### Interaction
+
+**Affordance**:
+A structured interactive element (question form, choice strip, questionnaire) emitted into the conversation stream as a rendered enhancement. Not a state machine — the conversation stays primary, and an affordance's payload is evidence in the session like any other entry.
+_Avoid_: exchange, exchange pair, terminal (brunch's retired turn-by-turn ontology)
+
+**Capture**:
+Extraction of structured evidence — envelope plus plugin-typed payload — from session entries. Produced by sweeps, never written directly during conversation.
+_Avoid_: extraction, harvest
+
+**Sweep**:
+An idempotent pass over a settled range of session entries that produces captures. Re-sweeping a range never double-captures. Disambiguation: the capture store's `apply-sweep` command names only the storage half — atomically applying a sweep's proposals; the sweep proper is the capture-producing pass, which does not exist yet (FE-1392).
+
+**Settlement**:
+The agent-judged event marking a range of conversation (a vein closing) ready to sweep. Always range-level, never per-question.
+_Avoid_: exchange completion
+
+**Interpretation render**:
+The harness-owned affordance form showing current captured state — the harness frames envelope semantics; the plugin's renderer definition (typed against its own payload shapes) supplies the content view when provided, with a harness default (plain JSON view) otherwise.
+_Avoid_: digest (brunch's form)
+
+### Envelope & packs
+
+**Intermediate representation (IR)**:
+The elicited conceptual model a target-document accumulates — the middle of three registers (ADR-0003): typed **assertions** (active captures) are folded by a pure, plugin-declared fold into the **model** (the IR proper — node instances with slot states), which **projections** consume without rereading the transcript. Not a second store — the model is a derivation, recomputable from active captures at any time, never a persistence surface; the rendered artifact is one projection of the model, never the model itself. Defining a plugin's IR means writing its contract — model schema, proposal catalog, fold table, demand table (`plugin-contract-spec.md`, provisional). An earlier definition read the capture set itself as the IR; ADR-0003 amends it.
+_Avoid_: knowledge store, domain model (as a stored unit), staging area
+
+**Capture envelope**:
+The harness-defined, domain-free wrapper around an opaque plugin payload: harness-minted id, evidence spans, epistemic status, confidence, value-xor-absence, alternatives grouping, one `supersedes` link. The hourglass waist. No stored status — envelope status (`active | superseded | retracted`) derives at read time from links and events.
+
+**Evidence span**:
+A capture's provenance link: a **quoted excerpt** (primary, the model-facing citation currency) plus a **pointer** (session id + entry range, harness-derived — entry identity is harness-side vocabulary only). Anchors only on true user and user-affordance-payload entries.
+
+**Epistemic status**:
+`explicit | inferred | tentative | defaulted | external-lookup` — how a capture's content relates to what the user actually said. Distinct from confidence; excluded from capture identity. One status per capture, coupled structurally to the provenance shape (see Basis) — per-field status is unrepresentable by design (FE-1390; FE-1405's central input, consumed without amendment: the structure that wanted per-field status lives below the status, in proposal interiors).
+
+**Grade**:
+How narrow a slot value's interpretation space is — "fewer readings remain." Per-slot orderings read by the fold, promotion, and demands ("this anchor demands the `range` rung"). Never claim strength: that is confidence (`firm | hedged | speculative`, envelope-side, orthogonal by design). Two sources: **form grades** from the standard-interiors library's ladders (e.g. verbal < point < range < quantiles), **composition grades** plugin-declared (e.g. Gherkin's given-only < given-when < full-gwt). Coined by the FE-1405 arc (`plugin-contract-spec.md`, provisional).
+_Avoid_: confidence (for narrowing), precision (unqualified)
+
+**Basis**:
+The provenance carrier for non-user-grounded captures: `declared-default` or `documented-transformation`, required exactly when epistemic status is `defaulted` / `external-lookup` and structurally exclusive with evidence spans (FE-1390 coined the field for what spec §5/C5 states in prose).
+_Avoid_: evidence (for these two statuses — evidence spans cite the user)
+
+**Absence state**:
+A first-class capture value where an answer would be: `unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred` (`not-mentioned` is a computed fact, not a sweepable capture). Never collapses to null.
+_Avoid_: null, missing (as the stored representation)
+
+**Supersession**:
+The explicit correction mechanism, single-hop over active heads only. Two channels: the creation-time `supersedes` link (sweep-time correction) and the resolution record (issue-time adjudication). Superseded captures stay visible — corrections don't erase history.
+
+**Resolution record**:
+The explicit capture-store event that alone closes a `conflicting` issue (and, with no successor capture, expresses retraction). Must cite the true user's utterance as evidence.
+
+**Issue**:
+Typed, stored backpressure to the elicitation controller: `missing / ambiguous / conflicting / invalid / unsupported / unmapped / low-confidence`, with factual attributes. Two producers, namespaced: plugin ops (payload level) and the harness itself (envelope level). Closes only explicitly.
+_Avoid_: advisory (a different thing, below)
+
+**Advisory**:
+A computed, ephemeral, non-blocking fact the harness surfaces to the agent (unaccounted ask, unswept tail, world-moved delta). Never stored in the capture store; never gates anything.
+
+**Pack**:
+A unit within a plugin: **ElicitationPack** (kernel cards, completion contract, clarification hints) or **ProjectionPack** (`project` + `validate`, optional `reconcile`, annotated shapes, typed loss reports). Packs are shapes-to-fill plus behavioral guidance, per Principle v2.
+
+**Kernel card**:
+The pack-content unit of elicitation guidance: Detects / Goal / contrastive Questions / Artifacts (brunch `BEHAVIORAL_KERNELS.md` lineage — "kernel" here names a small unit of behavioral guidance, not a shell; the compound is the glossary's one sanctioned "kernel" use). Splits by ownership: domain cards are plugin pack content; a harness-shipped **generic strategy quiver** (cards over envelope vocabulary — conflict, ambiguity, weak evidence) is named in spec §11.5, not designed.
+
+**PluginContext**:
+The narrow injected context through which a plugin receives harness capabilities (the ask API, envelope, issue queue, sweep bookkeeping). The plugin's entire world at runtime; the four operations remain pure (snapshot-in/deltas-out) regardless.
+
+**Storage port**:
+The harness-defined contract for the capture store (atomic sweep application, envelope invariants as store-level refusals), implemented by the binding for its deploy target. Plugins are storage-blind. In code the port's type is `CaptureStore` (`packages/core/src/capture-store.ts`) — grep for that, not for "storage port". Scope includes the **session-log archive** (archive-on-read; spec §9.6): session logs live with the target-document, retained indefinitely — the substrate's conversation store is the live transport copy, never the provenance record.
+
+### September demo
+
+**Demo shell**:
+A retired proposal for a one-off September application (FE-1362). ADR-0004 replaced it with two
+application-owned surfaces in `hashintel/hash`: `apps/brunch-agent` runs the remote Brunch server,
+while `apps/petrinaut-website` owns the user-facing integration. Reusable Brunch and Petrinaut
+libraries remain mutually unaware.
+_Avoid_: using "demo shell" for the accepted topology
+
+**Artifact boundary**:
+The inter-library contract retained by ADR-0004: the elicitor emits a versioned net file plus
+scenario; Petrinaut consumes it through its published parser and import-with-autolayout path.
+Applications may compose both libraries, but neither reusable library consumes the other.
+_Avoid_: file handoff (undersells it), integration (generic)
+
+**Revision story**:
+The working-hypothesis demo spine (FE-1363; recommended to PM, not ratified): a sped-up recorded elicitation (conversation, interpretation surface, and growing net visible together) plus a bounded live segment in which a few turns elicit a fact forcing a structural revision of the net, run before/after in Petrinaut.
+_Avoid_: live demo (unqualified — the live part is one bounded segment, not the format)
+
+### Simulation & evaluation
+
+**Situation pack**:
+The interviewee-side bundle defining a user-to-be-simulated: situation, scenario, and persona — knowledge and motivations, some facts deliberately coloured by the persona's perspective. Private to the agent (or human) playing the user. Invariant: never authored from, or shaped to mirror, the IR — the elicitor's job is to excavate across that wall.
+_Avoid_: fact pack (undersells the persona; collides with the answer key), persona pack (too narrow)
+
+**Answer key**:
+The modeller-side list of facts the reference net needs, derived from the reference model — the evaluation rubric for what an elicitation should have excavated from a situation pack. Satisfies PRO-99's "written list of all facts necessary to make the net". Sits on the elicitor-team side of the wall; never part of the situation pack.
+_Avoid_: fact list (ambiguous with situation-pack content)
+
+**Walking skeleton**:
+A build that proves a transport or integration end-to-end on the real substrate (e.g. a real Flue agent + web UI) with stubbed internals. The term names the proof shape, not a disposal policy: the FE-1389 skeleton is retained as a durable CI gate, and its integration test pins runtime semantics nothing else does (do-not-weaken; see the Flue patterns audit).
+
+**Logic-prototype**:
+A prototype that locks down mechanism semantics (e.g. capture sweeps, settlement) in isolation, without the full host substrate.
diff --git a/libs/@hashintel/brunch-agent/README.md b/libs/@hashintel/brunch-agent/README.md
new file mode 100644
index 00000000000..2e6bbc3eb89
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/README.md
@@ -0,0 +1,19 @@
+# Brunch agent
+
+Brunch is a stateful elicitation harness and package family inside the HASH monorepo.
+
+This directory is its context and agent-session root, not a package workspace:
+
+- [`CONTEXT.md`](./CONTEXT.md) defines the domain language.
+- [`docs/adr/`](./docs/adr/) records governing decisions.
+- [`docs/spec.md`](./docs/spec.md) defines the harness contract.
+- [`docs/INDEX.md`](./docs/INDEX.md) indexes Brunch documentation.
+- [`packages/core/`](./packages/core/) is `@hashintel/brunch-agent`.
+- [`packages/binding-flue/`](./packages/binding-flue/) is the Flue binding.
+- [`packages/transport-aisdk/`](./packages/transport-aisdk/) is the AI SDK transport.
+- [`packages/plugin-gherkin/`](./packages/plugin-gherkin/) is the Gherkin target plugin.
+- [`../../../apps/brunch-agent/`](../../../apps/brunch-agent/) is the remote server and diagnostic
+  application.
+
+HASH's repository root owns package discovery, dependency policy, the lockfile, and the Turbo task
+graph.
diff --git a/libs/@hashintel/brunch-agent/docs/INDEX.md b/libs/@hashintel/brunch-agent/docs/INDEX.md
new file mode 100644
index 00000000000..ca6ea309c02
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/INDEX.md
@@ -0,0 +1,115 @@
+# Document index
+
+One line per document: what it is, where it lives, where it's used. Protocol:
+[`docs/agents/documentation.md`](agents/documentation.md). Statuses: `inbox` (awaiting
+settlement) · `active` (artifact of a live effort) · `settled` (permanent home) · `superseded`
+(retained history replaced by newer canon) · `accepted` (ratified ADR) · `external` (canonical
+copy lives outside the repo).
+
+## Inbox (awaiting settlement)
+
+_(empty — items settle out via the arc-close inbox sweep)_
+
+## Reference (settled sources)
+
+| Document                                                                                                    | Status  | Date                         | Digest                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | Used by                                                                                                    |
+| ----------------------------------------------------------------------------------------------------------- | ------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| [agentic-elicitation-challenges](reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md)          | settled | 2026-08-06                   | Turn 1 of the founding analysis: four contracts, packs, IR; source of the "capture meaning before representation" principle                                                                                                                                                                                                                                                                                                                                                                   | elicitation-kernel spec §1                                                                                 |
+| [agentic-elicitation-criteria](reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md)              | settled | 2026-08-06                   | Turn 2: hourglass, five proof obligations, ten invariants, smells, test matrix                                                                                                                                                                                                                                                                                                                                                                                                                | elicitation-kernel spec §14                                                                                |
+| [SDCPN Library - Ideas](reference/SDCPN%20Library%20-%20Ideas.md)                                           | settled | 2026-08-11                   | Eight CPS use-case sketches (physical/cyber/events/continuous-state/emergence anatomy), ChatGPT-drafted                                                                                                                                                                                                                                                                                                                                                                                       | FE-1357 map; FE-1363 candidates                                                                            |
+| [hash-sails-public-report.pdf](reference/hash-sails-public-report.pdf)                                      | settled | 2026-08-11 (pub. 2026-01)    | SAILS/ARIA public report: Safeguarded AI gatekeeper (world model + safety spec + verifier), biopharma supply-chain research, tacit knowledge as adoption barrier                                                                                                                                                                                                                                                                                                                              | FE-1357 map (the "why"); FE-1363 cold-chain anchor                                                         |
+| [voice-implementation-recommendation-pplx](reference/voice-implementation-recommendation-pplx.md)           | settled | 2026-08-11                   | Perplexity research: voice-adapter options (ElevenLabs/OpenAI/Gemini/xAI)                                                                                                                                                                                                                                                                                                                                                                                                                     | FE-1359 (superseded in part by its findings)                                                               |
+| [yannis-dora-lu-transcript](reference/yannis-dora-lu-transcript-2026-08-11.md)                              | settled | 2026-08-11                   | Meeting transcript: no in-house interviewing practice; SDCPN-as-hypothesis aired; baseline-control and priming ideas                                                                                                                                                                                                                                                                                                                                                                          | expert-meeting-findings note; FE-1360, FE-1361                                                             |
+| [amp-analysis-flue-vs-tilde](reference/amp-analysis-flue-vs-tilde.md)                                       | settled | 2026-08-14                   | Amp thread export: comparative assessment of the Flue and tilde agent frameworks (development and deployment stories) and its import for this project; verdict: keep Flue, Tilde is a control plane not a runtime                                                                                                                                                                                                                                                                             | reconciled into flue-architecture-cheatsheet (2026-08-17); source of the pre-remote-exposure gates         |
+| [2026-08 SDCPNs for cyber-physical systems](reference/2026-08%20SDCPNs%20for%20cyber-physical%20systems.md) | settled | 2026-08 (settled 2026-08-18) | Unattributed draft blog post (image placeholders, typos): five-level SDCPN explainer applied to gas supply, truck fleet, semiconductor fab; arrived during the FE-1405 arc. Read skeptically: good pedagogy, promotional register — concedes its formal guarantees don't apply once continuous/stochastic features are used (open research problem), models carry heavy kernel/guard logic that strains the "formal and inspectable" claim, and Petrinaut's integrator limitation is admitted | Register-3 background (projection-target expressivity) only; not elicitation design input; no consumer yet |
+
+## history/planning/elicitation-kernel (effort complete 2026-08-10; settled 2026-08-12)
+
+| Document                                                                                                 | Status  | Linear                                                      | Digest                                                                                                                                                                         |
+| -------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [spec.md](spec.md)                                                                                       | settled | linked from FE-1366 (context-canonical)                     | The elicitation-kernel spec: 14 sections + adjudications; FE-1437 import amendment records the native HASH package family, context root, and remote-server application charter |
+| [product-description.md](history/planning/elicitation-kernel/product-description.md)                     | settled | none                                                        | STE-style product description                                                                                                                                                  |
+| [product-description-plain.md](history/planning/elicitation-kernel/product-description-plain.md)         | settled | none                                                        | Plain-prose rendering of the product description                                                                                                                               |
+| [map.md](history/planning/elicitation-kernel/map.md)                                                     | settled | **mirrored in full**: FE-1366                               | Completed wayfinder map                                                                                                                                                        |
+| [issues/](history/planning/elicitation-kernel/issues/) 01–13                                             | settled | **mirrored in full**: FE-1367–FE-1379 (relations preserved) | 13 resolved tickets                                                                                                                                                            |
+| [notes/consistency-prepass](history/planning/elicitation-kernel/notes/consistency-prepass-2026-08-10.md) | settled | none                                                        | Pre-assembly contradiction audit (7 contradictions, adjudicated in spec Appendix A)                                                                                            |
+
+## planning/process-model-elicitation (effort active — FE-1357)
+
+| Document                                                                                                                                     | Status     | Linear                                   | Digest                                                                                                                                                                                                                                                                                                                 |
+| -------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [recommendation-demo-vehicle](planning/process-model-elicitation/recommendation-demo-vehicle.md)                                             | superseded | linked from FE-1362/1328/1329/1331/1333  | Demo-vehicle recommendation: demo shell + artifact boundary; superseded by ADR-0004 (18 Aug meeting chose in-Petrinaut staging)                                                                                                                                                                                        |
+| [petrinaut-integration-spec](planning/process-model-elicitation/petrinaut-integration-spec.md)                                               | active     | FE-1433                                  | Integration spec: elicitor as remote server behind the `aiAssistant` transport; suspension-borne client tools; `transport-aisdk`; principal + owner key; two gating spikes                                                                                                                                             |
+| [FE-1434 suspension verdict](planning/process-model-elicitation/spikes/fe-1434-suspension-verdict-2026-08-19.md)                             | active     | FE-1434                                  | Flue 2.0.3 carries a terminating client-tool batch through one durable pending slot and one non-user result signal; 3- and 100-result cases preserve ids in two dispatches                                                                                                                                             |
+| [FE-1434 suspension evidence](planning/process-model-elicitation/spikes/fe-1434-suspension-evidence-2026-08-19.json)                         | active     | FE-1434                                  | Deterministic transcript from the faux-provider runtime probe: native tool-result admission refused, signal resume succeeds, returned text is non-user and uncitable                                                                                                                                                   |
+| [adapter-panel-spike-2026-08-19](planning/process-model-elicitation/adapter-panel-spike-2026-08-19.md)                                       | settled    | FE-1435                                  | Real-panel spike verdict: AI SDK v6 SSE drives Petrinaut text/reasoning, default server-tool summaries, two live-editor client tools in one batched follow-up, and the diagnostics decorator; full POST/SSE transcript frozen as golden fixtures                                                                       |
+| [transport-aisdk-implementation-2026-08-19](planning/process-model-elicitation/transport-aisdk-implementation-2026-08-19.md)                 | settled    | FE-1436                                  | Durable real-panel transport: application `/api/chat` endpoint, substrate-neutral harness reply events, AI SDK v6 encoding, boundary gates, opt-in protocol inspection, and a clean-checkout local Petrinaut launcher                                                                                                  |
+| [ask-return-implementation-2026-08-19](planning/process-model-elicitation/ask-return-implementation-2026-08-19.md)                           | active     | FE-1449                                  | Ask suspend/return over the wire: the ask leaves as an awaiting client tool, the correlated `{ answer }` submission is admitted against durable history and resumes the conversation; stale/forged/duplicate/non-ask outputs refused before dispatch                                                                   |
+| [notes/grilling-inputs-2026-08-12](planning/process-model-elicitation/notes/grilling-inputs-2026-08-12.md)                                   | active     | referenced from map                      | Session carryover: destination trend, facets/motions, Dora-checklist validate table                                                                                                                                                                                                                                    |
+| [notes/expert-meeting-prep](planning/process-model-elicitation/notes/expert-meeting-prep-2026-08-11.md)                                      | active     | referenced from map                      | Prep brief for the Yannis meeting                                                                                                                                                                                                                                                                                      |
+| [notes/expert-meeting-findings](planning/process-model-elicitation/notes/expert-meeting-findings-2026-08-11.md)                              | active     | referenced from map                      | Meeting findings: 5 facts, 7 idea seeds, 2 commitments                                                                                                                                                                                                                                                                 |
+| [notes/open-questions-elicitation-design](planning/process-model-elicitation/notes/open-questions-elicitation-design-2026-08-11.md)          | superseded | —                                        | Draft; canonical copy is the [Notion page](https://www.notion.so/hashintel/3b93c81fe024801b89b3cf63a9a6ff20) (`external`)                                                                                                                                                                                              |
+| [research/petrinaut-survey](planning/process-model-elicitation/research/petrinaut-survey.md)                                                 | active     | gisted in FE-1358 resolution             | Petrinaut architecture/assistant/format survey + coupling audit                                                                                                                                                                                                                                                        |
+| [research/voice-feasibility](planning/process-model-elicitation/research/voice-feasibility.md)                                               | active     | gisted in FE-1359 resolution             | Voice verdict: bolt-on with constraints; T0–T3 tiers                                                                                                                                                                                                                                                                   |
+| [research/elicitation-strategy-literature](planning/process-model-elicitation/research/elicitation-strategy-literature.md)                   | active     | gisted in FE-1360 resolution             | Literature synthesis, 9 sections, verification-labeled                                                                                                                                                                                                                                                                 |
+| [research/re-interviewing-literature-worker-report](planning/process-model-elicitation/research/re-interviewing-literature-worker-report.md) | active     | noted on FE-1361                         | Verbatim instruments: 34-mistake taxonomy, question typologies, LLM-interviewer results                                                                                                                                                                                                                                |
+| [baseline/](planning/process-model-elicitation/baseline/)                                                                                    | active     | gisted in FE-1361 resolution             | Baseline-control experiment: protocol, situation pack, v0 prompt, runner, both transcripts, scored read-out                                                                                                                                                                                                            |
+| [ir-design](planning/process-model-elicitation/ir-design.md)                                                                                 | active     | gisted in FE-1364 resolution             | The IR design: Layer A (ratified on worked examples, FE-1397; definition sentence amended by ADR-0003) + the CPS plugin's ten-kind payload (Layer B)                                                                                                                                                                   |
+| [ir-worked-examples](planning/process-model-elicitation/ir-worked-examples.md)                                                               | active     | gisted in FE-1397                        | Layer-A validation across Gherkin/CPS/BPMN + assurance: property verdicts, amendments, sublimation findings                                                                                                                                                                                                            |
+| [ir-design-plain](planning/process-model-elicitation/ir-design-plain.md)                                                                     | active     | strain findings on FE-1401               | Plain-prose rendering of the IR design; the rendering pass doubled as review (7 strain findings, one load-bearing)                                                                                                                                                                                                     |
+| [notes/research-patterns-audit](planning/process-model-elicitation/notes/research-patterns-audit.md)                                         | active     | FE-1401 / card inputs on FE-1403         | Plain-language audit of ~30 research imports in 7 families, evidence-graded, with an 8-point strain appendix                                                                                                                                                                                                           |
+| [notes/penciled-directions-2026-08-14](planning/process-model-elicitation/notes/penciled-directions-2026-08-14.md)                           | active     | FE-1401                                  | Penciled directions from the legibility session: 8 items with firming actions + editorial reflections                                                                                                                                                                                                                  |
+| [capture-store-plain](planning/process-model-elicitation/capture-store-plain.md)                                                             | active     | strain findings on FE-1401               | STE-leaning rendering of the capture-store semantics (FE-1390/FE-1389) with a load-bearing not-guaranteed section; 8-point strain report incl. two command-reachable unclosable-conflict paths (confirms FE-1419 commits 7/8) and the FE-1405 status-arity answer                                                      |
+| [notes/deep-read-fe-1389](planning/process-model-elicitation/notes/deep-read-fe-1389.md)                                                     | active     | FE-1401 / findings in FE-1420            | Deep-read of the walking skeleton: builder's account, spec-discharge table (issues 10/13 capabilities discharged; markdown floor contradicted in the UI), 12 findings; source of PR #10's backfilled record                                                                                                            |
+| [notes/deep-read-fe-1390](planning/process-model-elicitation/notes/deep-read-fe-1390.md)                                                     | active     | FE-1401 / probes on FE-1419              | Deep-read of the capture store: spec-discharge table, write-time tiering assessment (penciled item 7), the FE-1405 status-arity answer, and live-probed confirmation of FE-1419's capture-store claims plus one new aliasing hole; source of PR #11's backfilled record                                                |
+| [plugin-contract-spec](planning/process-model-elicitation/plugin-contract-spec.md)                                                           | active     | FE-1431 (spec issue); decided on FE-1405 | Provisional spec: a plugin is two schemas and two tables (model schema, proposal catalog, fold table, demand table) over the three-register IR (ADR-0003) — harness-machinery typology, standard-interiors library, grade-as-narrowing, derived fold rules; strains 4–7 and envelope pressure #2 held open with owners |
+
+## planning/\_shared (cross-effort control documents)
+
+| Document                                                                         | Status                             | Linear                                                                                                          | Digest                                                                                                                                                                                                                                                     |
+| -------------------------------------------------------------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [COORDINATION](planning/_shared/COORDINATION.md)                                 | active                             | cross-project; maintained by arc-close                                                                          | Current sequencing recommendation, soft cross-map edges, unresolved seams, and exceptional roots; hard blockers, state, and hierarchy remain in Linear                                                                                                     |
+| [hash-monorepo-import-plan](planning/_shared/hash-monorepo-import-plan.md)       | active until FE-1437 lands         | FE-1437                                                                                                         | Native HASH assimilation plan: preserved history and child package workspaces under one Brunch context root, explicit authority cutover, exhaustive repository-material disposition, toolchain port, boundary gates, and verification                      |
+| [SPEC-LEDGER](planning/_shared/SPEC-LEDGER.md)                                   | active until milestone-one closure | FE-1383                                                                                                         | Obligation-level status and evidence ledger for the elicitation-kernel specification; settles when the milestone closes                                                                                                                                    |
+| [flue-architecture-cheatsheet](planning/_shared/flue-architecture-cheatsheet.md) | active                             | commented on FE-1383; feeds docs/agents/flue-routing.md                                                         | Architect's consolidation of all 21 Flue guide pages: direct structured generation uses `harness.prompt`; model-delegated work uses `useSubagent`; three-lane boundary summary and ranked divergence risks; reconciled against installed Flue 2.0.3 source |
+| [topology](planning/_shared/topology.md)                                         | active                             | ratified → ADR-0002; N1 discharged by FE-1422 + FE-1392; local N5 implemented by FE-1391; N3 amended by FE-1437 | Pseudo-style verification of the package/app tree against the three-lane model and spec §12.2: portable ask/sweep protocols, Flue binding wiring, package boundaries, and application-only Brunch–Petrinaut composition                                    |
+
+## planning/legibility-sweep (FE-1401 arc records)
+
+| Document                                                                                                                  | Status  | Linear                                                                     | Digest                                                                                                                                                                                                                                               |
+| ------------------------------------------------------------------------------------------------------------------------- | ------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [refactor-queue-2026-08-14](planning/legibility-sweep/refactor-queue-2026-08-14.md)                                       | active  | FE-1419                                                                    | Nine-commit refactor queue from an inductive review of open PR comments: capture-store contract closure + verification-oracle integrity; second-order review of the FE-1400 sweep's own countermeasures                                              |
+| [flue-patterns-audit-2026-08-17](planning/legibility-sweep/flue-patterns-audit-2026-08-17.md)                             | active  | commented on FE-1383                                                       | Audit of Flue usage against the official docs: substantially canonical; two fragile spots since fixed; its two "undocumented semantics" strain items were later resolved by the cheatsheet's agent-hooks read (documented after all — the pins stay) |
+| [flue-entry-projection-source-read-2026-08-18](planning/legibility-sweep/flue-entry-projection-source-read-2026-08-18.md) | active  | FE-1391 source gate + FE-1392 refresh oracle; reshapes FE-1386             | Installed Flue 2.0.3 evidence followed through to the public reader/archive and a causal refresh-before-apply oracle; FE-1386 remains one behavioral pin                                                                                             |
+| [remediation-plan-2026-08-17](planning/legibility-sweep/remediation-plan-2026-08-17.md)                                   | active  | A1 discharged by FE-1422; A3/B1 by FE-1391; B2/B3 by source read + FE-1392 | Two ledgers from the consolidated sweep. FE-1392 resolves the private-model-call seam with direct `harness.prompt`, while keeping free-text/abandoned accounting in FE-1420 and the compaction pin in FE-1386                                        |
+| [review-remediation-2026-08-18](planning/legibility-sweep/review-remediation-2026-08-18.md)                               | settled | FE-1432                                                                    | Executed queue from the cross-stack review: six lens-backed findings fixed, all 15 residual threads adjudicated and resolved, below-gate findings owned or refused, and three graduation proposals routed to FE-1401's tooling lane                  |
+| [issue-pr-migration-2026-08-20/](planning/legibility-sweep/issue-pr-migration-2026-08-20/)                                | settled | FE-1451                                                                    | Completed legibility migration: byte-exact snapshots of 73 Linear issues and 25 GitHub PRs, reviewed proposals, canonical stored-target hashes, rollback data, a drift-gated validator, and an append-only apply log                                 |
+
+## Decision records (`docs/adr/`)
+
+Decisions taken _after_ the elicitation-kernel spec settled. The original spec text remains the
+record of what was decided in August; later changes live in ADRs and, when an accepted execution
+contract requires the spec to carry the new operating truth, in explicitly dated amendments.
+
+| Document                                                                                                      | Status   | Linear                                     | Digest                                                                                                                                                                                                                                                                     |
+| ------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [0001-brunch-is-the-product-name](adr/0001-brunch-is-the-product-name.md)                                     | accepted | FE-1388; package naming amended by FE-1437 | `brunch` remains the product and durable-agent identity: `brunch_*` tools and `brunch-gherkin-elicitor`; FE-1437 replaces the standalone `@brunch/*` scope with HASH's `@hashintel/brunch-agent*` package family                                                           |
+| [0002-topology-and-placement-rules](adr/0002-topology-and-placement-rules.md)                                 | accepted | FE-1401; FE-1422 is its one code change    | The three-lane topology and placement rules N1–N6 ratified; N3 now places remote Brunch and Petrinaut composition only in applications; N2/N5 become boundary gates                                                                                                        |
+| [0003-three-register-ir](adr/0003-three-register-ir.md)                                                       | accepted | FE-1405                                    | The IR is the elicited conceptual model, derived by a pure fold — three registers (assertions / model / projections); write-time-only semantics; promotion never refusal; amends ir-design.md Layer A's definition sentence; full FE-1397-style pass is a stated condition |
+| [0004-in-petrinaut-staging-and-the-monorepo-import](adr/0004-in-petrinaut-staging-and-the-monorepo-import.md) | accepted | FE-1433; amended by FE-1437                | September demo stages inside demo.petrinaut.org; the private package family lives under one Brunch context root; `apps/brunch-agent` is the Petrinaut-independent remote server; `apps/petrinaut-website` is the compile-time Brunch–Petrinaut meeting point               |
+
+## External canonical documents
+
+| Document                                                                                                              | Where  | Digest                                                                                                                                                                                                     |
+| --------------------------------------------------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Brunch — September Plan](https://www.notion.so/hashintel/Brunch-September-Plan-3b33c81fe02480a5af6bf3089c3ee640)     | Notion | Product leadership's September demo vision                                                                                                                                                                 |
+| [Petri Net business use cases (DB)](https://www.notion.so/hashintel/3893c81fe0248064baa9c13fed48e016)                 | Notion | Use-case database incl. the spec'd Production Scheduling exemplar                                                                                                                                          |
+| [Eliciting process models: open questions](https://www.notion.so/hashintel/3b93c81fe024801b89b3cf63a9a6ff20)          | Notion | Team-facing known-unknowns doc, awaiting comments                                                                                                                                                          |
+| [Cyber-physical process elicitation (Dora, PRO-98)](https://www.notion.so/hashintel/3b93c81fe0248019a7beda9bb31df2c8) | Notion | 14-category elicitation ontology + strategy outline + UX ideas; input claims for FE-1362/63/64 grilling — several categories map to net constructs, several "live only in the intermediate representation" |
+| Wayfinder maps FE-1357 (live), FE-1366 (archive)                                                                      | Linear | Issue-tracker records; see `docs/agents/issue-tracker.md`                                                                                                                                                  |
+
+## Path migration note (2026-08-12)
+
+`.scratch/` is retired. Both efforts moved wholesale to `docs/planning/<effort>/` (structure
+preserved; relative links fixed). Linear references to `.scratch/...` paths predating this date
+map 1:1 to `docs/planning/...`.
diff --git a/libs/@hashintel/brunch-agent/docs/adr/0001-brunch-is-the-product-name.md b/libs/@hashintel/brunch-agent/docs/adr/0001-brunch-is-the-product-name.md
new file mode 100644
index 00000000000..a12644b40a3
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/adr/0001-brunch-is-the-product-name.md
@@ -0,0 +1,80 @@
+# ADR-0001: `brunch` is the product name, and it may appear in structure
+
+Date: 2026-08-13
+Status: accepted
+Amended: 2026-08-20 by ADR-0004 / FE-1437 (HASH package namespace)
+Supersedes: spec [§12.3](../spec.md#123-naming--tool-namespacing) in part
+Decided on: FE-1388
+
+## Context
+
+The spec was written while the product name was open. Its preamble calls
+"elicitation kernel" and "brunch-lite" working labels, and §12.3 rules that
+_nothing bakes "elicit" or "brunch" into structure_, with a provisional tool
+prefix of `bl_*`.
+
+That rule bundled two different concerns:
+
+1. **Don't name a thing after what it does.** `elicit_*` fixes the product's
+   purpose in every model-facing string it owns, and the purpose is exactly
+   what a pluggable-target architecture expects to generalize.
+2. **Don't bake in a label you expect to discard.** `brunch` was assumed
+   temporary, so committing to it would have meant a rename later across
+   package names, the npm scope, tool names, and durable agent identities.
+
+The second assumption no longer holds: `brunch` is expected to stick.
+
+Carrying `bl_*` in the meantime had a cost the spec did not anticipate. `bl` is
+brunch-lite's initials, so it never actually satisfied §12.3 — it only obscured
+the label. And an unresolved name is worst where it is most expensive to
+change: Flue's `agentName` keys durable conversation storage, so every day the
+name stayed provisional was a day the eventual rename got dearer.
+
+## Decision
+
+Adopt `brunch` as the product name and let it appear in structure.
+
+- **Product name**: `PRODUCT_NAME = 'brunch'` in `@hashintel/brunch-agent`, the single
+  source every model-facing string derives from.
+- **Tool prefix**: `brunch_*` — so `brunch_ask`, computed via `toolName()`,
+  never written as a literal.
+- **Package names**: the standalone prototype uses `@brunch/*`. FE-1437 moves the private package
+  family into HASH's organizational scope as `@hashintel/brunch-agent` and role-suffixed companions
+  (`@hashintel/brunch-agent-binding-flue`, `@hashintel/brunch-agent-transport-aisdk`,
+  `@hashintel/brunch-agent-plugin-gherkin`). This amends package placement only; `brunch` remains
+  the product identity.
+- **Agent identity**: a **noun compound, target first**, product-prefixed:
+  `brunch-gherkin-elicitor`. The next target reads `brunch-assurance-elicitor`,
+  so the family sorts together.
+
+**Concern 1 above survives intact.** The prefix names _identity, not function_:
+`elicit_*` remains forbidden, and `packages/elicit-*` with it. A test in
+`packages/core/test/naming.test.ts` enforces this; the corresponding ban on
+`brunch` is deliberately removed there rather than left to rot.
+
+## Why the agent identity carries the product prefix
+
+This is the one place the prefix is load-bearing rather than cosmetic.
+
+Flue agent identities are **global per application** and key durable
+conversation storage. The demo shell (see `CONTEXT.md`) is chartered to consume
+this library _and_ the Petrinaut libraries in one application. A bare
+`gherkin-elicitor` could collide with an agent from another library, and the
+collision would land on durable storage rather than failing at boot.
+
+The exported symbol stays the shorter `GherkinElicitor`, because it reads
+better at the mount site. Flue's `agentName` static exists precisely so durable
+identity and source-level name can differ.
+
+## Consequences
+
+- Spec §12.3's `bl_*` provisional and its "nothing bakes in `brunch`" clause
+  are **superseded by this ADR**. The original spec text remains the settled August record; dated
+  amendments carry later operating truth when an accepted execution contract requires it.
+- FE-1437 supersedes this ADR's standalone `@brunch/*` scope and role-prefixed basename rule with
+  the HASH package names above. The tool prefix and durable agent identity are unchanged.
+- A future rename is still one edit for everything model-facing, because the
+  derivation stayed. It is **not** one edit for `agentName` — that string is
+  durable-storage-keyed, and changing it orphans existing conversations. Treat
+  it as permanent.
+- `plugin-assurance`, when authored, takes `brunch-assurance-elicitor`.
diff --git a/libs/@hashintel/brunch-agent/docs/adr/0002-topology-and-placement-rules.md b/libs/@hashintel/brunch-agent/docs/adr/0002-topology-and-placement-rules.md
new file mode 100644
index 00000000000..b8a56713755
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/adr/0002-topology-and-placement-rules.md
@@ -0,0 +1,54 @@
+# ADR-0002: The three-lane topology and placement rules N1–N6
+
+Date: 2026-08-17
+Status: accepted
+Amended: 2026-08-20 by ADR-0004 / FE-1437 (N3 application placement)
+Refines: spec [§12.2](../spec.md) (package topology) with placement
+rules the spec did not state
+Decided on: FE-1401 (remediation sweep); ratified by Lu, 2026-08-17
+
+## Context
+
+The Flue architecture cheatsheet's full read of the framework's affordance surface
+([flue-architecture-cheatsheet](../planning/_shared/flue-architecture-cheatsheet.md)) sorted this
+system into three lanes: shell-facing affordances to consume directly, agent-loop capabilities
+to translate in the binding, and elicitation semantics plus the capture store to own outright.
+The topology verification ([topology.md](../planning/_shared/topology.md)) then walked the actual tree
+against that model and spec §12.2 and found one violation — the ask/suspension protocol's
+portable mechanism living in the Flue binding (the §14.2 second-binding test failing in
+spirit) — and no rule governing where upcoming work lands, which is how the violation happened.
+
+## Decision
+
+The three-lane model and placement rules N1–N6, as specified in
+[topology.md](../planning/_shared/topology.md), are ratified. In brief:
+
+- **N1**: the ask protocol extracts to `core/src/ask-protocol.ts` (FE-1422, before FE-1392);
+  sweep mechanism starts in `core/src/sweep-protocol.ts` from day one. Bindings contain hook
+  wiring only.
+- **N2**: plugin-owned content (packs, cards) ships as plugin-package exports registered by
+  hosts — never per-agent `skills/` directories holding plugin content inside an app. Quiver
+  content is harness-shipped under the same rule.
+- **N3**: there is no dedicated demo shell. Applications are the only composition boundary:
+  imported `apps/brunch-agent` owns the remote Brunch server, target gallery, and diagnostics;
+  `apps/petrinaut-website` owns the September user-facing integration. Reusable Brunch and
+  Petrinaut libraries remain mutually unaware.
+- **N4**: experiment runners live beside their planning docs, JS-API pattern, `observe()`
+  accounting — never in `packages/`.
+- **N5**: storage-port implementations live one per (binding × deploy target), always in the
+  binding package, implementing core's `CaptureStore` with parse-on-read.
+- **N6**: `plugin-assurance`, when chartered, mirrors `plugin-gherkin`'s shape.
+
+`topology.md` remains the living reference (tree, per-node rules, tolerated-untils); this ADR
+records that its rules are decided, not proposed.
+
+## Consequences
+
+- FE-1422 is the one code change the ratification demands; it blocks FE-1392 by design.
+- The enforceable rules become boundary gates: N2 (no plugin content in app skills
+  directories) and N5 (port implementations only in bindings) get mechanical checks in
+  `packages/core/test/architecture/boundaries.test.ts` — designed with red-proofs, not filename
+  heuristics, per the
+  FE-1419 queue's discipline.
+- The two tolerated-untils stand: `chat.tsx` until FE-1385 adopts `@flue/react`; the flat
+  agent file until a second agent forces per-agent folders.
diff --git a/libs/@hashintel/brunch-agent/docs/adr/0003-three-register-ir.md b/libs/@hashintel/brunch-agent/docs/adr/0003-three-register-ir.md
new file mode 100644
index 00000000000..41c926cc4b4
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/adr/0003-three-register-ir.md
@@ -0,0 +1,75 @@
+# ADR-0003: The IR is the elicited model, derived — three registers, not one
+
+Date: 2026-08-18
+Status: accepted
+Amends: [ir-design.md](../planning/process-model-elicitation/ir-design.md) Layer A (the
+"Definition" paragraph), ratified FE-1364/FE-1397
+Decided on: FE-1405 (payload-interiors session); ratified by Lu, 2026-08-18
+
+## Context
+
+Layer A defined the intermediate representation as "the set of active captures, read through
+the plugin's declared payload type system," with every consolidated view a read-time
+projection. Working FE-1405's payload interiors against the baseline transcripts exposed the
+problem with that sentence: a bag of typed assertions is not a model of the plant. Mapping
+captures to a catalog of semantic types is a first small step that quietly delegates the
+actual assembly of a domain model to something several degrees removed — and unowned. The
+questions the system exists to answer ("is this model complete enough to answer the expert's
+objective?") are questions about a _model_, not about captures.
+
+The obvious fix — assemble the model at read time — founders on a real chasm: bridging "half
+a shift" or "every week or two" to model slots takes semantic interpretation, i.e. LLM
+inference, and interpretation hidden inside a read path is unauditable and unreproducible.
+
+## Decision
+
+Three registers, each with a designed schema:
+
+1. **Assertions** (captures) — answer-shaped typed semantic proposals, envelope-wrapped:
+   verbatim forms, hedges, absences, provenance. Every write-time semantic act — unit
+   parses, identity links, compositions, formalizations — is deposited here as a capture
+   (`inferred`, supersedable, contestable).
+2. **The elicited model** — the IR proper: domain-shaped, expert vocabulary, node kinds with
+   slots. **Derived, never stored**: assembly is a pure fold over active captures, forbidden
+   to interpret. Gaps surface as typed issues, never as silent inference. Every model part
+   answers "which captures made you."
+3. **Projections** — the net, the loss report, the completion table — derived from
+   register 2.
+
+Binding rules that make the split honest:
+
+- **Write-time-only semantics.** No semantic act at read time; every bridge is a capture.
+  The model is a pure function of the store, and the store contains every semantic judgment
+  the assembly needs, because the assembly is forbidden to make any.
+- **The acceptance oracle.** A second projection must be able to consume the conceptual
+  model without rereading the transcript or semantically interpreting generic capture
+  fields. If it can't, we have a capture ledger, not an IR.
+- **Promotion, never refusal.** Low-grade statements ("about 3 hours") are captured
+  honestly; the forcing function is that they never promote to a demanded grade without a
+  higher-grade capture superseding them.
+
+"No second store" survives intact — register 2 is a derivation, not a persistence surface.
+Layer A's five MUST properties and its recommended patterns are unamended; what changes is
+the definition sentence: the IR is register 2, and "active captures read through the payload
+type system" describes register 1.
+
+## Condition
+
+FE-1397's ratification bar applies to this amendment as it did to the original: worked
+designs across at least three plugin targets. Discharged so far by thumbnails only (Gherkin
+thin, formal-verification mid, CPS in full — recorded in the FE-1405 shapes work); a full
+FE-1397-style property-by-property pass is a stated condition on this record. Until the
+September build exercises a real fold, everything here is desk-validated, like the canon it
+amends.
+
+## Consequences
+
+- The FE-1405 output is a plugin _contract_, not just payload shapes: a model schema and a
+  proposal catalog (the two registers' declarations) joined by a fold table and a demand
+  table. Spec forthcoming from the session's working material.
+- Completion (FE-1402) computes over register-2 slot states, not over capture counts.
+- The sweep (FE-1392) becomes the single point of semantic failure by design — mitigations
+  travel with the FE-1405 handoff notes.
+- The capture envelope is untouched. The one pressure this work confirmed (absence captures
+  carry no locator, so a field-specific absence cannot name its slot) stays recorded at the
+  seam, pending adjudication — not forked around.
diff --git a/libs/@hashintel/brunch-agent/docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md b/libs/@hashintel/brunch-agent/docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md
new file mode 100644
index 00000000000..990ded32c95
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md
@@ -0,0 +1,83 @@
+# ADR-0004: In-Petrinaut demo staging and the brunch-agent monorepo import
+
+Date: 2026-08-18
+Status: accepted
+Amended: 2026-08-20 by FE-1437 (package family and imported application charter);
+2026-08-21 by FE-1437 (Brunch context root)
+Supersedes: the demo-shell recommendation in
+[recommendation-demo-vehicle](../planning/process-model-elicitation/recommendation-demo-vehicle.md)
+(FE-1362's resolution); amends ADR-0002's rule N3
+Decided on: the 2026-08-18 integration meeting (Dei, Chris, Lu); recorded on FE-1433
+
+## Context
+
+The demo-vehicle recommendation (FE-1362, the September demo staging decision) proposed a
+one-off demo shell consuming the elicitation and Petrinaut libraries, meeting at the artifact
+boundary. The 2026-08-18 integration meeting decided otherwise: the desired staging is
+**integration into demo.petrinaut.org** (`apps/petrinaut-website` in `hashintel/hash`) — the
+product view being that the existing implementation surface should be extended rather than
+paralleled.
+
+A re-assessment against the Petrinaut survey (FE-1358, the read-only architecture audit)
+found the topology viable without changes to the Petrinaut chat panel: the panel's
+`aiAssistant` prop takes a host-supplied `ChatTransport`, wraps it with its own decorators, and
+executes tool calls client-side against the live editor. What Petrinaut lacks — a server-side
+home for a stateful agent loop with durable persistence — is exactly what the elicitor server
+is. The meeting also settled the library's name and destination: `@hashintel/brunch-agent`,
+imported with git history into the `hashintel/hash` monorepo as a native workspace alongside
+`@hashintel/petrinaut`. The review and spike gates for that import are now satisfied.
+
+## Decision
+
+1. **Staging**: the September demo runs inside demo.petrinaut.org. The elicitor is a **remote
+   server** the site's chat panel addresses through the `aiAssistant` transport; the site's
+   stock `/api/chat` proxy and `petrinautAiPrompt` are bypassed entirely for brunch sessions.
+2. **Identity of the package family**: `@hashintel/brunch-agent` is the harness package, imported
+   into `hashintel/hash` with git history preserved and accompanied by the independently installable
+   `@hashintel/brunch-agent-binding-flue`, `@hashintel/brunch-agent-transport-aisdk`, and
+   `@hashintel/brunch-agent-plugin-gherkin` packages. All four are private through the import and
+   live under `libs/@hashintel/brunch-agent/packages/`, with the harness implementation in
+   `packages/core`; the harness does not re-export its extensions.
+3. **Boundary discipline** (the rule the monorepo makes easy to erode): `@hashintel/petrinaut`
+   stays elicitor-agnostic; `@hashintel/brunch-agent` stays renderer-agnostic;
+   **`apps/petrinaut-website` is their compile-time meeting point**. The `apps/brunch-agent`
+   server remains Petrinaut-independent and meets the website only through the AI SDK/HTTP
+   transport. Any Petrinaut-library change brunch needs is made as a generic host extension (e.g.
+   host-supplied client-tool handlers on the `aiAssistant` prop), never as brunch-specific
+   code in the library.
+4. **Session identity**: the principal lives in the ui shell, per spec §4 — a
+   localStorage-stored random UID sent on the transport for the demo site; HASH's Ory identity
+   later. The elicitor server resolves principal → session set; the harness stays
+   principal-free (keyed by session id), with an opaque owner key at the storage port for
+   store-level refusal of cross-principal access.
+5. **N3 amended**: ADR-0002's "the demo shell is `apps/demo`" is retired — there is no demo
+   shell. The imported `apps/brunch-agent` re-charters `apps/dev` as the remote Brunch server,
+   carrying forward its target-gallery and diagnostics charter as internal operational roles. The
+   September user-facing application is `apps/petrinaut-website`.
+6. **Context locality**: `libs/@hashintel/brunch-agent/` is the Brunch context and agent-session
+   root. It owns the domain glossary, decisions, guidance, planning records, and the four child
+   package workspaces. It is not a package-manager root and carries no package manifest, lockfile,
+   or competing toolchain. `apps/brunch-agent` remains at HASH's application root and points back
+   to this context authority.
+
+The artifact boundary (versioned net file + scenario through `parseSDCPNFile`) remains the
+inter-library contract and the "it's just a file" demo beat; what this ADR changes is where the
+elicitor is staged, not what it emits.
+
+## Consequences
+
+- FE-1362 re-resolves to this decision; FE-1333 (the integration-definition ticket) closes on
+  this ADR; FE-1331 (start elicitation from create-new-net) is un-deferred — in-Petrinaut
+  initiation is now the September topology, not the post-September one.
+- The integration build was specified on FE-1433
+  ([petrinaut-integration-spec](../planning/process-model-elicitation/petrinaut-integration-spec.md)),
+  and both gating spikes reported: Flue turn suspension carries client-tool round-trips, and the
+  Pi-to-AI-SDK stream adapter drives Petrinaut's panel.
+- The review stack and spikes have landed. FE-1437 records the final standalone SHA and imports
+  that history; from that point unfinished work continues only in `hashintel/hash`.
+- Grouping the package family under one context root preserves one glossary and one agent operating
+  surface without recreating the standalone Bun workspace.
+- The Flue server's deployment home is an open question owned with infra (Postgres exists;
+  deployment is unblocked by the import decision — the code will live in `hashintel/hash`).
+- FE-1433 applied the transport and suspension amendments. FE-1437 explicitly amends §12.2 and
+  §12.5 for the imported package family and application charter.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/arc-close.md b/libs/@hashintel/brunch-agent/docs/agents/arc-close.md
new file mode 100644
index 00000000000..5f24239ee15
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/arc-close.md
@@ -0,0 +1,81 @@
+# Arc close
+
+Arc close is the required final control pass before submitting a branch that closes a work arc.
+Load the `arc-close` skill and run this protocol; do not rely on remembering its constituent
+checks. It complements, rather than replaces, the legibility protocol's close-out rendering for
+arcs with significant agent-generated output.
+
+An arc is closing when a bounded branch or session lands implementation, settles a planning or
+design decision, closes or materially changes a Linear issue, or changes a project control
+surface. Exploratory work that leaves no durable truth does not require arc close.
+
+If a conditional pass changes nothing, do not append a dated evaluation or no-op record. Git is
+the history of these control surfaces.
+
+## Required sequence
+
+### 1. Settle the inbox and reconcile the index
+
+Always inspect `docs/inbox/` and `docs/INDEX.md` together.
+
+- Move settled inbox material to its canonical home under `docs/reference/`,
+  `docs/planning/<effort>/`, or `docs/planning/_shared/`.
+- Delete source material only when its durable information has been transferred and its
+  consumption is named.
+- Ensure every non-archive Markdown document is indexed and every index entry still resolves.
+- Update status, ownership, and digest text when this arc changed their truth.
+
+### 2. Audit the Linear registry and touched references
+
+Always run `turbo run linear:graph --filter '@hashintel/brunch-agent'` and inspect every open project
+issue with no parent.
+
+- Every non-root issue must have a parent.
+- Every intentional root must be a recognized map or sweep root under the registry rule, or be
+  named under **Exceptional roots** in `docs/planning/_shared/COORDINATION.md`.
+- Repair missing parentage in Linear when the intended owner is unambiguous; otherwise record the
+  unresolved root in `COORDINATION.md`.
+- Re-read every issue the arc closes or materially changes. Repair stale branch, dependency,
+  evidence, and document references before closing it.
+- Follow `issue-writing.md`: preserve a root issue's human-owned contract and put agent-maintained
+  detail inside `🏗️ Agent notes`.
+
+### 3. Reconcile the spec ledger when affected
+
+Update `docs/planning/_shared/SPEC-LEDGER.md` in the same change when the arc builds, disproves,
+supersedes, or changes evidence for a milestone-one specification obligation. Change the smallest
+affected set of rows; do not add an evaluation narrative. When milestone one closes, settle the
+ledger as a terminal record rather than keeping it artificially live.
+
+### 4. Reassess project coordination when affected
+
+Reassess `docs/planning/_shared/COORDINATION.md` when the arc changes:
+
+- a hard blocker, issue parent, project membership, or exceptional root;
+- a soft `coord`, `input`, or `state-gate` edge;
+- an unresolved cross-map seam; or
+- issue semantics that could change the current project-wide sequencing recommendation.
+
+Use `turbo run linear:graph --filter '@hashintel/brunch-agent'` for deterministic facts, then read
+the relevant issue bodies and infer the recommendation. Linear remains canonical for hard blockers,
+state, and hierarchy. Keep one compact pseudo-style map of the current recommendation; do not paste
+the full generated graph or maintain alternative or historical orderings. If the judgment did not
+change, leave the document untouched.
+
+### 5. Repair tense and report
+
+Read the arc's planning prose in the state that will exist after landing. Remove stale future
+tense, provisional labels, temporary pointers, and inaccurate status language. Report which
+control surfaces changed and which conditional passes were not applicable; do not persist the
+no-op report in those surfaces.
+
+## Definition of done
+
+Arc close is complete when:
+
+1. inbox and index agree with the tree;
+2. the Linear orphan audit has no unexplained roots;
+3. touched issue references are current;
+4. affected spec-ledger rows are current;
+5. affected coordination judgment is current; and
+6. changed planning prose reads correctly after landing.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/documentation.md b/libs/@hashintel/brunch-agent/docs/agents/documentation.md
new file mode 100644
index 00000000000..daa7b5a05ff
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/documentation.md
@@ -0,0 +1,71 @@
+# Documentation protocol: ingest, settle, index
+
+How documents enter the Brunch context, where they end up, and how we prove nothing is lost. Companion
+to `issue-tracker.md` (which governs issues; this file governs documents).
+
+## Zones
+
+| Zone                      | Role                                                                                                                                | Lifetime                                           |
+| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
+| `docs/inbox/`             | Untriaged arrivals: PDFs, exports, transcripts, pasted research. Timestamped filenames where the arrival date matters.              | Temporary — everything here is awaiting settlement |
+| `docs/planning/<effort>/` | All artifacts of an effort, active or complete: notes, research findings, maps, specs — nested by effort name.                      | Permanent (dispositioned at effort close)          |
+| `docs/planning/_shared/`  | Cross-effort control documents: current coordination, obligation ledgers, topology, and consolidations that outlive any one effort. | Permanent; lifecycle declared by each document     |
+| `docs/reference/`         | Settled documents of lasting value: external reports, transcripts, digested research.                                               | Permanent                                          |
+| `docs/INDEX.md`           | The TOC: one line per settled or in-flight document — title, date, one-line digest, provenance, where used.                         | Permanent, always current                          |
+| `CONTEXT.md`              | Glossary only (see domain-modeling discipline).                                                                                     | Permanent                                          |
+
+**Ephemera** live outside all zones: any directory named `drafts/` is git-ignored (root
+`.gitignore`), for documents whose delivered form is the record — outbound comment and message
+drafts, one-off prep. Place one directly inside the effort it serves
+(`docs/planning/<effort>/drafts/` — no deeper nesting). Never register drafts in `INDEX.md`, and never link a
+`drafts/` path from Linear or a committed document — once delivered, link the destination
+(the posted comment, the sent message) instead.
+
+**Control surface vs record.** A _record_ is arc-scoped, carries its date in the filename, and
+eventually stops changing — it lives inside the effort directory that produced it. A
+cross-effort _control surface_ is never dated in the filename and lives in
+`docs/planning/_shared/`. Most remain current; a bounded ledger may declare its own terminal
+condition and settle when that condition is met. The planning top level contains only
+directories; this rule and `INDEX.md` coverage (every file has a row, every row's path resolves)
+are enforced by `packages/core/test/architecture/docs-index.test.ts`. Freshness — whether statuses and digests are still
+_true_ — cannot be mechanized without building a dead gate; it belongs to the arc-close sweep.
+
+External stores (Linear, Notion) hold _pointers and mirrors_, never the only copy: Linear issue
+descriptions gist and link; Notion pages that originate content (e.g. team-facing question docs)
+are listed in `INDEX.md` with their URL.
+
+## The ingest protocol
+
+1. **Arrive**: new material lands in `docs/inbox/` (timestamped name if the date matters).
+2. **Register**: the first time a document is _used_ (read into an effort, cited by a ticket),
+   add its line to `docs/INDEX.md` with status `inbox`.
+3. **Settle**: move it to its permanent home (`docs/reference/` for external/source material;
+   `docs/planning/<effort>/` if it is a working artifact of that effort), update its `INDEX.md`
+   line (new path, status `settled`), and fix any links that pointed at the inbox path.
+4. **Sweep**: at every effort boundary (map charted, map closed), empty the inbox — everything
+   either settles or is deleted _with its INDEX line recording the deletion and reason_. This
+   runs as step 1 of the arc-close sweep (`arc-close.md`).
+
+## Referencing ephemera (issues, external state)
+
+Long-lived documents outlive the trackers they cite. Three rules:
+
+- **Gloss at first mention**: an issue ID in a living document is introduced with its gist —
+  "FE-1423 (the pre-remote gates)" — so the document degrades gracefully for a reader who
+  cannot resolve Linear.
+- **Load-bearing only in the tracking layer**: coordination and obligation/remediation ledgers
+  may depend on issue resolution — tracking is their job. Everywhere else an issue ID is a
+  parenthetical citation the sentence must survive without.
+- **Tense repair at arc close**: prophecy becomes history when the issue lands ("will
+  extract" → "extracted (FE-1422)") — step 5 of `arc-close.md`.
+
+## Effort completion
+
+When an effort closes, its `docs/planning/<effort>/` directory is reviewed file-by-file and
+the review recorded in `INDEX.md`: tracker records (map, tickets) are mirrored to Linear if
+not already there; everything else stays in place with status `settled`. (`.scratch/` was
+retired 2026-08-12 — efforts live under `docs/planning/` from birth.)
+
+**Nothing is deleted until its `INDEX.md` line records the disposition.** Linear mirrors gist
+and link; the repo copy is canonical, so a repo path referenced from Linear must never be
+deleted without updating the Linear reference.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/domain.md b/libs/@hashintel/brunch-agent/docs/agents/domain.md
new file mode 100644
index 00000000000..a0a98c58290
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/domain.md
@@ -0,0 +1,45 @@
+# Domain Docs
+
+How engineering skills consume Brunch domain documentation inside the HASH monorepo.
+
+## Before exploring, read these
+
+- **`CONTEXT.md`** at the Brunch context root
+- **`docs/adr/`** — read ADRs that touch the area you're about to work in
+
+If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `ds-domain-modeling` skill (also reached from the grilling and codebase-deepening flows in the same skill set) creates them lazily when terms or decisions actually get resolved.
+
+## File structure
+
+Brunch is one context inside the multi-context HASH repository:
+
+```text
+libs/@hashintel/brunch-agent/
+├── CONTEXT.md
+├── docs/adr/
+│   ├── 0001-example-decision.md
+│   └── 0002-another-decision.md
+└── packages/
+    ├── core/
+    ├── binding-flue/
+    ├── transport-aisdk/
+    └── plugin-gherkin/
+
+apps/brunch-agent/  # host module governed by this context
+```
+
+Package seams do not imply separate domain contexts. Add another Brunch `CONTEXT.md` only if the
+domain language itself diverges enough to require an explicit context map; do not create one merely
+because another binding, transport, plugin, or host appears.
+
+## Use the glossary's vocabulary
+
+When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
+
+If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `ds-domain-modeling`).
+
+## Flag ADR conflicts
+
+If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
+
+> _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_
diff --git a/libs/@hashintel/brunch-agent/docs/agents/flue-routing.md b/libs/@hashintel/brunch-agent/docs/agents/flue-routing.md
new file mode 100644
index 00000000000..62938e2db1e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/flue-routing.md
@@ -0,0 +1,43 @@
+# Flue routing: what to rely on, by symptom
+
+Consult this at design moments — when you notice yourself about to add state, a layer, a
+loop, a route, or a test harness — _before_ writing the new thing. Each row routes an
+indication to the affordance to rely on, the divergence it exists to prevent, and the point
+where canon stops and a human or an owning ticket decides. Every row is grounded in the
+[architecture cheatsheet](../planning/_shared/flue-architecture-cheatsheet.md) (§ refs), the
+[patterns audit](../planning/legibility-sweep/flue-patterns-audit-2026-08-17.md), or the
+[flue-vs-tilde analysis](../reference/amp-analysis-flue-vs-tilde.md); details live there.
+
+**Which lane am I in?** Flue's surface sorts our system into three lanes (cheatsheet,
+boundary summary). _Shell-facing_ (UI transport, observability, evals, schedules, deploy):
+consume Flue directly, never wrap. _Agent-loop_ (tools, state, suspension, subagents,
+projection reads): translate in the binding — the eight-capability list is the line.
+_Elicitation semantics + capture store_: ours outright; canon itself says "your application
+should manage its own data store separately". If your change doesn't fit its lane, that is
+the finding — stop and check the boundary summary before proceeding.
+
+## Routing table
+
+| Indication                                                                              | Rely on                                                                                                                                                                                                                                                                                                                                                                            | Never                                                                                                                                                                                     | Escalate when                                                                                                                                                                                                                                          |
+| --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| You're about to persist **per-conversation** state                                      | `usePersistentState` — atomic with the unit of work; updater form sees the latest write, documented ([agent-hooks](https://flueframework.com/docs/guide/agent-hooks/); §2)                                                                                                                                                                                                         | A side file or table keyed by conversation id — a parallel copy of Flue's own record                                                                                                      | The state is really per-_target-document_ → next row                                                                                                                                                                                                   |
+| You're persisting **cross-conversation** state (captures, issues, target-documents)     | The storage port / capture store — lane 3, ours ([database](https://flueframework.com/docs/guide/database/); §5)                                                                                                                                                                                                                                                                   | `db.ts` or DO SQLite for captures — Flue's stores are conversation-scoped, and the analysis confirms the capture store stays application-owned under every future                         | Schema changes → the archive slot's `migrate()`-style versioned provisioning (FE-1391)                                                                                                                                                                 |
+| You need the **model to see a harness fact**                                            | `ctx.append` signal entries (same-response) or tool results; instructions stay render-invariant (§2; spec §7.4)                                                                                                                                                                                                                                                                    | Interpolating state into instructions — that is the wake-wart, killed at its cause in FE-1389                                                                                             | The fact must also be user-visible → §9.3 insertion notice, FE-1396                                                                                                                                                                                    |
+| You're adding a **second place that renders conversation parts**                        | `useFlueAgent()` — parts-based messages; the affordance arrives as a `dynamic-tool` part whose `.output` is the validated payload, text parts as floor ([react](https://flueframework.com/docs/guide/react/); §4)                                                                                                                                                                  | Growing `chat.tsx` feature-by-feature into a hand-rolled client — divergence risk 1, and it's how the markdown floor broke                                                                | Adoption timing is FE-1385 / demo-shell; the floor fix is FE-1420 — don't build it twice                                                                                                                                                               |
+| You're touching the **kickoff or injected entries**                                     | `useInitialData` (recorded once, structurally non-user) or a dispatched `signal` (§2, §4)                                                                                                                                                                                                                                                                                          | Machine-authored `kind: 'user'` entries — anchorable non-utterances that launder system words into the person's mouth (trace §9.4)                                                        | The re-entry briefing's insertion notice — FE-1396                                                                                                                                                                                                     |
+| You need a **private model call**                                                       | For deterministic structured work inside a harness tool, `harness.prompt(..., { result })` ([tools](https://flueframework.com/docs/guide/tools/); §3). For model-chosen specialist delegation with its own frame/model, declare `useSubagent`; the parent invokes it only through the model-visible `task` tool ([subagents](https://flueframework.com/docs/guide/subagents/); §2) | A second provider client hand-rolled inside the binding, or pretending `useSubagent` returns a callable delegate                                                                          | The deterministic call needs a distinct model/frame → accept model-driven `task` delegation or raise a substrate-capability decision; do not blur the two surfaces                                                                                     |
+| You want **work to survive a crash**                                                    | `durable: true` tools + `step.do` — exactly-once-recorded; hooks run at-least-once, so guard side effects with persistent state ([tools](https://flueframework.com/docs/guide/tools/); §3, §5)                                                                                                                                                                                     | Assuming an external effect ran once — the at-least-once floor is universal (tilde analysis); content-keyed dedup exists _because_ of it                                                  | Orchestration itself must survive interruption → external engine seam (§6), a human call                                                                                                                                                               |
+| You're adding an **HTTP surface**                                                       | Explicit mounts in `app.ts`; `createAgentRouter`; auth as app middleware ([routing](https://flueframework.com/docs/guide/routing/); §1, §4)                                                                                                                                                                                                                                        | Side-channel servers or file-based routing — removed in 2.0; `app.ts` owns every mount                                                                                                    | Anything exposed beyond localhost → pre-remote row below                                                                                                                                                                                               |
+| You're writing a **loop that drives an agent through turns** (experiment, runner, cron) | The JS-API workflow pattern: `start()` + `init()` + `dispatch()`/`read()`; schedules resolve on durable admission ([workflows](https://flueframework.com/docs/guide/workflows/), [schedules](https://flueframework.com/docs/guide/schedules/); §6)                                                                                                                                 | A bespoke runner daemon — the baseline runner already converged on the documented pattern independently                                                                                   | FE-1404 owns the armed rerun's design                                                                                                                                                                                                                  |
+| You're writing a **test that boots the runtime**                                        | In-process `start()` + `init()` (no id → fresh conversation) + `read()`; faux provider; the reviewed substrate inventory in `test/boundaries.test.ts` ([evals](https://flueframework.com/docs/guide/evals/); §7)                                                                                                                                                                   | Substrate imports outside the inventory; substring oracles over stringified history when `onEvent` captures tool calls directly                                                           | The code under test rides the Vite graph (skills) — plain runners can't load it; eval config or fixture-grade copies (reconciliation §)                                                                                                                |
+| You're **counting tokens or costs**                                                     | `observe()` `turn` events (`totalTokens`, `cost`, cache splits); `useResponseFinish` in-agent ([observability](https://flueframework.com/docs/guide/observability/); §7)                                                                                                                                                                                                           | Hand-counting from transcripts — divergence risk 5                                                                                                                                        | Cross-process aggregation — events are live-only; export via OTel instead                                                                                                                                                                              |
+| You're **scoring elicitation quality**                                                  | `vitest-evals` judges (`createJudge`, `FactualityJudge`) asserting behavioral contracts (§7)                                                                                                                                                                                                                                                                                       | String assertions on real-model output                                                                                                                                                    | FE-1407's failure catalogue is the rubric source                                                                                                                                                                                                       |
+| You're **loading guidance content into the prompt**                                     | Skills: name+description in prompt, `activate_skill` for full instructions — progressive disclosure _is_ the card economy of penciled item 4; `defineSkill` for programmatic packs; `useInstruction()` for always-on content ([skills](https://flueframework.com/docs/guide/skills/); §3)                                                                                          | A bespoke card loader in the harness — divergence risk 3                                                                                                                                  | Card-to-skill compilation is FE-1403/FE-1406 design; keep card content assertable outside the Vite graph                                                                                                                                               |
+| You're about to **wrap a Flue API in a binding layer**                                  | The three-lane test (boundary summary): shell-facing → consume directly; agent-loop → it should already be on the eight-capability list                                                                                                                                                                                                                                            | Wrapping lane-1 affordances — a parallel SDK, lens-2 debt at the API level                                                                                                                | A genuinely new capability → extend `capabilities.ts` and apply the second-binding test (spec §14.2)                                                                                                                                                   |
+| You're **archiving or reading conversation history**                                    | `createFlueClient({ url, fetch? }).history()` — one unpaged public materialized-message snapshot. The host injects the full conversation URL because Flue cannot discover its mount; custom `fetch` plus the router's `.fetch` is the candidate in-process composition (source-read record; §4, §5)                                                                                | Shadow-recording entries inside hooks, consuming private canonical record types, or inventing offset arithmetic — all create a drifting second protocol (divergence risk 4)               | FE-1391 must pin the in-lifecycle transport, archive pointer identity (public IDs are not canonical ranges), and identity-keyed merge/version semantics for repeated snapshots; retention authority vs. transport copy remains adjudicated (spec §9.6) |
+| You're about to **expose the demo remotely**                                            | The four gates, all before exposure: auth + per-conversation authorization (the mounted route is public), runtime telemetry, persisted-state versioning/backup, restart durability. All four are ticketed as **FE-1423** (FE-1396 blocks it, covering durability); they are requirements, not recommendations (ratified 2026-08-17)                                                | Exposing the mounted route while any FE-1423 gate is open                                                                                                                                 | A deploy-target choice → N5 applies (new storage-port impl in the binding, never a leaked path assumption)                                                                                                                                             |
+| You're **deploying the demo shell**                                                     | `dist/server.mjs` + a real `db.ts` adapter; one live owner per conversation; env read at startup only (§1)                                                                                                                                                                                                                                                                         | Active-active replicas behind a shared database — the one-owner rule is not relaxed by sharing storage                                                                                    | Cloudflare is not a casual choice: per-object SQLite replaces `db.ts` and the capture store needs a separate cross-conversation design (§8)                                                                                                            |
+| You're **upgrading Flue**                                                               | Re-verify the walking-skeleton pins (`boundReplyReachedModel`, `secondAskRejected`, `noInstructionWake`) and the FE-1386 compaction/history/state pin — they protect documented-but-load-bearing or source-settled semantics (audit; source-read record; §2/§5)                                                                                                                    | Treating minor bumps as safe or docs' future tense as shipped — 2.0.0 rewrote the architecture days before 2.0.3, and beta stores were rejected with no migration path (reconciliation §) | Any pin flips → stop; re-read agent-hooks, streaming protocol, and durability before adapting the binding                                                                                                                                              |
+
+Rows route to tickets by design: if your situation's "Escalate when" names an issue, the
+decision belongs there — record it there, not in the code comment.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/git-workflow.md b/libs/@hashintel/brunch-agent/docs/agents/git-workflow.md
new file mode 100644
index 00000000000..90600c48944
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/git-workflow.md
@@ -0,0 +1,47 @@
+# Git workflow: Graphite stacks
+
+Branches are managed with **Graphite** (`gt`), matching HASH's repository-wide use of Graphite
+(its CI runs the Graphite optimizer). The standalone repository's late `gh stack` convention does
+not carry over. The unit of branching is the **Linear issue**: one stacked branch per issue tackled,
+created when work on that issue starts. Work discovered while
+resolving the issue (slices, refinements, side-fixes it requires) stays on its branch; only a
+different issue gets a new branch. Branches predating this convention (and the trunk) may mix
+multiple issues.
+
+## git vs gt boundary
+
+Use **git** for local operations that don't touch the stack: `status` / `diff` / `log`,
+`add` / `commit`, `stash`. Use **`gt`** for stack-aware operations: `gt create`, `gt submit`,
+`gt restack`, `gt sync`, and `gt checkout`. Raw branch creation or rebasing bypasses Graphite's
+stack parentage metadata; commits and reads are safe as plain git (run `gt restack` afterwards
+if upstack branches exist). Do not use `gh stack` in `hashintel/hash`.
+
+## Naming
+
+- **Branch**: `{prefix}/{issue-id}-{keywords}` (e.g. `ln/fe-1362-demo-vehicle`).
+- **PR title**: `{ISSUE-ID}: {Linear issue title in sentence case}`
+  (e.g. `FE-1362: Decide the September demo vehicle`).
+- PR descriptions are written when tying off a branch, not during active development. They fill
+  the repository template (`.github/pull_request_template.md`) with the visible-summary /
+  `🏗️ Agent notes` split applied inside its sections, per `issue-writing.md`.
+
+## Deposit rule
+
+Work deposits its own description at authoring time, whatever tool authored it: a commit
+carries a body that explains outcome and mechanism (the FE-1400 sweep's messages are the
+register), and a branch is not tied off until its PR body says what it establishes. A
+semantically heavy branch with an empty message is a defect, not a style choice — prose
+backfill is remediation, not workflow (see `legibility.md`).
+
+## Lifecycle
+
+```text
+gt create {prefix}/fe-XXXX-keywords    # new branch stacked on the current one
+# ... work ...
+git add <files> && git commit          # plain git for commits
+gt submit                              # push + create/update the PR when ready
+gt sync                                # after merges: pull trunk, restack, prune
+```
+
+Trunk is `main`. Link the PR from the Linear issue (or let Linear's GitHub integration attach
+it) so the issue records where its work landed.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/issue-tracker.md b/libs/@hashintel/brunch-agent/docs/agents/issue-tracker.md
new file mode 100644
index 00000000000..60d329f0c94
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/issue-tracker.md
@@ -0,0 +1,128 @@
+# Issue tracker: Linear
+
+Issues for this repo live in **Linear**, worked through the `linear` CLI (see the
+`tool-linear-cli` skill). Long-form artifacts — specs, research write-ups, notes — stay in this
+repo under `docs/planning/<effort>/` (see `documentation.md`); Linear issues link to them by repo path (and to Notion/Google
+docs by URL). The issue is the tracker record; the repo file is the document.
+
+How issue titles and bodies are written — the contract/execution-record split, outcome-shaped
+titles, plain-prose context — is covered in `issue-writing.md`; it applies to every issue an
+agent authors from this repo.
+
+## Conventions
+
+- **Default team**: `FE`. **Project**: `brunch-agent`. Create issues with
+  `linear issue create --team FE --project brunch-agent`. The project is the
+  ownership boundary for this codebase — see the registry rule below.
+- Related work also lives on teams `PRO` (product) and `H` (HASH) — read/reference those freely;
+  create there only when asked. The legacy `brunch` project holds the old brunch product's
+  history and is not this codebase's tracker.
+- Use `--description-file` / `--body-file` for any multi-line markdown (shell-escaping otherwise
+  mangles it).
+- Triage state is expressed through Linear workflow states and labels (see `triage-labels.md`).
+- Comments and conversation history go on the issue as Linear comments, shaped per
+  `issue-writing.md`'s comment rules: the decision or change in one or two sentences, with
+  detail in `🏗️ Agent notes`.
+
+## When a skill says "publish to the issue tracker"
+
+Create a Linear issue on team `FE`, project `brunch-agent`. If the content is long-form, commit
+it under `docs/planning/<effort>/` and link the repo path from the issue description.
+
+## When a skill says "fetch the relevant ticket"
+
+`linear issue view <ID>` (e.g. `FE-1333`). The user will normally pass the identifier directly.
+
+## Editing issue bodies from the CLI
+
+Bodies carry collapsed `🏗️ Agent notes` sections (`issue-writing.md`), and agents maintain
+them by fetching, editing, and pushing the raw description. Fetch immediately before every
+write, preserve the human-owned summary, and apply the smallest material change; never push a
+stale local copy. Three more facts keep that process safe:
+
+- **Read the raw description via GraphQL**, never via `issue view` — view prepends a
+  title/state header that would be pushed back into the body:
+
+  ```bash
+  linear api --variable id=FE-XXXX <<'GRAPHQL' | jq -r '.data.issue.description'
+  query($id: String!) { issue(id: $id) { description } }
+  GRAPHQL
+  ```
+
+- **Linear normalizes markdown on save** (collapsed-section spacing, `-` → `*` bullets). A diff
+  against your draft is not drift; don't "fix" it.
+- **Issue references in Linear bodies and comments are full URLs**
+  (`https://linear.app/hash/issue/FE-XXXX`), which Linear renders as issue chips — a bare ID
+  stays dead text. In repo documents the opposite holds: bare IDs with a gloss, per
+  `documentation.md`.
+
+## Project updates
+
+Linear project updates (`linear project-update`) reach a wider audience than issue comments.
+They give a plain-prose summary of decisions, confidence changes, risks, and opportunities
+since the last update, using the native health field. They contain no working detail, and empty
+sections are omitted. Draft one from the changes recorded in issue comments since the last
+update. Publish it to the `brunch-agent` project.
+
+## Wayfinding operations
+
+Used by the `ds-wayfind` skill. The **map** is a Linear issue with one **child** sub-issue per
+ticket.
+
+- **Map**: an FE issue in project `brunch-agent`, labeled `wayfinder → map` (label group `wayfinder`,
+  children `map` / `research` / `prototype` / `grilling` / `manual-task` — created 2026-08-11;
+  `manual-task` stands in for the skills' `task` type because the workspace already has an
+  unrelated "Task" label). The issue description holds the map body: Destination / Notes /
+  Decisions so far / Not yet specified / Out of scope.
+- **Child ticket**: a sub-issue of the map (native parent relation), same team and project,
+  carrying its `wayfinder → <type>` label. The description holds the question.
+- **Blocking**: Linear's native **blocks / blocked-by** relations. A ticket is unblocked when
+  every issue blocking it is closed (Done or Canceled).
+- **Frontier**: open, unblocked, **unassigned** sub-issues of the map — lowest issue number
+  first.
+- **Claim**: assign the issue to yourself (the dev driving the map) before any work.
+- **Resolve**: post the answer as a comment on the issue, set state **Done**, then append a
+  one-line gist + link to the map issue's _Decisions so far_ section (edit the map description).
+- **Out of scope**: set state **Canceled** and record the gist + reason in the map's
+  _Out of scope_ section.
+- Pre-existing product issues (the PM's stubs) are **referenced** from map tickets via _related_
+  relations — never duplicated as wayfinder tickets and never closed by the map. A wayfinder
+  ticket that validates a product issue links to it and records its verdict in the resolution
+  comment.
+
+## The registry rule
+
+**Project membership is the ownership boundary**: an issue belongs to this codebase iff it is
+in the `brunch-agent` project. Nothing else — no label, no team, no root-walking — decides
+belonging. Within the project, every issue must additionally be **reachable from a root**: either
+it is a sub-issue (directly or transitively) of a root map — currently FE-1383 (build) and
+FE-1357 (demo + plugin spec) — or a sub-issue of a named sweep ticket (FE-1401-style), or it
+_is_ a root and `docs/planning/_shared/COORDINATION.md` names it under **Exceptional roots**. An
+issue in the project but reachable from no root is captured-then-orphaned, the failure mode this
+rule exists to stop. Set the parent at creation (`--parent FE-XXXX`), not in a later sweep.
+
+Audit (run at arc close, alongside the legibility protocol's consolidation step):
+
+```shell
+turbo run linear:graph --filter '@hashintel/brunch-agent'
+```
+
+Check each open row without a `p:` parent against the roots above. An orphan gets a parent or an
+explicit root listing in `COORDINATION.md` — silence is not an option it has. The projection is
+project-wide rather than assignment-scoped: assignment is fallible, and more contributors means
+unassigned work is normal. A shared custom view — "brunch-agent: open without parent" — surfaces
+candidate orphans continuously; its only legitimate rows are the roots themselves.
+
+## Historical note
+
+Before 2026-08-11 this repo tracked issues as local markdown under `.scratch/<feature-slug>/`
+(map at `map.md`, tickets at `issues/NN-<slug>.md`; live trees moved under `docs/planning/`,
+completed ones under `docs/history/planning/`). The completed `elicitation-kernel` effort
+remains in that form as the canonical archive (now at `docs/history/planning/elicitation-kernel/`), and is **mirrored in Linear for team
+visibility** as FE-1366 (map) with sub-issues FE-1367–FE-1379, all Done, blocking relations
+preserved. New efforts go to Linear directly.
+
+Between 2026-08-11 and 2026-08-20 lite work was identified by a `lite` label plus the shared
+`brunch` project — filters, not ownership, which is how six pre-registry stubs (FE-1328–FE-1334)
+ended up orphaned. On 2026-08-20 the `brunch-agent` project was created, all 73 lite issues
+moved into it, and the `lite` label was deleted; the project itself is now the boundary.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/issue-writing.md b/libs/@hashintel/brunch-agent/docs/agents/issue-writing.md
new file mode 100644
index 00000000000..8f24631c13c
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/issue-writing.md
@@ -0,0 +1,218 @@
+# Writing issues and pull requests
+
+How to write Linear issues and GitHub pull requests for this repo. Adapted from the dogsled
+`ds-writing-issues` skill (the "issue contract"); motivated by team feedback that agent-authored
+records read as jargon and are not readable by non-engineers. Apply whenever creating or editing
+an issue title or body or a pull-request title or description.
+
+This file governs **structure and house style**. Write the visible layer as **plain technical
+prose** for an informed colleague who does not know the implementation. The style is Google
+Developer Documentation plus GOV.UK plain English, with INCOSE precision but not INCOSE
+formality: complete sentences, short paragraphs, active voice, concrete nouns and direct verbs.
+State causal, temporal, and conditional relationships explicitly. Keep sentence structure
+simple without simplifying the idea; prefer two clear sentences over one compressed sentence.
+
+Use shared product and system vocabulary, but avoid implementation-specific names unless they
+are necessary to explain the behavior. Do not write in telegraphic, checklist, ticket,
+changelog, or runbook style. Avoid fragments and labeled fields. Use a list only when readers
+need to compare or enumerate parallel items; use prose when the relationship between facts is
+the information.
+
+The org technical-writing skill drafted in
+[internal-agents#20](https://github.com/hashintel/internal-agents/pull/20) (GEN-449) supplies the
+plain-word and banned-words checks. Search all prose against that list before publishing,
+regardless of the PR's merge state; exact machine text is exempt. The list transcribes what
+colleagues asked for.
+
+Every issue serves two audiences: the team, who scan for direction and progress, and the agent,
+which needs precise state to continue the work. Don't make one body serve both equally. Give
+the issue a **contract** — the human-readable summary — above, and an **execution record** —
+the working state — inside a collapsed `🏗️ Agent notes` section below. The human driving the
+work owns the summary; agents may draft or update it on that person's behalf. The rhetorical
+mode changes by layer: **task language for scanning, explanatory language for understanding,
+specification language for execution.**
+
+## Who carries the contract
+
+The test is authorship, not parentage. Every issue an agent authors from this repo on behalf of
+the human driving the work carries the contract, including every sub-issue. A teammate-authored
+issue outside this workflow keeps its author's structure; comment, relate, and record verdicts
+without rewriting its title or body unless that author delegates the change.
+
+Before changing an issue that carries the contract, fetch its current raw body and read the
+human-owned summary.
+Preserve edits made since the agent last saw it. Change that summary only when acting on behalf
+of its owner and only for a material change. Never regenerate it from a stale local draft.
+
+## Title — the scan layer
+
+Start with an active verb and name the concrete task, problem, or decision in the fewest words
+that remain clear. Examples include "Keep issues easy to scan," "Stop duplicate
+notifications," "Decide how agents retrieve planning decisions," and "Map the September demo."
+Research, planning, documents, and maps are tasks too; use verbs such as "decide," "test,"
+"write," "map," or "plan."
+
+Match the title to the issue's current commitment. If the approach is undecided, name the
+problem or decision rather than a favored implementation. Once an approach is agreed and
+implementing it is the task, name it directly. Domain terms the wider team already uses
+("elicitation," "Petrinaut," "net") belong in a title; internal class, package, framework, and
+algorithm names belong only when changing that named mechanism is itself the task.
+
+Title a bug by its observable symptom, not the hypothesized root cause. Internal work names its
+real engineering task rather than inventing an end-user story.
+
+## Context — the prose layer
+
+One or two short paragraphs of plain prose at the top of the body, mandatory on every issue that
+carries the contract; two to four sentences suffice for a small task. The reader should be able
+to recover:
+**current state → consequence → intended change → material status or uncertainty.**
+
+The central rule: **use a list when the list itself is the information; use prose when the
+relationship between the facts is the information.** Cause, impact, direction, status, and
+uncertainty are relationships — prose. The failure mode is the property-bag (`Problem: … /
+Impact: … / Solution: …`); write the explanation instead. Update the context only on a
+_material_ change — outcome, scope, status, risk, timing — never on routine progress.
+
+When an issue comes from user, stakeholder, or teammate feedback, quote their words directly
+and link the original conversation when its audience is allowed to read it. A summary can lose
+the pain or qualification that made the feedback useful; prefer the source when it is
+available.
+
+## Wayfinder maps
+
+A map is an aggregating issue, so it carries both layers: a **plain-prose preamble**
+(the context layer, written so a non-engineer understands what the effort is, why, and where it
+stands), then, inside `🏗️ Agent notes`, the wayfinder working sections (Destination / Notes /
+Decisions so far / Not yet specified / Out of scope) as the execution record. The map's
+list-shaped sections are earned — enumerating many children's state is the
+information; `Not yet specified` is the map's one home for known-unknowns. When resolving a
+ticket updates the map, refresh the preamble's status sentence in the same edit.
+
+## The execution record
+
+The working layer lives inside a `🏗️ Agent notes` section that Linear and GitHub render closed
+by default:
+
+```
++++ 🏗️ Agent notes
+
+…working detail…
+
++++
+```
+
+on Linear; `<details><summary>🏗️ Agent notes</summary>…</details>` on GitHub PR descriptions
+and long comments. Linear requires the space after `+++` and a blank line on both sides of the
+working detail; its API inserts that whitespace when it is absent. The label is one canonical
+string: **copy the complete wrapper from here, never retype it**. The emoji carries a variation
+selector, so visually identical labels can have different bytes. Write bare domains as explicit
+Markdown links when raw-body fidelity matters; Linear otherwise expands them into link syntax.
+The section is **agent-maintained**: agents update it by fetching the raw body, editing, and
+pushing back (see `issue-tracker.md` for the safe process), so a human edit inside it can be
+overwritten. The human-owned summary outside this section must be preserved unless its owner
+has delegated the change.
+
+The content is optional and schema-free: hold whatever the workflow needs (constraints,
+assumption tables, acceptance criteria, asset links). Present when there's something to hold;
+never mandatory boilerplate. Technical detail is additive — never deleted merely to simplify
+the issue, only moved into `🏗️ Agent notes`.
+
+## Pull requests
+
+A pull request uses the same two layers, expressed through the repository's pull-request
+template. Its title is `{ISSUE-ID}: {current Linear issue title}` as required by
+`git-workflow.md`. Its body **fills `.github/pull_request_template.md`** rather than replacing
+it; the layer discipline applies inside the template's sections:
+
+- **`## 🌟 What is the purpose of this PR?`** is the scan layer: one or two sentences of plain
+  technical prose that stand alone for a reader arriving from the repository feed — the larger
+  change this work belongs to, why it is happening, and what this branch establishes within it.
+  Spell out project-local shorthand on first use; a phrase such as "import gates" is not context
+  until the body says what is being imported and what the gates protect.
+- **`## 🔍 What does this change?`** carries the remaining layers in order: first a
+  plain-language description of the change, then implementation detail, verification, and stack
+  mechanics inside the GitHub `🏗️ Agent notes` wrapper shown above.
+- Fill the template's other sections (related links, blockers, checklists, known issues, tests)
+  per their own inline comments; answer the checklists honestly and keep the sections the
+  template says not to delete.
+
+The prose rules govern throughout: within each section, write sentences, not `What` / `Why` /
+`Testing` label-fragments beyond the headings the template itself provides.
+
+When reshaping an existing pull request, preserve its detailed record byte-for-byte inside the
+wrapper. A title or outer summary may change only to improve the scan layer without changing the
+recorded claim or status.
+
+## Comments
+
+A comment lands in inboxes and feeds. Write it as a notification you chose to send the team.
+Its visible content says what was decided or what changed in confidence, risk, or scope, in one
+or two short sentences. Implementation detail about that change goes into a collapsed
+`🏗️ Agent notes` section in the comment or the issue body. Two boundaries:
+
+- **Progress narration is never a comment.** "Tried X, now attempting Y" is working state — it
+  belongs in the issue body's `🏗️ Agent notes`, edited in place. If nothing was decided and no
+  belief changed, there is no comment to write.
+- **State goes in the body; events go in comments.** Current truth (status, plan,
+  findings-so-far) is edited into the body, where the next reader looks. Comments are the
+  chronological record of what happened.
+
+The resolution comment keeps its length exemption: verdict paragraph first, detail in
+`🏗️ Agent notes`. Linear **project updates** reach a wider audience than comments — see
+`issue-tracker.md`.
+
+## One kind of entity
+
+Investigative work — research, a prototype, a spike — becomes a **sub-issue** holding both the
+query and the result. Never a comment thread used as a workspace; never a body checklist as
+decomposition. The single exception is the immutable **resolution comment** posted when an
+issue closes — a closing act, not a workspace.
+
+## Ownership direction
+
+State a fact once; everywhere else links. Within an issue, a plan links to a decision, never
+restates it. Across issues, a sub-issue never re-explains a fact its parent's context already
+states. Long-form artifacts live in the repo (`docs/planning/<effort>/`) and are linked by
+path, per `issue-tracker.md`.
+
+## Voice and authority
+
+Match the writing's authority to the author's actual remit. Decisions inside the dev remit —
+how something will be built, in what order, on what architecture — are stated plainly in first
+person ("I'm rebuilding the core greenfield because…"). Claims owned by someone else — product
+shape, a PM's checklist, another team's area — get **recommendation voice**: "I strongly
+recommend against X, because…", "the practical considerations don't point this way for the
+demo, IMO; I'd rather we…" — never "we've decided X" about a thing that is theirs to decide.
+Analytic verdict vocabulary ("contradicted", "redefined", "superseded") belongs in internal
+planning records (maps, decision docs, resolution comments on our own tickets); at the
+boundary — comments on others' issues, messages to colleagues — it becomes a recommendation
+with its reasons.
+
+## Vocabulary — three tiers
+
+Apply the technical-writing rules first. Then use these three tiers, judged by whether the
+reader resolves the word without a lookup:
+
+1. **Industry-standard terms** (thread, pipeline, module, interface): free everywhere.
+2. **Terms from technical literature**: use in `🏗️ Agent notes` only when no plainer exact phrase
+   fits. A visible summary may use one only after glossing it at first mention and adding it to
+   `CONTEXT.md`.
+3. **Locally coined terms**: do not coin one for an issue. When an issue inherits one from a
+   linked source, use it only in `🏗️ Agent notes`.
+
+Check banned constructions and filler with a string search. Judge other nouns by whether the
+reader can resolve them without a lookup.
+
+## Before publishing
+
+- **Scan test** — does the title start with an active verb and name the task compactly?
+- **Commitment test** — does the title avoid committing to an approach that is still undecided?
+- **Prose test** — does the context explain causality, or list fragments?
+- **Containment test** — are code-level details inside `🏗️ Agent notes`?
+- **Standalone-context test** — can a reader arriving from a feed recover the larger change, its
+  purpose, and this work's place in it without opening the issue?
+- **Word test** — has all prose been searched against the technical-writing banned list, and
+  does every term of art in the visible summary pass the glossary test?
+- **List test** — does every list hold parallel or ordered items?
+- **Uncertainty test** — are open questions presented as uncertainty, not fact?
diff --git a/libs/@hashintel/brunch-agent/docs/agents/legibility.md b/libs/@hashintel/brunch-agent/docs/agents/legibility.md
new file mode 100644
index 00000000000..20d5a462492
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/legibility.md
@@ -0,0 +1,71 @@
+# Legibility protocol: render, read the strain, reconcile
+
+How work arcs with significant agent-generated output close: produce legibility artifacts that
+aid review and re-establish shared understanding between the humans and the agents carrying the
+work. Companion to `documentation.md` (which governs where documents live; this file governs
+how understanding is checked and kept).
+
+The protocol serves one thesis, the same one the CI gates and the capture store serve in code:
+**no claim without a way for it to fail.** A document read in its own register can nod along
+with itself; re-rendered into a different register, every claim must survive translation, and
+the places where it doesn't are findings.
+
+## The move: render and read the strain
+
+At the close of an arc, re-render its central artifact into another register and instruct the
+renderer to report **every place the source resisted plain rendering** — a dangling referent, a
+term defined nowhere, a prohibition citing nothing, a causal claim whose causality had to be
+inferred. The strain report _is_ the review yield; the rendering itself is a byproduct (often a
+useful one — a teammate-readable account).
+
+Run renderings as fork subagents carrying the strain-report instruction, so the main thread
+reviews the findings instead of doing the translation. Instrumenting the collection raises the
+yield: the ir-design plain rendering returned seven strain points where an uninstrumented
+round-2 read of the FE-1374 spec renderings had found four by accident (each of which fed a
+real spec change — the practice predates its name).
+
+## The register dial
+
+The register is a dial, not a single target. One practice, several grades — pick the cheapest
+grade that can still fail:
+
+- **Plain prose** (Google/GOV.UK style): the default. Catches undefined terms, uncited rules,
+  compressed allusions.
+- **STE grade** (controlled vocabulary, one instruction per sentence): for sources whose claims
+  are dense or load-bearing enough that plain prose can still paper over them. Costs more;
+  earns it when the source will govern implementation.
+- **Worked examples** (FE-1397's form): re-render a _definition_ into concrete instances and
+  check what breaks. The strongest grade for type systems and contracts — a definition that
+  survives three worked designs at different thicknesses has been tested, not admired.
+
+## Filings are render-and-read material too
+
+A sweep's own capture — its tickets, its accrual comments, its penciled directions — is itself
+a rendering of the session's understanding, and gets the same treatment: expect a challenge
+pass over the filings before the arc closes. The FE-1405/FE-1406 round came from re-reading the
+first round's own text ("shapes-to-fill" quoted back); the gaps were real and had been deepened
+by the filings meant to close them.
+
+## Consolidation: capture-as-we-go, reconcile-before-landing
+
+Capture channels (accrual comments, pencil lists, strain appendices, handoffs) guard against
+evaporation, not fragmentation. Two rules keep the yield coherent:
+
+- **Every capture channel names its consolidation target** — accruals reconcile into the
+  owning control surface, pencils graduate to issues or planning documents, and strain reports
+  become document fixes. A channel with no named target is a leak with a delay.
+- **An arc is not closed until consolidation runs.** The closing step reconciles what the
+  captures established into the durable artifacts (coordination, ledger, docs, issues) — a
+  handoff note alone is a deferral, not a deposit.
+
+## Deposit: work describes itself at authoring time
+
+Prose backfill is remediation, not workflow. A branch's commit message and PR body carry its
+semantics when it lands — the record must not abstain exactly where description is most needed
+(FE-1390 landed 1,392 lines with an empty body; the deep-read that repaired it cost more than
+writing it at authoring time would have). The same rule for tooling: a skill output written
+into `docs/` passes through the documentation protocol — an `INDEX.md` row or an `AGENTS.md`
+pointer — like any other document.
+
+Reflections belong in work products, marked as `> **Reflection:**` blockquotes, distinct from
+the captured facts — insight left only in chat evaporates with the context that produced it.
diff --git a/libs/@hashintel/brunch-agent/docs/agents/posture.md b/libs/@hashintel/brunch-agent/docs/agents/posture.md
new file mode 100644
index 00000000000..b2d08e23220
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/posture.md
@@ -0,0 +1,4 @@
+posture: prototype
+
+stakes: high # Persisted capture data and merge gates must fail loudly rather than admit silent corruption.
+horizon: current-milestone
diff --git a/libs/@hashintel/brunch-agent/docs/agents/triage-labels.md b/libs/@hashintel/brunch-agent/docs/agents/triage-labels.md
new file mode 100644
index 00000000000..e78b86b996a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/agents/triage-labels.md
@@ -0,0 +1,17 @@
+# Triage Labels
+
+The skills speak in terms of five canonical triage roles. This file maps those roles onto
+Linear (team `FE`) — using workflow **states** where a state is the natural fit, and labels
+only where no state expresses the role.
+
+| Label in mattpocock/skills | In our tracker (Linear FE)                    | Meaning                                  |
+| -------------------------- | --------------------------------------------- | ---------------------------------------- |
+| `needs-triage`             | state **Triage**                              | Maintainer needs to evaluate this issue  |
+| `needs-info`               | label `needs-info` (create on first use)      | Waiting on reporter for more information |
+| `ready-for-agent`          | label `ready-for-agent` (create on first use) | Fully specified, ready for an AFK agent  |
+| `ready-for-human`          | label `ready-for-human` (create on first use) | Requires human implementation            |
+| `wontfix`                  | state **Canceled**                            | Will not be actioned                     |
+
+When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding
+state or label from this table. Wayfinder ticket-type labels are separate — see the
+`wayfinder` label group in `issue-tracker.md`.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/01-flue-architecture-deep-read.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/01-flue-architecture-deep-read.md
new file mode 100644
index 00000000000..d25fb2370be
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/01-flue-architecture-deep-read.md
@@ -0,0 +1,127 @@
+# Flue architecture deep-read
+
+Type: research
+Status: resolved
+Resolved: 2026-08-06
+
+## Question
+
+What does Flue's architecture offer — and constrain — for embedding an elicitation kernel, such that the shipping-shape and contract-decomposition tickets can decide on facts rather than the marketing page?
+
+Specifically:
+
+- The agent programming model (React-like hooks API): what is "an agent" as a unit of code, state, and deployment?
+- How skills, tools, subagents, persistent state, sandboxes, and channels are defined and composed
+- How Pi is exposed through Flue — can an embedded library reach Pi primitives directly, or only through Flue's abstractions?
+- Local vs. remote parity: what changes between a Node local run and a Cloudflare/CI deploy? What state survives where?
+- Is a "kernel library embedded in a thin Flue agent" a natural pattern, or does Flue push toward the agent _being_ the program?
+- Channels (Slack/Teams/Discord/GitHub) as host input pathways — what does a host surface look like in Flue terms?
+
+Sources: https://flueframework.com/docs/guide/ (pages are fetchable as markdown at `/docs/guide/<topic>/index.md`).
+
+## Answer
+
+> Resolved by `/research` subagent, 2026-08-06.
+
+# Flue Architecture — Findings for an Embedded "Elicitation Kernel"
+
+Version context: `@flue/runtime` **2.0.3** (npm, published 2026-08-05; package created 2026-05-14, 48 versions). Siblings `@flue/cli`, `@flue/sdk`, `@flue/react`, `@flue/vite` all at 2.0.3. Docs pages carry "Last updated Jul 21–23, 2026". Repo: `github.com/withastro/flue`.
+
+## 1. Agent as a unit
+
+**Code.** An agent is a plain exported, capitalized JS function that returns its system-prompt string. Capabilities come from `use*` hooks called in its body. A module marked `'use agent'` is scanned at build time by the Vite plugin (`flue()` from `@flue/vite`); every exported capitalized function in it becomes a registered agent. One file may export several.
+
+**Lifecycle.** The function **re-renders before every model call** and rebuilds instructions and its declared resource set from scratch. Unlike React, resource hooks _may_ be called conditionally — this is the framework's central design bet ("an agent is a program to write, not an object to configure"). Between renders the runtime diffs the declared set against a "last-narrated snapshot" and appends a framework-authored `resources` signal at the next turn boundary ("New tool available: …"). Skill/subagent catalogs are frozen on a durable baseline so flips don't bust the prompt cache; custom-tool changes rewrite the native tools array and _do_ invalidate cache (documented exception: a tool unlocked by a completed tool call, on non-Haiku Anthropic models).
+
+**State.** Durable identity is the function name (or the `Fn.agentName` static) — it keys conversation storage, so renaming without pinning `agentName` is a DB migration. Each conversation is addressed by a caller-chosen `id`. `Fn.initialData` (a Valibot schema static) validates creation-time data exactly once.
+
+**Deployment.** Registration ≠ mounting. `createAgentRouter(agent)` returns a Hono sub-app you mount yourself in `src/app.ts`; agents reached only via `dispatch(...)` need no mount at all. Entry points: `flue run <module>` (CLI, no server), HTTP `POST /:id` (202 fire-and-forget), `dispatch(agent, {id, message, initialData, uid})`, and `start()` + `init()` for standalone Node processes.
+
+## 2. Primitive inventory (what a library could register/own)
+
+- **Tools.** `defineTool({name, description, input?, output?, harness?, durable?, run})` — Valibot schemas, frozen at module load, importable from a light `@flue/runtime/tool` entry "for tool-only modules". Mounted per render via `useTool(def)`. `run` receives `{data, signal, log, toolCallId}`; `harness: true` adds `harness`, `durable: true` adds `step`. Reserved names: `task`, `activate_skill`, `read_skill_resource`, plus sandbox built-ins (`read/write/edit/bash/grep/glob`). **This is the primary registration surface an embedded kernel would own.**
+- **Harness tools** (worth calling out separately). `harness.sandbox` (direct file/exec verbs, _never recorded in the conversation_) and `harness.prompt(text, {result: Schema, tools, model, thinkingLevel, images})` — runs a model operation in a private scratch conversation invisible to clients, with Valibot-validated structured output enforced via a framework-injected `finish` tool. Repeated calls continue that scratch conversation. **This is the closest thing Flue has to a sub-LLM call primitive, and it is a strong fit for a kernel's internal extraction/normalization steps.** Also `harness.compact()`.
+- **Skills.** Open Agent Skills format (`SKILL.md` + supporting files), or `defineSkill({name, description, instructions, files})` for generated/assembled content. Progressive disclosure: one catalog line always present; full instructions arrive as an `activate_skill` tool _result_, so activation never mutates the system prompt and the cached prefix survives. Supporting files are served read-only from the app bundle at virtual paths — **not** copied into the sandbox. Also auto-discovered from `<cwd>/.agents/skills/` when a sandbox exists.
+- **Subagents.** `defineSubagent({name, description, agent})` + `useSubagent()`. Model-driven via the always-present `task` tool. Child inherits _environment_ (sandbox, workspace context, parent model) but **nothing conversational** — no history, instructions, tools, skills, persistent state, or initialData. Only the final message returns. Explicitly _not_ a second addressable agent: "no conversation id, no persistent state, and no address." `GeneralSubagent` ships as a blank delegate under `flue-general`.
+- **Persistent state.** `usePersistentState(name, initial)` — React-shaped, JSON-serializable, keyed by name, durable for the life of the conversation. Writes commit **atomically with the unit of work that made them** (tool batch, or event-hook seam checkpoint), which is what makes it the correct guard for at-least-once callbacks. Prefer updater functions; the render value is a snapshot.
+- **Sandboxes.** `useSandbox(factory, {cwd})`. `local()` from `@flue/runtime/node`, or adapters (Daytona, E2B, Modal, Cloudflare Sandbox/Computer) built against the Sandbox Adapter API. Attaching one adds the six built-in file/shell tools; an adapter may replace that set entirely. Sandbox filesystems are **ephemeral by default** and independent of conversation durability.
+- **Channels.** Inbound-only verified HTTP ingress (Slack, Discord, Teams, GitHub, Stripe, …), shipped as **blueprints** (`flue add channel slack`) that generate project source rather than as opaque packages. A channel is "an object with declarative routes"; `createChannelRouter(routes)` builds one by hand. Handlers call `dispatch(...)` themselves. **Outbound is explicitly not Flue's job** — no send-message abstraction; you use the provider SDK and expose narrow tools with the destination bound in trusted code.
+- **Event hooks / data writers.** `useAgentStart` (async — the load-data seam), `useAgentFinish`, `useResponseStart/Finish` (return values merge onto response _metadata_). `useDataWriter(name, {schema})` streams typed structured data parts to clients (`{type: 'data-orderCard', data}`), strictly one-way out of the agent — **the model never sees data parts**, and a write never re-renders the agent.
+- **Custom hooks.** Plain `use*` functions composing the built-ins, returning instruction fragments to the caller. Docs explicitly frame this as the reuse/packaging unit.
+
+## 3. Pi exposure
+
+Partial and deliberate, concentrated at the **model-provider layer**. Documented facts:
+
+- `@flue/runtime`'s npm dependencies include `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` directly.
+- Models guide: "Providers are Pi's own objects, and Flue accepts them directly: build one with Pi's `createProvider()` … and hand it to `setProvider()` at module top level in `app.ts`." Examples import from `@earendil-works/pi-ai`, `.../api/anthropic-messages.lazy`, `.../providers/anthropic`, `.../api/openai-completions.lazy`.
+- `start({providers})` registers "the Pi providers this runtime registers, replacing the default set."
+- `PromptImage` "re-exports pi-ai's `ImageContent`."
+- Why-Flue: "Flue builds on Pi, the open agent harness behind OpenClaw, and integrates it deeply into every agent you build."
+
+Everything else — conversation loop, tool dispatch, skills, subagents, durability — sits behind Flue's own abstractions. **Inference:** there is no documented path to Pi's agent loop, message list, or Pi extension/package system from inside a Flue agent. A kernel that currently assumes Pi-level tool registration, transcript control, or `renderResult`-style TUI hooks would have to be re-expressed entirely in Flue's `defineTool` + render model. Flue also uses Durable Streams (`@durable-streams/client`) as its client transport protocol.
+
+## 4. Local vs. remote parity
+
+Durable _records and recovery decisions are identical_ across targets; ownership and wake mechanics differ.
+
+|            | Node                                                                                                                                                                                | Cloudflare                                                                                                                                                                        |
+| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Unit       | one server process, coordinator with **lease-based** ownership                                                                                                                      | one **Durable Object per agent conversation**, own SQLite; ownership structural                                                                                                   |
+| Recovery   | startup reconciliation + periodic lease scans                                                                                                                                       | wake-on-start + self-renewing durable wake schedule, bounded supervision pass                                                                                                     |
+| Storage    | `db.ts` adapter required (sqlite, Postgres, MySQL, Mongo, Redis, libSQL, Turso, Supabase, Valkey); **without one, conversations are process-local memory and a restart loses them** | built in                                                                                                                                                                          |
+| Constraint | must route each conversation to exactly one owner; active-active / round-robin for the same conversation is unsafe                                                                  | every deployed agent needs an append-only DO migration tag in your hand-authored `wrangler.jsonc`; renames/deletes are storage migrations (`renamed_classes` / `deleted_classes`) |
+
+Core contract: "Every accepted submission reaches exactly one durable terminal outcome — completed, failed, or aborted — no matter how many crashes happen in between." Submissions are recorded durably _before_ any model work; that is what the 202 and the `DispatchReceipt` attest to. There is a retry budget plus a wall-clock timeout, enforced preemptively via the attempt's abort signal.
+
+**Deliberately not durable:** sandbox files (rebuilt fresh on each initialization unless the adapter keys a provider workspace on the instance id — "a durable database does not make a sandbox durable"); in-flight local promises (persist the `DispatchReceipt` and `read(receipt)` re-attaches from any process); and **code outside the agent** — Flue explicitly does not checkpoint arbitrary TypeScript. For that, docs point to Cloudflare Workflows / Inngest / Temporal calling Flue "like any other service." External side effects are never recorded, only that a tool ran and what it returned.
+
+Also: there is **no GitHub Actions or GitLab _target_**. CI is just `flue run` in a shell step (`--new` + deterministic `--id` gives exactly-once conversation creation). GHA/GitLab appear only in the ecosystem catalog. Builds are Vite (`vite build` → `dist/server.mjs` + `dist/app.mjs`, or the Cloudflare plugin's output). Node deps are externalized, not bundled; the built server does not load `.env`.
+
+## 5. Library-in-agent vs. agent-as-product
+
+**Embedding is a natural pattern, and the docs endorse it explicitly.** Evidence:
+
+- `defineTool` / `defineSkill` / `defineSubagent` all exist specifically as _exportable, frozen, module-load-validated_ units — described as "the natural shape for tools shared across agents" and "the exportable unit — define a delegate once, mount it from any agent."
+- **Custom hooks are the documented composition unit:** "a `useGitHub()` hook that bundles the right tools, skills, and instructions can be written once and dropped into every agent that works with GitHub." That is precisely a kernel-in-a-hook.
+- `@flue/runtime/tool` is a lighter entry point for tool-only modules — a library can depend on Flue without pulling in the server runtime.
+- Source-dir resolution order puts **`.flue/` first**, described as "a self-contained Flue source area inside a larger application," with authored modules free to "import ordinary supporting code from elsewhere in the project."
+- Per-mount overrides "spread cleanly": `useSubagent({ ...issueClassifier, model: 'anthropic/claude-haiku-4-5' })`.
+
+Counter-pressure: Flue insists the _agent itself_ be a program, not config, and the `'use agent'` build-time scan means a library **cannot ship a pre-registered agent** — the agent module must be authored in the consuming project.
+
+**Recommendation (inference):** ship the kernel as a published custom hook — `useElicitationKernel(targetPlugin)` — that internally calls `useTool` / `useSkill` / `usePersistentState` / `useDataWriter` and returns instruction fragments, plus raw `defineTool` exports for hosts that want selective mounting. The host owns a ~10-line `'use agent'` module, the `app.ts` mount, and `db.ts`. This is library-in-a-thin-agent, and Flue's grain supports it. One real constraint: tool names are globally unique per render and collide with reserved names, so the kernel needs a namespacing convention.
+
+## 6. Channels as host surfaces
+
+A "host input pathway" in Flue is: verified ingress → `dispatch(agent, {id, message, initialData})`. Three distinct payload lanes:
+
+- **`initialData`** — recorded once at conversation creation, validated against the agent's schema static, read with `useInitialData()`, immutable thereafter. This is where an elicitation _target descriptor_ belongs.
+- **`kind: 'signal'` messages** — `{type, body, attributes}` where `attributes` is a string→string map of facts _trusted code_ attached. Read with `useDelivery()`. Docs push this hard as the authorization pattern: "the model may choose an order ID to look up, but it cannot choose the customer." For a kernel, this is the channel for host-verified respondent identity. Channel deliveries are signals rather than `user` messages precisely because a Slack thread is multi-participant.
+- **`kind: 'user'`** — direct human turns.
+
+**Interviewing-UX rendering surfaces, ranked by fit:**
+
+1. **`useDataWriter` + `@flue/react`.** Named, schema-validated structured data parts arriving alongside text on the same message; a tool can write several times mid-run to drive live progress. `useFlueAgent({url})` gives `messages`, `parts`, `status`, `historyReady`, `sendMessage()`, `refresh()`. Message parts are `text | reasoning | dynamic-tool | file`, and **validated structured tool output is preserved on the `dynamic-tool` part's `output`** — the React docs say this exists "so applications can render custom tool interfaces without a separate data-event channel." Direct fit for question cards, choice sets, and review panes.
+2. **Chat channels** (Slack/Teams/Discord/GitHub) for text-shaped interviewing only. There is **no outbound abstraction** — every reply is a tool you write against the provider SDK with the destination bound in trusted code (the `replyInThread(data)` pattern). Rich Slack Block Kit interviewing is entirely your code.
+
+**Gap worth flagging loudly: Flue documents no first-class human-in-the-loop / elicitation / interrupt primitive.** There is no "ask the user and suspend" hook. `terminate: true` on a tool result ends the turn once the current batch settles; the documented pattern for waiting on a human is state-gated tools (`record_approval` unlocks `publish_release`) plus a new inbound submission. **Inference:** the kernel must implement its own turn-suspension protocol — a `terminate: true` tool that writes the pending question into `usePersistentState` and emits a data part, with the host's answer arriving as a fresh `dispatch`. That is exactly the kind of thing a kernel _should_ own, but Flue provides no scaffolding for it, so it is net-new work either way.
+
+## 7. Constraints & risks
+
+- **Maturity.** 2.0.3, with 2.0 a full API rewrite around hooks announced this cycle; a Migration Guide exists. `@flue/vite` first published 2026-07-10 (19 versions). Fast-moving — expect churn.
+- **Build-time magic is load-bearing.** `'use agent'` scanning, `SKILL.md` module imports, and agent-identity stamping all happen in the Vite plugin. **This effectively requires Vite.** A kernel published as a library must not depend on that transform internally — keep to `defineTool`/`defineSkill` (plain runtime calls) and let the host own the scanned module.
+- **Durable-identity coupling.** Conversation storage is keyed by agent function name. Always pin `agentName`.
+- **Cloudflare migration ceremony.** Adding an agent is always agent + mount + new DO migration tag. If the design ever wants _dynamic_ agent creation per elicitation target, Cloudflare forbids it — agents are a build-time set. Use one agent + many conversation ids instead.
+- **Prompt-cache economics constrain dynamism.** "Gate tools on state that changes rarely." An interviewing kernel that swaps tools per question would thrash the cache. Prefer one stable tool set + state-driven instructions, or skill activation (cache-safe by design).
+- **Valibot lock-in** at every schema boundary (`input`, `output`, `initialData`, `useDataWriter`, `harness.prompt({result})`). A kernel with Zod-based plugin contracts needs a conversion layer or a dual-schema strategy.
+- **Node multi-replica.** No active-active per conversation; you must own routing.
+- **Subagents are conversationally sterile** — no id, no state, no address. If elicitation-target plugins need their own durable memory, they cannot be subagents; they must be state + tools inside the parent, or separately registered agents.
+- **Petrinaut / non-React web-UI host risk:** the rich path (`useFlueAgent`) is React-specific. `@flue/sdk` (`createFlueClient` → `send/read/wait/observe/history`, built on `@durable-streams/client`) is framework-neutral and is what `@flue/react` sits on, so a non-React host is viable — but it must reimplement the materialized-snapshot / reconnect / canonical-reset layer that `useFlueAgent` provides. **Inference:** budget for that, or wrap `createFlueClient` directly and accept a thinner UI contract.
+- **`skills` frontmatter `allowed-tools` is accepted but not enforced** — Flue does not restrict the session toolset from a skill. Any kernel-level tool gating must be done with conditional `useTool`.
+
+## 8. Unreached sources
+
+**HTTP 404 (do not exist at those paths):** `/docs/guide/deployment/`, `/docs/guide/state/`, `/docs/guide/cloudflare/`, `/docs/guide/cli/`, `/docs/guide/github-actions-target/`, `/docs/reference/index.md`, `/llms.txt`. (Real equivalents: `/docs/guide/deploy/`, state is a section of `agent-hooks`, `/docs/guide/cloudflare-target/`.)
+
+**Exist but not fetched** (nav-confirmed; would sharpen specific answers): `/docs/guide/database/`, `/docs/guide/schedules/`, `/docs/guide/evals/`, `/docs/guide/observability/`, `/docs/guide/configuration/`, `/docs/guide/migration/`, `/docs/guide/agent-behavior/`, `/docs/reference/sandbox-api/`, `/docs/reference/provider-api/`, the full `/docs/reference/agent-hooks-api/` (indexed, read only via search), the CLI and Agent SDK reference sections, all `/docs/ecosystem/*` sub-pages, the `@flue/react` package README, and `examples/react-chat`. The GitHub repo (`withastro/flue`) source and Pi's own docs (`pi.dev/docs/latest`) were not read.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/02-zil-lean-survey.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/02-zil-lean-survey.md
new file mode 100644
index 00000000000..4607c055928
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/02-zil-lean-survey.md
@@ -0,0 +1,123 @@
+# zil-lean survey
+
+Type: research
+Status: resolved
+Resolved: 2026-08-06
+
+> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](09-formal-verification-canon-survey.md)'s category-error verdict). This ticket's ElicitationPack sketch is superseded by ticket 09's `Statement` contract (pre-pass S10); the surviving contributions are the existence proof, the assurance lattice with prohibited promotions, derivation provenance, and the derived-status idea.
+
+## Question
+
+What elicitation-for-formal-verification insights does https://github.com/jagg-ix/zil-lean hold, and is a lean/formal-flavored elicitation target _dev-sized_ — small enough to develop the kernel against without wading into a massively complex target?
+
+Specifically:
+
+- What is the repo: purpose, structure, how it relates natural-language intent to Lean formalization
+- What would an **ElicitationPack** for a lean-flavored target need: concept contract (what counts as a proposition/invariant/assumption), observation lenses, completion criteria
+- What would its **ProjectionPack** need: output contract/shape, validators (does Lean itself act as the deterministic validator?), lossiness
+- Verdict: dev-sized or too heavy? If too heavy, what is the smallest formal-flavored slice that still exercises both pack axes differently from elicit-gherkin? (Fallback second target is BPMN/process-mining.)
+
+## Answer
+
+> Resolved by `/research` subagent, 2026-08-06. Local clone for follow-up: scratchpad `zil-lean/` (session-temporary).
+
+# zil-lean survey
+
+## 1. What it is
+
+**Documented facts.**
+
+- `jagg-ix/zil-lean` — "ZIL: a relational knowledge language implemented in Lean 4 with a Clojure runtime and toolchain." Primary language Clojure; no license file; 31 stars, 1 fork, 0 subscribers, 1 open issue, no topics.
+- **Provenance/activity**: repo created 2026-07-27T06:10, last push 2026-07-29T02:26. Entire history is **27 commits over ~2 days**. First commit is "Initial public snapshot" by `github-actions[bot]`; all six PRs are branches named `agent/modularize-*`, `agent/complete-engine-governance-modules`. There is also a `PUBLIC-CONTENT-POLICY.md` and commits titled "Isolate validated source publication." **Inference (high confidence)**: this is an agent-authored code dump published from a private working repo — ~140k tracked lines landed in one snapshot, then mechanically split into modules. Not an organically evolved project, and not battle-tested.
+- **Size/structure**: 532 files. `Zil/` (106 files, 14.2k lines Lean 4 — the native library), `src/zil/` (75 files, 17.5k lines Clojure — runtime/CLI/bridges), `spec/` (44 markdown specs, 5.3k lines), `examples/` (133 files, 85k lines — dominated by generated data), `lib/` + `libsets/` (`.zc` macro libraries), `test/` (57 files, 6.1k). Lean pinned to `leanprover/lean4:v4.31.0`.
+- **What "ZIL" is**: a **relation-tuple + Horn-rule (Datalog) knowledge language**, explicitly modeled on Google's Zanzibar `object#relation@user` tuple syntax, extended from authorization into general project knowledge: `declaration ─implements→ requirement`, `theorem ─validates→ component`, `claim ─supportedBy→ document`. Four primitives: nodes, relations, rules, queries. Two surface syntaxes (`.zc` tuple text; native Lean macros `zil_fact` / `zil_theorem_rule`) plus a canonical IR, snapshot format `ZILX/1`, delta format `ZILD/1`, revision log `ZILR/1`, and exporters to Soufflé and Prolog.
+- **Relation to Lean**: Lean is (a) the implementation host of the engine and (b) a **certification backend for a narrow slice**. `Zil.Trust` has three levels — `asserted` (registered fact), `graphDerived` (rule-inferred), `certified` (a rule paired with a Lean proposition + proof term, kernel-checked). Everything else about proofs is _bookkeeping_: `spec/proof-obligation-governance-v1.md` governs declared obligations across `z3 | tlaps | lean4 | acl2 | manual` and validates _presence of evidence references_, not their content ("Lean kernel validation remain[s] the responsibility of [its] producing system").
+
+**It is not**: a benchmark, a proof-automation system, an autoformalization pipeline, or anything with an LLM in it. `grep -ril 'openai|anthropic|llm|prompt|natural.language|gpt-'` across the repo hits **two files, both false positives** (a Terraform API schema, a config macro lib). "assistant" appears only as node names in examples (`assistant.formalization`, `assistant.codegen`) — agents are _modeled as nodes in the graph_, never as interviewers. **There is no elicitation, no question-asking, and no natural-language front-end anywhere in this repo.**
+
+## 2. Elicitation-relevant insights
+
+The bookmark intuition is wrong about the surface but partly right about the substrate. zil-lean contains **no informal→formal capture**, but it is an unusually well-worked-out example of **the layer the kernel calls the claim graph** — and it is worth reading precisely for that.
+
+Transferable, documented:
+
+- **Evidence-graded claim graph as a first-class artifact.** `spec/assurance-levels-v1.md` defines five orthogonal labels — `exploratory`, `validated`, `kernel-backed`, `externally-attested`, `byte-attested` — with an explicit **prohibited-promotion lattice** (`validated ↛ kernel-backed`, `externally-attested ↛ kernel-backed`, `byte-attested ↛ validated`). Crucially: "Assurance labels state what checked a result… must not be inferred from a successful exit code alone." Directly reusable as the kernel's IR annotation on captured claims, and the sharpest thing in the repo.
+- **Full derivation provenance.** `spec/derivation-provenance-v1.md`: every fact node carries `id / fact / origin / stratum`, where origin is `base` or `rule(ruleName, premiseFactIds, negativeChecks, binding)`. Query answers emit witnesses with premise fact IDs and bindings. Reports are deterministic and **timestamp-free** so they hash stably. This is the evidence-preserving IR the kernel wants, worked out concretely — including the honest caveat: "The trace is graph-derived evidence. It is not a Lean kernel proof term."
+- **A concept vocabulary for formal-flavored capture that already distinguishes the kernel's hard cases.** `examples/formalization-arc-demo.zc` + `lib/theorem-dsl-macros.zc` separate **assumption** (with class + `ASSUME_HOLDS(source)` / `ASSUME_BROKEN(source, reason)`), **lemma**, **theorem**, **guarantee** (`THEOREM_ENSURES`), **evidence** (engine + token), **component**, **signal**, and **incident** (which can _break_ an assumption and propagate). Derived statuses: `PROVED` (deps satisfied + witness), `CONDITIONAL` (witness but assumption under review), `WEAK` (no witness), `BROKEN` (required assumption broken). That is a completion-criteria ladder, expressed as Datalog, that the kernel could adopt nearly verbatim.
+- **Two forms of "enough."** `spec/formalization-plan-v1.md` schedules `FORMALIZATION_TARGET` declarations (`module, file, declaration, status, priority, dependencies?`) over a validated acyclic dependency graph, defining _readiness_ as `status ∈ {ready, in_progress} ∧ ∀dep. dep.status ∈ {verified, reviewed, proved}`, with structured blocking reasons (`status:<s>`, `missing:<t>`, `dependency:<t>:<s>`). `spec/agent-context-v1.md` defines a **context bundle** for handing a task to an agent — changed nodes → reverse impact → relevant facts → originating rules → auto-selected queries and targets — with explicit incompleteness issues (`unknown-changed-node`, `missing-query`, `missing-formalization-target`) and `context_bundle_id = sha256(report bytes)`.
+- **Drift detection on formal statements.** `spec/theorem-statement-locks-v1.md` locks `(token_id, declaration, module, kind, type_fingerprint)` and reports ordered check states (`fingerprint_changed`, `declaration_changed`, `missing_token`, `current_unresolved`, `unexpected_token`…). Answers "did the formalization silently stop meaning what the user said?" — a re-elicitation trigger.
+- **A request-elicitation schema that already exists.** `spec/request-form-core-v0.1.md` (draft) formalizes "a requester asks for `<something>`" as `Data | Action | Compound | Recursive`, with `mode ∈ {dry_run, apply}`, explicit `Effect` entities, and `Criterion` acceptance predicates, lowered to canonical tuples with derived judgments (`has_side_effect`, `is_recursive`, `execution_contract plan_only`). **Inference**: this is the closest thing in the repo to an elicitation target schema, and it is _not_ Lean-flavored at all — it is intent-flavored. It may be more useful to the kernel than the theorem DSL.
+
+What zil-lean does **not** show, and the kernel must supply: how anyone _arrives_ at these declarations. Every `.zc` file is hand-authored. There is no question generation, no ambiguity detection, no candidate extraction from prose, no clarification loop. The Lean checker is used as an oracle over _already-formal_ artifacts, never as a feedback signal into a conversation.
+
+## 3. ElicitationPack sketch (elicit-lean/formal)
+
+Grounded in the vocabulary zil-lean shows is actually load-bearing.
+
+**Concept contract** — five kinds, distinguished by their _evidential obligations_, not their grammar:
+
+| Kind                  | Test                                                       | Obligation on capture                         |
+| --------------------- | ---------------------------------------------------------- | --------------------------------------------- |
+| `assumption`          | Taken as given; not to be discharged here                  | must name a holder/source and a review status |
+| `invariant`           | Must hold at all times over a named state/scope            | must name scope + the state it constrains     |
+| `proposition/theorem` | A claim asserted to follow from others                     | must name required assumptions + lemmas       |
+| `guarantee` (ensures) | An outcome promised to a consumer                          | must attach to a producing component          |
+| `constraint`          | A restriction on inputs/config, not a claim about behavior | must name what it restricts                   |
+
+Non-negotiable per-item fields (from `THM_*` + proof-obligation governance): `id`, `criticality`, `depends_on: [assumption|lemma]`, `evidence?: (engine, token)`, `status`, and — added by the kernel, absent in zil-lean — `source_span` (the utterance it came from) and `paraphrase_confirmed: bool`.
+
+**Observation lenses** (what to notice in conversation):
+
+1. **Modal/quantifier lens** — "always", "never", "must", "for every", "at most one" → invariant candidate.
+2. **Hedge lens** — "assuming", "as long as", "we can take for granted", "in practice X is well-formed" → assumption candidate, and a _required_ follow-up on who guarantees it. `a_input_well_formed` in the demo is exactly this shape.
+3. **Consequence lens** — "so then", "which means", "that guarantees" → proposition with an implicit dependency edge to name.
+4. **Break lens** — "except when", "unless", "this fell over once when…" → either a missing precondition on an existing item, or an incident that breaks an assumption (`INCIDENT_BREAK_ASSUMPTION`).
+5. **Undefined-term lens** — a noun used in a claim that has no node yet → must be introduced before the claim can be normalized.
+
+**Completion criteria** (ladder taken from the demo's status computation, plus dependency-closure from the plan spec):
+
+- _Structurally complete_: every claim's `depends_on` targets exist; dependency graph acyclic; every term referenced has a node. (Directly = the plan spec's set-validation rules.)
+- _Epistemically complete_: no claim is `WEAK` without the user having explicitly deferred it; every `CONDITIONAL` names the assumption under review and its owner; every `critical` item has either evidence or an explicit, reasoned waiver (governance spec forbids waiving critical items).
+- _Faithfulness_: every captured item has a user-confirmed paraphrase. This is the one criterion zil-lean cannot inform — there is no user in it.
+
+## 4. ProjectionPack sketch
+
+**Output contract**: the claim graph projects to a `.zc`-shaped tuple set plus derived-status queries — the `formalization-arc-demo.zc` shape is a working, concrete target. Textual, diffable, deterministic, machine-checkable _without Lean_.
+
+**Deterministic validators, in ascending cost** — and this is the important structural finding: **zil-lean demonstrates that Lean is the wrong first validator.** Three cheaper tiers exist and catch most errors:
+
+1. **Schema/graph validation** (free): unique IDs, nonnegative priorities, existing dependency targets, acyclicity, stratification safety, relation declared in some base fact or rule head (`unknown-relation` verdict).
+2. **Datalog closure** (cheap, deterministic, bounded — default fuel 64/stratum): derives `PROVED / CONDITIONAL / WEAK / BROKEN`, impact sets, break roots. The real workhorse oracle, and it runs on the _informal_ graph.
+3. **Obligation governance** (cheap): checks that declared statuses are supported by evidence references — `proved-status-requires-evidence`, `obligation-not-discharged`, `waiver-reason-missing`, `critical-obligation-cannot-be-waived`.
+4. **Lean elaboration** (expensive, narrow): only for items actually written as Lean declarations. `spec/lean-verification-report-v1.md` runs `lake env lean <file>` per module + SHA-256 manifest match; `Zil.Trust.CertifiedRule` kernel-checks a proposition/proof pair.
+
+So: **Lean serves as the deterministic validator only for the `kernel-backed` tier, and zil-lean's own architecture says you must not let success at tiers 1–3 masquerade as tier 4.** The prohibited-promotion table is the lossiness policy, pre-written.
+
+**What's lossy**: the natural-language statement itself (`statement` is a free-text field in the obligation schema, unvalidated); the _reason_ an assumption is believed (only `source` is kept); alternative derivations (v1 provenance retains only the first witness); and — the deep one — the gap between "Lean accepted this declaration" and "this declaration means what the user said." `theorem-statement-locks` spells it out: "The lock does not claim that unchanged type fingerprints imply unchanged proof terms, source text, or external scientific meaning." The kernel must keep the utterance→claim→declaration chain because nothing downstream can reconstruct it.
+
+## 5. VERDICT — dev-sized?
+
+**A full elicit-lean/formal target is not dev-sized. A slice of it is, and it's a good one — but it is not the slice with Lean in it.**
+
+Reasoning:
+
+- **The heavy part is real.** Getting from a user's claim to a Lean _statement_ (not proof) requires committing to a type-theoretic encoding of the domain — the step autoformalization research finds hardest. That is deep-Lean-expertise work, and the contract is not definable without it. zil-lean quietly concedes this: it never writes theorem statements from intent. It stores `proof:Normalize.idempotent` as an opaque **token naming a declaration a human already wrote**. The demo file says so outright: "Proof status here is bookkeeping only. The proof assistant remains the sole proof authority; proof tokens name checked declarations but do not assert them."
+- **The light part is genuinely there, and zil-lean is a working existence proof of it.** Eliciting an **assumption/lemma/theorem dependency graph with criticality and evidence pointers** — no Lean statements, no proofs — is weeks-scale. Every validator you need is graph-level and already specified in this repo.
+
+**Smallest formal-flavored slice: "elicit-proof-obligations" / the verification arc.** Interview a user about a system they believe is correct; capture assumptions (with owners and review status), lemmas, theorems, guarantees, and the dependency edges among them; attach evidence references where they exist; project to a `.zc`-style graph; validate by acyclicity + stratified Datalog closure yielding `PROVED/CONDITIONAL/WEAK/BROKEN` + break-root and impact queries.
+
+**Does it differ from elicit-gherkin on both pack axes? Yes, cleanly:**
+
+- _ElicitationPack_: Gherkin's concept contract is **scenario-shaped and example-driven** (Given/When/Then, concrete instances, no cross-item structure); completion is per-scenario coverage. This target's contract is **claim-shaped and dependency-structured** — the unit is a proposition with edges to other propositions, the hedge lens is central (Gherkin has no notion of an assumption), and completion is _graph closure plus evidence adequacy_, not enumeration. Different lenses, genuinely different "enough."
+- _ProjectionPack_: Gherkin projects to a flat, independently-executable list; validation is parse + step-binding. This projects to a **DAG with derived statuses**, validated by fixpoint computation and an evidence-promotion lattice. The lossiness policy is substantive (assurance levels, first-witness-only) rather than near-absent.
+
+**Fallback comparison.** Take this slice **over** elicit-BPMN/process-mining as second target. Both differ from Gherkin, but the proof-obligation slice stresses the kernel harder on the axes the design cares about: it forces the claim-graph IR to carry _evidence grades and derivation provenance_ (BPMN mostly forces sequencing and gateway structure, which Gherkin partly covers), and it gives you a deterministic non-trivial validator — a Datalog fixpoint — without any external tooling or domain SME. Keep BPMN as third; it's the better _breadth_ target once the IR is stable, and it has an easier user-recruitment story. **Inference**, based on pack-axis distance, not on any BPMN sources reviewed here.
+
+One caveat worth carrying: nothing in this repo has been validated by use. Treat the specs as well-reasoned design documents by an agent-assisted author, not as field-tested contracts — the `assurance-levels` lattice and the `THM_*` status ladder are worth stealing on their merits, not on their track record.
+
+## 6. Unreached sources
+
+- Did not build or run anything (`lake build`, `lake exe zilLeanTests`, `clojure -M:test`) — no Lean toolchain here; **all correctness claims are from specs and source, not execution.**
+- Did not read: the 129 Lean files in `Zil/` beyond filenames; `spec/zil-formal-core-v0.1.md` (427 lines, the core semantics); `spec/canonical-relational-ir-v0.1.md`; `spec/evidence-envelope-v1.md`; `spec/query-governance-v1.md`; `spec/recovery-audit-v1.md`; `spec/dmetavm-core-v0.1.md`; `formal/` (TLA+/SMT); the 17 `libsets/` domain packs; the 133 example files beyond three.
+- Repo wiki is enabled (`has_wiki: true`) — not checked. 1 open issue — not read. No discussions, no releases checked.
+- Author `jagg-ix` (Jorge A. Garcia) — no external profile or publication search performed, so no independent read on provenance beyond commit metadata.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md
new file mode 100644
index 00000000000..ec7c8624322
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md
@@ -0,0 +1,138 @@
+# Brunch exchange-schema audit
+
+Type: research
+Status: resolved
+Resolved: 2026-08-06
+
+## Question
+
+Catalog brunch's structured-exchange vocabulary and classify each element as **generic to any elicitation** vs. **brunch-specific** (coupled to the spec-graph/product), so the questioning-UX and contract-decomposition tickets inherit a map of what to keep, generalize, or drop.
+
+Specifically, in `../brunch` (read-only):
+
+- `src/exchanges/` — schemas (`ask`, `present_candidates`, `present_digest`, `present_review_set`, `request_choice`/`request_review`, capture/editor envelopes), projections, recovery
+- `src/agents/runtime/elicitor/` — prompt/context assembly, active-tool policy, the control-ownership table (spec posture / elicitation style / asking agenda)
+- `src/agents/skills/` — the activity-move routing table (analyze/elicit/ingest/propose/project/map/review) as candidate generic elicitation routines
+- Relevant `TOPOLOGY.md` files for boundary intent
+
+For each element: what interaction problem it solves, where it hard-codes brunch's graph/spec shape, and any right-sizedness doubts visible in the code or docs (the abstractions "were also just a guess" — look for strain marks: legacy kept-for-reads projections, migration notes, loud failure modes).
+
+## Answer
+
+> Resolved by `/research` subagent, 2026-08-06. Facts cited to file:line-range in `../brunch`; judgments marked **[J]**.
+
+# Brunch Structured-Exchange & Elicitor Audit
+
+## 1. Exchange catalog
+
+**`ask` (the only registered interactive terminal).** Solves: getting exactly one typed response from a human, in one of four shapes, without a separate collect tool per shape. Params (`src/exchanges/schemas/params.ts:~180-215`) carry markdown `body`, optional `options[]`, `multiple`, `allowOther`, `allowNone`, `commentPrompt`, `topLabel`/`bottomLabel`; no options ⇒ free text, options ⇒ single choice, options + `multiple` ⇒ multi-choice (`src/.pi/extensions/exchanges/TOPOLOGY.md`, "Answer sources"). Details (`src/exchanges/schemas/request.ts:~390-460`) echo the question _and_ the answer in one result: `question` echo (body, options, `commentPrompt`, `otherPrompt`) plus exactly one of `answered | cancelled | unavailable` — a **property-presence union** rather than a status enum (`src/exchanges/schemas/TOPOLOGY.md:293-300`). Continuation: `ask({ continues: exchange_id })` reads the declared continuation off a prior present; model-authored payload fields on a continuing ask are rejected at the params boundary (`params.ts` `zAskParams.superRefine`, message `"continuing ask payload is declared by the referenced offer"`).
+
+**`present_candidates`.** Solves: fan-out comparison — let the user _recognize_ a direction among alternatives instead of authoring one. Details (`src/exchanges/schemas/present.ts:185-235`): `display{heading, body?}` plus `candidates[]` of `{id, title, user_rubric, meta_rubric, graph_refs[]}`. `user_rubric` is six required nonblank markdown fields — `core_bet, best_fit, cost_complexity, covers_well, main_risks, lock_in_constraints` (+ optional `recommendation`); `meta_rubric` is four optional fields — `legibility_cost_of_knowing, failure_modes, coverage_range, commitment` (the D31-L four-axis meta-rubric, `memory/SPEC.md:262`). Continuation: `continuation: zOptionRequiredAskContinuationDeclaration` → `{tool: "ask", params: {body, options, ...}}`; the answer emits a `request_choice` detail discriminant with `tool_meta.prev = present_candidates`, and may lead to `capture_candidate`.
+
+**`present_digest`.** Solves: putting a large ingested source in front of the user as prose. Details (`present.ts:237-262`): `digest{abstract (required, nonblank), analysis?, recommendation?}`. Explicitly _not_ a graph carrier — graph payload fields are rejected (`schemas/TOPOLOGY.md:289`). Continuation is the **free-text** variant (`zFreeTextAskContinuationDeclaration`, which `z.never()`s options/multiple/allowOther/allowNone/commentPrompt/labels — `shared.ts`), collecting conversational feedback only. Acceptance is deliberately _not_ a review decision: a later standalone `ask({acceptsDigest, questions})` questionnaire or a `confirm|revise` single-select mints the accepted carrier, copying `accepted_abstract` from the runtime-resolved digest — caller-authored abstracts are rejected (`src/exchanges/TOPOLOGY.md:27`; `projections/ask.ts` `projectDigestQuestionnaire` / `projectDigestConfirmation`).
+
+**`present_review_set`.** Solves: batch approval of a structurally valid graph-mutation proposal. Details (`present.ts:60-180`): `review_set{nodes[], edges[]}` where each node is `{draft_id, proposed_code, settlement: advisory|settled, plane: intent|oracle|design|plan, kind, title, body?, detail?}` and each edge is a role-named discriminated union over nine categories (`dependency, witness, rationale, realization, refinement, exclusion, composition, cross_reference, supersession`) with `{draft_id}|{existing_code}` endpoint refs. Continuation is option-required. Approval is the commit: an approved continuation invokes shared settlement _before_ `ask.execute` returns, so only a committed, `receipt`-bearing result is appended (`.pi/extensions/exchanges/TOPOLOGY.md`; `ask/continuation.ts:527` throws `'Review-set approval must route through shared settlement'`). `request_changes` requires a comment; `request_changes`/`reject` are terminal-only, no graph effect.
+
+**Legacy `present_question`.** A merged question/offer anchor (`response_kind: answer|choice|choices` + options inline). Unregistered; its Pi adapter is deleted; the projection survives only for old persisted reads (`schemas/TOPOLOGY.md:132-134`; `projections/present-question.ts`).
+
+**`request_choice` / `request_review` / `request_answer` / `request_choices`.** No longer registered tools — they are the _preserved wire vocabulary_ for terminal details, so capture/sweep readers keep reading what they always read (`.pi/extensions/exchanges/TOPOLOGY.md:81-84`). `request_review` projection callers must pass a present-tool discriminator because review-set and digest close through the same detail kind but capture reads them differently (`projections/request-response/review.ts` `ReviewPresentTool`).
+
+**Capture envelopes.** `capture_answer|choice|choices|review|candidate` (`schemas/capture.ts`), each a `zCaptureDetailsHeader` + `tool_meta{prev, curr}`. Graph payloads intentionally undesigned in this pass (`schemas/TOPOLOGY.md:386-390`); `capture_candidate` consumes only the selected id.
+
+**Editor envelope.** `editor.ts` is a _wire_ envelope, not transcript detail: a JSON blob prefilled into `ctx.ui.editor` for the one payload Pi built-ins can't carry over RPC (multi-choice). Its `status: 'answered'|'cancelled'` string never enters details, which carry outcome as key presence (`schemas/TOPOLOGY.md:36-38`).
+
+**Questionnaires.** `schemas/questionnaire.ts`: `{id, kind: free-text|single-select|multi-select, prompt, options[]}` questions and kind-matched answers, replayed on persisted completion so IDs/kinds/option-membership/completeness can't diverge.
+
+## 2. Classification
+
+| Element                                                                                                                                                      | Class                       | Change needed / coupling                                                                                                                                                                                                                                                                                      |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ask` single-tool-four-shapes                                                                                                                                | **Generic**                 | The strongest abstraction here. **[J]** One terminal covering free-text/single/multi + a declared-continuation mode is the right primitive.                                                                                                                                                                   |
+| Property-presence terminal union (`answered`/`cancelled`/`unavailable`)                                                                                      | **Generic**                 | Distinguishes "user declined" from "no UI available" — both are non-answers, and conflating them is the classic bug.                                                                                                                                                                                          |
+| `comment` (user-authored) vs `message` (system-authored) split                                                                                               | **Generic**                 | `schemas/TOPOLOGY.md:108-112`. Cheap, high-value provenance discipline.                                                                                                                                                                                                                                       |
+| Question-echo-in-result (self-contained terminal)                                                                                                            | **Generic**                 | Makes the transcript replayable without joining back to the present.                                                                                                                                                                                                                                          |
+| Declared continuation (`present` names its own terminal; collector rejects model re-authoring)                                                               | **Generic**                 | **[J]** The single most transferable idea: the offer owns the answer vocabulary, so the model cannot drift the options between showing and collecting.                                                                                                                                                        |
+| `exchange_id` + `tool_meta{prev,curr,next}` chain                                                                                                            | **Generalize-with-changes** | Currently a hand-maintained discriminated union of ~15 literal prev/curr/next triples (`shared.ts`). Replace with a generic `{exchangeId, parentId?}` link + one `form` tag; the pairwise enumeration is combinatorial and buys little.                                                                       |
+| Recovery scan / pending-present resumption                                                                                                                   | **Generic**                 | `recovery.ts:78-81`: only an _answered_ terminal closes an exchange; cancelled/unavailable stay resumable. Any interviewer needs this.                                                                                                                                                                        |
+| Present-then-ask two-step (offer ≠ collection)                                                                                                               | **Generalize-with-changes** | Generic as "render surface separate from input surface", but brunch pins the offer set at three named tools. A kernel wants one `present(form, payload)` with pluggable payload validators.                                                                                                                   |
+| `present_candidates` as an _interaction_                                                                                                                     | **Generic**                 | Fan-out/compare/recognize is plane-invariant (A31-L, `memory/SPEC.md:111`).                                                                                                                                                                                                                                   |
+| Candidate `user_rubric` (six required fields)                                                                                                                | **Brunch-specific**         | Hard-codes brunch's product judgment about what makes specs comparable (`core_bet`, `lock_in_constraints`). A kernel should take a caller-declared rubric schema.                                                                                                                                             |
+| Candidate `meta_rubric` (D31-L four axes)                                                                                                                    | **Generalize-with-changes** | SPEC calls it "a soft heuristic… not architecturally enforced" (`memory/SPEC.md:262`) yet it is a required schema key. Demote to optional caller-supplied axes.                                                                                                                                               |
+| `graph_refs[]` on candidates                                                                                                                                 | **Brunch-specific**         | Node-id coupling to the spec graph.                                                                                                                                                                                                                                                                           |
+| `present_digest` as an interaction                                                                                                                           | **Generic**                 | "Here is my reading of your source; react to it" is universal to ingestion-shaped interviewing.                                                                                                                                                                                                               |
+| Digest accept-via-later-carrier (feedback ≠ acceptance)                                                                                                      | **Generalize-with-changes** | **[J]** The _separation_ is a real lesson; the specific `acceptsDigest`/`accepted_abstract` field names and the "runtime resolves the final eligible digest" recognizer (`recovery.ts:18`) are brunch plumbing.                                                                                               |
+| `present_review_set` as an interaction                                                                                                                       | **Generalize-with-changes** | "Approve/request-changes/reject a proposed batch of writes, atomically" is generic. Brunch's version hardwires the target.                                                                                                                                                                                    |
+| Review-set node/edge draft schema                                                                                                                            | **Brunch-specific**         | `plane: intent\|oracle\|design\|plan`, nine graph edge categories, `settlement: advisory\|settled` (D27-L), `proposed_code`. Params import `zReviewSetProposalPayloadForBoundary` from `graph/review-set.ts` — the only inbound coupling `exchanges/` allows (`exchanges/TOPOLOGY.md`, dependency direction). |
+| "Boundary-teaching" schema (advertise nested shape so the model sees it before the deep validator runs)                                                      | **Generic**                 | `schemas/TOPOLOGY.md:47-52`. **[J]** A genuinely good pattern: shallow schema for model legibility, deep validator for correctness.                                                                                                                                                                           |
+| Approval-commits-atomically + receipt                                                                                                                        | **Generalize-with-changes** | Generic as "the approve branch runs the target's commit and the terminal carries the target's receipt"; `MutateGraphSuccess` (`request.ts:1`) is the coupling. Kernel needs an opaque target-supplied receipt type.                                                                                           |
+| Capture layer                                                                                                                                                | **Brunch-specific**         | Exists as envelope only, graph payloads undesigned; `capture_candidate` semantics are graph-shaped.                                                                                                                                                                                                           |
+| Editor envelope (`editor.ts`)                                                                                                                                | **Generalize-with-changes** | Real problem (host UI can't carry a payload over RPC), brunch-shaped solution. Kernel: name it a "degraded-transport fallback", don't bind it to multi-choice.                                                                                                                                                |
+| Option-id regex `^[^>\r\n]+$`                                                                                                                                | **Generalize-with-changes** | The comment says ids round-trip through an HTML-comment marker recovered by a regex stopping at `>` (`params.ts`). **[J]** A rendering leak in a validation schema — a kernel should encode ids opaquely instead.                                                                                             |
+| `active-tools.ts` allowlist                                                                                                                                  | **Generalize-with-changes** | Generic pattern (fixed tool policy per role), brunch-specific contents (`read_graph`, `mutate_graph`, `read_elicitation_scratchpad`).                                                                                                                                                                         |
+| Elicitation scratchpad (private, non-authoritative obligations)                                                                                              | **Generic**                 | D101-L: session-local, last-snapshot-wins, "durable truth stays in the graph; low-confidence noticings land here." Every interviewer needs a place for "noticed, not yet asked."                                                                                                                              |
+| `elicitation_style: interrogate\|disambiguate\|propose`                                                                                                      | **Generic**                 | `session/elicitation-style.ts`. Style ≠ authority ≠ capability.                                                                                                                                                                                                                                               |
+| `warrant-before-commit` directive (hash-pinned, ablatable)                                                                                                   | **Generic**                 | `compose-live-prompt.ts` validates exactly one directive block, hashes it, exposes it as `providerVisibleText`, and supports dev-only ablation. **[J]** Treating one prompt paragraph as a versioned, A/B-testable artifact is a pattern worth stealing outright.                                             |
+| Skill moves `analyze / elicit / ingest / propose / project / review`                                                                                         | **Generic**                 | These six are the actual elicitation routine vocabulary.                                                                                                                                                                                                                                                      |
+| Skill move `map`                                                                                                                                             | **Brunch-specific**         | Graph vocabulary/routing/persistence.                                                                                                                                                                                                                                                                         |
+| Skill move `tutorial`                                                                                                                                        | **Brunch-specific**         | Product walkthrough of Brunch itself.                                                                                                                                                                                                                                                                         |
+| `elicit` topology-driven question ranking table                                                                                                              | **Generalize-with-changes** | The _shape_ — structural signal in the target ⇒ question shape — is generic; every row names graph kinds (`assumption`, `witness` path, `criterion`, `exclusion`). Kernel: targets supply their own signal→question-shape table.                                                                              |
+| Readiness bands as "concentric concern envelopes, not workflow stages"                                                                                       | **Generalize-with-changes** | **[J]** Excellent dialogue policy ("absence matters _later_, capture is never illegal earlier"); the band vocabulary is brunch's.                                                                                                                                                                             |
+| Prompt-injected skill manifest (`<brunch-skills>` with absolute paths, "do not infer additional skills")                                                     | **Generic**                 | `skills/registry.ts` `renderBrunchSkills`.                                                                                                                                                                                                                                                                    |
+| `intent -> design -> verification -> scope -> build` handoff sequence, frontier/scope edge directions, `PROJECT_EXECUTION_HARNESS_TITLE` verify-recipe block | **Brunch-specific**         | `prompts/elicitor.md`; `compose-live-prompt.ts` `renderProjectExecutionHarnessGuidance`.                                                                                                                                                                                                                      |
+
+## 3. Strain marks
+
+**Legacy-kept-for-reads.** `present-question.ts` and `request-response.ts` survive as projections with no registered tool (`exchanges/TOPOLOGY.md:22`; `.pi/.../TOPOLOGY.md:81-84`). `shared.ts` literally names the residue: `STRUCTURED_EXCHANGE_TERMINAL_NAMES = { current: 'ask', legacyRequestPrefix: 'request_' }`. The tool topology collapsed from `present_question → request_response` to `ask`, but the _detail_ vocabulary could not follow because capture/sweep readers were written against it.
+
+**Same detail kind, two meanings.** `request_review` closes both review-set and digest, so `projectRequestReview` demands a `ReviewPresentTool` discriminator from callers (`projections/request-response/review.ts`). Receipts are required for review-set approval and _strictly rejected_ on every digest branch (`schemas/TOPOLOGY.md:~325`). **[J]** Two different transactions wearing one name — a merge that shouldn't have happened.
+
+**A retracted merge.** Digest acceptance _was_ a review decision and was pulled back out: "digest acceptance is no longer a review decision" (`exchanges/TOPOLOGY.md:27`), with `recovery.ts:31-36` retaining a `legacyReview` parse path for digests approved under the old model.
+
+**Doc/code drift on edge categories.** `schemas/TOPOLOGY.md:194` documents `dependency | proof | support | realization | boundary | composition | association | supersession`; the Zod in `present.ts:89-160` implements `dependency | witness | rationale | realization | refinement | exclusion | composition | cross_reference | supersession`. Four categories were renamed and the schema doc was not updated.
+
+**Retired axes.** D98-L retired strategy/lens/method as runtime or manifest state; A35-L records the retreat: the axis model "may still be useful as prompt-resource organization, but it is no longer trusted as user-changeable or transcript-backed runtime state" (`memory/SPEC.md:115`). The migration note in `skills/TOPOLOGY.md` maps seven old constructs onto activity homes and ends with a hard rule: _"if a skill is live, it appears in the first-level registry; if guidance is not there, it is not switchable product state."_ Retired axes also left dead vocabulary behind — `lens` is still advertised in the review-set boundary schema (`schemas/TOPOLOGY.md:50`) and the elicitor prompt still says "plan-lens review set".
+
+**Loud failure modes.** Only two `throw`s in the whole exchange surface, both about authority: `'Review-set approval must route through shared settlement'` (`ask/continuation.ts:527`) and `'parsed ask parameters do not describe a runtime variant'` (`ask.ts:748`). Everything user-facing degrades to an `unavailable` terminal with a message instead (`continuation.ts:222` — a missing continuation declaration is an error string, not a crash). Params failures return bounded `TOOL_INPUT_INVALID` tool results with no human-visible transcript line.
+
+**Where validation lives (revised once).** D105-L: validate at trust boundaries — LLM params, RPC input, editor replies, transcript read-back — _not_ inside constructors, which "do not parse objects [they] just built." D108-L consolidated the whole contract out of two prior homes (`src/.pi/extensions/exchanges/schemas/` and `src/projections/exchanges/`) into `src/exchanges/`.
+
+**Lessons [J].** (a) Wire vocabulary outlives tool names — version the _detail_ schema independently of the tool registry from day one, or every tool rename leaves a fossil. (b) Do not merge two interaction forms because their outcomes look alike; brunch merged digest into review and had to un-merge it while keeping a legacy read path. (c) An enumerated `prev/curr/next` chain across N forms is O(N²) maintenance for a link that could be one parent pointer. (d) The `settlement: advisory|settled` retrofit (D27-L, FE-1187) shows that _strength of assertion_ is a first-class field, not a later annotation.
+
+## 4. Elicitor control model
+
+Three controls, three owners, three lifetimes (`runtime/elicitor/TOPOLOGY.md`, "Control ownership"):
+
+- **Spec posture** (`kind`/`origin`/`relatesToSpecId`) — owned by the persisted product row, spec lifetime. Session establishment decides _whether to ask_, not what the fact is; the live context renderer "cannot establish or overwrite it." Enforced in code: `context.ts:14-19` comments that `workspace.posture` is a _workspace_ stub, "not D118-L spec posture."
+- **Elicitation style** (`interrogate|disambiguate|propose`) — last valid `brunch.elicitation_style` entry on the active branch, session lifetime across kicks. The prompt adapter "projects it into the live elicitor control block without changing capability or authority."
+- **Asking agenda** — _has no state field at all_. Turn lifetime, "reconsidered from current conversation and on-demand reads." Origination supplies neutral graph facts once; the prompt directs `establish orientation` then `focus a vein`.
+
+The closing rule is the sharp part: **"Formatting is not authority: shared text helpers may render facts, but spec posture cannot satisfy style, style cannot persist or gate an agenda, and the prompt cannot establish product posture."**
+
+The conduct itself lives in `prompts/elicitor.md`: a new session "starts from graph facts and an empty or inherited elicitation scratchpad, **never a scored or ranked agenda**"; establish orientation, then "pick one concrete thread worth pursuing this session and let the scratchpad track obligations you notice along the way, rather than trying to cover every absence at once." Scratchpad obligations are private working state — "do not disclose even a summary… unless the user explicitly asks."
+
+**Judgment [J].** _Generic dialogue policy:_ the three-way separation of persisted-fact / session-style / turn-agenda; the refusal to persist an agenda (D101-L retired the persisted spec-scoped register in favour of a session scratchpad — `memory/SPEC.md:180`); "one vein, not full coverage"; private-by-default working state; the three style values; "formatting is not authority." _Product policy:_ that spec posture is the persisted axis at all; the specific graph facts constituting orientation; the `intent→design→verification→scope→build` sequence and execution-harness verify-recipe block; the `mutate_graph`/`read_graph` tool allowlist. **[J]** The most under-appreciated design move is the _negative_ one — an agenda deliberately has no storage, so it cannot go stale, cannot be gamed, and cannot become a scoring engine the prompt defers to instead of reading the conversation.
+
+## 5. Design lessons for a greenfield questioning-UX contract
+
+**Inherit**
+
+1. **Declared continuations.** The offer names its own terminal in its result; the collector fills body/options from that declaration and rejects model-authored payload on a continuing call. This is the mechanism that makes offer→answer non-forgeable.
+2. **Property-presence outcome union with three arms** — answered / cancelled / unavailable — plus the recovery rule that _only answered closes an exchange_ (`recovery.ts:78-81`). Cancel must leave the offer resumable, and the user-facing hint must stay honest after a cancel.
+3. **One terminal tool, several shapes.** Not one collect-tool per question type. Params-level cross-field refinement decides the shape; the runtime asserts the parsed params "describe a runtime variant" and throws if not.
+4. **Self-contained terminals.** Echo the question, the options, and the sub-prompts into the answer detail so a transcript reader never needs the present.
+5. **`comment` vs `message`** — never let user text and system text share a field.
+6. **Boundary-teaching schemas.** Advertise the nested shape shallowly for model legibility; keep the deep requiredness contract in one validator the target owns.
+7. **Agenda as derived state, not stored state**, with a private, non-authoritative scratchpad for "noticed but not asked."
+8. **Version and hash load-bearing prompt paragraphs.** `LIVE_ELICITOR_DIRECTIVES` pins one directive by sha256, validates its stable opening sentence, and supports dev-only ablation — prompt text as a testable artifact.
+9. **Separate "react to this" from "accept this."** Digest feedback and digest acceptance are different exchanges for a reason brunch learned by reverting the merge.
+10. **Approval-commits, with the target's receipt in the terminal.** Never leave "approved" and "committed" as two states the model can straddle — the settlement runs before the terminal is appended.
+
+**Avoid**
+
+1. **Enumerated `prev/curr/next` tool-meta unions.** Use one parent link and one form tag.
+2. **Product judgment baked into required schema fields** — the six-field `user_rubric` and the four-axis `meta_rubric` (documented as "a soft heuristic… not architecturally enforced" yet schema-required). Rubrics belong to the target, declared per call.
+3. **Rendering constraints leaking into validation** — the option-id regex exists because ids round-trip through an HTML comment. Encode ids opaquely.
+4. **One detail kind for two transactions.** `request_review` forces every caller to hand-carry a discriminator and forks receipt rules downstream.
+5. **Tool names as the versioning unit.** Brunch's wire vocabulary froze independently of its tool registry; plan for that from the start rather than maintaining `legacyRequestPrefix` and a parallel unregistered projection tree.
+
+**Key paths:** `../brunch/src/exchanges/{TOPOLOGY.md,recovery.ts,editor-envelope.ts,text.ts}`, `../brunch/src/exchanges/schemas/{TOPOLOGY.md,shared.ts,present.ts,request.ts,params.ts,questionnaire.ts,capture.ts,editor.ts}`, `../brunch/src/exchanges/projections/`, `../brunch/src/.pi/extensions/exchanges/{TOPOLOGY.md,ask.ts,ask/continuation.ts,index.ts}`, `../brunch/src/agents/runtime/elicitor/{TOPOLOGY.md,active-tools.ts,compose-live-prompt.ts,context.ts}`, `../brunch/src/agents/prompts/elicitor.md`, `../brunch/src/agents/skills/{TOPOLOGY.md,registry.ts,elicit/SKILL.md,propose/SKILL.md}`, `../brunch/src/session/elicitation-style.ts`, `../brunch/memory/SPEC.md`.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/04-contract-decomposition.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/04-contract-decomposition.md
new file mode 100644
index 00000000000..66002ac067e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/04-contract-decomposition.md
@@ -0,0 +1,88 @@
+# Contract decomposition: kernel / host / plugin / pack boundary
+
+Type: grilling
+Status: resolved
+Resolved: 2026-08-06
+Blocked by: 01, 03 (both resolved)
+
+## Question
+
+What exactly does the kernel own (mechanism + orchestration), what does the host supply (input shapes and pathways, deploy target), and what do plugins define (target policy) — and does the four-contract + pack decomposition (ElicitationPack: concept/observation/completion; ProjectionPack: projection) survive contact with the Flue facts and the brunch audit?
+
+Sub-questions this grilling must close:
+
+- Are the A-axis (semantic target) and B-axis (representation target) genuinely separately swappable in our first milestone, or bundled per plugin?
+- Where does the evidence-preserving IR / claim graph live, and how thin is its common core?
+- Persistence: does the plugin-owned-persistence hypothesis hold, or does the host (deploy target) own it with plugins declaring shape? What state must the kernel externalize (session, transcript refs, artifact-in-progress, episteme ledger)?
+- Where is control inverted: typed issues as backpressure (projector → elicitation controller) — is that the only inversion, or do observation lenses invert too?
+- The policy-vs-mechanism rule: enumerate what would otherwise become the central `switch` and check each is on the plugin side.
+
+Primary input: docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md
+
+Named input from the portfolio decision (issue 07): **behavioral over procedural** — agents do better with behavioral guidance than procedural scripts, and with clear shapes/patterns to fill rather than schemas that require extensive parsing to build a model of the output shape. Brunch's unsolved problem — specifying how an elicitation process should work plus skill material to guide an agent through it, without over-proceduralizing — is a core stress test for the pack contract. The decomposition must say what a pack _feels like_ to the agent consuming it, not only what it validates.
+
+Concrete test cases for every boundary claim (from issue 07): how would `elicit-gherkin` do this vs. `elicit-proof-obligations`? The spec mandates both packs are authored before the pack interface freezes.
+
+## Answer
+
+> Resolved by HITL grilling, 2026-08-06 (four rounds, including an evidence pass over `~/Clones/mattpocock/skills` + `../brunch/docs/design/BEHAVIORAL_KERNELS.md`, and integration of [agentic-elicitation-criteria](../../../../reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md), the second inbox doc).
+
+### Ownership table
+
+|                                          | Owns                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Kernel** _(mechanism + orchestration)_ | The conversation loop, agent-forward (agent judgment at the helm) · the questioning-UX contract (issue 05's subject) · the **capture envelope** (below) around opaque plugin payloads · the **typed issue queue** (vocabulary, storage, factual attributes; the only stored agenda-like state; also where conflict/equivalence live) · the private scratchpad · the **turn-suspension protocol** (Flue has no ask-primitive; the kernel owns one) · operation _signatures_ (`observe/reconcile/project/validate`) with snapshot-in/deltas-out calling convention, validation, and application of returned deltas · completion evaluation (running plugin-declared criteria) · pack loading, progressive disclosure, kernel-card activation · capture-id minting · the **storage port** definition |
+| **Host** _(embedding + affordances)_     | Input surfaces and pathways (TUI / web / chat channel / Petrinaut later) · verified respondent identity · deploy target · **storage port implementation** · artifact delivery (repo write, API, post) · model/provider via the Pi family                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| **Plugin** _(target policy)_             | Its **own IR payload structure** — graph, flat list, whatever fits; shared between its packs, never universal; namespaced concepts · **ElicitationPack**: kernel cards (Detects / Goal / contrastive Questions / Artifacts), completion contract, clarification hints · **ProjectionPack(s)**: `project` + `validate` (required), `reconcile` (optional), output contract, annotated shapes, **typed loss reports**, lossiness policy · artifact persistence _shape_ · domain vocabulary                                                                                                                                                                                                                                                                                                          |
+
+### The capture envelope (the hourglass waist)
+
+Kernel-defined, domain-free — semantically rich, structurally minimal:
+
+- `id` (kernel-minted), evidence spans (utterance provenance, phrase-level where possible)
+- **Epistemic status** enum, distinct from confidence: `explicit | inferred | tentative | defaulted | external-lookup`
+- Confidence (qualitative), status: `active | superseded | retracted`, one `supersedes` link
+- **Absence states** as first-class capture values: `not-mentioned | unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred`
+- **Alternatives** grouping: >1 live interpretation of the same evidence may coexist until resolved
+- Opaque, plugin-typed payload. **No kernel edges, no graph, no kind taxonomy** — structure is payload business. Conflict (`conflicting`) and equivalence (`possibly-equivalent`) are **typed issues referencing capture ids**, not edges; resolution must be an explicit event (supersession or recorded decision) — "no silent conflict resolution."
+
+### Operations
+
+- **Required**: `project` (captures → draft artifact **+ typed loss report**: `mapped-exactly / normalized / approximate / collapsed / omitted / defaulted / unrepresentable`) and `validate` (→ typed issues).
+- **Optional**: `reconcile` (dedup/merge over the plugin's own structure); kernel calls it when present.
+- **Agent-native**: `observe` — noticing is the agent's work guided by pack kernel cards; code-level extractors are an optimization, never the required path.
+- **Calling convention**: plugin ops receive an **immutable state snapshot**, return observations/issues/deltas; the kernel validates and applies. Buys atomic plugin failure, semantically idempotent retries (a retry never counts as a second user assertion), and tracing.
+- **Backpressure**: validators and projectors never address the user; they return typed issues the agent consumes.
+
+### Dialogue policy
+
+Behavioral guidance + factual issue queue. **Facts computed, weights judged**: the kernel computes issue facts (blocks-required-criterion, origin semantic|representational, can*default); the agent weighs them qualitatively. The inbox doc's priority formula is adopted as \_prose the agent thinks with*, never as a computed score — computed-priority dimensions are judgments wearing metric costumes, and a stored ranking becomes an authority the agent defers to instead of reading the conversation (brunch's no-stored-agenda lesson).
+
+### Cross-cutting decisions
+
+1. **No universal IR** — the kernel's slice is the envelope; structure is plugin-unique. Typed-entity-graph maximalism explicitly not adopted; a graph remains any plugin's private choice (including a future brunch-target plugin).
+2. **Smallest-honest-plugin test** — a flat record list + one validator must suffice; every kernel-contract addition is checked against the bar it raises. Empirical form: the black-box authoring test.
+3. **Axes separated in contract, bundled in shipping** — one ElicitationPack + N ProjectionPacks per plugin sharing the plugin's IR; swappability proven by reprojection.
+4. **Principle v2 (ratified, replaces "behavioral over procedural")**: _procedure for mechanism, anchors for judgment, shapes for output_. Evidence: the mattpocock skills are full of procedure that works because it is short, carried by leading words (pretrained concepts recruited deliberately), ends on checkable completion criteria, and rides on shapes/templates with progressive disclosure. Failure modes to design against: sprawl, negation-steering, no-ops, judgment-encoded-as-procedure — not procedure itself. `writing-for-agents` is the cited pack-authoring standard.
+5. **Kernel cards** (from BEHAVIORAL_KERNELS.md) are the unit of ElicitationPack content: Detects (signal-phrase activation) / Goal / contrastive Question patterns / Artifacts (typed claims emitted) / validator hooks. The fifteen-kernel ontology itself stays brunch prior art; packs declare their own kernels. Contrastive classification over open-ended essays.
+6. **Pack physical form**: kernel cards + annotated shapes + deterministic validators + small wire schemas (boundary-teaching: shallow for model legibility, deep requiredness in validators) + completion contract as checkable bounds.
+
+### Acceptance material adopted into the spec (from the criteria doc)
+
+- The **five proof obligations** as contract acceptance criteria: independent variability, semantic conservation, explicit transformation, controlled elicitation, local implementation.
+- The **ten kernel invariants** (§9) as kernel-enforced test properties (no unsupported value without provenance; no silent conflict resolution; no silent projection loss; corrections don't erase history; retries idempotent; target issues namespaced; plugin failures atomic; equivalent state → equivalent projection; unknown ≠ false; explicit ≠ inferred/defaulted).
+- Gating tests: **reprojection/projector substitution**, **minimal pairs** ("the budget is / might be €20,000"), **black-box authoring test** (count concepts, boilerplate, escape hatches).
+- Named smells as review vocabulary: opaque payload waist, giant context bag, schema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden target leakage.
+
+### Deferred to fog (post-milestone)
+
+Simultaneous multi-plugin composition · plugin removal · full replay · capability negotiation · version/migration machinery (the spec names the five version axes — API contract / plugin impl / concept-schema / target-schema / persisted state — implements nothing).
+
+### Routed onward
+
+- §4 SDK-machinery list (evidence anchoring, issue construction, fixtures, **local simulation harness** — "debugging should not require reading an entire agent transcript") → issue 06 (Shipping shape).
+- Envelope + absence states + turn-suspension → issue 05 (Questioning-UX contract).
+
+## Comments
+
+**2026-08-07 (vocabulary clarification from issue 05's resolution).** The ownership table's "Host (embedding + affordances)" bundled two concerns that later split: the **ui** shell (interface: rendering, input, reply transport, identity) and the **substrate** (the embedding environment: deploy target, storage-port implementation, artifact delivery, model/provider). Under the hardened lexicon (`CONTEXT.md`), this table's "Host" row reads as substrate concerns plus ui concerns; "kernel" reads as **harness**. No substantive change to the decomposition.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/05-questioning-ux-contract.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/05-questioning-ux-contract.md
new file mode 100644
index 00000000000..d35d21c1696
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/05-questioning-ux-contract.md
@@ -0,0 +1,58 @@
+# Questioning-UX contract
+
+Type: grilling
+Status: resolved
+Resolved: 2026-08-07
+Blocked by: 03
+
+## Question
+
+What is the kernel's generic questioning-UX contract — the successor to brunch's `ask` / `present_*` / `request_*` exchange family — critiqued rather than copied?
+
+Sub-questions:
+
+- Which of brunch's exchange forms earn a place in the generic contract, which generalize with changes, which are brunch-specific and stay behind?
+- What does the "one high-value question over several low-value questions" dialogue policy need from the UX contract (question budgets, visible current interpretation, distinguish not-mentioned/no/unknown/N-A)?
+- How do typed issues (missing/ambiguous/conflicting/invalid/unsupported/unmapped/low-confidence) render as user-facing exchanges?
+- What must the contract leave to the host surface (TUI vs. web vs. chat channel) vs. fix in the kernel?
+
+Input from Contract decomposition (issue 04): the exchange contract must carry the envelope's conversation-level semantics — **absence states** (`unknown-to-user | declined | deferred | not-applicable`… as answer outcomes, not null), **alternatives** (letting more than one interpretation stay live through an exchange), and conflict-resolution exchanges (an explicit resolution event for a `conflicting` issue). Dialogue policy is behavioral guidance + factual issue queue — the UX contract renders issues to the agent, never scores them.
+
+Note from the Flue deep-read (issue 01): Flue has **no first-class ask-the-user primitive** — the kernel must own a turn-suspension protocol (`terminate: true` tool + pending question in persistent state + structured data part; the answer arrives as a fresh dispatch). The UX contract should be designed with that as the remote rendering path (`useDataWriter` / `dynamic-tool` output parts), alongside richer local surfaces.
+
+## Answer
+
+> Resolved by HITL grilling, 2026-08-06 (five rounds), with a live fact-finding pass over Flue's docs mid-session. All shape-level commitments are **working hypotheses** per the built-artifacts-as-proofs preference (ratified into the map's Notes during this session); delegated proof obligations live in tickets 10 (walking skeleton) and 11 (logic-prototype). Vocabulary hardened via `/domain-modeling` into repo `CONTEXT.md`.
+
+### The load-bearing reframe: no exchange-pair ontology
+
+Brunch's exchange machinery (offer→terminal pairs, pending-exchange state, recovery scans) was baggage from its older agent-initiated turn-by-turn model and is **not inherited**. The free-flowing conversation is primary. When the agent poses a structured question it emits an **affordance** — a rendered enhancement in the stream, not a state machine the harness maintains. There is no "pending exchange" concept, hence no cardinality rule, no recovery scan, no terminal union.
+
+- Ask invocations **do commit** structured question payloads to the session (design clue: Claude Code's `AskUserQuestion` — question set as `tool_use`, selections/interruption as adjacent `tool_result`; self-contained, replayable, no separate exchange store). The answer may follow as a structured response, or the ask may be cancelled/redirected — all of it is **session evidence**.
+- **Capture is decoupled from asking**: a **range-sweep** over session entries, run on **settlement** (agent-judged, range-level — a vein closing — never per-question, which would resurrect exchange-pairs through the back door). Harness owns sweep bookkeeping (high-water mark, idempotence); agent owns settlement judgment. → ticket 11.
+- Audit lessons demoted by the reframe: _declared continuations / non-forgeability_ (the failure mode shifts from forgery to misinterpretation, which the envelope's `epistemic_status: inferred` already covers; whether a widget reply needs an echo token is empirical → ticket 10); _only-answered-closes recovery_ and _self-contained terminals_ (patterns at most, not structure).
+
+### Shells, vocabulary, and control (hardened)
+
+**substrate** (Pi family, Flue) → **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI) → **harness** (the generic capability layer — mechanism + orchestration; the effort's essence is _harness-engineering_; replaces "kernel" as shell name) → **plugin** (target policy). Control is IoC per the Hollywood principle: the plugin declares and registers; the harness discovers, orders, invokes; harness capabilities (the ask API, capture envelope, issue queue, sweep bookkeeping) reach the plugin as a **narrow injected context** — the questioning-UX contract is literally part of the PluginContext surface. Composition is the plugin's at authoring time; control flow is the harness's at runtime. Schema ownership follows capability ownership: _the shell that defines a capability owns its affordance schemas._
+
+### What the harness fixes (the generic contract)
+
+1. **Baseline question forms**: free-text / single-choice / multi-choice, plus **questionnaire chaining** as first-class baseline (beyond brunch's `ask`). The harness owns the standard ask API and payload shapes; plugins add custom presentation/collection forms through the plugin API.
+2. **Absence**: interpret by default, afford when structured. Agent-interpreted absence from free conversation carries `epistemic_status: inferred`; structured affordances carry a one-tap absence strip (don't-know / not-applicable / decide-later — generalizing `allowNone`), keeping `unknown-to-user` vs `declined` vs `not-applicable` explicit. Transport outcome and epistemic absence never conflate.
+3. **One harness data channel** multiplexing all affordance forms (`form` tag + plugin-typed body + markdown baseline), because Flue channel names are static structural identity in a flat collision-prone namespace. Plugin widgets are progressive enhancement keyed on the form tag; hosts that know only the envelope render everything via markdown. → ticket 10.
+4. **Interpretation render** ("visible current interpretation"): the one affordance form that must be harness-owned, since it renders the harness's own envelope vocabulary — captures with epistemic status, absence states, live alternatives. The **plugin may supply a renderer/projector definition with typed arguments** (typed against its own payload shapes), which the harness uses to produce the ui-level view; **when it doesn't, the harness falls back to a default renderer (plain JSON view of payloads)** — keeping the renderer optional, consistent with the smallest-honest-plugin test. React vs. accept are two _capture semantics_, not exchange steps. Renderer-seam exercised once real packs exist (ticket 07's portfolio).
+5. **Issues → exchanges**: only `conflicting` / `possibly-equivalent` get forced treatment — a `conflicting` issue closes **only via an explicit resolution record** (capture-layer event citing the user's utterance as evidence); the guarantee moved from wire to store. Every other issue type renders however the agent judges best, guided by kernel cards — prescribing seven mappings would be judgment-as-procedure. → ticket 11.
+6. **No question-budget machinery**: economical interviewing is implemented through strategy and judgment guidance in pack kernel cards; with asks committed to session, anything countable is derivable — no stored counters, no ask-to-issue attribution model, no stored number for the agent to defer to.
+
+### What the ui owns
+
+Rendering (zero built-in widgets in Flue — the embedding app branches on part types), reply transport, identity. Flue facts recorded for the spec: outbound is rich (Valibot-validated `data-*` parts, dynamic-tool outputs), **inbound is string-only** (`sendMessage(text, images)`; SDK signals are string-body too) — so answer typing/validation happens entirely harness-side on read-back; unknown part types are silently dropped (hence the markdown-baseline floor); one documented contradiction (data-part update-in-place vs append) needs the ticket-10 runtime check; turn suspension confirmed (`terminate: true`, answer as fresh dispatch; multi-tool batches terminate only when every result terminates).
+
+### Brunch disposition (sub-question 1)
+
+**Earns a place**: the three answer shapes as interaction vocabulary; questionnaire (promoted); absence affordances (generalized from `allowNone`); react≠accept (as capture semantics); no-stored-agenda (extended: no stored counters either). **Generalizes with changes**: named present tools → plugin-declared forms over one channel; approval-commits-atomically → the resolution-record store guarantee. **Stays behind**: the exchange-pair ontology and everything predicated on it (terminal unions, recovery scans, prev/curr/next chains, declared continuations as wire mechanism), plus everything the audit already classed brunch-specific (rubric schemas, review-set node/edge machinery, graph_refs). Audit lessons not touched by the reframe (comment-vs-message provenance, boundary-teaching schemas, hash-pinned prompt directives, private scratchpad) stand as pattern guidance for the spec.
+
+### Process decision (map-level)
+
+**Built artifacts as proofs** ratified into the map Notes: grilling tickets resolve decisions provisionally and name the proof obligations they delegate. Two prototype tickets created from this session: [Walking skeleton: Flue question round-trip](10-walking-skeleton-flue-roundtrip.md) and [Logic-prototype: capture sweep & settlement](11-logic-prototype-capture-sweep.md). Plugin lifecycle, fault containment, and contract versioning routed to [Shipping shape](06-shipping-shape.md).
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/06-shipping-shape.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/06-shipping-shape.md
new file mode 100644
index 00000000000..7ad3eb48837
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/06-shipping-shape.md
@@ -0,0 +1,74 @@
+# Shipping shape: kernel library vs. Flue agent
+
+Type: grilling
+Status: resolved
+Resolved: 2026-08-07
+Blocked by: 01, 04
+
+## Question
+
+What does the carve-out physically ship as — a kernel library that a thin Flue agent (and later Petrinaut/web/brunch hosts) embeds, or a Flue agent as the product itself — and what is the viable/ideal package structure?
+
+Sub-questions:
+
+- Given the Flue deep-read: is library-embedded-in-agent natural in Flue, or fighting the framework?
+- What does each option cost the Petrinaut-UI and web-UI futures?
+- Package topology: one package or kernel + packs as separate packages? Where do dev targets (elicit-gherkin, elicit-lean) live?
+- What is the local dev loop (run against both targets) vs. the remote deploy story?
+
+Input from Contract decomposition (issue 04): the plugin **SDK surface** is part of the shipping shape — standard machinery for evidence anchoring, claim identity, issue construction, schema validation, retries, idempotency, state-delta application, tracing, test fixtures, and a **local simulation harness** (fixture-driven pack testing: conversation in → expected claims/issues/projections out; "debugging should not require reading an entire agent transcript"). The black-box authoring test and change-surface metric are the acceptance bar.
+
+## Answer
+
+> Resolved by HITL grilling, 2026-08-07 (two rounds + a testing-strategy revision pass grounded in `expert-property-based-testing`).
+
+### Root: harness library in a thin host-authored agent — ratified, with the second-binding test
+
+The product is the **harness library** (core + packs/plugins); every host authors its own thin `'use agent'` module, `app.ts` mount, and storage adapter, and calls a hook shaped like `useElicitation(plugin)`. The Flue facts make the alternative structurally unavailable anyway (build-time `'use agent'` scan lives in the consuming project; a library cannot ship a pre-registered agent). A runnable reference app ships alongside as a dev/demo vehicle, not as the product.
+
+**Amendment — portability as a named pressure test, not a build target.** The deliverable decomposes into (1) pure runtime mechanism, (2) a tool surface, (3) prompt/skill material — and (3) is already portable for free (Open Agent Skills format is shared by Flue, Claude Code, and Pi-family harnesses). The substrate-agnostic-core non-goal stands as written (no ports for hypothetical consumers, no second maintained binding), but the decomposition must keep a second binding _demonstrably small_:
+
+- The spec **enumerates the substrate-facing surface as a short named capability list** the binding must supply: register a tool · contribute instructions · persist state · emit an affordance payload · suspend-for-reply · private model call. Porting = reimplementing that list; if it grows exotic Flue-shaped entries, that is an early smell signal.
+- **Second-binding test** (sibling to smallest-honest-plugin, adopted into spec acceptance material): every time mechanism wants to land in the binding rather than the core, ask "is this genuinely substrate-specific, or is mechanism leaking into Flue's dialect?"
+- Binding-size asymmetry is expected, not a failure: Flue's binding carries the turn-suspension compensation (ticket 10); a terminal binding gets ask-the-user nearly free but may only afford the questioning-UX markdown floor (which issue 05 already fixed as universal). Claude Code/Codex would be the awkward cousins (out-of-process: MCP server + skills dir). The core stays identical; each binding absorbs what its substrate lacks or forbids.
+- **Binding** entered the glossary (`CONTEXT.md`): the harness defines the capability list; a binding imports both harness and substrate; the harness imports no substrate.
+
+### Package topology
+
+- **Core and Flue binding as two workspace packages from day one.** The package boundary is the enforcement mechanism for the portability property; extracting a subpath later is visible churn. Acknowledged as mild ceremony now — accepted because the cost is low if kept clean.
+- **Monorepo in this repo** (brunch-lite becomes the workspace; rename is cheap once the real name resolves). Bun workspaces: `packages/core`, `packages/flue` (binding), `packages/plugin-gherkin`, `packages/plugin-proof-obligations`, `apps/dev`. The dev app owns the `'use agent'` module, `app.ts`, `db.ts`, and the Vite build Flue requires. Spec records the layout as intended structure; nothing is scaffolded during this map.
+- **Plugin packages are `plugin-*`, not `elicit-*`** — the prefix names what they are architecturally; "elicit" is the function, not the identity.
+- **Plugin SDK is core's public export surface** (authoring types + machinery; test/fixture machinery on a `core/testing` subpath so prod bundles stay clean). A separate SDK package would re-export core with no seam-value.
+- **Dependency rule, stated as a spec invariant: plugins depend on `core` only** — never on the binding, never on Flue. Every plugin is substrate-portable by construction, and the black-box authoring test stays honest (a plugin author's world is one package's exports).
+- **Envisioned horizon** (named, not built): per-substrate binding packages (`flue-<name>`, `pi-<name>`, `codex-<name>`), same harness inside each. The payoff _if the second-binding test keeps passing_, not a commitment.
+
+### Cross-cutting choices
+
+- **Valibot throughout** — Flue locks it at every boundary; Standard-Schema-at-the-waist would buy plugin-author comfort at the cost of a conversion seam that can silently drop constraints (named smell: silent coercion/loss).
+- **Tool namespacing: prefix derived from the product name**, provisionally `bl_*` — never `elicit_*` (function vs. identity again). Core names ops abstractly; the binding renders them as substrate tool names. All model-facing tools are harness-owned (plugins expose ops, not tools).
+- **Naming principle** (recurring, carried forward): architectural strings name _identity_ (product, role), not _function_; the name-fog eventually resolves every one of these strings, so nothing bakes "elicit" or "brunch" into structure.
+- **Publishing posture: workspace-internal** — no npm publishing until the real name resolves and an external consumer exists. The spec describes the publishable shape; publishing waits.
+
+### Testing strategy: generation-first fixtures, deterministic replay
+
+The scripted deterministic driver (ticket 11's headless-driver pattern) is the **execution/replay layer**: fixtures are data, replay is pure, everything runs in plain `bun test` — no model, no substrate. But hand-written fixtures demote to **seeds**; the corpus is generated, answering the two untruthfulness modes:
+
+1. **Circularity** (fixtures tailored to the plugin-as-written): properties come from the **kernel contract** — the ten kernel invariants (ticket 04) are literally properties (re-sweep idempotence, equivalent-state → equivalent-projection, corrections don't erase history, retries idempotent, …) — and generators come from the **plugin's declarations**, never its implementation. The SDK ships `arbitraryFromSchema` (Valibot → fast-check arbitraries) for generated capture populations, plus negative-space properties for plugin code (validators total: never throw, always typed issues; `project` never emits an undeclared loss category).
+2. **Unrealistic conversational dynamics**: (i) most invariants hold over capture/state space directly — no conversation needed; (ii) where dynamics are the subject (sweep/settlement, supersession, absences), **model-based command-sequence testing** (`fc.commands`) over a small command alphabet — utter · settle-range · sweep · correct · contradict · reply-with-absence · redirect — derived from the envelope vocabulary; the fuzzer explores interleavings no hand-scripted conversation contains; (iii) language realism via a **model as offline generator, never CI oracle**: a model plays the respondent against the plugin's own kernel cards (Detects/Questions = targeting spec), varied by persona/curveball, plus a **mutation library** generalizing the minimal-pairs test (epistemic-status flips, absence injections, supersession injections). Outputs freeze as replayable fixture files; **regenerate when declarations change** (the anti-drift mechanism).
+
+Bonus adopted: shrunk counterexamples from broken invariants _are_ minimal pathological conversations — pinned as regressions and read first as type-design feedback on envelope/payload types. SDK surface therefore includes: schema-driven arbitraries, the command alphabet, mutation operators, fixture freeze/replay format — alongside ticket 04's list (evidence anchoring, capture identity, issue construction, retries, tracing).
+
+### Dev loop, demo, deploy
+
+- **One agent per target** in one dev app (`ElicitGherkin`, `ElicitProofObligations`): static per-agent tool sets (Flue cache economics), and the shape Cloudflare forces later anyway (build-time agent set; plugin choice is conversation-lifetime-immutable via `initialData` regardless).
+- **The dev app is chartered with three roles, spec'd as roles not features**: (1) local dev loop against both plugins; (2) the colleague-facing **target-gallery demo** — parallel tabbed sessions: start a BDD-spec elicitation, open another tab for a proof obligation, another for a process model; (3) the diagnostic/probe surface — provisional affordance renderers now (the deferred UI package's exploratory material), exploded-view instrumented readout when it graduates. Demo-polish and probe-internals pull opposite ways, so they are different views/routes of one app.
+- **UI affordance package deferred**: spec names it as intended (React renderers + reply transport over `@flue/react`; non-React hosts build on `@flue/sdk`), milestone one keeps renderers in the dev app.
+- **Remote deploy: milestone one is local-only; the spec pins the remote-parity constraints** (one-agent-many-conversations, pinned `agentName`, host-owned storage port, no dynamic agent creation) so nothing local-only creeps in. CI smoke = `vite build` + the simulation suite (no model key, no flake); an optional secret-gated real-model `flue run` smoke once a provider key exists. Actual deploy-target choice waits on an infra conversation (user, 2026-08-07) and blocks nothing on this map.
+
+## Comments
+
+**2026-08-07 (context pointer, from issue 11's cleanup).** The prototype branches are the implementation seeds for this topology, kept as primary sources out of main: `prototype/11-capture-sweep` holds the pure capture-layer reducer (no DOM, envelope semantics only) whose behavior `packages/core`'s capture module lifts _as semantics, not code-by-copy_, plus a headless driver whose 32 checks seed the invariant-property suite described under Testing strategy (several are already kernel-invariant instances: re-sweep idempotence, atomic sweep application, corrections-don't-erase-history, single-hop supersession). Likewise `prototype/10-flue-roundtrip` is the sketch `packages/flue` starts from. Working-tree copies were deleted after HITL review; retrieve any file with e.g. `git show prototype/11-capture-sweep:.scratch/elicitation-kernel/prototypes/11-capture-sweep.html`.
+
+**2026-08-10 (amendment, from [Multi-session elicitation & durable target state](12-multi-session-durable-target.md)).** The charter's persistence hypothesis resolved: **flipped** — the storage port is harness-defined and binding-implemented, plugin-blind; plugin-addressable storage exists only as harness-defined methods passed through the injected PluginContext. This sharpens two things already in this ticket: the capability-list entry "persist state" and the remote-parity constraint "host-owned storage port". Additionally, evidence spans carry pointer + quoted excerpt, so capture provenance is self-contained regardless of how a deploy target exposes substrate session logs.
+
+**2026-08-10 (amendment, second-target rename).** Per the [Formal-verification canon survey](09-formal-verification-canon-survey.md)'s category-error verdict, the second target is now the **assurance argument**; the topology's `packages/plugin-proof-obligations` reads `packages/plugin-assurance`.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/07-dev-target-portfolio.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/07-dev-target-portfolio.md
new file mode 100644
index 00000000000..f2631b7ffa5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/07-dev-target-portfolio.md
@@ -0,0 +1,34 @@
+# Dev-target portfolio confirmation
+
+Type: grilling
+Status: resolved
+Resolved: 2026-08-06
+Blocked by: 02
+
+> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](09-formal-verification-canon-survey.md)'s category-error verdict). Also superseded here: the four-rung status ladder is demoted to a derived UI label with the assumption ledger as headline (pre-pass S8), and the Geolog/ARIA adjacency guess is refuted (pre-pass S9).
+
+## Question
+
+Confirm the first milestone's two live dev targets. The zil-lean survey resolved the shape of the second: full elicit-lean is **not** dev-sized (writing Lean statements from intent is the deep-expertise step), but the **elicit-proof-obligations** slice is — capture an assumption/lemma/theorem/guarantee dependency graph with criticality and evidence refs, validated by acyclicity + Datalog closure (no Lean statements, no proofs), per the ElicitationPack/ProjectionPack sketches in the survey answer. The survey judges it a _better_ second target than BPMN on both pack axes; BPMN stays third.
+
+Proposed portfolio to confirm: **elicit-gherkin** (tracer) + **elicit-proof-obligations** (second, forces the pack swap and the evidence-graded IR).
+
+## Answer
+
+> Resolved by HITL grilling, 2026-08-06.
+
+**Portfolio confirmed**: `elicit-gherkin` + `elicit-proof-obligations` are the first milestone's two live dev targets; `elicit-BPMN/process-mining` is named third; full elicit-lean is deferred (writing Lean statements from intent is the deep-expertise step zil-lean itself never attempts).
+
+**Order — hybrid, addressing the real risk at the design layer**: the spec mandates that **both packs are authored before the pack interface freezes** (design against both simultaneously, on paper — the "two targets on each axis from the beginning" rule), while **elicit-gherkin wires end-to-end first** as the cheap mechanism proof, with elicit-proof-obligations immediately after. Rationale: the user's identified risk — brunch failed to find a scalable, modular way to specify an elicitation process plus guiding skill material without over-proceduralizing — lives in interface design, not wiring order. The trivial target must not freeze the pack contract before the hard target has stressed it.
+
+**Design principle surfaced (routed to Contract decomposition as a named input)**: agents do better with _behavioral_ guidance than procedural, and with _clear shapes/patterns to fill_ rather than schemas that require extensive parsing to build a model of the output shape. Packs are shapes-to-fill plus behavioral guidance — not procedural scripts, not parse-heavy schemas.
+
+**Proof-obligations output format**: steal the ideas, own the format. Adopt zil-lean's load-bearing vocabulary (evidence-graded assurance lattice with prohibited promotions; PROVED/CONDITIONAL/WEAK/BROKEN status ladder; acyclicity + Datalog-closure validation) in our own claim-DAG serialization, **hewing to whatever existing canon fits** — Dafny's `requires/ensures/invariant` contract vocabulary is the leading candidate; Geolog (ARIA program, axioms addressed via Datalog-like queries) is plausibly adjacent. Grounding this is the new **Formal-verification canon survey** ticket (09), which blocks Assemble-the-spec so the milestone lands canon-grounded. `.zc` export is someday-maybe; no dependency on the unproven zil-lean repo.
+
+**Gherkin validator depth (milestone one)**: parse validity + optional **pack-declared step-lexicon** binding check. The apparent codebase coupling dissolves: a step lexicon carried as pack policy needs no external project; only live-codebase step binding defers, named as the target's growth path.
+
+Sub-questions:
+
+- Do the two chosen targets differ materially on _both_ pack axes (semantic + representation)?
+- What is each target's smallest honest output contract for milestone one?
+- Which target is the tracer (built first) and which trails to force the second-pack swap?
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/08-assemble-the-spec.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/08-assemble-the-spec.md
new file mode 100644
index 00000000000..4c062fd66ba
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/08-assemble-the-spec.md
@@ -0,0 +1,40 @@
+# Assemble the spec
+
+Type: task
+Status: resolved
+Resolved: 2026-08-10
+Blocked by: 04, 05, 06, 07, 09, 10, 11, 12, 13
+
+## Question
+
+Assemble the destination spec from the resolved decisions: architecture + contract decomposition + questioning-UX contract + shipping shape + first milestone against the confirmed dev-target portfolio. Non-goals (harness-agnosticism) and the elicitor→executor seam named explicitly. This is the map's terminal deliverable; resolving it ends the effort.
+
+## Answer
+
+> Resolved by spec assembly, 2026-08-10. Full read of the ~54K-token working set (map, glossary, tickets 01–13 in the pre-pass's amendment order, both inbox docs), one session, no digest subagents — as sized.
+
+**The spec is assembled: [spec.md](../../../../spec.md)** — the map's terminal deliverable. Fourteen sections + an adjudications appendix: purpose · non-goals & the elicitor→executor seam · vocabulary · four shells + binding · the capture envelope (derived-status principle, three strata) · operations & validation strata · questioning-UX contract · capture mechanics · sessions/durability/storage port · the ten-item substrate-capability list · plugins & packs · shipping shape · dev targets & milestone one (gherkin + assurance argument, `Statement` contract) · acceptance material (five proof obligations, ten harness invariants restated in envelope vocabulary, gating tests, testing strategy, open verification items).
+
+**All seven pre-pass contradictions adjudicated** (spec Appendix A): C1 storage port binding-implemented, with the `db.ts`-vs-capture-store reconciliation stated; C2 the four operations stay pure — ticket 12's PluginContext-storage clause scoped to non-op code, milestone one defines no such methods; C3 status derived, never stored — retraction specified as an explicit user-cited event with no successor; C4 tap-ness made a transport fact via a harness-defined reserved reply encoding (else absences are inferred); C5 invariant 1 reconciled with the provenance rule — user-derived captures cite user entries, `defaulted`/`external-lookup` cite declared defaults/documented transformations; C6 the channel is a per-message current-affordance surface, durable identity on tool output parts, reject-second-interactive-affordance as mechanism; C7 picked together — no instruction interpolation (kills the wake wart's cause), pending question on the ask tool result + pending-affordance slot, reply binding harness-mechanical via the single-pending invariant, no echo token.
+
+**Notable assembler adjudications beyond the seven** (each flagged inline in the spec): retraction semantics; `not-mentioned` demoted to computed fact; absence-strip label mapping and the `not-yet-decided`/`deferred` distinction; advisories as computed-ephemeral vs. stored issues; issue namespacing; domain labels computed via `project` at read time; transport outcomes `answered | redirected | unanswered` (`unavailable` retired); session→target-document binding via `initialData`; milestone-one store format constrained by whole-sweep atomicity; **kernel card** kept as a term of art, **"kernel invariants" renamed harness invariants**.
+
+**Fold-ins completed alongside**: `CONTEXT.md` gained the envelope-vocabulary section (capture envelope, evidence span, epistemic status, absence state, supersession, resolution record, issue, advisory, pack, kernel card, PluginContext, storage port — pre-pass L11) and the kernel-compound ruling (L12); the `plugin-assurance` rename propagated as header notes on tickets 02 and 07; the 42-item obligation checklist verified covered (§ mapping held during drafting); the ten kernel invariants restated in current vocabulary (S14) so only one vocabulary exists in the acceptance criteria.
+
+Resolving this ticket ends the effort: the map's frontier is empty. Remaining fog (dev-app probe view, remote deploy target, storage format, concurrent-session coordination, plugin-ecosystem machinery, the real name) is post-spec by construction and graduates with the build effort the spec now enables.
+
+## Comments
+
+**2026-08-10 (pre-assembly prep, HITL).** Three prep items completed ahead of this ticket:
+
+- **Second-target rename decided**: the target is the **assurance argument**, package `plugin-assurance` (recorded on the [Formal-verification canon survey](09-formal-verification-canon-survey.md); ticket 09's category-error verdict discharged). Propagate over the historical `elicit-proof-obligations` occurrences in tickets 02 and 07.
+- **Cross-ticket consistency pre-pass**: [notes/consistency-prepass-2026-08-10.md](../notes/consistency-prepass-2026-08-10.md) — the assembler's working checklist. Contents: **seven contradictions** the spec must adjudicate, each with an authoritative-side recommendation (C1 storage-port implementer; C2 op purity vs PluginContext storage methods; C3 derived capture status changes 04's envelope schema; C4 `deferred (explicit)` lacks a transport mechanism; C5 provenance rule vs kernel invariant 1's declared defaults; C6 one-live-affordance slot vs multiplexed forms; C7 wake-wart remedy and reply binding must be picked together); **fourteen stale statements** (S1–S14) so nobody re-imports superseded material — notably 03's partly-overturned classification table and the requirement to restate the ten kernel invariants in current vocabulary; the **42-item "the spec must…" checklist** (§3b) collected from every ticket; and the **amendment-order reading guide** (§4) — read tickets in that order, treating 01/02/03 as lookup sources.
+- **Sizing corrected**: ~54K tokens total — map + glossary + tickets (~42K) **plus the two inbox docs** (`agentic-elicitation-challenges`, `agentic-elicitation-criteria`, ~13K), which ticket 04 adopts by reference and by count, so the spec cannot be assembled without reading them. Fits one session raw; no digest subagents needed.
+
+**New blocker added**: [Walking skeleton: sweep seam on Flue](13-walking-skeleton-sweep-seam.md) — the pre-pass found the sweep seam unproven on the committed substrate (no settlement-trigger lifecycle event exercised, no proven harness path to read a session entry range; items L1–L3). Decision (HITL, 2026-08-10): prove it before assembly. Its resolution also completes the substrate-capability list this spec must enumerate.
+
+Also fold in when drafting: the glossary needs the envelope vocabulary added (pre-pass L11–L12) — capture envelope, evidence span, epistemic status, absence state, resolution record, supersession, pack, issue, kernel card, PluginContext, storage port — and a ruling on the "kernel card" / "kernel invariants" compounds vs the glossary's "avoid: kernel".
+
+**2026-08-10 (HITL review round 1, via tuicr).** Seven comments on the draft; five spec amendments: (1) **executor/handoff language removed entirely** — brunch adoption leakage; the spec now names _no privileged downstream consumer_ (partially supersedes obligation 17's "elicitor→executor seam" clause); (2) absence-state enum marked a working set with expected extension pressure (the assumption vs. known-unknown lesson; naming-for-behavioral-activation as kernel-card-grade work); (3) structured taps pinned as optional ui capability, not a requirement; (4) `project` kept as canon op name with a stated prose preference for the noun (and the §9.4 "signals project" verb collision fixed); (5) **new §9.7 compaction vs. durable log** — compaction may shrink what the model re-reads, never what the store can resolve; durable-projection independence stated as a storage-contract constraint, binding absorbs otherwise; verification item added to §14.5; (6) Principle v2 ratified by acclaim, no change; (7) **binding packages take the role prefix**: `packages/binding-flue`, horizon `binding-*` (product name lives in the npm scope, not the basename).
+
+**2026-08-11 (HITL review round 2, from the plain-prose read-through).** Four observations, all folded in: (1) evidence pointers confirmed already stored — §5 sharpened so quote→entry resolution is stated as write-time-once, every later reader navigates by pointer, never text search; (2) `declined` ≠ `deferred` pinned in §5.1 — a decline is a boundary (closes only via explicit act), a deferral an invitation (completion evaluation chases it); (3) **conversations are documents too** — storage-port scope extended to capture store **plus session-log archive**, archive-on-read mechanism, session logs retained indefinitely with the target-document (§9.1/§9.6/§9.7 amended; the archive also becomes the compaction defense); (4) **generic strategy quiver written in as §11.5**, named-not-designed — guidance ownership follows vocabulary ownership; harness-shipped strategy cards over envelope vocabulary, plugin-composed; reference shapes `ln-grill`/`ln-disambiguate` and brunch's style trichotomy; the assurance technique decomposes into generic strategy + domain cards. `CONTEXT.md` (storage port, kernel card) and both companion docs updated to match. Note: round 2's changes were narrated in-session on 2026-08-10 but committed 2026-08-11 — the earlier narration preceded the actual edits.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/09-formal-verification-canon-survey.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/09-formal-verification-canon-survey.md
new file mode 100644
index 00000000000..25039df9bb0
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/09-formal-verification-canon-survey.md
@@ -0,0 +1,137 @@
+# Formal-verification canon survey
+
+Type: research
+Status: resolved
+Resolved: 2026-08-06
+
+## Question
+
+> **Rename decided 2026-08-10** (HITL, during spec-assembly prep): the second target is the **assurance argument** — GSN's own noun, per this ticket's verdict that "proof obligations" reads as a category error. Package: `plugin-assurance` (was `plugin-proof-obligations` in the Shipping-shape topology). References to `elicit-proof-obligations` below are the historical name.
+
+What existing canon should the `elicit-proof-obligations` output contract hew to, and — written didactically, for a reader new to formal verification — what does a verification workflow _actually do_: what are its artifacts, what is one trying to produce, where does the human effort go?
+
+Specifically:
+
+- **Dafny's contract vocabulary** (`requires` / `ensures` / `invariant` / `decreases`, pre/postconditions, loop invariants): how practitioners actually express obligations, and how much of that vocabulary transfers to a language-agnostic claim DAG
+- **Proof-obligation workflow 101**: in Dafny/Lean/TLA+-style work, what is the day-to-day loop (state → obligation → discharge/failure → refine)? What does "an obligation" look like as an artifact? What roles do assumptions/axioms play?
+- **Geolog / ARIA relevance**: what is Geolog (ARIA program context — axiom sets ostensibly addressed via Datalog-like queries), and does its shape align with our acyclicity + Datalog-closure validator design?
+- **Recommendation**: what our claim-DAG format should align to — which canon's vocabulary, which parts to adopt vs. leave, and what the smallest canonical-feeling output contract for milestone one looks like
+
+Context: the portfolio decision (issue 07) adopted zil-lean's _ideas_ (assurance lattice, PROVED/CONDITIONAL/WEAK/BROKEN ladder, Datalog-closure validation) but rejected its format as unproven; the output contract should feel native to people who do this work.
+
+## Answer
+
+> Resolved by `/research` subagent, 2026-08-06.
+
+# Formal-Verification Canon Survey — for the `elicit-proof-obligations` target
+
+## 1. Proof-obligation workflow 101
+
+**The daily loop (Dafny-style, most concrete of the three).** You write code _and_ annotations in the same file. You hit save. The verifier translates your program into a pile of logical formulas called **verification conditions (VCs)** and asks an automated prover whether each is valid. Dafny specifically "verif[ies] that the program meets its specifications, by translating the program to verification conditions and checking those with Boogie and an SMT solver, typically Z3" ([Dafny Reference Manual §13.1](https://dafny.org/latest/DafnyRef/DafnyRef)). Green = discharged. Red = an assertion the solver could not prove. You then edit _the annotations, not usually the code_, and re-run. Loop time is seconds-to-minutes; Midspiral reports "proofs often take more than 10 minutes to run" on real domains ([midspiral.com](https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/)).
+
+**What a proof obligation _is_.** It is machine-generated, not human-authored. The human writes _contracts_; the tool derives obligations from them. Worked micro-example:
+
+```dafny
+method Decrement(n: int) returns (m: int)
+  requires n > 0        // precondition — caller must establish
+  ensures m == n - 1    // postcondition — callee must establish
+  ensures m >= 0
+{ m := n - 1; }
+```
+
+From those three lines the verifier generates roughly: (a) _assuming_ `n > 0` and the body's effect, prove `m == n-1`; (b) same, prove `m >= 0`; (c) at every call site of `Decrement`, prove `n > 0` holds there. Add a loop and you get more: the invariant holds on entry, is preserved by one iteration, and (with the negated guard) implies what follows — "The `invariant` clause is effectively a precondition and it along with the negation of the loop test condition provides the postcondition. The `decreases` clause is used to prove termination" (Dafny RM §7.6). Termination needs the `decreases` expression to both _decrease_ and be _bounded below_ ([Dafny tutorial, Termination](https://dafny.org/dafny/OnlineTutorial/guide)).
+
+**"Discharging"** = the prover established that VC. Nobody hand-writes it. **On failure there are exactly two diagnoses** and telling them apart is the actual skill: "there are two main causes for Dafny verification errors: specifications that are inconsistent with the code, and situations where it is not 'clever' enough to prove the required properties" (Dafny tutorial). Failure gives you an error at a source location, optionally a counterexample — which Dafny explicitly downgrades to a hint: "Dafny cannot guarantee that the counterexample it reports provably violates the assertion... should be inspected manually and treated as a hint" (RM §13.7.1).
+
+**Where human effort goes.** Not into proofs — into _specs, invariants, and hints_. Concretely: strengthening a loop invariant; adding a `lemma` ("a lemma states a logical fact, summarizing an inference that the verifier cannot do on its own," RM §6.3.3); hiding irrelevant facts so the solver focuses ("sometimes less information is better for the solver," RM §8.20.2). Midspiral's numbers make the shape vivid: same kernel, "counter domain (~50 lines of proofs) and the Kanban domain (~1,400 lines of proofs)."
+
+**Durable vs. ephemeral artifacts.** Durable: the specification (contracts, invariants), the lemma corpus, and — critically — **the ledger of things assumed rather than proved**. Ephemeral: SMT queries, counterexamples, timings, proof-search traces. And the canon is explicit that the durable spec is the weak point: "Proofs guarantee that the implementation satisfies the specification. They don't guarantee that the specification is what you actually wanted... The human still owns the spec" (Midspiral, _Methodology Limitations_). That sentence is the entire justification for your product.
+
+## 2. Dafny's contract vocabulary — what transfers
+
+| Keyword              | Meaning                                   | Transfers to a claim DAG about an arbitrary system?                                                                      |
+| -------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `requires`           | precondition, obligation on the _caller_  | **Yes** — the canonical name for "this claim's premise / what must hold for my guarantee to mean anything"               |
+| `ensures`            | postcondition, obligation on the _callee_ | **Yes** — canonical for "guarantee"                                                                                      |
+| `invariant`          | property preserved across steps           | **Yes** — reads naturally as a system-level always-true claim                                                            |
+| `decreases`          | termination measure                       | **Partial** — as a _well-foundedness witness_ it's the honest canonical way to license a cycle; otherwise program-bound  |
+| `modifies` / `reads` | frame conditions                          | **No** — "framing only applies to the heap, or memory accessed through references" (RM §7.1.4). Inherently program text. |
+| `assert`             | prove this here                           | **Yes** — an obligation you accept                                                                                       |
+| `assume`             | take this on faith                        | **Yes** — this _is_ your "assumption with review status"                                                                 |
+| ghost state          | spec-only variables, erased at compile    | **No** — an artifact of having a compiler                                                                                |
+| `lemma`              | named reusable inference step             | **Yes** — maps directly to your lemma record                                                                             |
+
+The single most transferable thing in the Dafny ecosystem is not a keyword: it is **`dafny audit`**, which "reports issues in the Dafny code that might limit the soundness claims of verification" and flags declarations marked `{:axiom}`, `{:verify false}`, `{:extern}` with contracts, any `assume` in a body, and `decreases *` — because "the key purpose of the `audit` command is to ensure that all assumptions are intentional and acknowledged" (RM §13.6.1.8). It emits a **Markdown table**. That is, near-verbatim, the output artifact you are building. Adopt its framing.
+
+## 3. Adjacent canons
+
+**TLA+.** Obligation-like artifact: an _invariant_ or _temporal property_ checked against a state machine. Two tools, two epistemics. TLC does bounded exhaustive search: it "builds a finite state model... performs a breadth-first search... If TLC discovers a state which violates a system invariant, it halts and provides a state trace path" ([Wikipedia](https://en.wikipedia.org/wiki/TLA%2B)). TLAPS does real proof: proofs are "transformed into individual obligations which are sent to back-end provers" (Isabelle, Zenon, Z3), and are "hierarchically structured, easing refactoring and enabling non-linear development: work can begin on later steps before all prior steps are verified." **Fit: strong on structure** — hierarchical, obligation-per-step, partial completion is normal — but the vocabulary (`Init`, `Next`, `[]`, fairness) presumes a state machine you don't have.
+
+**Lean / Isabelle.** Artifacts: `definition` / `lemma` / `theorem`, organized in namespaces, with `axiom` a first-class declaration kind ([Lean Language Reference §8](https://lean-lang.org/doc/reference/latest/)). The culture-critical mechanism is **`sorry`-tracking**: a proof left incomplete still typechecks but taints the result, and `#print axioms` reveals the taint. **Fit: excellent for your lemma/theorem/assumption trichotomy and for the CONDITIONAL rung** — "proved, but modulo these named holes" is native theorem-prover thinking.
+
+**Alloy.** Vocabulary: `sig` (signatures define vocabulary), `fact` (always-true constraints), `pred`, `fun`, `assert` — checked by a SAT-based model finder within a bounded scope ([Wikipedia](<https://en.wikipedia.org/wiki/Alloy_(specification_language)>)). "Lightweight formal methods": finds counterexamples, never proves. **Fit: weaker on vocabulary, but philosophically closest to milestone one** — you too are doing a cheap, bounded, always-terminating check that surfaces defects rather than certifying correctness. Borrow the _stance_, not the nouns.
+
+**GSN (assurance cases).** Six core element types: **Goal** (a claim), **Strategy** (the nature of the inference from a goal to its sub-goals), **Solution** (a reference to evidence), **Context**, **Assumption**, **Justification** (rationale). Two link types: **SupportedBy** (inferential or evidential) and **InContextOf** (relating Context/Assumption/Justification to Goals and Strategies). Goals and Strategies may be marked **Undeveloped** — "a line of argument has not been developed yet." Large arguments modularize via **away goals** ([GSN Community Standard v1, FAA-hosted PDF](https://www.faa.gov/about/office_org/headquarters_offices/ang/redac/redac-sas-201503-gsn-community-standard-v1.pdf); [SCSC GSN](https://scsc.uk/gsn); GSN liaises with OMG's [SACM](https://www.omg.org/spec/SACM/)). **Fit: best of the four for interviewed claims about an arbitrary system.** It was designed for exactly your situation — a human argues that a system is adequate, with heterogeneous evidence, in a graph, where "not yet argued" is a legitimate node state.
+
+## 4. Geolog / ARIA — negative result, stated plainly
+
+**No ARIA / Safeguarded AI / davidad artifact named "Geolog" could be found.** Searches across `geolog + davidad`, `geolog + Safeguarded AI`, `geolog + Datalog + verification kernel`, and GitHub returned nothing. The ARIA [Programme Thesis v2](https://aria.org.uk/media/ikrkutfk/safeguarded-ai-programme-thesis-v2.pdf) is an image-heavy PDF whose text could not be extracted; the [funded projects page](https://aria.org.uk/opportunity-spaces/mathematics-for-safe-ai/safeguarded-ai/funded-projects) and the [TA1.1 Theory call](https://aria.org.uk/media/tfkjkjxy/aria-safeguarded-ai-ta11-theory-call-for-proposals.pdf) describe "computationally practicable mathematical representations and formal semantics" without naming a logic. **Do not build on a claim that ARIA ships something called Geolog.**
+
+**What "Geolog" actually names in the literature** (documented): a logic-programming language for **coherent logic**, the language whose queries Skolem machines compute (Fisher & Bezem, _Skolem Machines_; Bezem & Coquand, _Automating Coherent Logic_). Coherent logic is "a restriction of first-order logic due to Skolem that is proof-theoretically tractable"; geometric logic is its infinitary generalisation, with axioms written as sequents built from `⊤, ∧, ⊥, ⋁, ∃, =`, and models "preserved and reflected by geometric morphisms" ([Wikipedia: Geometric logic](https://en.wikipedia.org/wiki/Geometric_logic); [nLab: geometric theory](https://ncatlab.org/nlab/show/geometric+logic)). There is a separate, unrelated _Geolog_ for GIS/spatial Prolog ([arXiv:2109.08295](https://arxiv.org/abs/2109.08295)).
+
+**Does the shape align with acyclicity + Datalog closure?** Yes, and non-trivially. Coherent-logic provers are **forward-chaining fixpoint engines** — "the first automated theorem prover based on coherent logic, Euclid, was developed in Prolog and its inference system relied on a forward-chaining mechanism," computing "the fixpoint for a geometric configuration" ([Automating Coherent Logic, Springer](https://link.springer.com/chapter/10.1007/11591191_18); [A Deductive Database Approach to Automated Geometry Theorem Proving](https://link.springer.com/article/10.1023/A:1006171315513)). Datalog is precisely the ∃-free, ⋁-free fragment of that. **(Inference):** the validator is a Datalog restriction of a coherent-logic saturation engine, which is a genuinely canonical lineage you can cite — Geolog is the _right ancestor_ to name, just not an ARIA one. Honest caveat: coherent logic in general is undecidable; Datalog is not. The restriction is what buys determinism.
+
+_(Adjacent, real, and possibly what was half-remembered: ARIA-adjacent work on **Kolm**, "an early-stage decentralized proof database designed to interoperate with Lean" — mentioned in [a davidad interview](https://www.cognitiverevolution.ai/alignment-with-awakening-davidad-on-moral-realism-ai-wisdom-why-his-p-doom-is-down-to-5/), with usable tools projected end of 2027. Single-source; treat as unconfirmed.)_
+
+## 5. RECOMMENDATION
+
+**Align to a GSN skeleton with Dafny nouns on the claim fields and Lean/Dafny-audit semantics on the status ladder.** GSN because it is the only canon designed for _argued_ claims about a system by humans with mixed evidence; Dafny because `requires`/`ensures`/`invariant`/`lemma` are the words verification people reach for first and cost nothing to adopt; `dafny audit` because it is literally the deliverable.
+
+**Adopt:** GSN's Goal / Strategy / Solution / Assumption / Justification vocabulary and its two link types; Dafny's `requires`/`ensures`/`invariant`/`lemma`/`assumption`; Lean's `sorry`-taint semantics; `dafny audit`'s "list of intentional, acknowledged assumptions" as the primary output.
+**Leave:** `modifies`/`reads` (heap-bound), ghost state, TLA+'s temporal operators, Alloy's `sig`/scope machinery.
+
+### Smallest canonical-feeling milestone-one contract
+
+**One record type, `Statement`, with a `kind` discriminant** (avoids five near-identical schemas):
+
+- `id`, `kind` ∈ {`goal`, `strategy`, `assumption`, `lemma`, `theorem`, `guarantee`, `constraint`, `evidence`, `justification`, `context`}
+- `statement` — one natural-language sentence, indicative mood
+- `owner`, `review_status` ∈ {`unreviewed`, `accepted`, `disputed`, `retired`} _(assumptions only; from `dafny audit`)_
+- `criticality` ∈ {`catastrophic`, `major`, `minor`} — **note: this comes from safety engineering (DAL/SIL/ASIL), not from Dafny/Lean, which have no notion of it.** Source it there and say so.
+- `evidence_refs[]`, `provenance` (transcript span), `developed: bool` (GSN Undeveloped)
+
+**Four edge kinds:**
+
+1. `supports` (GSN SupportedBy — inferential; child → parent)
+2. `evidenced_by` (GSN SupportedBy — evidential; claim → evidence)
+3. `requires` (Dafny precondition; claim → premise it needs)
+4. `in_context_of` (GSN InContextOf; claim → assumption/context/justification)
+
+Only `supports`, `evidenced_by`, `requires` are load-bearing for status. `in_context_of` is scoping.
+
+**Derived status, stratified:**
+
+- **S0** `refuted(X)` if evidence marked contradicting; `open(X)` if `kind=assumption ∧ review_status ∈ {unreviewed, disputed}`
+- **S1** `BROKEN(X)` if `refuted(X)` ∨ ∃ load-bearing child `BROKEN` _(pure positive recursion — closes first)_
+- **S2** `WEAK(X)` if ¬BROKEN ∧ (`¬developed` ∨ (no `evidenced_by` ∧ no `supports`))
+- **S3** `CONDITIONAL(X)` if ¬BROKEN ∧ ¬WEAK ∧ ∃ transitively-reachable `open` assumption
+- **S4** `PROVED(X)` if ¬BROKEN ∧ ¬WEAK ∧ ¬CONDITIONAL
+
+Negation only ever looks at a lower stratum — that is the stratification the validator must enforce, alongside acyclicity of the three load-bearing edge kinds.
+
+### Where canon conflicts with already-made decisions
+
+1. **The four-rung ladder is not canon; the audit list is.** Dafny and Lean are binary (verified / not) _plus an enumerated list of soundness caveats_. **Canon should win on emphasis:** make the per-claim status a derived UI label, and make the **assumption ledger** — every `open` assumption with its owner, review status, and which guarantees it taints — the headline artifact. Ship it as a Markdown table, like `dafny audit`.
+2. **Acyclicity is stricter than canon.** Lean and Dafny permit mutual recursion licensed by a `decreases` measure. **The acyclicity decision should win for milestone one** — it makes validation trivially decidable and the failure message legible — but record it as a deliberate restriction and name `decreases` as the future escape hatch. That framing reads as informed rather than naive to a verification reader.
+3. **GSN is deliberately _not_ computed.** A GSN goal structure is a human argument; nobody derives a verdict from it mechanically. The Datalog closure must therefore be sold as a **well-formedness and taint-propagation check, not an assurance verdict.** Never let the UI say a claim is "proved" unqualified. Borrow Alloy's honest stance: this finds defects; it does not certify.
+4. **"Proof obligation" is a term of art for a machine-generated VC.** We are eliciting _contracts and claims_, from which obligations would later be generated. Calling the output "proof obligations" will read as a category error to a Dafny user. **Prefer "obligation ledger," "claim structure," or "assurance argument."**
+
+## 6. Unreached sources
+
+- ARIA **Safeguarded AI Programme Thesis v1.2 / v2** — PDFs are image-based; no text extraction. Likely the single highest-value unread source for Q4.
+- **GSN Community Standard v3 (SCSC-141C)** — download endpoint returns a redirect stub, not the PDF. GSN element definitions come from the FAA-hosted v1 plus secondary literature; v3 may have refined them.
+- **Bezem & Coquand, _Automating Coherent Logic_** (ResearchGate HTTP 403) and **Fisher & Bezem, _Skolem Machines_** (Semantic Scholar, empty body) — the primary Geolog sources. Read via institutional access before citing Geolog's concrete syntax.
+- **LessWrong: _Davidad's Provably Safe AI Architecture_** — HTTP 429 rate-limited. Worth a retry for Q4.
+- **Alloy online tutorial** (HTML parser crash) and **alloytools day-course slides** (PDF) — Alloy detail rests on Wikipedia plus its citation of Jackson's _Software Abstractions_.
+- **TLAPS project site** (`lamport.azurewebsites.net/tla/tlaps.html`, 404); TLAPS facts are from Wikipedia and the INRIA mirror.
+- **Isabelle documentation** (fetch error) — Isabelle is covered only by analogy to Lean here.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md
new file mode 100644
index 00000000000..9efa6328e82
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md
@@ -0,0 +1,43 @@
+# Walking skeleton: Flue question round-trip
+
+Type: prototype
+Status: resolved
+Resolved: 2026-08-07
+Blocked by: 05
+
+## Question
+
+Does the one-channel questioning transport hold up in a real Flue agent + web UI? Build a walking skeleton — real Flue agent, minimal elicitor stub (no plugin), one question round-trip: structured ask affordance emitted via a single kernel-owned data channel (`form` tag + markdown-baseline payload), answer returned as string dispatch, interpretation recorded to the session.
+
+Proves or refutes (proof obligations delegated from the Questioning-UX contract, issue 05):
+
+- The **one-channel multiplex** working hypothesis: one fixed `data-exchange` channel, forms discriminated inside the payload, plugin widgets as progressive enhancement.
+- The **data-part update-in-place vs. append** contradiction in Flue's docs (hooks reference says in-place; streaming protocol + `AgentReply.data` say append) — runtime check.
+- Whether a reply needs an **echo token** binding it to the question asked, or whether transcript adjacency + agent interpretation suffice.
+- What the **turn-suspension protocol** actually needs to persist (`terminate: true` tool + fresh-dispatch answer) — and how a cancelled/redirected question reads back from the session.
+- UI-side **rendering ergonomics**: branching on the form tag, markdown fallback for unknown forms, `purpose`/`display` filtering of non-user-facing traffic.
+
+## Answer
+
+> Resolved by walking skeleton, 2026-08-07. Real Flue agent (`@flue/runtime` 2.0.3, vite 8, Node target, no db) + React UI (`useFlueAgent`), driven live over multiple conversations: full round-trips through single-choice, free-text, an unknown form, absence-strip taps, and a redirect. Prototype captured on branch **`prototype/10-flue-roundtrip`** (`prototypes/flue-roundtrip/` — README documents the probes; `probe-stream.mjs` is the SSE-level evidence).
+
+**Overall: the transport holds — with one load-bearing amendment.** The one-channel questioning transport survives contact with the real runtime, but the fixed data channel is a _one-live-affordance slot per message_, not an accumulating log, so affordance **identity** must ride the ask tool's output part, not the channel.
+
+### Verdict per proof obligation
+
+1. **One-channel multiplex: PROVEN, amended.** One `data-exchange` channel carried three forms (single-choice, free-text, and the deliberately unknown `rating-stars`); the UI branched on the `form` tag, rendered widgets for known forms and the markdown floor for the unknown one, and reply transport stayed string-only throughout. **The amendment:** writes to one channel name materialize _last-write-wins per assistant message_ — forced two `ask_user` calls in one turn, and the first question's affordance was silently clobbered from the durable record (both `dynamic-tool` parts survived, with inputs and validated outputs). So: the channel is a "current affordance" surface; per-ask identity and payload belong on the ask tool's `output` (Flue's React docs bless exactly this — tool output parts exist "so applications can render custom tool interfaces"). A kernel invariant follows: **the ask tool must reject a second ask in the same batch** (mechanism, not instruction — the stub's instruction-level "one question at a time" held until deliberately overridden, but the guarantee belongs in the tool).
+2. **Update-in-place vs append: SETTLED — update-in-place, at every layer.** The hooks reference wins; the streaming protocol's "append" describes delta chunks, not part materialization. Evidence: two same-channel writes (`draft` → `open`) produced two SSE deltas but every snapshot held exactly one part; durable history holds one part (final value); even `readSubmissionReply`'s "emit order" array returns one entry. Clients DO see intermediate values live (progress rendering works); only the final value persists.
+3. **Echo token: NOT NEEDED for the tested shapes — adjacency + persistent pending state suffice.** All replies were bare strings (typed text, choice-button labels, absence taps, a mid-stream redirect); the agent bound every one to the correct `exchangeId` because the pending question (with its id) is interpolated into the instructions from `usePersistentState`. The binding evidence is the `record_interpretation` tool part citing the exchangeId — session evidence, exactly as issue 05 hypothesized. Untested residual: simultaneous multiple open questions (ruled out by the one-ask invariant above) and long-delay/interleaved answers.
+4. **Turn suspension: WORKS, with a wake wart.** `terminate: true` + pending question in `usePersistentState` + answer-as-fresh-dispatch is sufficient; nothing else needed persisting. A cancelled/redirected question reads back cleanly: the affordance part stays in the transcript, and the `record_interpretation` part (`outcome: redirected`, `epistemicStatus: stated`) is the resolution evidence — the store-level guarantee issue 05 wanted. **The wart:** writing pending-state that's interpolated into instructions triggers a "System instructions updated" advisory _after_ the terminating batch, which wakes the model for an extra turn that emits redundant "I'm still waiting…" text — one wasted model call per ask, plus transcript noise. Spec options: don't interpolate the pending question into instructions (keep it in state only, or narrate it inside the ask tool's result), or accept and UI-filter. Related fact: a mixed batch (non-terminating `record_interpretation` + terminating `ask_user`) still suspended correctly.
+5. **Rendering ergonomics: PROVEN.** Form-tag branching, markdown fallback, and read-back of a whole past conversation from durable history (including resolved-question dimming derived purely from `record_interpretation` parts in the transcript — no side store) all worked first try. Messages carry `purpose` and `display` fields (`display: "diagnostic"` on the advisory noise) — the UI must filter on them; the skeleton didn't at first, and the advisories rendered as visible cards.
+
+### Incidental facts worth the spec's attention
+
+- **`@flue/vite` hard-requires vite ^8** (its `parseAstAsync` TS support); on vite 6 the `'use agent'` scan dies with a bare parse error. The directive must also be the file's first statement.
+- **The Flue dev controller gives `app.ts` the entire request space** — no fall-through to vite's HTML serving — so a co-located browser UI is served by the Hono app itself (vite still transforms module requests, but react-refresh/HMR is off the table without a second server). A real deployment would face the same: the ui shell is a separate app or app-served static assets.
+- Data-channel writes are Valibot-validated per write; `body: v.any()` works fine as the opaque plugin-payload slot with typed envelope fields around it.
+- Restart durability untested by design (no `db.ts` → process-memory conversations; a restart wipes them — consistent with the deploy-target-owns-persistence hypothesis).
+
+## Comments
+
+**2026-08-07 (user, post-resolution):** Ratified reading of the questionnaire dimension against the clobbering finding — the whole questionnaire is a **single affordance with multiple steps**, not per-question affordances. The **one-ask-per-batch invariant stands** even though one ask may carry multiple questions passed in the same call. **Progression is UI-driven**: the payload carries all N questions, the ui walks them locally, answers return as evidence (individually or batched), and the agent interprets on settlement — zero intermediate model turns, sidestepping the wake-wart. Interpretation-on-settlement hands off to the capture-sweep semantics in ticket 11.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md
new file mode 100644
index 00000000000..d4cdf0916c2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md
@@ -0,0 +1,67 @@
+# Logic-prototype: capture sweep & settlement
+
+Type: prototype
+Status: resolved
+Resolved: 2026-08-07
+Blocked by: 05
+
+## Question
+
+Do the session-as-evidence capture mechanics hold up when implemented in isolation (no substrate — mechanism semantics only)? Build a logic-prototype of the harness's sweep machinery over a synthetic session log.
+
+Working hypotheses to prove or refute (delegated from the Questioning-UX contract, issue 05):
+
+- **Range-level settlement**: settlement is declared over ranges of conversation (a vein closing), never per-question — the agent judges _when_ a range has settled; the harness provides the bookkeeping (swept high-water mark). Per-question "settled" events are the rejected alternative (exchange-pair machinery through the back door).
+- **Sweep idempotence**: re-sweeping a range never double-captures (the retries-idempotent kernel invariant, exercised at the sweep level).
+- **Cancelled/redirected questions at sweep time**: an ask affordance committed to session but answered by cancellation, silence, or topic-change must read back honestly — as absence evidence, not as an answer.
+- **Supersession across sweeps**: a later range's captures superseding an earlier range's, via the envelope's one `supersedes` link and explicit events only.
+- **Conflict-resolution record**: a `conflicting` issue closes only via an explicit resolution record — a capture-layer event citing the user's utterance as evidence; the harness refuses to close the issue without it (the "no silent conflict resolution" invariant moved from wire to store).
+
+## Answer
+
+> Resolved by logic-prototype + HITL reaction, 2026-08-07. Prototype on throwaway branch
+> `prototype/11-capture-sweep` (commit d235258): single-file demo
+> (`11-capture-sweep.html`, an untracked historical artifact available from that branch) + headless
+> driver (32 checks passing) + browser walkthrough smoke (refusals land exactly on the
+> deliberately-illegal steps, no console errors). The pure reducer module — the liftable part — is
+> the demo's first script block.
+
+### Verdict: all five hypotheses hold, each sharpened
+
+1. **Range-level settlement — holds.** Zero per-ask state exists anywhere in the model; the swept high-water mark is the only sweep bookkeeping. Sharpened by the reaction: settlement decomposes into **trigger** (when to invoke the judgment — substrate lifecycle events such as turn-end/agent-settled; wiring proof delegated to ticket 10) and **judgment** (the agent names `upTo`). The race with concurrent user input is benign by construction: a sweep asserts only "read up to N," never "conversation paused" — new entries land above the high-water mark, in the next range.
+2. **Sweep idempotence — holds, split in two.** The harness guarantee is **mechanical** idempotence via evidence-anchored capture identity (dedup key = evidence spans + payload/absence) — aligned with where retries actually occur, since a retried tool call re-executes byte-identical proposals. **Semantic** re-interpretation (a fresh judgment re-phrasing the same fact) is deliberately not a harness concern: that is plugin `reconcile` + `possibly-equivalent` issues. Identity is **content-based, not range-based**: a re-sweep never double-captures but _can repair omissions_ (exercised in the dodged-question walkthrough). Epistemic status is excluded from identity — revising the epistemic reading of unchanged evidence requires explicit supersession, never a silent update.
+3. **Honest absence — holds.** A dodge reads back as `declined (inferred)`, a strip tap as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Absences are **evidence, not agenda**: the re-ask path runs through plugin `validate` → typed issues, with completion evaluation as the backstop for unresolved deferrals on required concepts. Adopted mechanism: the **unaccounted-ask advisory** — a swept range containing an ask with no reply and no capture citing it makes the harness report the fact and block nothing.
+4. **Explicit supersession — holds.** Supersession is single-hop over **active heads only**: superseding an already-superseded capture is refused, which is the lost-update guard (a corrector must confront the current head, so history stays a chain, never a silently forking tree). Sweeps validate and apply atomically; superseded captures remain visible — corrections don't erase history.
+5. **No silent conflict resolution — holds, with the wrinkle.** A bare close is refused; a resolution citing the _agent's_ words is refused; only a record citing the user's utterance closes a `conflicting` issue. Wrinkle: the envelope's one creation-time `supersedes` link cannot adjudicate between two _already-existing_ alternatives — there are **two supersession channels**: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status while authority sits in the record, suggesting per-capture status be **derived at read time** (echoes the derived-label approach from the formal-verification canon survey, issue 09).
+
+### Amendments to prior decisions (from the HITL reaction)
+
+- **Two validation strata**, amending the operation tiering in Contract decomposition (04): **envelope-level, harness-owned** — hard invariants enforced as refusals (provenance required, value-xor-absence, single-hop supersession) plus computed facts raised as advisories or generic `possibly-equivalent` issues (same-evidence duplicate actives, near-identical payload text — the harness can compare payloads as strings without understanding them) — versus **payload-level, plugin-owned** (`validate`/`reconcile` as already decided). Strengthens the smallest-honest-plugin test: a flat-record plugin gets generic duplicate detection for free.
+- **Op cadence is orchestration policy, not correctness.** Nothing had pinned when `project`/`validate`/`reconcile` run; snapshot-in/deltas-out purity means the harness may run them at any time without changing outcomes. Sweep-completion is the default trigger; the spec states cadence as explicit harness policy.
+- **Resume-time sweep reconciliation.** A session ending between settlement judgment and sweep leaves an unswept tail — a computable fact (entries above the high-water mark). On resume the harness surfaces it as an advisory and the agent judges whether to sweep before proceeding. Facts computed, weights judged.
+
+### Graduated
+
+The multi-session question raised in the reaction (target state durable beyond sessions; interleaved sessions against one target; re-entry semantics) graduates the map's "Spec permanence / sessions-roam-across-specs" fog → [Multi-session elicitation & durable target state](12-multi-session-durable-target.md). The prototype's decomposition carries it: durable capture store / per-session evidence logs / sweep as sole bridge, with the single-hop refusal doubling as the stale-session guard.
+
+## Comments
+
+**2026-08-07 (prototype built — awaiting your reaction; HITL).** The logic-prototype is done and the mechanics were exercised end-to-end. **Provisional verdict: all five hypotheses hold**, with two design wrinkles surfaced for the spec.
+
+**Assets** (throwaway branch `prototype/11-capture-sweep`, commit d235258):
+
+- `11-capture-sweep.html` — single-file shareable demo retained only on the historical branch. Five
+  guided walkthroughs (one per hypothesis, including every deliberately-illegal move) plus a
+  free-play console with evidence-ticking and a sweep-proposal builder. The pure reducer module (no
+  DOM) is the first `<script>` block — the liftable part.
+- `prototypes/driver/` (branch only) — headless sanity driver; `node driver.js` re-runs all five walkthroughs plus edge probes (32 checks, all passing). Also smoke-driven in headless Chrome: every walkthrough completes, refusals land exactly on the three illegal steps, no console errors.
+
+**Per hypothesis:**
+
+1. **Range-level settlement — holds.** The swept high-water mark is the _only_ sweep state; nothing per-ask exists anywhere in the model. An ask is just a session entry. The demo's "✓ Mark this question settled" button exists solely to explain why it isn't in the vocabulary.
+2. **Sweep idempotence — holds, and sharpened.** Idempotence falls out of _evidence-anchored capture identity_: a capture's dedup key is (evidence spans + payload/absence). That makes idempotence **content-based, not range-based** — a re-sweep of an already-swept range never double-captures _but can repair omissions_ (the dodged-question walkthrough does exactly this). This is stronger and more useful than gating on the high-water mark, and is the semantics the spec should pin.
+3. **Honest absence — holds.** A dodged ask reads back as `declined (inferred)`, a tapped strip as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Bonus mechanism worth speccing: a non-blocking **advisory** — when a swept range contains an ask with no reply and no capture citing it, the harness reports the fact and blocks nothing ("facts computed, weights judged" applied to sweep honesty).
+4. **Explicit supersession — holds.** Single-hop enforced (superseding an already-superseded capture is refused), sweeps apply atomically, history is never erased. Also surfaced: epistemic status is deliberately _excluded_ from capture identity, so re-reading the same evidence with a different epistemic status dedups as a retry — an actual revision must go through explicit supersession. The alternative (epistemic in the key) silently spawns near-duplicate actives.
+5. **Resolution records — holds, with the interesting wrinkle.** Bare close refused; resolution citing the _agent's_ words refused; only a record citing the user's utterance closes the issue. **Wrinkle:** the envelope's one creation-time `supersedes` link cannot express adjudication between two _already-existing_ alternatives — the resolution record (an event) has to carry that supersession instead. The spec should name both supersession channels: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status (`tentative` in the walkthrough) while the authority lives in the resolution record — which suggests read-time _derived_ status, echoing the derived-label idea from the formal-verification canon survey (issue 09).
+
+**To resolve this ticket:** click through the five walkthroughs (and free-play if inclined), react, and we record the verdict + fold the two wrinkles into the map.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/12-multi-session-durable-target.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/12-multi-session-durable-target.md
new file mode 100644
index 00000000000..fa4a756de47
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/12-multi-session-durable-target.md
@@ -0,0 +1,42 @@
+# Multi-session elicitation & durable target state
+
+Type: grilling
+Status: resolved
+Resolved: 2026-08-10
+
+## Question
+
+What is the multi-session model for elicitation: the target state that endures independently of sessions, the per-session evidence logs, and the semantics of leaving, resuming, and interleaving sessions against one target?
+
+Graduated from the map's "Spec permanence / sessions-roam-across-specs" fog by the capture-sweep logic-prototype (issue 11), whose model already decomposes cleanly for this: the capture store (captures, issues, events) as durable, session-independent truth; session logs as per-session evidence streams, each with its own swept high-water mark; the sweep as the only bridge between them. Evidence spans become session-qualified; idempotence keys already anchor on evidence and extend without redesign; the single-hop supersession refusal doubles as the stale-session lost-update guard; "the world changed since my last entry" is a computable re-entry fact (captures created/superseded since this session's last sweep).
+
+Prior art (brunch history, from the HITL reaction on issue 11): brunch v1 assumed one-session elicitation and it proved brittle and constraining; v2's direction made the elicited artifact durable beyond and independent of the sessions contributing to it — start a session, leave it unresolved, open another that picks up from the current state of truth, later return to the first, which must then understand that the world moved between its last entries and whatever it writes next.
+
+Sub-questions:
+
+- What exactly is durable — captures + issues + events only, or projections/artifacts too? What is stored vs derived?
+- Session identity and lifecycle: what _is_ a session in this model (one conversation? one substrate dispatch chain?), and what state is strictly per-session?
+- Interleaved or concurrent sessions against one target: are the single-hop supersession refusal plus a re-entry advisory sufficient coordination, or is more needed (locking, merge, explicit sync events)?
+- Re-entry briefing: what is a resuming agent told — unswept tail, world-moved delta, open issues — and in what form (advisory facts? the interpretation render)?
+- What does this do to the persistence-plugin-owned hypothesis and the storage port (feeds Shipping shape, issue 06) and to the spec's session vocabulary (feeds Assemble the spec, issue 08)?
+
+## Answer
+
+> Resolved by HITL grilling, 2026-08-10 (two rounds; frontier exhausted, every branch confirmed).
+
+### The model: durable target-document, transient sessions, sweep as the only bridge
+
+**Terms** (pinned in `CONTEXT.md`): the family/instance collision on "target" resolves by compound disambiguation, not a fresh noun — **target-domain** = the artifact family a plugin defines (gherkin, proof obligations); **target-document** = the durable unit sessions attach to: one target-domain + its capture store + its session history. Bare "target" stays legal where context disambiguates. The instance-noun names the unit by its _purpose_; the spec states plainly that its authoritative state is the capture store, never the render.
+
+1. **What is durable.** Durable truth = the capture store (captures, issues, events) **plus all session logs** — provenance must resolve forever; discarding swept logs would dead-end every capture's evidence spans. This is "corrections don't erase history" applied at the store level. Projections/renders/artifacts are strictly **derived**: cacheable, never authoritative.
+2. **Session identity & lifecycle.** A session is **one substrate conversation** — Pi's own model (the log of all messages: user, agent, tool calls, custom/state messages), which Flue inherits. Strictly per-session state is exactly three things: the evidence log, the swept high-water mark, the pending-affordance slot. **No formal close**: sessions go quiet and stay resumable indefinitely; "ended" would be a fiction the harness cannot verify. The ragged edge (ending between settlement and sweep) is already handled by ticket 11's resume-time unswept-tail advisory.
+3. **Concurrency: interleaved-only** (milestone one). The store is **serialized** — sweeps validate and apply atomically, a plain transactional guarantee, not a session lock. Staleness is optimistic: the **single-hop supersession refusal doubles as the stale-session lost-update guard** (a stale session superseding a moved head is refused, and the refusal carries the world-moved facts). Refusal granularity is **whole-sweep atomic** — matches the prototype; re-proposing is cheap once the advisory is digested (per-item partial application → fog). No locking, no merge, no sync events; true simultaneous-sweep coordination → fog, graduating only if a real concurrent consumer appears.
+4. **Re-entry briefing.** Injected **state messages**, following Pi's custom-entry convention: authored _on behalf of the user_ (compaction and session-branch summaries are the precedent — the transcript the model reads contains messages from or on behalf of the user summarizing important changes). Advisory-only, agent-facing, with a minimal user-visible insertion notice (as for other state changes). Content = the computed facts: unswept tail, world-moved delta (captures created/superseded and issues opened/closed since this session's last sweep; anchor = session start when it never swept), open issues, pending unanswered affordance. Harness computes, agent weighs — nothing forced; surfacing the world-moved summary conversationally is judgment guidance (kernel-card level), with the interpretation render available on request.
+5. **Provenance principle, sharpened: only the _true_ user's side is evidence.** The data model distinguishes true user entries from entries injected on the user's behalf. Capture evidence spans anchor only on true user (and user-affordance-payload) entries; injected advisories live in the log honestly — the session reads back complete — but are **never citable as capture evidence**. This generalizes ticket 11's resolution-record rule ("must cite the user's utterance") into one clean principle.
+6. **Completion is derived, never a gate.** A target-document has no lock/terminal state: completion-contract satisfaction is a read-time **derived status** (same family as derived capture status and issue 09's derived labels). A user returning with a correction after "done" is the motivating story of this ticket.
+
+### The storage flip (amends the standing hypothesis; feeds Shipping shape 06 and the spec 08)
+
+**Persistence is not plugin-owned — the hypothesis is flipped.** Mapping persistence to the plugin was a conflation; the capture-sweep model already made the store harness mechanism (envelope invariants enforced as store-level refusals). The **storage port is harness-defined and binding-implemented**: the deploy target decides _how_, the plugin never touches persistence, and if storage is addressable from plugin code at all, it is only through **harness-defined methods passed via the injected PluginContext**. This aligns with (and sharpens) ticket 06's capability-list entry "persist state" and its remote-parity constraint "host-owned storage port".
+
+**Evidence spans carry pointer + quoted excerpt**: session-id + range as the pointer, the load-bearing quote embedded in the capture. Provenance stays self-contained across local/remote differences in substrate log access; the substrate log remains the full record, the excerpt the citable quote.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md
new file mode 100644
index 00000000000..af5aa6fac1e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md
@@ -0,0 +1,72 @@
+# Walking skeleton: sweep seam on Flue
+
+Type: prototype
+Status: resolved
+Resolved: 2026-08-10
+
+## Question
+
+Prove the four substrate capabilities the capture-sweep machinery assumes but no prototype has exercised on Flue — the unproven seam between ticket 10's transport skeleton and ticket 11's synthetic-log logic-prototype, surfaced by the [2026-08-10 consistency pre-pass](../notes/consistency-prepass-2026-08-10.md) (items L1–L3):
+
+1. **Settlement trigger** — a substrate lifecycle event (turn-end / agent-settled) that invokes the agent's settlement judgment. Ticket 11 recorded this as "wiring proof delegated to ticket 10", but ticket 10 contains no settlement or lifecycle-event finding; the claim was a misattribution (L1).
+2. **Read a session entry range** — harness code reading the entries it sweeps. Ticket 01 found no documented path to Pi's message list from inside a Flue agent; ticket 10 proved read-back only on the ui side via `useFlueAgent`; ticket 11 ran against a synthetic log. The hinge between the two prototypes is proven nowhere (L2).
+3. **Inject an on-behalf-of-user state entry** — the carrier for ticket 12's re-entry briefing. Candidate: Flue's `kind: 'signal'` message with trusted-code attributes (ticket 01 §6), which would also yield the true-user-versus-injected provenance distinction for free.
+4. **Transactional durable store distinct from per-conversation state** — ticket 12 requires whole-sweep-atomic application (and refusals) across sessions; conversation-scoped `usePersistentState` cannot provide it (ticket 01).
+
+Success = a minimal Flue walking skeleton (seeded from `prototype/10-flue-roundtrip`) that wires ticket 11's pure reducer (`prototype/11-capture-sweep`) to a real session log through these four capabilities. The resolution amends Shipping shape's six-item substrate-capability list — these are its four missing entries (pre-pass L3) — or records what Flue lacks or forbids and what the Flue binding must therefore absorb (binding-size asymmetry is expected, per ticket 06).
+
+Blocks: [Assemble the spec](08-assemble-the-spec.md).
+
+## Answer
+
+> Resolved by walking skeleton + two HITL reaction rounds, 2026-08-10. Real Flue agent + web UI with a live target-document panel, two browser sessions against one target-document, driven live by the user; 21-check headless probe suite passing. Prototype on branch **`prototype/13-sweep-seam`** (`prototypes/sweep-seam/`; commits 276c0e4 skeleton, bbb3646 HITL fix).
+
+**Overall: all four capabilities hold on Flue — two natively, two absorbed by the binding, none forbidden — with one load-bearing amendment from the HITL rounds: evidence anchoring must be harness-resolved, not model-chosen.**
+
+### Verdict per capability
+
+1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is the would-stop control seam: awaited before the response settles; `ctx.append` steers a settlement-check signal into a same-response continuation turn; the hook re-fires at the next would-stop; the response settles only when nothing appends. Trigger computes facts, judgment stays with the agent (declining is legal). Mechanism findings: the hook **fires on `terminate: true` suspensions too** (the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn); the nudge itself becomes a session entry, so the trigger needs a **loop guard** (never re-nudge the same latest-user-entry). Observed cadence drift: the model preferred sweeping at reply time without waiting for a nudge — harmless _because_ sweeps are content-idempotent and harness-anchored; cadence is policy, exactly as ticket 11 said.
+2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (`getFlueRuntime` is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** (`GET <agent-url>?view=history`, @flue/sdk) over self-HTTP; works mid-response. The projection is sweep-sufficient: stable ids, stream order, **`purpose` as the provenance discriminator** ('user'/'assistant'/'dispatch'/'advisory'), signal descriptors, tool parts with validated outputs. **The amendment (HITL round 1):** the projection numbering is harness-side knowledge ONLY — hidden advisories inflate it and the model's seq guesses never converge, while its verbatim quotes are flawless. So the model-facing citation currency is the **quoted excerpt**; the harness resolves quotes to entries (user-entries-only candidates; no-match refuses with a repair hint; multi-match anchors latest with an advisory). Sharpens ticket 12's span shape: the excerpt is primary at proposal time, the pointer is derived.
+3. **Inject an on-behalf-of-user state entry — PROVEN, native.** `ctx.append` (same-response) and `dispatch({kind:'signal'})` (real delivery) share one vocabulary. Caller-defined signals project as system-role / `purpose: 'dispatch'` / `display: 'diagnostic'` with tagName + trusted attributes — **structurally distinct from true user entries, so ticket 12's citable-evidence rule is mechanically enforced** (a capture citing an injected entry is refused). The re-entry briefing worked in every shape: fresh session, resumed session, post-restart session — and in HITL round 2 it produced unscripted **conversational conflict-surfacing**: briefed with "September 12" and told "September 13", the agent asked instead of overwriting, then swept the correction as a supersession citing both the assertion and the confirmation.
+4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (milestone one: JSON file, tmp+rename atomic, in-process serialization), and every ticket-11 semantic survived the real log: whole-sweep-atomic apply/refuse, content-keyed idempotence (**load-bearing, not optional**, under Flue's at-least-once tool re-execution), single-hop supersession as the stale-session guard. Restart probe: conversations 404 (in-memory, no `db.ts`), store survives, a fresh session answers correctly from its briefing alone.
+
+### Capability-list amendment (Shipping shape, issue 06 — closes pre-pass L3)
+
+The six-item substrate-capability list gains four entries: **7. subscribe to the would-stop lifecycle seam, with same-response signal steering** (native); **8. read the session's durable entry projection, with provenance-discriminating entry kinds** (binding-absorbed; no in-process API); **9. inject typed non-user signal entries, same-response and as deliveries** (native); **10. provide a transactional durable store outside conversation state** (binding-absorbed entirely). Binding-size asymmetry landed exactly where ticket 06 predicted.
+
+### HITL round 2 — cross-session dynamics observed live
+
+Session-a captured date/time, guests, budget; session-b opened with a contradictory assertion ("Hilton, September 13"): briefing → conversational conflict-surfacing → user confirmed → **c4 superseded c1 citing both user entries**. Then the superseded-history payoff: the user said "the same time we said before, whatever that was" — the time lived only in the _superseded_ capture; the agent resolved it from the briefing's history and captured it as its own fact, honestly marked **inferred**, anchored to the user's actual words. "Corrections don't erase history" paying rent. One wrinkle for the spec: **compound payloads make supersession lossy** (c1 bundled date+time; c4 superseded it with date+venue and silently dropped the time until the user's remark rescued it) — capture granularity is plugin `validate`/kernel-card guidance territory. Same stratum as the other live find: a payload can smuggle an absence (`payload: "not-yet-decided"`) past the envelope — exactly the payload-level validation ticket 11 assigned to plugins.
+
+### Spec consequences (for issue 08)
+
+Entry identity is harness-side vocabulary; excerpts are the model-facing citation currency (amends the envelope's span story). Judgment prompts must never be the model's only source of mechanical facts (trigger suppression during suspension is correct but starves numbered context). Two payload-level validation examples now exist for the smallest-honest-plugin section. The wake-wart (ticket 10) remains cosmetically noisy ("I've noted the update…" doubling) — unchanged spec options.
+
+## Comments
+
+**2026-08-10 (walking skeleton built — awaiting your reaction; HITL).** The skeleton is done and all four capabilities were exercised against the real runtime, live model turns included. **Provisional verdict: all four hold on Flue — two absorbed by the binding as expected, none forbidden.**
+
+**Assets** (branch `prototype/13-sweep-seam`, commit 276c0e4, `prototypes/sweep-seam/`): real Flue agent + web UI with a live target-document panel (`bun run dev`, sessions `?id=session-a`/`session-b` share target-document `demo`); `node probe-seam.mjs` re-runs 18 checks (all passing). README documents the ask/terminate and restart probes.
+
+**Per capability:**
+
+1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is exactly the would-stop seam ticket 11 needed: awaited before the response settles, `ctx.append` steers a `settlement-check` signal into a same-response continuation turn, the hook re-fires at the next would-stop, and the response settles only when nothing appends. Trigger computes the facts (numbered unswept tail); judgment stays with the agent (declining is legal). Two mechanism findings: (a) the hook **fires on `terminate: true` suspensions too**, so the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn; (b) the nudge itself becomes a session entry, so the trigger must be **loop-guarded** (don't re-nudge the same max-user-seq; persistent `lastNudgedAt`).
+2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (the runtime getter is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** — `GET <agent-url>?view=history` via `@flue/sdk` — over self-HTTP; works mid-response (both the finish hook and the sweep tool read during the live response). The projection is sweep-sufficient: stable ids, stream order (seq), **`purpose` as the provenance discriminator** (`user` / `assistant` / `dispatch` / `advisory`), signal descriptors, tool parts with validated outputs. Warts: the binding must know its own base URL (env var here); a mid-flight read sees the partial assistant message; >1000-entry paging unprobed. Live-model finding: **entry-seq citation is error-prone for a small model** — the typed refusal steered a mis-cited sweep to correct in two hops (backpressure works), but the spec may prefer harness-resolved excerpt anchoring over model-chosen seqs.
+3. **Inject an on-behalf-of-user state entry — PROVEN, native.** Two carriers share one vocabulary: `ctx.append` (same-response, no delivery) and `dispatch({kind: 'signal'})` (real delivery). Caller-defined signals project as system-role, `purpose: 'dispatch'`, `display: 'diagnostic'`, with `tagName` + trusted `attributes` — **structurally distinct from true user entries, so ticket 12's provenance rule is mechanically enforceable** (probe: a capture citing an injected entry is refused at validation). The re-entry briefing worked in all three shapes: fresh session, resumed session, and post-restart session — the last answered the user correctly from the briefing alone. Nuance: Flue classifies these as dispatch/diagnostic rather than literally "on behalf of the user"; the Pi convention survives as signal + render guidance, and the sharpened citable-evidence rule is _stronger_ under Flue's classification.
+4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (JSON file, tmp+rename atomic, in-process serialization — milestone-one local), and **every ticket-11 semantic survived contact with the real log**: whole-sweep-atomic apply/refuse, content-keyed idempotence, single-hop supersession as the stale-session guard (cross-session probe: session-b superseded session-a's capture; a stale re-supersession was refused with world-moved facts). Restart probe: conversations 404 (`stream_not_found` — in-memory, no `db.ts`), the store file survives. Confirms pre-pass L13: Flue's at-least-once tool re-execution makes content-keyed idempotence load-bearing, not optional.
+
+**Proposed capability-list amendment** (Shipping shape 06 — its four missing entries, per pre-pass L3): 7. _subscribe to the would-stop lifecycle seam, with same-response signal steering_ (native: `useAgentFinish`/`ctx.append`); 8. _read the session's durable entry projection, with provenance-discriminating entry kinds_ (binding-absorbed: history route; no in-process API); 9. _inject typed non-user signal entries, both same-response and as deliveries_ (native: append/dispatch, `kind: 'signal'`); 10. _provide a transactional durable store outside conversation state_ (binding-absorbed entirely; Flue offers none). Binding-size asymmetry landed exactly where ticket 06 predicted — the Node binding absorbed 8 and 10.
+
+**Incidental Flue facts:** `agentName` must be a string _literal_ (the build-time scan rejects a constant reference); injected signals carry `display: 'diagnostic'`, so the ticket-10 UI-filtering lesson extends to them (the skeleton renders them as labeled cards instead — exploded-view-lite, per the map's fog note).
+
+**To resolve this ticket:** drive the skeleton (two browser sessions against one target-document is the fun path: sweep in one, resume the other), react, and we record the verdict + the capability-list amendment + graduate whatever fog the reaction surfaces.
+
+---
+
+**2026-08-10 (HITL reaction #1 → diagnosed and fixed; commit bbb3646).** The user drove session-a and sweeps never converged: an ask-heavy interview, then "let's sweep" → five refusals, model deflecting into more questions. Diagnosis from the session log: **the model's verbatim excerpts were flawless in every attempt; every entry seq was a guess** — five attempts, five different numberings, zero convergence. Two compounding causes: (a) the model _cannot_ know the projection numbering (hidden `System instructions updated` advisories — the ticket-10 wake-wart — inflate it, and the model never sees them); (b) in an ask-heavy flow the pending guard suppresses every settlement-check, so the numbered tail never re-arrives and a user-requested sweep runs blind.
+
+**The fix, which is itself the sharpened finding: evidence anchoring must be harness-resolved, not model-chosen.** The model now cites only verbatim user quotes (plain strings); the harness — the only party that can see the projection — resolves each quote to its entry (`resolveEvidence`: user-entries-only candidates, no-match refuses with a repair hint, multi-match anchors latest with an advisory note); seq numbers and `upTo` left the model-facing tool contract entirely. Replaying the user's exact failing flow headlessly now converges (the residual refusals en route were _correct_ envelope refusals — empty evidence, value-and-absence — which the model repaired). Probe suite extended and made self-contained: 21/21, twice consecutively.
+
+Spec consequences: (1) the questioning-UX/envelope contract should state that **entry identity is harness-side vocabulary; the model-facing citation currency is the quoted excerpt** — this also strengthens ticket 12's "pointer + quoted excerpt" span shape (the excerpt is primary at proposal time; the pointer is derived); (2) a payload can _smuggle_ an absence (`payload: "not-yet-decided"` observed live) — the envelope cannot catch it; that is exactly the payload-level stratum ticket 11 assigned to plugin `validate`, worth an explicit spec example; (3) trigger suppression during suspension is correct, but judgment prompts must never be the model's only source of mechanical facts.
+
+Still open for your reaction: the cross-session dynamics you originally set out to test (sweep in one browser session, resume the other — the headless probes exercise it, but the HITL reaction is the point).
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/map.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/map.md
new file mode 100644
index 00000000000..2b71cae130f
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/map.md
@@ -0,0 +1,70 @@
+# Map: Elicitation Kernel — carve-out spec
+
+Label: wayfinder:map
+Status: closed — destination reached 2026-08-10 (the spec is assembled:
+[spec.md](../../../spec.md))
+Created: 2026-08-06
+
+## Destination
+
+A reviewable **spec** for a standalone architecture (working name **elicitation kernel**) that generalizes brunch's elicitor into agentic interviewing against pluggable elicitation targets, on the Pi-family substrate, deployable local and remote (Flue-shaped). The spec fixes: the shipping shape (kernel library vs. Flue agent); the kernel / host / plugin contract decomposition (leading hypothesis: the four-contract + pack model from the agentic-elicitation-challenges doc, with persistence plugin-owned in accord with deploy target); the questioning-UX contract (successor to brunch's structured exchanges, critiqued not copied); and a first milestone against two live dev targets (elicit-gherkin + elicit-lean/formal, BPMN named third).
+
+## Notes
+
+- Tracker: local markdown (`docs/agents/issue-tracker.md`); this map and `issues/` are canonical. Ticket `Status:` values: `open` / `claimed` / `resolved`.
+- HITL tickets consult `/grilling` + `/domain-modeling`; research tickets resolve via `/research` subagents, AFK.
+- Plan, don't do: tickets resolve decisions. The spec (ticket 08) is the map's only deliverable.
+- Lexicon (hardened via `/domain-modeling` 2026-08-06, during the Questioning-UX grilling; canonical home: repo `CONTEXT.md`): **substrate** (the agent framework beneath: Pi family, Flue — the charter's "harness-agnostic core" non-goal reads "substrate-agnostic"), **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI; replaces "host"/"host-interface"), **harness** (the generic capability layer: mechanism + orchestration — the effort's essence is harness-engineering; replaces "kernel" as shell name), **plugin** (target-defining policy; composes packs, receives harness capabilities via a narrow injected context), **pack** (unchanged: ElicitationPack = concept/observation/completion contracts; ProjectionPack = projection contract; "kernel card" survives only as the pack-content unit), **target** (split 2026-08-10 by the multi-session resolution: **target-domain** = the artifact family a plugin defines; **target-document** = the durable unit sessions attach to; bare "target" legal where context disambiguates), **issue** (typed backpressure to the elicitation controller; two producers since the capture-sweep resolution — plugin ops at the payload level, the harness itself at the envelope level).
+- **Built artifacts as proofs** (ratified 2026-08-06, from the Questioning-UX grilling): prototypes, walking skeletons, and logic-prototypes are the proof path — grilling tickets resolve decisions _provisionally_ and name the proof obligations they delegate to prototype tickets, rather than pinning everything through precedent + conversation alone.
+- Primary references: [docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md](../../../reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md) (turn 1: four contracts, packs, IR) and [docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md](../../../reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md) (turn 2: hourglass, proof obligations, invariants, smells, test matrix)
+- Reference codebase (read-only): `../brunch` — esp. `src/agents/runtime/elicitor/`, `src/exchanges/`, `src/agents/skills/`
+- External: [Flue docs](https://flueframework.com/docs/guide/why-flue/), [zil-lean](https://github.com/jagg-ix/zil-lean)
+
+### Charter decisions (pre-map grilling, 2026-08-06)
+
+- Destination artifact = a spec (not a decision-set alone, not a build)
+- Elicitor-first: the elicitor is this map's spine
+- Greenfield reimplementation; brunch is reference architecture, not shared code
+- Fully decoupled from brunch's September MVP
+- Pi-family substrate committed; harness-agnostic core is a named non-goal
+- Brunch's exchange vocabulary is prior art to critique, not an incumbent to preserve
+- Persistence plugin-owned (in accord with deploy target) is a hypothesis to test, not a decision — **resolved 2026-08-10, flipped** by [Multi-session elicitation & durable target state](issues/12-multi-session-durable-target.md): storage port harness-defined, binding-implemented, plugin-blind
+- Two live dev targets from day one (forces generalization on both pack axes); BPMN/process-mining named third
+- "brunch-lite" is a temporary label; real name is fog
+- **Principle v2** (ratified 2026-08-06, replaces "behavioral over procedural" after an evidence pass over `~/Clones/mattpocock/skills` and `../brunch/docs/design/BEHAVIORAL_KERNELS.md`): _procedure for mechanism, anchors for judgment, shapes for output_. Short step sequences with checkable completion criteria where order matters; leading words wherever judgment is required; annotated shapes for everything produced; reference disclosed progressively. Design against sprawl, negation-steering, no-ops, judgment-as-procedure — not against procedure itself. `writing-for-agents` is the pack-authoring standard; kernel cards (BEHAVIORAL_KERNELS.md) are the unit of elicitation guidance.
+
+## Decisions so far
+
+<!-- one line per closed ticket: gist + link -->
+
+- [Assemble the spec](issues/08-assemble-the-spec.md) — **the destination: [spec.md](../../../spec.md) assembled** (fourteen sections + adjudications appendix) from the full working set in amendment order; all seven pre-pass contradictions adjudicated (storage port binding-implemented with the `db.ts` reconciliation; ops stay pure; status derived never stored, retraction specified; tap-ness as a transport fact via a reserved reply encoding; invariant 1 reconciled with the provenance rule; per-message current-affordance surface with identity on tool output parts; no instruction interpolation + harness-mechanical reply binding, no echo token); ten harness invariants restated in envelope vocabulary; `CONTEXT.md` gained the envelope vocabulary and the kernel-compound ruling (kernel card kept, "kernel invariants" → harness invariants); rename propagated over tickets 02/07. **The frontier is empty — this map is complete.** Remaining fog is post-spec and graduates with the build effort.
+- [Walking skeleton: sweep seam on Flue](issues/13-walking-skeleton-sweep-seam.md) — **all four capabilities hold on Flue** (two native, two binding-absorbed, none forbidden), closing pre-pass L1–L3: settlement trigger = `useAgentFinish` would-stop seam with same-response signal steering (fires on `terminate:true` suspensions too — the pending guard is load-bearing; needs a re-nudge loop guard); session-entry read = binding-absorbed via the public durable-history projection (no in-process API; `purpose` discriminates provenance) with the load-bearing HITL amendment that **evidence anchoring is harness-resolved — the model cites verbatim user quotes, never entry numbers** (sharpens issue 12's span shape: excerpt primary, pointer derived); on-behalf injection = `kind:'signal'` append/dispatch, projecting structurally non-user so the citable-evidence rule is mechanically enforced (live: unscripted conversational conflict-surfacing off the re-entry briefing; a fact recovered from a _superseded_ capture, honestly marked inferred); transactional store = binding-owned entirely (content-keyed idempotence is load-bearing under Flue's at-least-once re-execution). **Amends Shipping shape's capability list to ten entries** (adds would-stop seam, entry-projection read, signal injection, transactional store). New payload-stratum spec examples: absence smuggled as payload; compound payloads make supersession lossy. Prototype on branch `prototype/13-sweep-seam`.
+- [Multi-session elicitation & durable target state](issues/12-multi-session-durable-target.md) — **durable target-document, transient sessions, sweep as the only bridge**: "target" splits into **target-domain** (family a plugin defines) / **target-document** (durable unit sessions attach to — capture store **plus all session logs** as truth, renders strictly derived); session = one substrate conversation (per-session state: log + swept high-water mark + pending-affordance slot), never formally closes; **interleaved-only** concurrency — serialized store, whole-sweep-atomic refusals, the single-hop refusal doubling as the stale-session guard (true concurrency + per-item application → fog); re-entry briefing = injected on-behalf-of-user state messages (Pi convention), advisory-only, with the sharpened provenance rule that **only true user entries are citable evidence**; completion = derived status, never a write gate; **persistence hypothesis flipped** — storage port harness-defined, binding-implemented, plugin-blind (plugin-addressable only via PluginContext-passed methods); evidence spans = pointer + quoted excerpt.
+- [Shipping shape: kernel library vs. Flue agent](issues/06-shipping-shape.md) — **harness library in a thin host-authored agent, ratified with the second-binding test**: the spec enumerates a six-item substrate-capability list as the core/binding seam (portability = pressure test, not build target; **binding** entered the glossary); topology = Bun-workspace monorepo in this repo — `packages/core` (plugin SDK is its export surface; `core/testing` subpath), `packages/flue` (binding), `packages/plugin-gherkin` + `packages/plugin-assurance` (renamed from `plugin-proof-obligations` 2026-08-10, per the Formal-verification canon survey's category-error verdict; plugins depend on core _only_ — stated spec invariant), `apps/dev`; Valibot throughout; tool prefix from product name (provisionally `bl_*`, never `elicit_*` — strings name identity, not function); workspace-internal, no publishing; testing = **generation-first fixtures over a deterministic replay driver** (kernel invariants as properties, `arbitraryFromSchema`, `fc.commands` conversation fuzzing from the envelope vocabulary, model as offline generator never CI oracle, regenerate-on-declaration-change); dev app chartered with three roles (dev loop / target-gallery demo / diagnostic probe views); one agent per target; milestone one local-only with remote-parity constraints pinned in spec; CI smoke = build + simulation suite.
+- [Walking skeleton: Flue question round-trip](issues/10-walking-skeleton-flue-roundtrip.md) — **transport proven, one amendment**: the one-channel multiplex works end-to-end (three forms, markdown floor, string-only replies, absence strip, redirect), but the fixed data channel is a _one-live-affordance slot per message_ (update-in-place at every layer — stream, history, reply read-back), so per-ask identity/payload must ride the ask tool's **output part** and the kernel must **reject a second ask per batch** as mechanism; echo token not needed (adjacency + persistent pending state bound every bare-string reply); turn suspension (`terminate: true` + persistent state + fresh dispatch) sufficient, with a wake wart — instruction-interpolated pending state triggers an extra "instructions updated" model turn per ask; cancelled/redirected questions read back cleanly via `record_interpretation` evidence. Flue facts: `@flue/vite` needs vite ^8; dev server gives `app.ts` the whole request space (ui is app-served). Prototype on branch `prototype/10-flue-roundtrip`.
+- [Logic-prototype: capture sweep & settlement](issues/11-logic-prototype-capture-sweep.md) — **all five capture hypotheses hold** in a working prototype (branch `prototype/11-capture-sweep`; double-clickable demo + headless driver), each sharpened: settlement splits into **trigger vs judgment** (lifecycle-event wiring _not_ proven in ticket 10 — misattribution caught by the 2026-08-10 consistency pre-pass; delegated to the sweep-seam walking skeleton, ticket 13); idempotence splits into **mechanical (harness, evidence-anchored capture identity) vs semantic (plugin reconcile)** and is content-based, so re-sweeps repair omissions; absences are **evidence, not agenda** (re-ask runs through plugin validate → issues); single-hop supersession over active heads = the lost-update guard; **two supersession channels** (sweep-time link / issue-time resolution record) with read-time _derived_ status suggested (cf. issue 09). Amendments: **two validation strata** (envelope-level harness-owned refusals + advisories / payload-level plugin ops — strengthens smallest-honest-plugin), op cadence = pure orchestration policy (snapshot-purity), **resume-time sweep reconciliation** (unswept tail as computed re-entry fact). Graduated the multi-session fog → ticket 12.
+- [Questioning-UX contract](issues/05-questioning-ux-contract.md) — the reframe: **no exchange-pair ontology** — conversation is primary, structured questions are **affordance emissions** committed to session as evidence, capture via idempotent **range-sweeps** on agent-judged, range-level **settlement**; shells renamed **substrate / ui / harness / plugin** (the effort's essence is _harness-engineering_; IoC via narrow injected PluginContext — the ask API is part of it); harness fixes: three baseline shapes + questionnaire chaining, absence interpret-by-default/afford-when-structured, **one multiplexed data channel** with markdown floor (Flue: outbound rich / inbound string-only), interpretation render harness-owned with plugin-optional typed renderer (JSON default), conflicts close only via explicit **resolution records**, no question-budget machinery (economical interviewing = judgment guidance); all shape-level commitments are working hypotheses with proof obligations delegated to the two prototype tickets created here (10, 11); **built-artifacts-as-proofs** ratified into Notes.
+
+- [Contract decomposition](issues/04-contract-decomposition.md) — the load-bearing resolution: **agent-forward hybrid** (agent judgment owns the loop; deterministic mechanism as tools; typed-issue backpressure); **no universal IR** — the kernel owns only a domain-free **capture envelope** (evidence spans, epistemic-status enum, absence states, alternatives, one `supersedes` link) around opaque plugin payloads, no kernel edges or graph (conflicts/equivalence are typed issues, resolved only explicitly); operations tiered `project`+`validate` required / `reconcile` optional / `observe` agent-native, all snapshot-in/deltas-out with typed loss reports; **facts computed, weights judged** dialogue policy (no scoring engine); packs = kernel cards + shapes + validators + shallow schemas + completion contract; smallest-honest-plugin test; five proof obligations + ten kernel invariants + gating tests (reprojection, minimal pairs, black-box authoring) adopted as spec acceptance material; multi-plugin composition, removal, replay, capability negotiation, versioning deferred to fog. Full ownership table in the ticket.
+
+- [Flue architecture deep-read](issues/01-flue-architecture-deep-read.md) — embedding is Flue's grain: ship the kernel as a custom hook (`useElicitation(plugin)` — final name per Shipping shape) + exportable `defineTool`s over a thin host-authored `'use agent'` module; Pi is exposed only at the provider layer (no path to Pi's loop/extensions — brunch-style Pi assumptions don't transfer); durability contract identical local/remote but storage/ownership differ; **no first-class ask-the-user primitive — the kernel must own its turn-suspension protocol** (`terminate: true` tool + persistent state + data part, answer arrives as fresh dispatch); constraints: Valibot at every schema boundary, stable-tool-set cache economics, subagents conversationally sterile, non-React hosts must build on `@flue/sdk`.
+- [Formal-verification canon survey](issues/09-formal-verification-canon-survey.md) — align the second target to a **GSN skeleton** (Goal/Strategy/Solution/Assumption/Justification; the one canon built for argued claims about a system) with **Dafny nouns** (`requires`/`ensures`/`invariant`/`lemma`/`assume` transfer; `modifies`/ghost don't) and **Lean sorry-taint semantics**; the headline artifact is a `dafny audit`-style **assumption ledger** (per-claim status becomes a derived label); acyclicity kept as a deliberate restriction with `decreases` as future escape hatch; sell the Datalog closure as taint-propagation, never as an assurance verdict; **"proof obligations" is a category error to verification readers — rename the target** (resolved 2026-08-10: the second target is the **assurance argument**, package `plugin-assurance`); Geolog is _not_ an ARIA artifact (negative result) but coherent-logic saturation is the validator's genuinely canonical lineage; concrete milestone-one contract sketch (one `Statement` record, four edge kinds, five-stratum status rules) is in the ticket.
+- [Dev-target portfolio confirmation](issues/07-dev-target-portfolio.md) — confirmed `elicit-gherkin` + `elicit-proof-obligations` live (BPMN third, full elicit-lean deferred); **hybrid order**: both packs authored before the pack interface freezes, gherkin wires end-to-end first; proof-obligations format = zil-lean's ideas in our own claim-DAG serialization, hewing to existing canon (Dafny leading candidate — grounded by new ticket 09); gherkin milestone-one validation = parse validity + pack-declared step lexicon; surfaced the **behavioral-over-procedural** design principle (routed to Contract decomposition).
+- [Brunch exchange-schema audit](issues/03-brunch-exchange-schema-audit.md) — full catalog + three-way classification: **generic** (the `ask` one-terminal-four-shapes primitive, declared continuations that make offer→answer non-forgeable, answered/cancelled/unavailable property-presence union, self-contained terminals, boundary-teaching schemas, no-storage asking agenda + private scratchpad, hash-pinned prompt directives); **generalize-with-changes** (present-then-ask two-step → one `present(form, payload)` with pluggable validators, parent-link instead of enumerated prev/curr/next unions, opaque target-supplied receipts, rubrics declared by the target); **brunch-specific** (review-set node/edge schema, plane vocabulary, `graph_refs`, `map`/`tutorial` skills). Strain marks confirm the "just a guess" caution: wire vocabulary outlived tool names, a digest-into-review merge was retracted, doc/code drift on edge categories. 15 inherit/avoid lessons feed tickets 04 and 05.
+- [zil-lean survey](issues/02-zil-lean-survey.md) — zil-lean contains **no elicitation** (agent-authored 2-day snapshot; Datalog/Zanzibar-style claim graph in Lean 4 + Clojure) but is a strong existence proof of the kernel's claim-graph layer: evidence-graded assurance lattice with prohibited promotions, full derivation provenance, assumption/lemma/theorem/guarantee vocabulary with derived PROVED/CONDITIONAL/WEAK/BROKEN statuses. **Verdict: full elicit-lean is not dev-sized; the "elicit-proof-obligations" slice is** (claim DAG + criticality + evidence refs, validated by acyclicity + Datalog closure — no Lean statements) and beats BPMN as second target on both pack axes; BPMN stays third.
+
+## Not yet specified
+
+- Diagnostic "exploded view" harness for HITL prototype sessions — an instrumented walking-skeleton UI with parallel state readout and labeled moving parts (persistent state, pending affordance slot, tool traffic, terminate boundaries, advisory wakes, activation timing) so the human can react to internals, not just the chat surface; surfaced by the user after the ticket-10 walking skeleton, wanted "at some point" — **host identified** by the Shipping-shape resolution: the dev app's probe view (role 3 of its charter); graduates with the dev app, post-spec
+- Remote deploy target choice & provisioning — pending an infra-colleagues conversation (2026-08-07); blocks nothing on this map (the spec pins remote-parity constraints without naming the target)
+- Unstructured-ingest crossover at scale — the IR inside the contract-decomposition ticket absorbs the parsing/mapping core; what remains foggy is bulk/brownfield ingest as a first-class mode
+- elicit-to-petri-net as a future plugin — abstract questions (what fits a net; what IR precedes a net) wait until the pack model exists
+- JSONL-vs-YAML storage-format comparison — persistence resolved harness-defined / binding-implemented (multi-session resolution, 2026-08-10), so the format is a binding-internal choice; graduates with the local binding implementation, post-spec
+- Concurrent-session coordination beyond interleaving — simultaneous sweeps against one target-document, per-item partial sweep application, merge machinery; the spec's stance (serialized store + single-hop refusal + re-entry advisory) covers interleaving, and this graduates only if a real concurrent consumer appears
+- The real product name
+- Deferred plugin-ecosystem machinery (from Contract decomposition): simultaneous multi-plugin composition, plugin removal, full replay, capability negotiation, version/migration (spec names the five version axes only)
+
+## Out of scope
+
+- **Executor-standalone** — a different kind of project; the spec only names the elicitor→executor handoff seam
+- **Harness-agnostic core** — every named consumer is Pi-family; revisit only if a non-Pi consumer materializes (would be a fresh effort under a redrawn destination)
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/notes/consistency-prepass-2026-08-10.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/notes/consistency-prepass-2026-08-10.md
new file mode 100644
index 00000000000..6893e8d4530
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/notes/consistency-prepass-2026-08-10.md
@@ -0,0 +1,181 @@
+# Cross-ticket consistency pre-pass — Elicitation Kernel map
+
+> Prep asset for [Assemble the spec](../issues/08-assemble-the-spec.md). Produced 2026-08-10 by a full read of `map.md`, `CONTEXT.md`, tickets 01–12, and §9 of the criteria inbox doc, at commit `0dc71e2` (plus the second-target rename decision, folded in). The assembler should treat this as the working checklist alongside the map.
+
+**Rename incorporated:** the second target is the **assurance argument**, package `plugin-assurance`. That closes what would otherwise have been the sharpest contradiction in the set (_Formal-verification canon survey_ (09) §5.4 called "proof obligations" a category error, and _Shipping shape_ (06) then froze the flagged name into the topology a day later). Two follow-through notes for the assembler, not flagged as inconsistencies: _zil-lean survey_ (02) and _Dev-target portfolio confirmation_ (07) still say `elicit-proof-obligations` in body text, and 09's own three rename candidates ("obligation ledger / claim structure / assurance argument") should now read as a settled choice.
+
+---
+
+## 1. CONTRADICTIONS — the assembler must pick a side
+
+**C1. Who implements the storage port: the host app, the binding, or the substrate?**
+
+- _Shipping shape: kernel library vs. Flue agent_ (06), §Root and §Package topology: "every host authors its own thin `'use agent'` module, `app.ts` mount, and **storage adapter**"; "The dev app owns the `'use agent'` module, `app.ts`, `db.ts`, and the Vite build"; remote-parity constraint "**host-owned storage port**".
+- _Multi-session elicitation & durable target state_ (12), §The storage flip: "The **storage port is harness-defined and binding-implemented**."
+- Ticket 12's comment on 06 claims this "aligns with (and sharpens)" the host-owned constraint. It does not — it moves the implementation from the host application into `packages/flue`. **12 is later and authoritative on ownership**, but the spec must state the reconciliation explicitly, and the cleanest one available is: Flue's `db.ts` (substrate _conversation_ storage) stays host-authored because Flue requires it, while the harness's _capture store_ is the storage port, implemented in the binding. No ticket says this. Note also that 04's ownership table still assigns "storage port implementation" to the Host row — pre-split and pre-flip.
+
+**C2. Are plugin operations pure over a snapshot, or can plugin code reach storage?**
+
+- 04, §Operations: "plugin ops receive an **immutable state snapshot**, return observations/issues/deltas; the kernel validates and applies." _Logic-prototype: capture sweep & settlement_ (11) leans on exactly this to justify "op cadence is orchestration policy, not correctness — snapshot-in/deltas-out purity means the harness may run them at any time without changing outcomes."
+- 12, §The storage flip: "if storage is addressable from plugin code at all, it is only through **harness-defined methods passed via the injected PluginContext**."
+- If `project`/`validate`/`reconcile` can call storage methods, snapshot purity is gone and 11's cadence-as-policy result collapses. **Authoritative read: 04 + 11 win for the four operations** — they must stay pure — and 12's clause must be scoped to _non-op_ plugin code, or dropped. The spec has to say which, because "op cadence is free" is load-bearing for the harness's orchestration latitude.
+
+**C3. Capture `status` — stored field or derived at read time?**
+
+- 04, §The capture envelope: the envelope carries "status: `active | superseded | retracted`" as a field.
+- 11, §5: "the winning capture keeps its original epistemic status while authority sits in the record, suggesting per-capture status be **derived at read time**." 12, §6 then treats "derived capture status" as settled fact.
+- **12 is authoritative**: status is not a stored field. This is the load-bearing half of the derived-status chain and it changes the envelope schema in 04 that everything else quotes. Related unrecorded item: no ticket says how a capture becomes `retracted` — supersession and resolution records are specified, retraction is not.
+
+**C4. Explicit-versus-inferred absence is unachievable over the proven transport.**
+
+- 11, §3: "a dodge reads back as `declined (inferred)`, a strip tap as `deferred (explicit)`."
+- _Walking skeleton: Flue question round-trip_ (10), §3: every reply arrived as a bare string — "typed text, choice-button labels, **absence taps**, a mid-stream redirect" — and _Questioning-UX contract_ (05) fixes inbound as string-only with "answer typing/validation happens entirely harness-side on read-back."
+- A bare string cannot distinguish a one-tap `not-applicable` from a user typing "doesn't apply", so the harness cannot honestly assign `explicit` to a tap. Neither ticket noticed. The spec must either give the ui a canonical reply encoding for affordance taps (making tap-ness a transport fact) or accept that all absences are `inferred`. **10's transport finding is the physical constraint and wins**; 11's `deferred (explicit)` currently lacks a mechanism.
+
+**C5. "Only true user entries are citable evidence" versus kernel invariant 1.**
+
+- 12, §5: "Capture evidence spans anchor only on true user (and user-affordance-payload) entries."
+- The ten kernel invariants that 04 adopts verbatim as spec acceptance material state (criteria doc §9, invariant 1): "Every projected value must point to a claim, a **declared default**, or a **documented transformation**." And 04's own epistemic-status enum includes `defaulted` and `external-lookup` — captures with no user utterance behind them.
+- **Genuinely inconsistent as written.** 12 is later, but invariant 1 is the more carefully drafted rule: the reconciliation is that user-derived captures cite user entries only, while `defaulted` / `external-lookup` captures cite a declared default or a documented transformation instead. The spec must say that, or drop `defaulted`/`external-lookup` from the enum.
+
+**C6. One channel multiplexing all affordance forms versus one live affordance slot.**
+
+- 05, §3: "**One harness data channel** multiplexing all affordance forms"; §4 makes the interpretation render one of those forms.
+- 10, verdict 1: writes to one channel name "materialize _last-write-wins per assistant message_", so the channel is a "current affordance" surface and per-ask identity and payload must ride the ask tool's `output` part. The invariant 10 derives covers only "**reject a second ask** in the same batch."
+- An ask plus an interpretation render in one batch still clobber each other, and nothing forbids it. **10 is authoritative on the mechanism**; the spec must say where non-ask affordances (interpretation render, choice strip) ride, and whether the one-live-affordance rule is per-message or per-affordance-kind.
+
+**C7. The wake wart's fix removes the reason no echo token is needed.** Both statements sit inside ticket 10.
+
+- Verdict 3: "the agent bound every one to the correct `exchangeId` **because the pending question (with its id) is interpolated into the instructions** from `usePersistentState`" — that is the entire basis for "echo token: NOT NEEDED."
+- Verdict 4 offers as a spec option: "**don't interpolate the pending question into instructions** (keep it in state only, or narrate it inside the ask tool's result)."
+- Taking that option costs the binding mechanism that made the echo token unnecessary. The spec must pick the wake-wart remedy and the reply-binding mechanism **together**: interpolate and eat one wasted model call per ask, or stop interpolating and reinstate an explicit binding (narrate the pending id in the ask tool result, or restore the echo token).
+
+---
+
+## 2. STALE STATEMENTS — superseded, and misleading if read alone
+
+**S1. The classification table in _Brunch exchange-schema audit_ (03) §2 has four rows that 05 overturned.** The table looks authoritative and was never edited. 05's "Audit lessons demoted by the reframe" and "Brunch disposition" sections demote: _declared continuations / non-forgeability_ (03 calls it "the single most transferable idea") to a covered-by-`epistemic_status: inferred` non-issue; _recovery scan / pending-present resumption_ (03: "Any interviewer needs this") to nothing, since there is no pending-exchange concept; _self-contained terminals_ to "patterns at most"; and the _`exchange_id` + `tool_meta` chain_ generalization, since the exchange-pair ontology stays behind entirely. Anyone mining 03's table for the spec will re-import all four.
+
+**S2. Ticket 10's own vocabulary violates `CONTEXT.md`.** The proven mechanism names the channel `data-exchange` and the affordance identity `exchangeId`; `CONTEXT.md`'s **Affordance** entry lists "_Avoid_: exchange, exchange pair, terminal". Those names need renaming as the prototype is lifted, and the spec needs a term for affordance identity that isn't `exchangeId`.
+
+**S3. Ticket 10 line 39 invokes the flipped hypothesis.** "Restart durability untested by design… consistent with the **deploy-target-owns-persistence hypothesis**." The map and 06 carry 12's flip; 10 does not.
+
+**S4. `epistemicStatus: stated` (10, verdicts 3 and 4) is not a legal value.** 04's enum is `explicit | inferred | tentative | defaulted | external-lookup`. 11 uses the legal values. Ticket 10's prototype vocabulary drifted; the spec must pin one enum.
+
+**S5. Ticket 04's "Host" row now splits three ways, not two.** The 2026-08-07 comment on 04 maps "Host" onto substrate + ui, but predates _Binding_ (introduced by 06) and the storage flip (12). Under the current model: input surfaces and identity → **ui**; deploy target, model/provider, artifact delivery → **substrate**; storage port implementation → **binding**.
+
+**S6. Ticket 04's Plugin row "artifact persistence _shape_"** reads as plugin involvement in persistence, which 12 makes plugin-blind. The surviving legitimate meaning is "the plugin declares its payload/output shape" — say that instead.
+
+**S7. Ticket 04 lists "the private scratchpad" as kernel-owned.** 05 demotes it to "pattern guidance for the spec", and 12 fixes per-session state as "**exactly three things**: the evidence log, the swept high-water mark, the pending-affordance slot" — no scratchpad. **12 is authoritative**, so the scratchpad is not harness session state; the spec should either drop it or say where it lives (Flue's `harness.prompt` private scratch conversation, per _Flue architecture deep-read_ (01), is the natural home and is a different thing from brunch's scratchpad).
+
+**S8. The PROVED/CONDITIONAL/WEAK/BROKEN ladder is demoted from headline to derived label.** 02 §3 makes it the completion-criteria ladder and 07 adopts it as load-bearing vocabulary; 09 §5.1 rules that "the four-rung ladder is not canon; the audit list is… make the per-claim status a derived UI label, and make the **assumption ledger** the headline artifact," shipped as a Markdown table. 09 is the grounding ticket and wins.
+
+**S9. Ticket 07's "Geolog (ARIA program, axioms addressed via Datalog-like queries) is plausibly adjacent" is refuted.** 09 §4 is an explicit negative result: no ARIA artifact named Geolog exists; Geolog is a coherent-logic language, and _that_ lineage (Datalog as the ∃-free, ⋁-free fragment of coherent-logic saturation) is the citable one. "Do not build on a claim that ARIA ships something called Geolog."
+
+**S10. Ticket 02's ElicitationPack sketch is superseded by 09's contract sketch.** 02 proposes five kinds (`assumption`/`invariant`/`proposition-theorem`/`guarantee`/`constraint`) with per-item `source_span` and `paraphrase_confirmed: bool`; 09 replaces this with one `Statement` record + a ten-value `kind` discriminant + four edge kinds + five status strata. Two further reasons 02's version is stale: `source_span` duplicates the harness's evidence spans inside the plugin payload (the "hidden target leakage" smell 04 adopted as review vocabulary), and `paraphrase_confirmed` is a per-item confirmation gate — exactly the machinery 05 retired and the write-gating 12 forbids.
+
+**S11. Ticket 06's title still says "kernel library"** while its body ratifies "**harness library**". Minor, but the title is what a skim reads.
+
+**S12. `useElicitationKernel(plugin)`** (01 §5 recommendation, echoed in the map's 01 line) versus **`useElicitation(plugin)`** (06 §Root). 06 is later; fixed in the map 2026-08-10.
+
+**S13. The map's lexicon line for _issue_** — "typed backpressure from projection/validation to the elicitation controller" — predates 11's two-validation-strata amendment, which gives the harness its own issue and advisory production (same-evidence duplicate actives, generic `possibly-equivalent`). Issues now have two producers. Fixed in the map 2026-08-10.
+
+**S14. The ten kernel invariants are written in the criteria doc's vocabulary, not ours.** They say "claim" (we say **capture**), "core" (we say **harness**), and invariant 6 says "**target** issues are namespaced" (pre-split — should read target-domain / plugin-namespaced). The spec must restate them in current envelope vocabulary rather than quote them, or two vocabularies will coexist inside the acceptance criteria.
+
+---
+
+## 3. LOOSE ENDS
+
+### 3a. Referenced as settled, never actually recorded
+
+**L1. Settlement-trigger wiring is claimed as proven by a ticket that never mentions it.** Ticket 11 §1 says settlement decomposes into trigger and judgment, with "wiring proof **delegated to ticket 10**", and the map's ticket-11 line upgrades this to "lifecycle-event wiring **proven in ticket 10**". _Ticket 10 contains no settlement, lifecycle-event, or `useAgentFinish`/`useResponseFinish` finding at all._ The substrate lifecycle event that triggers the agent's settlement judgment is unproven and unspecified. This is the most consequential gap found.
+
+**L2. Nothing establishes that the harness can read the substrate's session log — which is what a sweep is.** 11 defines a sweep as "an idempotent pass over a settled range of **session entries**", and 12 makes session logs durable truth. But 01 §3 records that there is "no documented path to Pi's agent loop, **message list**, or extension/package system from inside a Flue agent," and 01's primitive inventory contains no read-the-transcript capability. 10 proved read-back of durable history **on the ui side** via `useFlueAgent`; 11 ran against a **synthetic** log with no substrate at all. So the seam where the harness reads the entry range it sweeps is proven nowhere — and it is the hinge between the two prototypes.
+
+**L3. 06's six-item substrate-capability list is incomplete after 10, 11 and 12.** The enumerated list is: register a tool · contribute instructions · persist state · emit an affordance payload · suspend-for-reply · private model call. Missing, each demanded by a later resolution: **read a session entry range** (L2); **inject an on-behalf-of-user state entry** (12's re-entry briefing — Flue's `kind: 'signal'` message with trusted-code `attributes`, per 01 §6, looks like the intended carrier and would also give the true-user-versus-injected distinction for free); **subscribe to a settlement-trigger lifecycle event** (L1); and a **transactional durable store** distinct from per-conversation state (12 requires whole-sweep-atomic application across sessions, which `usePersistentState` — conversation-scoped, per 01 — cannot provide). Since the capability list is the spec's portability seam and its early-smell detector, its completeness matters more than most items here.
+
+**L4. How a session binds to a target-document is unstated.** 12 makes sessions attach to a durable target-document; 06 fixes one Flue agent per plugin with many conversations; 01 says `initialData` is validated once at creation, immutable after, and "is where an elicitation _target descriptor_ belongs". Nobody wrote down that a new session's `initialData` carries the target-document id, nor what happens when a caller dispatches to an existing conversation id versus a new one.
+
+**L5. Where plugin-level derived labels are computed.** 09's five-stratum status rules are read-time derivations over the plugin's own graph, but 04's operation set has no derive-status op — the nearest is `project`. 11's derived capture status and 12's derived completion are harness-computed. The spec needs one sentence placing 09's derivation (inside `project`, or a new read-time op) and confirming the harness may invoke it at read time under 11's cadence-as-policy rule.
+
+**L6. Advisory versus issue is two vocabularies for one thing.** 11 introduces the unaccounted-ask advisory and the resume-time unswept-tail advisory; 12 adds the world-moved advisory and a refusal that "carries the world-moved facts". 12's durable store holds "captures, issues, events" — advisories appear nowhere. Are advisories a non-blocking issue severity, a computed-not-stored fact, or a third kind?
+
+**L7. Issue namespacing after two-strata validation.** 04's invariant 6 requires target issues be namespaced; 11 gives the harness its own issue production. The harness-versus-plugin issue namespace split is unwritten.
+
+**L8. Two notions of capture identity coexist.** 04 gives the kernel "capture-id minting"; 11 makes the dedup key "evidence spans + payload/absence", content-based. Both can hold (a minted id plus a content-derived dedup key), but the spec should say so, since 11 explicitly excludes epistemic status from the key and that exclusion is load-bearing.
+
+**L9. Ask-outcome vocabulary is unpinned.** 03 catalogs brunch's `answered | cancelled | unavailable` property-presence union; 10 observed `outcome: redirected`; 05 retires the terminal union while keeping the transport-versus-epistemic distinction. What the outcome vocabulary is — and whether `unavailable` survives given 05's universal markdown floor — is open.
+
+**L10. Absence-state enum has near-duplicates and unmapped ui labels.** 04 lists seven states including both `not-yet-decided` and `deferred`; 05's strip offers three labels ("don't-know / not-applicable / decide-later"). The label→state mapping and the `not-yet-decided` / `deferred` distinction are unresolved.
+
+**L11. `CONTEXT.md` is missing two terms the map's own lexicon carries: _pack_ and _issue_.** More broadly, the glossary covers shells, sessions and interaction but not the envelope vocabulary the spec is mostly about — no entry for capture envelope, evidence span, epistemic status, absence state, resolution record, supersession, kernel card, PluginContext, or storage port. Chain (e) otherwise checks out: `CONTEXT.md` agrees with 05 and 12 on substrate/ui/harness/plugin/binding and on the target-domain / target-document split. But the glossary is roughly half the vocabulary the spec needs.
+
+**L12. "kernel" survives in three compounds the glossary forbids without exempting.** `CONTEXT.md`'s **Harness** entry says "_Avoid_: kernel", yet **kernel card** (granted survival by the map's lexicon, absent from `CONTEXT.md`), **kernel invariants** (04, 06, 10, 11), and stray shell-sense uses ("the kernel must reject a second ask", 10) all persist. The spec should decide: keep both compounds as terms of art and add them to the glossary, or rename to guidance card / harness invariants.
+
+**L13. Milestone-one local storage must satisfy 12's atomicity, which constrains the "binding-internal" format choice.** The map defers JSONL-versus-YAML as "a binding-internal choice", but 12 requires a serialized store with whole-sweep-atomic application and refusals, which a flat append-only text file does not give. The spec should state the transactional requirement as a constraint on the format decision rather than leaving the format wholly free.
+
+**L14. Plugin-declared form payloads versus frozen tool schemas.** 01 records that `defineTool` schemas are Valibot and "frozen at module load", so the harness's ask tool cannot carry a plugin-parameterised output schema per render. 10 confirmed `body: v.any()` works as the opaque payload slot. The spec should state that plugin form payloads are opaque at the tool boundary and validated harness-side against plugin declarations — closing the loop with 05's "answer typing/validation happens entirely harness-side on read-back".
+
+**L15. Unretired proof obligations.** The interpretation-render plugin-renderer seam (05 §4: "exercised once real packs exist", ticket 07's portfolio) and restart durability (10: "untested by design") are both open and neither has a home ticket.
+
+**L16. Minor:** ticket 05's frontmatter says `Resolved: 2026-08-07` while its Answer says "Resolved by HITL grilling, 2026-08-06". Affects only the reading order, where 05-before-10/11 is fixed by delegation anyway.
+
+### 3b. Collected "the spec must…" obligations — one checklist
+
+**Acceptance material**
+
+1. Five proof obligations (independent variability, semantic conservation, explicit transformation, controlled elicitation, local implementation) as contract acceptance criteria — _04_.
+2. Ten kernel invariants as harness-enforced test properties, restated in capture/harness vocabulary — _04_, criteria doc §9; see S14.
+3. Gating tests: reprojection / projector substitution, minimal pairs, black-box authoring — _04_.
+4. Named structural and semantic smells as review vocabulary — _04_.
+5. Smallest-honest-plugin test, and **second-binding test** as its sibling — _04_, _06_.
+6. Testing strategy: generation-first fixtures over a deterministic replay driver; kernel invariants as properties; `arbitraryFromSchema`; `fc.commands` over the envelope-derived command alphabet; model as offline generator, never CI oracle; regenerate on declaration change; shrunk counterexamples pinned as regressions and read as type-design feedback — _06_.
+7. CI smoke = `vite build` + the simulation suite; optional secret-gated real-model `flue run` — _06_.
+
+**Architecture and boundaries** 8. Enumerate the substrate-facing capability list as the core/binding seam — _06_; **it needs four more entries, see L3**. 9. State as a spec invariant: plugins depend on `core` only, never on the binding, never on Flue — _06_. 10. Record the Bun-workspace package layout as intended structure; nothing scaffolded during this map — _06_. 11. Name the deferred UI affordance package as intended (React renderers over `@flue/react`; non-React hosts on `@flue/sdk`) — _06_. 12. Describe the publishable shape; publishing waits on the real name — _06_. 13. Name the envisioned per-substrate binding packages as a payoff, not a commitment — _06_. 14. Charter the dev app with three roles, spec'd as roles not features (dev loop / target-gallery demo / diagnostic probe views) — _06_. 15. Pin remote-parity constraints: one-agent-many-conversations, pinned `agentName`, storage port owned outside the plugin, no dynamic agent creation — _06_, amended by _12_ per C1. 16. Name the five version axes (API contract / plugin impl / concept-schema / target-schema / persisted state); implement none — _04_. 17. Name the non-goals (substrate-agnostic core, executor-standalone) and the elicitor→executor seam — _map_, _08_. 18. Tool prefix derived from the product name, provisionally `bl_*`, never `elicit_*`; core names ops abstractly, the binding renders substrate tool names; all model-facing tools harness-owned — _06_.
+
+**Mechanism** 19. Pin content-based, evidence-anchored capture identity, with epistemic status excluded from the key — _11_. 20. Name **both** supersession channels: the creation-time link (sweep-time correction) and the resolution record (issue-time adjudication) — _11_. 21. State op cadence as explicit harness policy, sweep-completion as the default trigger — _11_. 22. Spec the unaccounted-ask advisory and resume-time sweep reconciliation — _11_. 23. Spec the two validation strata: envelope-level harness-owned refusals plus advisories, versus payload-level plugin ops — _11_. 24. Make the ask tool **reject a second ask per batch** as mechanism, not instruction; per-ask identity and payload ride the tool's output part — _10_. 25. Resolve the wake wart, and jointly the reply-binding mechanism — _10_, see C7. 26. Require the ui to filter on `purpose` / `display` — _10_. 27. Record the Flue transport facts: outbound rich, inbound string-only, unknown part types silently dropped, hence the universal markdown floor — _05_, _10_. 28. Record that `@flue/vite` requires vite ^8 with the directive as the file's first statement, and that the dev controller owns the whole request space so the ui is a separate or app-served app — _10_. 29. State plainly that a target-document's authoritative state is the capture store plus session logs, never the render — _12_. 30. Evidence spans carry pointer **plus** quoted excerpt — _12_. 31. The data model distinguishes true user entries from on-behalf-of-user injected entries — _12_. 32. Completion is a derived read-time status, never a write gate; no lock, no terminal state — _12_. 33. A minimal user-visible insertion notice accompanies injected state messages — _12_.
+
+**Targets** 34. Both packs authored before the pack interface freezes; gherkin wires end-to-end first — _07_. 35. Gherkin milestone-one validation = parse validity + pack-declared step lexicon — _07_. 36. Use the decided name — the **assurance argument** target, package `plugin-assurance` — and propagate it over the `elicit-proof-obligations` / `plugin-proof-obligations` occurrences still in 02 and 07 body text — _09_ + the 2026-08-10 rename decision. 37. Ship the assumption ledger as the headline artifact, as a Markdown table, with per-claim status a derived label — _09_. 38. Record acyclicity as a deliberate restriction and name `decreases` as the future escape hatch — _09_. 39. Sell the Datalog closure as well-formedness and taint propagation, never an assurance verdict; the ui never says "proved" unqualified — _09_. 40. Source `criticality` to safety engineering (DAL/SIL/ASIL), not Dafny or Lean, and say so — _09_. 41. Adopt the one-`Statement`-record, four-edge-kind, five-stratum contract sketch — _09_. 42. Carry as pattern guidance, not mechanism: comment-versus-message provenance, boundary-teaching schemas, hash-pinned prompt directives, private scratchpad — _05_, subject to S7.
+
+---
+
+## 4. AMENDMENT-ORDER READING GUIDE
+
+Read `CONTEXT.md` and `map.md` first for vocabulary and charter, then the tickets in this order, then re-check `CONTEXT.md` against L11–L12.
+
+| #   | Ticket                                                    | Take                                                                                                                                                                                                                                                                                 | Later tickets override                                                                                                                                                                                      |
+| --- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | **Flue architecture deep-read** (01)                      | Substrate facts: hooks/render model, `defineTool`, `harness.prompt`, `usePersistentState`, `useDataWriter`, signals versus user messages, local/remote parity table, no ask primitive, Valibot lock-in, no path to Pi's message list                                                 | 06 renames the hook `useElicitation`; 12 flips persistence; the "no path to the message list" fact becomes loose end L2                                                                                     |
+| 2   | **zil-lean survey** (02)                                  | Existence proof of the claim-graph layer: assurance lattice, prohibited promotions, derivation provenance, dependency-closure readiness                                                                                                                                              | 09 supersedes the pack sketches, the status-ladder emphasis and the format; `paraphrase_confirmed` / `source_span` conflict with the envelope; target name now `plugin-assurance`                           |
+| 3   | **Brunch exchange-schema audit** (03)                     | The one-tool-four-shapes primitive, comment-versus-message provenance, boundary-teaching schemas, agenda-as-derived-state, hash-pinned directives, the strain marks, the fifteen inherit/avoid lessons                                                                               | 05 overturns four Generic classifications — declared continuations, recovery scan, self-contained terminals, the tool_meta chain (S1)                                                                       |
+| 4   | **Dev-target portfolio confirmation** (07)                | Portfolio (gherkin + the formal target, BPMN third), hybrid order, both-packs-before-freeze rule, gherkin validator depth                                                                                                                                                            | 09 demotes the four-rung ladder and refutes the Geolog/ARIA guess; the target is now the assurance argument                                                                                                 |
+| 5   | **Formal-verification canon survey** (09)                 | GSN skeleton + Dafny nouns + Lean sorry-taint; assumption ledger as headline; the `Statement`/edge/stratum sketch; derived labels; the rename argument                                                                                                                               | Nothing overrides it; its rename obligation is now discharged as `plugin-assurance`                                                                                                                         |
+| 6   | **Contract decomposition** (04)                           | The spine: agent-forward hybrid, no universal IR, capture envelope, typed issue queue, operation tiering and snapshot-in/deltas-out, facts-computed-weights-judged, packs and kernel cards, Principle v2, all acceptance material                                                    | 05 renames the shells and retires the exchange ontology; 11 splits validation into two strata and frees op cadence; 12 flips storage, derives capture status, and shrinks per-session state (S5–S7, C2, C3) |
+| 7   | **Questioning-UX contract** (05)                          | The reframe (no exchange-pair ontology; affordances as evidence; capture via range-sweeps on settlement), the shell renames, IoC via PluginContext, the six harness commitments, the brunch disposition                                                                              | 10 amends the one-channel commitment to a one-live-affordance slot and adds the reject-second-ask invariant; 11 hardens absence and resolution records; 12 supersedes its provenance rule                   |
+| 8   | **Walking skeleton: Flue question round-trip** (10)       | Transport truth: one-live-affordance slot, identity on the tool output part, update-in-place settled, no echo token needed _as configured_, turn suspension plus the wake wart, `purpose`/`display` filtering, questionnaire as one multi-step affordance with ui-driven progression | Nothing amends it; its `exchangeId` / `data-exchange` / `epistemicStatus: stated` vocabulary needs renaming (S2, S4) and its persistence aside is stale (S3)                                                |
+| 9   | **Logic-prototype: capture sweep & settlement** (11)      | All five capture hypotheses, each sharpened: trigger-versus-judgment, mechanical-versus-semantic idempotence, content-based identity, absences as evidence, two supersession channels — **and its three amendments to 04**                                                           | 12 settles the derived-status suggestion as fact and generalizes the cite-the-user rule; its `deferred (explicit)` needs a transport mechanism (C4)                                                         |
+| 10  | **Shipping shape** (06)                                   | Harness library in a thin host-authored agent, the capability list and second-binding test, package topology and dependency invariant, Valibot, tool prefix, testing strategy, dev-app charter, remote-parity constraints                                                            | 12 flips the storage port to binding-implemented (C1); the capability list needs four more entries (L3); the plugin package is now `plugin-assurance`                                                       |
+| 11  | **Multi-session elicitation & durable target state** (12) | Durable target-document, transient sessions, sweep as the only bridge; interleaved-only concurrency; re-entry briefing as injected state messages; only-true-user-entries-are-evidence; completion as derived status; the storage flip; evidence spans as pointer + excerpt          | Latest ticket — authoritative wherever it speaks, but see C2 (its PluginContext-storage clause versus snapshot purity) and C5 (its provenance rule versus kernel invariant 1)                               |
+
+Reference material, read alongside 04: `docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md` (four contracts, packs, IR) and `docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md` (five proof obligations §1, swap tests §6, smells §7–8, ten invariants §9). Ticket 04 adopts these by reference and by count, not by content, so the spec cannot be assembled without them.
+
+**Composability check on the derived-status chain — the three ideas do compose,** into one principle worth stating once: _no status is ever written; every status is computed at read time from stored captures, issues and events._ It operates at three strata, and the spec should name them separately — envelope status (harness-computed: `active`/`superseded` from links and resolution records, per 11); completion status (harness-computed by running plugin-declared criteria, per 12); and domain labels (plugin-computed by stratified derivation over its own payload graph, per 09). The only casualty is 04's stored `status` field (C3), and the only gap is where the plugin-level derivation is invoked (L5).
+
+---
+
+## 5. SIZE
+
+| Material                                 | Bytes       | ≈ Tokens     |
+| ---------------------------------------- | ----------- | ------------ |
+| `map.md`                                 | 18,427      | 4,600        |
+| `CONTEXT.md`                             | 5,415       | 1,350        |
+| Tickets 01–12 (13 files, incl. 08)       | 143,209     | 35,800       |
+| **Subtotal — map + glossary + tickets**  | **167,051** | **≈ 41,800** |
+| `agentic-elicitation-challenges` (inbox) | 18,060      | 4,500        |
+| `agentic-elicitation-criteria` (inbox)   | 32,612      | 8,150        |
+| **Total the assembler must hold**        | **217,723** | **≈ 54,400** |
+
+Roughly 54k tokens, of which about 42k is the map plus tickets and 13k is the two inbox docs where 04's acceptance material actually lives — comfortably one session, read raw; no digest subagents required.
+
+Three of the largest files are early research tickets — 01, 02 and 03 total 62KB, about 15k tokens — and their load-bearing content is largely already condensed into the map's decision lines and into 04, 05, 07 and 09. The assembler can treat those three as lookup sources rather than sequential reads, with two exceptions: 03's classification table is needed and partly stale per S1, and 01's primitive inventory plus local/remote parity table are needed for the capability-list work in L3.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description-plain.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description-plain.md
new file mode 100644
index 00000000000..9aad7cd26eb
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description-plain.md
@@ -0,0 +1,130 @@
+# Elicitation Kernel — Product Description (plain prose edition)
+
+Status: companion document to [spec.md](../../../spec.md); an alternate rendering of
+[product-description.md](product-description.md) in plain technical prose rather than
+Simplified Technical English.
+Written: 2026-08-10
+
+The specification remains the authority. Where this document and the specification disagree,
+the specification is correct.
+
+---
+
+## What the product is
+
+The product is a library that developers add to a chat agent. With the library in place, the
+agent can run structured interviews: it talks with a person in an ordinary chat conversation,
+gathers facts as they come up, and records each fact together with the person's own words. The
+result is a structured document — a set of test scenarios, for example, or a safety argument.
+
+The system itself has no fixed subject matter. A plugin defines what kind of facts to look
+for, how to check them, and what document to produce from them. Because the plugin carries all
+of the subject knowledge, adding a new document type means writing a new plugin, not changing
+the system.
+
+## How an interview works
+
+The conversation always comes first. The agent does not walk the person through a form, and it
+does not ask questions in the order a schema happens to list its fields. It follows the
+conversation, and it asks about what matters when the conversation makes the gap visible.
+
+When the agent needs a precise answer, it can place a question card in the chat: a free-text
+prompt, a single choice, a multiple choice, or a set of related questions the person can work
+through in one sitting. Every card also renders as plain text, so a chat surface that cannot
+display cards still carries the full interview — the person reads the question and types the
+answer instead.
+
+The person stays free throughout. They can answer the card, type something else entirely,
+change the subject, or leave a question for later. None of this is an error. The system
+records what actually happened, because an unanswered question is itself information the
+interview should not lose.
+
+## How facts are recorded
+
+The agent does not commit facts to the record mid-sentence. It waits until a stretch of
+conversation has settled — a topic has been talked through and the thread has moved on — and
+then reads back over that stretch and records the facts it contains. This read-back is safe to
+repeat: because each fact is identified by its content and its evidence, reading the same
+stretch twice never produces duplicates, and a second pass can pick up anything the first one
+missed.
+
+Each recorded fact carries three things: the fact itself, in the structure the plugin defines;
+a quotation of the exact words that support it, together with a durable link to the point in
+the conversation record where they were said — nobody searches by text to find a source; and a
+source label that says how the system came by it — stated directly by the person, inferred from context, held tentatively, filled in
+from a default, or fetched from an external source. The distinction matters because a
+plausible inference must never be mistaken for something the person actually said.
+
+Three rules hold without exception. A fact without a source is refused. Only the person's own
+words count as evidence — text the system adds to the conversation, such as a catch-up summary,
+never does. And what the system inferred stays permanently distinguishable from what the
+person stated.
+
+## Corrections, conflicts, and non-answers
+
+People change their minds, so the record is built for revision. A correction produces a new
+fact that replaces the old one, and the old one is kept — the history of every fact stays
+readable, which is what makes a late correction safe rather than destructive.
+
+When two facts contradict each other, the system does not quietly pick a winner. It records a
+conflict and leaves it open until the person decides, and it records that decision in the
+person's own words. Recency is not authority: the newest statement wins only when the person
+says it does.
+
+Not every answer is a value, and the system keeps the different kinds of non-answer apart: the
+person does not know; the decision has not been made yet; the question does not apply; the
+value genuinely does not exist; the person declined; the person put it off. "We have no
+deadline" and "I don't know the deadline" are different facts that should lead the interview
+in different directions, so the system never collapses them into one empty field.
+
+## Documents outlast conversations
+
+The product of the interviews is a target document, and it persists independently of any
+conversation. A person can stop mid-interview and lose nothing. Days later they can open a new
+conversation against the same document, and the agent starts with a short, clearly marked
+summary of what changed in the meantime. Several conversations can feed one document in turn.
+The conversations themselves are part of the record: each one is kept indefinitely, stored
+alongside the document it fed, because it is the provenance that every recorded fact points
+back into.
+
+If a dormant conversation resumes after the document has moved on, the system protects the
+document: a change built on stale information is refused, with an explanation of what moved,
+so the person can decide with current facts in view. The document itself is never locked.
+Completeness is a status the system computes from the record, not a gate it enforces — the
+person who comes back with one more correction after "done" is a normal case, not an
+exception.
+
+## What you can read out
+
+At any point, the system can show the current facts with their sources and quotations, the
+open conflicts and questions, the history behind any fact, and the output document the plugin
+derives from it all. The facts are the truth; the output document is a view computed from
+them. When the output format cannot express something the record holds — a nuance, an
+alternative, a qualification — the system says so in a loss report rather than dropping it
+silently.
+
+## The first two subjects
+
+The first release ships two plugins. The Gherkin plugin interviews for system behaviour and
+produces scenarios in Given/When/Then form, checking that the output parses and that its steps
+use the agreed vocabulary. The assurance plugin interviews for an assurance argument — claims
+about a system, the evidence behind them, and the assumptions they rest on, connected in a
+structured argument. Its primary output is the assumption ledger: a table of every open
+assumption, who owns it, its review state, and which claims it undermines. The tool exists to
+expose weak points in an argument, not to certify one — it will tell you which claims stand on
+unreviewed assumptions, and it will never call a system proven. A plugin for business process
+models is planned third.
+
+## Scope and limits
+
+The first release runs on one chat framework, Flue, on a local machine. The design pins the
+constraints that remote deployment will impose, so nothing in the first release blocks the
+move to a server, but remote operation itself is not included. The developer embedding the
+library writes a small amount of glue — the agent module, the server mount, and a database
+connection — and the library supplies everything else.
+
+Some boundaries are deliberate. The system does not forward its results to any other tool;
+whoever consumes the document, human or machine, reads it through the same functions. It does
+not score or budget questions, because judgement about what to ask belongs to the agent
+reading the conversation, guided by the plugin. And it does not fill silence with guesses:
+when information is missing, the record says so, plainly.
diff --git a/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description.md b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description.md
new file mode 100644
index 00000000000..4edd1c52b3d
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/product-description.md
@@ -0,0 +1,202 @@
+# Elicitation Kernel — Product Description
+
+Status: companion document to [spec.md](../../../spec.md)
+Written: 2026-08-10
+
+This document tells you what the product does. It uses product terms, not architecture terms.
+It obeys the writing rules of ASD-STE100 Simplified Technical English where possible. Some
+technical names are necessary. Section 12 gives the list of technical names and connects them
+to the terms in the specification.
+
+The specification has the full technical rules. If this document and the specification do not
+agree, the specification is correct.
+
+---
+
+## 1. What the product is
+
+The product is a software library for chat agents. A developer puts the library into an agent.
+The agent can then do structured interviews with a person.
+
+The agent speaks with the person in a normal chat conversation. In the conversation, the agent
+collects facts. The system records each fact together with the words of the person. The result
+is a structured document. Examples of such documents: a set of test scenarios, or a safety
+argument.
+
+The product has no fixed subject. A **plugin** tells the system what facts to collect, and what
+document to make. A developer can write a new plugin for a new subject. The system does not
+change when a new plugin comes.
+
+## 2. What an interview is like
+
+The conversation is primary. The person and the agent speak freely. The agent does not follow
+a fixed list of questions. The agent does not fill a form field by field.
+
+When the agent needs a precise answer, it can show a **question card** in the chat. A question
+card is a small form. There are three basic types:
+
+- A free text question.
+- A question with one choice.
+- A question with more than one choice.
+
+The agent can also show a **question set**: one card with a list of questions. The person can
+answer them one by one, in the chat, without a stop after each answer.
+
+Every question card also appears as simple text. If the chat window cannot show cards, the
+person can read the question and type an answer. No function is lost.
+
+The person is always free. The person can:
+
+- Answer the card.
+- Type a different answer as normal text.
+- Speak about a different subject.
+- Come back to the question later, or not at all.
+
+The system records all of these results correctly. An unanswered question is not an error.
+
+## 3. How the system collects facts
+
+The agent does not record facts one by one while the person speaks. The agent waits until a
+part of the conversation is complete. Then the system does a **sweep**: it reads that part of
+the conversation and records the facts from it.
+
+A sweep is safe to do again. If the system reads the same conversation twice, it does not
+record the same fact twice. If the first sweep missed a fact, a second sweep can add it.
+
+## 4. What a recorded fact contains
+
+Each recorded fact is a **capture**. A capture contains:
+
+- The fact itself, in the structure that the plugin defines.
+- A quotation: the exact words of the person that show the fact.
+- A link to the point in the conversation record where the person said those words. You do not
+  search by text to find the source. You follow the link.
+- A source label. The label shows how the system got the fact:
+  - The person said it directly.
+  - The agent found it from context (an inference).
+  - The agent is not sure (a tentative reading).
+  - The system used a standard value (a default).
+  - The system got the value from an external source.
+
+The system obeys these rules at all times:
+
+- Each fact must have a source. A fact without a source is refused.
+- Only the words of the person are applicable as evidence. Text that the system adds to the
+  conversation is never evidence.
+- An inference must never look the same as a direct statement from the person.
+
+## 5. Corrections and conflicts
+
+The person can change a fact at any time, also after the interview seems complete.
+
+When a fact changes, the system makes a new capture. The new capture replaces the old capture.
+The system keeps the old capture. The full history of each fact stays available. A correction
+never erases information.
+
+If two facts do not agree, the system does not select one of them automatically. It records a
+**conflict**. The conflict stays open until the person gives a decision. The system records
+the decision together with the words of the person. There is no silent resolution.
+
+## 6. Answers that are not values
+
+Sometimes the person cannot give a value. The system records the type of each such answer.
+The types are different, and the system keeps them different:
+
+- The person does not know the value.
+- The person did not make the decision yet.
+- The question is not applicable.
+- The value does not exist. Example: "We have no deadline."
+- The person refused to answer.
+- The person moved the answer to a later time.
+
+Example of the difference: "We have no deadline" and "I do not know the deadline" are two
+different facts. A form that writes an empty field for both loses this difference. This system
+does not lose it.
+
+## 7. Documents that continue across conversations
+
+The result of the interviews is a **target document**. The target document stays when a
+conversation stops.
+
+- A person can stop a conversation at any point. Nothing is lost.
+- Days later, the person can start a new conversation about the same document. The agent then
+  gets a short summary of what changed. The person sees a note that this summary was added.
+- Different conversations can add facts to one document, one after the other.
+- If an old conversation continues after the document changed, the system protects the
+  document. A change that does not agree with the current state is refused, with an
+  explanation. The person can then decide.
+
+The conversations are also documents. The system keeps each conversation record together with
+the target document, in the same store. The conversation records are the source of the facts.
+The system does not delete them.
+
+A target document is never locked. "Complete" is a calculated status, not a gate. The person
+can always come back with one more correction.
+
+## 8. What you can read from the system
+
+At any time, the system can show:
+
+- The current facts, with their sources and quotations.
+- The open conflicts and the open questions.
+- The history of each fact.
+- The output document that the plugin makes from the facts. Example: the Gherkin text, or the
+  assurance argument.
+- A loss report. If the output format cannot show a recorded fact, the report says so. The
+  system does not drop facts silently.
+
+The output document is always calculated from the facts. The facts are the truth. The output
+is a view.
+
+## 9. The first two subjects
+
+The first release contains two plugins.
+
+**Test scenarios (Gherkin).** The agent interviews the person about the behavior of a system.
+The output is a set of scenarios in the Gherkin format (Given / When / Then). The plugin makes
+sure that the output has correct syntax, and that the steps use the agreed vocabulary.
+
+**Assurance argument.** The agent interviews the person about a claim, for example: "this
+system is safe to operate". The output is a structured argument: claims, evidence, and
+assumptions, connected in a tree. The primary output is the **assumption ledger**: a table of
+all open assumptions, with their owners and their review states. The tool shows which claims
+stand on unproven assumptions. The tool finds weak points. It does not certify the system.
+
+More subjects can follow. A plugin for business process models is planned as the third.
+
+## 10. Where the product operates
+
+The first release operates on one chat framework (Flue), on a local machine. The design
+prepares for remote operation on a server, but the first release does not include it.
+
+The developer who adds the library to an application writes a small amount of code: the agent
+module, the server mount, and the database connection. The library supplies the rest.
+
+## 11. What the product does not do
+
+- It does not send its results to another tool automatically. Persons and tools read the
+  target document through the same read functions.
+- It does not give scores to questions, and it does not count questions. The agent decides
+  what to ask from the conversation, with guidance from the plugin.
+- It does not continue without the person. The person is the source of the facts. When
+  information is missing, the system records that it is missing. It does not invent values.
+- It does not lock a document, and it does not close a conversation.
+
+## 12. Technical names in this document
+
+| Name in this document                      | Name in the specification                          |
+| ------------------------------------------ | -------------------------------------------------- |
+| the system                                 | the harness                                        |
+| question card                              | affordance                                         |
+| question set                               | questionnaire                                      |
+| capture                                    | capture (with capture envelope)                    |
+| sweep                                      | sweep (on settlement)                              |
+| source label                               | epistemic status                                   |
+| answer that is not a value                 | absence state                                      |
+| conflict                                   | `conflicting` issue, closed by a resolution record |
+| replaces                                   | supersession                                       |
+| target document                            | target-document                                    |
+| summary at the start of a new conversation | re-entry briefing                                  |
+| loss report                                | typed loss report from `project`                   |
+| plugin                                     | plugin (with its packs)                            |
+| chat framework                             | substrate                                          |
diff --git a/libs/@hashintel/brunch-agent/docs/inbox/.gitkeep b/libs/@hashintel/brunch-agent/docs/inbox/.gitkeep
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/libs/@hashintel/brunch-agent/docs/planning/_shared/COORDINATION.md b/libs/@hashintel/brunch-agent/docs/planning/_shared/COORDINATION.md
new file mode 100644
index 00000000000..54e343fb836
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/_shared/COORDINATION.md
@@ -0,0 +1,122 @@
+# Project coordination
+
+This is the cross-map coordination surface for the `brunch-agent` project. FE-1383 owns the
+milestone-one harness build; FE-1357 owns the September demo and process-model plugin design.
+Linear is canonical for issue state, parentage, and hard `blocks` relations. This file owns
+only the judgment Linear cannot express: the current project-wide recommendation, soft edges,
+unresolved seams, and exceptional roots.
+
+Before revising the recommendation, run
+`turbo run linear:graph --filter '@hashintel/brunch-agent'`. Its compact projection supplies the
+factual open-issue DAG; read the relevant issue bodies for semantic content, then infer the smallest
+honest recommendation. Do not paste the generated graph here or mirror issue status.
+
+## Current sequencing recommendation
+
+As of **2026-08-21**, the FE-1437 authority cutover has been executed: the full brunch-lite
+history is imported on `ln/fe-1437-hash-monorepo-import` in `hashintel/hash` (frozen standalone
+SHA `43a0022918861846344b96a32cb94f92e2ee96ae`), every import gate re-verified. `hashintel/hash`
+is authoritative; the standalone repository accepts no further implementation work. FE-1437
+closes when the branch lands on `main` (squash merge, per convention). Part of FE-1440's website
+wiring (the Brunch interactive-tool panel in `apps/petrinaut-website`) travelled with the import
+branch; FE-1440 was trimmed on 2026-08-21 to the remaining mode wiring (mode switch, browser
+identifier bootstrap, remote transport swap). After landing, advance FE-1438 (client-tool round-trip)
+beside FE-1393 (plugin SDK and first projection); FE-1439 (private durable sessions) proceeds in
+parallel. The integration stream joins at FE-1440 and deployment follows at FE-1441 (which also
+waits on FE-1423's pre-exposure gates), while the harness stream reaches its contract-freeze
+decision at FE-1387. FE-1402/FE-1403 form a parallel content/evaluation stream, without
+displacing the two convergence edges.
+
+```text
+legend:
+  -[hard]->       native Linear blocker
+  -[coord]->      either order; do not implement concurrently
+  -[input]->      semantic input, not a blocker
+  -[state-gate]-> condition in the world, not an issue edge
+
+nodes:
+  FE-1437 [executed, landing]      # history imported; HASH authoritative; PR pending
+  FE-1438 [next]                   # client-tool round-trip
+  FE-1439 [next, parallel]         # private durable sessions
+  FE-1440 [join, partly landed]    # website elicitor mode; panel wiring on import branch
+  FE-1441 [post-landing]           # HASH deployment
+  FE-1393 [next]                   # plugin SDK + first projection
+  FE-1387 [after-FE-1393]          # second pack + contract freeze
+  FE-1395 [coordination]           # full affordance set
+  FE-1402 [parallel, content]      # completion contract
+  FE-1403 [parallel, content]      # interviewing guidance
+  FE-1404 [after-content]          # armed baseline
+
+edges:
+  FE-1449                 -[hard]->       FE-1438
+  FE-1392                 -[hard]->       FE-1393
+  FE-1438, FE-1439,
+  FE-1437                 -[hard]->       FE-1440
+  FE-1437, FE-1439,
+  FE-1423                 -[hard]->       FE-1441
+  FE-1393                 -[hard]->       FE-1387
+  FE-1402, FE-1403        -[hard]->       FE-1404
+  FE-1395                 -[coord]->      FE-1438
+  FE-1437 branch on main  -[state-gate]-> FE-1438, FE-1439, FE-1393
+  FE-1387                 -[input]->      FE-1440
+```
+
+Hard-edge truth remains in Linear. The graph above is a deliberately focused recommendation,
+not a second issue database.
+
+## Repository handoff threshold
+
+FE-1437 (the monorepo import; [execution plan](./hash-monorepo-import-plan.md)) was the authority
+cutover, not a general freeze on harness work. It was crossed on 2026-08-21:
+
+```text
+brunch-lite authoritative (until 2026-08-21)
+  FE-1434 + FE-1435 verdicts landed
+  FE-1388/1389/1390/1399 review stack merged
+                    |
+                    v
+      == FE-1437 import (executed) ==
+                    |
+                    v
+hashintel/hash authoritative (now)
+  FE-1440 website wiring + FE-1441 deployment
+```
+
+The standalone repository is frozen at SHA `43a0022918861846344b96a32cb94f92e2ee96ae` and is
+read-only reference material. All further work — including FE-1438 and FE-1439, which were not
+import gates — happens in `hashintel/hash`. Do not run both repositories as writable authorities.
+Closing out the standalone repository's shared state (archival, access) is deferred and requires
+explicit approval from Lu.
+
+## Open seams
+
+- **Contract freeze — FE-1387.** The process-model target must stress the plugin contract before
+  it freezes. FE-1393 makes the contract programmable; FE-1387 remains the cross-map hinge.
+- **Absence locator.** An absence capture carries no payload, but the fold needs a field-specific
+  coordinate (anchor × slot). The plugin-contract spec records three worked cases; any envelope
+  amendment belongs to the harness side of this seam.
+- **Structured-tap evidence — FE-1395 × capture store.** `resolve-conflict` currently rejects
+  `user-affordance-payload` evidence. FE-1395 must decide the transport fact before the store
+  rule can settle.
+- **Guidance placement — FE-1403 × FE-1406.** Plugin cards and the harness-shipped generic
+  strategy quiver share authoring methods but not ownership. Packages export; hosts register.
+- **Telemetry vocabulary — FE-1385 × FE-1404 × FE-1423.** The probe surface, experiment
+  accounting, and remote telemetry should share span vocabulary rather than invent it three
+  times.
+- **Living-prototype charter.** The deployed elicitor as a cumulative record of proved and
+  unproved behavior remains pre-charter until the infrastructure conversation settles.
+
+Settled seam decisions still governing open work: FE-1392 established the plugin-declared
+verbatim proposal floor, and ask accounting remains a read-time relation rather than an envelope
+field. ADR-0003 keeps field-level structure below the capture's single epistemic status.
+
+## Exceptional roots
+
+These project issues intentionally have no parent and are roots under the registry rule:
+
+- **FE-1331 — start elicitation from Petrinaut's create-new-net flow.** Deferred post-September
+  consumer topology; returns after in-Petrinaut staging proves itself.
+- **FE-1334 — offer the user a surprising scenario of their model.** A validation gesture with
+  no owning map yet; closest to the motif/quiver strategy work.
+- **FE-1406 — design reusable elicitation strategies.** The cross-map home for the
+  harness-shipped generic strategy quiver; intentionally independent of either delivery map.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/_shared/SPEC-LEDGER.md b/libs/@hashintel/brunch-agent/docs/planning/_shared/SPEC-LEDGER.md
new file mode 100644
index 00000000000..226a72fac31
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/_shared/SPEC-LEDGER.md
@@ -0,0 +1,126 @@
+# Milestone-one specification ledger
+
+This living ledger tracks the elicitation-kernel specification's obligations against the built
+system. Code and tests are authoritative; a branch that changes an obligation updates its row in
+the same change. Unlike `COORDINATION.md`, this document has a terminal lifecycle: it settles as
+a record when milestone one closes.
+
+Status vocabulary: **discharged** (built and proved) · **partial** (built with named gaps) ·
+**pending** (nothing built) · **superseded** (an ADR changed the obligation) · **orphaned**
+(owned by no issue) · **contradicted** (implementation and spec disagree).
+
+`test/open-gaps.ts` separately mechanizes selected behavioral-proof closures. It overlaps this
+ledger deliberately but does not replace its partial, contradicted, superseded, and evidence
+states.
+
+## Architecture & shipping shape (§4, §12)
+
+| Obligation                                                                              | Spec         | Status                      | Evidence                                                                                                                                                                                                                                                                                                                                                        |
+| --------------------------------------------------------------------------------------- | ------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Shell separation: plugins→core only; core imports no substrate; binding imports both    | §4, §12.2    | **discharged**              | boundary gates (FE-1388/FE-1399, `test/boundaries.test.ts`); `workspacePackages()` derives groups from manifest; `plugin-gherkin` imports `@brunch/core` only                                                                                                                                                                                                   |
+| Package topology                                                                        | §12.2        | **partial**                 | `core` (+`testing` subpath), `binding-flue`, `transport-aisdk`, `plugin-gherkin`, `apps/brunch-agent` exist; `plugin-assurance` pending. FE-1437 imported them to their native HASH destinations and preserved the existing dependency boundaries. Topology pin derives from §12.2 itself (FE-1400 `ef00201`); FE-1436 adds the transport-only dependency gate. |
+| Core _is_ the harness (mechanism lives in core)                                         | §12.2, §14.2 | **discharged**              | FE-1422 moved ask mechanism into `core/ask-protocol`; FE-1392 added range selection, trigger/repair decisions, quote-only prompting, and advisory semantics in `core/sweep-protocol`. `binding-flue` supplies substrate reading and orchestration wiring only                                                                                                   |
+| Tool naming: identity not function                                                      | §12.3        | **superseded → discharged** | ADR-0001 replaces `bl_*` with `brunch_*`; `toolName('ask')` → `brunch_ask`; `elicit_*` ban enforced                                                                                                                                                                                                                                                             |
+| Valibot at every boundary                                                               | §12.4        | **discharged**              | core + binding schemas throughout; `transport-aisdk` validates the external UI POST before typed request parsing                                                                                                                                                                                                                                                |
+| SDK surface (anchoring, retries, tracing, arbitraries, simulation harness)              | §12.4        | **pending**                 | none built; owned by FE-1393 (FE-1383 slice), export-surface ratification gated on the contract freeze (FE-1387)                                                                                                                                                                                                                                                |
+| Host-authored thin agent calling `useElicitation(plugin, session)`                      | §12.1        | **discharged**              | `apps/brunch-agent/src/agents/gherkin-elicitor.ts`; FE-1392 adds host-owned immutable session/document and transport wiring                                                                                                                                                                                                                                     |
+| Imported app's four roles (remote server, dev loop, target gallery, probe surface)      | §12.5        | **partial**                 | remote server + dev loop exist; gallery and probe surface remain owned by FE-1385. FE-1437 re-chartered `apps/dev` as HASH's `apps/brunch-agent`; no dedicated demo shell is created.                                                                                                                                                                           |
+| CI smoke: no model key, no network, no flake                                            | §12.5        | **discharged**              | faux-provider integration test through real runtime + real Hono app (FE-1389); the smoke workflow itself never executed until FE-1400 `699ebe4` un-killed it (org policy vs. tag-pinned actions). Hermeticity probed, not assumed: explicit `start()` config leaves the dev db untouched across the run (Flue audit, 2026-08-17)                                |
+| Remote-parity constraints (pinned agentName, storage outside plugin, no dynamic agents) | §12.5        | **discharged**              | pinned-identity gates (FE-1399/FE-1400); storage port in binding (FE-1390)                                                                                                                                                                                                                                                                                      |
+| Version axes                                                                            | §12.6        | **pending**                 | named, none implemented — as spec states                                                                                                                                                                                                                                                                                                                        |
+
+## Capture envelope (§5)
+
+| Obligation                                                                                                                                               | Spec     | Status                              | Evidence                                                                                                                                                                                                                                                                                                                                                                                                                               |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------------------- |
+| Envelope fields: minted id + content dedup key (status excluded), spans, epistemic status, confidence, value XOR absence, alternatives, one `supersedes` | §5       | **discharged**                      | `packages/core/src/capture-store.ts` (FE-1390); invariants 9/10 pinned by named tests                                                                                                                                                                                                                                                                                                                                                  |
+| No stored status; derived at read time (C3)                                                                                                              | §5       | **discharged**                      | `deriveCaptureStatus`/`deriveIssueStatus`; tests assert no `status` field persisted                                                                                                                                                                                                                                                                                                                                                    |
+| Retraction: explicit user-cited event, no successor                                                                                                      | §5       | **discharged**                      | `RetractionEvent` (FE-1390)                                                                                                                                                                                                                                                                                                                                                                                                            |
+| Pointer **derived by the harness**; model cites quotes, never sequence numbers                                                                           | §5, §8.2 | **discharged**                      | FE-1391 split caller `EvidenceQuote` from persisted `EvidenceSpan`: every evidence command accepts verbatim quotes only, resolves once against the session archive, and stores an archive-owned ordinal range; extra pointer/source fields are refused. FE-1464 adds a full-prefix retry proof: a later identical entry preserves the first capture's harness-owned occurrence                                                         |
+| Confidence qualitative, never a scalar                                                                                                                   | §5       | **partial**                         | non-empty string only; `"0.93"` accepted. Vocabulary is settled by the plugin-contract spec as `firm                                                                                                                                                                                                                                                                                                                                   | hedged | speculative`; its proposed store refusal rule for numeric-parsing strings remains to implement |
+| Six absence states; `not-mentioned` computed, never stored                                                                                               | §5.1     | **discharged**                      | `ABSENCE_STATES` (FE-1390)                                                                                                                                                                                                                                                                                                                                                                                                             |
+| Reserved reply encoding for structured taps (C4)                                                                                                         | §5.1     | **pending**                         | UI sends bare text; absences from this UI are honestly `inferred`                                                                                                                                                                                                                                                                                                                                                                      |
+| One epistemic status per capture                                                                                                                         | §5       | **discharged**, with named friction | Status is the proposal union's discriminant, coupled to provenance shape — per-field status is unrepresentable, and payload-smuggling it breaks dedup identity. This was FE-1405's central input (deep-read FE-1390, tiering section); the arc consumed it _without_ amendment — one status per capture survives, and the structure that wanted per-field status lives below it in proposal interiors (ADR-0003, plugin-contract spec) |
+
+## Operations & validation (§6)
+
+| Obligation                                                                   | Spec | Status         | Evidence                                                                                                                                                                                                                                                                          |
+| ---------------------------------------------------------------------------- | ---- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `project` + typed loss report; `validate`; optional `reconcile`; purity (C2) | §6.1 | **pending**    | FE-1392 adds only the plugin-declared `statement-noted` verbatim proposal floor; operations remain FE-1393                                                                                                                                                                        |
+| Envelope-level refusals (provenance, XOR, single-hop supersession)           | §6.2 | **discharged** | FE-1390 command surface                                                                                                                                                                                                                                                           |
+| Citations resolve to true user entries                                       | §6.2 | **discharged** | FE-1391 resolves quote-only inputs against archived public messages and refuses injected non-user matches. FE-1392's mounted oracle starts with a quote absent from the archive, permits only non-writing peeks, then proves the refresh adjacent to apply resolves and stores it |
+| Duplicate detection free for flat-record plugins                             | §6.2 | **partial**    | near-identical advisory fires for string payloads only; a flat record gets none                                                                                                                                                                                                   |
+| Issues typed + namespaced to producer (invariant 6)                          | §6.3 | **partial**    | all seven types, origin variants present; producer self-declared, unauthenticated                                                                                                                                                                                                 |
+| Advisories computed, ephemeral, never stored                                 | §6.3 | **discharged** | returned in results, never in snapshot (FE-1390)                                                                                                                                                                                                                                  |
+| Cadence as policy (§6.4)                                                     | §6.4 | **partial**    | FE-1392 makes successful sweep the cadence boundary and keeps projection/validation read-time-only, leaving sweep outcome unchanged. Concrete operations remain absent until FE-1393                                                                                              |
+
+## Questioning UX (§7)
+
+| Obligation                                                                                   | Spec | Status           | Evidence                                                                                                                                                                                  |
+| -------------------------------------------------------------------------------------------- | ---- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| No exchange-pair ontology                                                                    | §7.1 | **discharged**   | affordances as entries; retired vocabulary absent                                                                                                                                         |
+| Three baseline forms + questionnaire chaining                                                | §7.2 | **partial**      | free-text only, by design (FE-1389); remainder owned by FE-1395                                                                                                                           |
+| Markdown floor: unknown forms still render                                                   | §7.2 | **contradicted** | dev UI `safeParse`s the whole concrete form and renders nothing on failure (`apps/brunch-agent/src/ui/chat.tsx`); needs envelope-only schema. Filed FE-1420                               |
+| One live affordance; durable identity on tool output part; channel as live-render sugar (C6) | §7.3 | **discharged**   | updater-form guard + `output` part + channel write (FE-1389); _retry hole_: a re-executed ask (at-least-once tools) is refused as a duplicate — FE-1420                                   |
+| No instruction interpolation; mechanical reply binding via signal; no echo token (C7)        | §7.4 | **discharged**   | render-invariant instructions; `affordance-reply-bound` signal (FE-1389); FE-1392's high-water and repair-signal paths run through the mounted lifecycle without instruction-update wakes |
+| Transport outcomes `answered / redirected / unanswered`                                      | §7.5 | **pending**      | slot clears unconditionally; no outcome recorded. FE-1420 (abandoned asks)                                                                                                                |
+| Interpretation render                                                                        | §7.6 | **pending**      | open in `test/open-gaps.ts` (FE-1394)                                                                                                                                                     |
+| Outbound rich / inbound string; UI filters on `purpose`/`display`                            | §7.7 | **discharged**   | FE-1389                                                                                                                                                                                   |
+
+## Capture mechanics (§8)
+
+| Obligation                                                     | Spec             | Status                                         | Evidence                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| -------------------------------------------------------------- | ---------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Settlement trigger + judgment                                  | §8.1             | **discharged**                                 | FE-1392 computes the unswept true-user tail, guards pending asks and repeated frontiers, permits decline, and injects same-response settlement judgment through awaited `useAgentFinish`                                                                                                                                                                                                                                                                         |
+| Harness-resolved anchoring at sweep application                | §8.2             | **discharged**                                 | FE-1391 resolves exact quotes against archived user entries at command application; no match returns a repair hint, multiple matches choose latest with an advisory, and injected non-user matches refuse                                                                                                                                                                                                                                                        |
+| Sweep idempotence, evidence-occurrence and content-keyed       | §8.3             | **discharged**                                 | FE-1392's durable executor may replay the settled prefix; the mounted oracle proves a repeated proposal skips while an earlier omission applies. FE-1464 proves a later identical entry cannot re-anchor a retry while distinct identical occurrences remain capturable. On refusal the successful high-water stays fixed while the loop guard reopens; the oracle stops once on the repair continuation and proves the range is offered again before succeeding |
+| Single-hop supersession over active heads; stale-session guard | §8.4, §9.2       | **discharged**                                 | refusal carries `currentHeadIds` (FE-1390)                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| Resolution records close conflicts; user-cited                 | §8.5             | **discharged**                                 | FE-1419 (`ln/fe-1419-contract-closure`): conflicts open only over two-plus distinct active captures, referenced captures are pinned until a user-cited resolution frees them, resolutions compare by set equality, and every accepted command round-trips through the persisted parser. The one-reference and supersession-stranding holes are closed and red-proved. The tap-evidence adjudication (contradicted row below) remains open                        |
+| Resolution evidence may be a structured tap                    | §5.1/C4 vs. §8.5 | **contradicted** (silent adjudication)         | `resolve-conflict` rejects `user-affordance-payload` evidence — a user who resolves a conflict by tapping a choice strip cannot close it. Defensible strict reading of §8.5; made without a record. FE-1395's body owns the other half of the same fact (tap-ness must be a transport fact); neither ticket references the other — seam item                                                                                                                     |
+| Unaccounted-ask advisory                                       | §8.6             | **discharged for affordance-bound accounting** | FE-1392 derives ask → bound user entry → capture evidence at read time and returns unmatched asks only as sweep advisories. Free-text accounting and abandoned slots remain FE-1420; no envelope field was added                                                                                                                                                                                                                                                 |
+| Resume-time sweep reconciliation                               | §8.7             | **pending**                                    | —                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+
+## Sessions & durability (§9)
+
+| Obligation                                                                       | Spec | Status                                            | Evidence                                                                                                                                                                                                                                                                                                                                         |
+| -------------------------------------------------------------------------------- | ---- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Durable target-document, transient sessions, sweep the only bridge               | §9.1 | **partial**                                       | store is session-independent (FE-1390); dev UI mints a fresh document per page load, so many-sessions-one-document is unreachable from any surface (deep-read FE-1389)                                                                                                                                                                           |
+| Per-session state = evidence log, swept high-water mark, pending-affordance slot | §9.2 | **discharged**                                    | pending slot (FE-1389), durable session-log archive (FE-1391), and FE-1392's parse-validated high-water/last-judged bookkeeping under one `sweepHighWater` state slot                                                                                                                                                                            |
+| Re-entry briefing; user-visible insertion notice                                 | §9.3 | **pending**                                       | signal carrier proved; no briefing; the one injected signal is filtered out of the UI. Owned by FE-1396                                                                                                                                                                                                                                          |
+| Only the true user's side is evidence; injected entries structurally non-user    | §9.4 | **partial**                                       | FE-1391 verifies role/purpose against the public projection, refuses signal/advisory text, and classifies affordance replies only from the harness-owned reply-binding signal. The kickoff remains a machine-authored `user` entry until FE-1420/FE-1385 move it to `useInitialData`; FE-1396 still owns briefing-never-evidence                 |
+| Completion derived, never a gate                                                 | §9.5 | **pending**                                       | —                                                                                                                                                                                                                                                                                                                                                |
+| Storage port: harness-defined, binding-implemented, plugin-blind (C1)            | §9.6 | **discharged for the local target**               | core owns capture/archive/anchoring semantics; `binding-flue` owns the file implementation; plugins cannot import the binding (FE-1390 + FE-1391)                                                                                                                                                                                                |
+| Port scope includes the session-log archive                                      | §9.6 | **discharged**                                    | FE-1391 provisions a versioned target-document record containing capture state and session logs, migrates the legacy capture-only shape on mutation, parses both halves on read, identity-versions evolving messages, and retrieves every cited ordinal independently of Flue                                                                    |
+| Compaction vs. durable log                                                       | §9.7 | **partial — source-settled, behavioral pin open** | Flue 2.0.3's append-only stream contract and implementation show compaction appends a canonical record, rewrites only model context, preserves the public message projection, and leaves `state_write` reduction untouched. The source-read record reshapes FE-1386 to one upgrade pin; `test/open-gaps.ts` remains until behavioral proof lands |
+
+## Binding capabilities (§10)
+
+| Obligation                                                                                        | Spec | Status         | Evidence                                                                                                                                                                                                                                                          |
+| ------------------------------------------------------------------------------------------------- | ---- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Caps 1–5: tool, instructions, persistent state, affordance emission, suspend-for-reply (absorbed) | §10  | **discharged** | all five exercised against the real runtime (FE-1389 integration test)                                                                                                                                                                                            |
+| Caps 6–8, incl. entry-projection read                                                             | §10  | **discharged** | FE-1391 supplies the public reader/archive. FE-1392 uses direct structured `harness.prompt` inside a durable tool whose peek/extract/refresh/apply boundaries use `step.do`; the mounted runtime pins same-response finish-hook steering and refresh-before-apply |
+
+## Plugins, packs, dev targets (§11, §13)
+
+| Obligation                                                                       | Spec       | Status                           | Evidence                                                                                                                                                                                                                   |
+| -------------------------------------------------------------------------------- | ---------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Plugin ownership: packs, forms, validators                                       | §11.1      | **partial**                      | `plugin-gherkin` now owns its one FE-1392 proposal declaration/schema and target identity; packs, forms, validators, fold, and demand table remain FE-1393/FE-1387 work                                                    |
+| Pack form, Principle v2                                                          | §11.2      | **pending**                      | —                                                                                                                                                                                                                          |
+| Smallest honest plugin as a standing bar                                         | §11.3      | **partial**                      | `statement-noted.test.ts` and the core plugin fixture encode the one-type verbatim floor and reject undeclared parsed/pointer shape; the standing bar must grow with FE-1393's operations                                  |
+| Generic strategy quiver                                                          | §11.5      | **pending** (ownership repaired) | was **orphaned** — named-not-designed, carried by no map — now FE-1406 (root issue)                                                                                                                                        |
+| Portfolio + hybrid order: both packs authored before the pack interface freezes  | §13        | **pending**                      | Owned by FE-1387 (FE-1383 slice, backlog), explicitly gated on FE-1357's second-target decision — the inter-map seam in miniature (see `COORDINATION.md`). Gherkin wiring ahead stays legal while FE-1387 holds the freeze |
+| Gherkin validation (parse validity, step lexicon)                                | §13.1      | **pending**                      | —                                                                                                                                                                                                                          |
+| Assurance target (Statement record, four edges, five-stratum derivation, ledger) | §13.2–13.3 | **pending**                      | —                                                                                                                                                                                                                          |
+
+## Acceptance material (§14)
+
+| Obligation                                                      | Spec  | Status                          | Evidence                                                                                                                                                                                                                                          |
+| --------------------------------------------------------------- | ----- | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Invariants 2, 4, 5, 7, 9, 10                                    | §14.1 | **discharged**                  | named tests in `capture-store.test.ts` (FE-1390), one hand-written example each                                                                                                                                                                   |
+| Invariant 1 (no value without provenance)                       | §14.1 | **partial**                     | structural (span/basis shapes required); pointer truth unverified                                                                                                                                                                                 |
+| Invariant 6 (issues namespaced)                                 | §14.1 | **partial**                     | namespace stored, producer unauthenticated                                                                                                                                                                                                        |
+| Invariants 3, 8 (projection loss, equivalent projection)        | §14.1 | **pending**                     | no `project` exists                                                                                                                                                                                                                               |
+| Five proof obligations; smallest-honest + second-binding tests  | §14.2 | **partial**                     | smallest-honest holding; FE-1422 repaired the ask protocol's second-binding failure by moving portable mechanism to core. No literal second binding exists yet                                                                                    |
+| Gating tests (reprojection, minimal pairs, black-box authoring) | §14.3 | **pending**                     | —                                                                                                                                                                                                                                                 |
+| Generation-first fixtures, `arbitraryFromSchema`, `fc.commands` | §14.4 | **pending**                     | both new suites are hand-written examples; no fast-check anywhere. Owned by FE-1384 (FE-1383 slice, backlog)                                                                                                                                      |
+| Open verification items tracked with homes                      | §14.5 | **discharged** (as a mechanism) | `test/open-gaps.ts` deletes claims only with behavioral proof. FE-1392's mounted lifecycle closes `history-refresh-before-sweep` causally and exercises its high-water/repair writes without an instruction wake, closing `wake-wart-write-paths` |
diff --git a/libs/@hashintel/brunch-agent/docs/planning/_shared/flue-architecture-cheatsheet.md b/libs/@hashintel/brunch-agent/docs/planning/_shared/flue-architecture-cheatsheet.md
new file mode 100644
index 00000000000..0147008a202
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/_shared/flue-architecture-cheatsheet.md
@@ -0,0 +1,379 @@
+# Flue architecture cheat sheet
+
+An architect's consolidation of the Flue documentation — all 21 guide entrypoints, fetched
+2026-08-17 — organized by _our_ concerns: the demo shell, the binding boundary, and the
+FE-1383/FE-1357 roadmap. Purpose (Lu's charter): align with recommended patterns and use
+provided affordances _before_ we diverge by building layers we don't need or drawing
+boundaries in the wrong place. Companion to the narrower usage audit
+([`flue-patterns-audit-2026-08-17.md`](../legibility-sweep/flue-patterns-audit-2026-08-17.md)); same caveat —
+WebFetch summarizes, so unquoted API details are paraphrase-grade.
+
+The FE-1391 B1/B2 gate later checked the installed 2.0.3 source, exported types, and
+package-shipped docs directly. Its corrections below are source-grade and link to the
+[source-read record](../legibility-sweep/flue-entry-projection-source-read-2026-08-18.md).
+
+Link form: every page has a markdown mirror at `<url>/index.md`.
+
+---
+
+## 1. App shell & runtime
+
+[project-layout](https://flueframework.com/docs/guide/project-layout/) ·
+[node-target](https://flueframework.com/docs/guide/node-target/) ·
+[deploy](https://flueframework.com/docs/guide/deploy/)
+
+**Affordances**
+
+| Thing                     | What it is                                                                               |
+| ------------------------- | ---------------------------------------------------------------------------------------- |
+| `app.ts`                  | Route map + server entry. Required; convention-discovered                                |
+| `db.ts` / `cloudflare.ts` | Optional convention-discovered entries                                                   |
+| Source-dir resolution     | `.flue/` → `src/` (recommended) → root; first match wins, no merging                     |
+| `flue.config.ts`          | Explicit overrides: entry paths, `providers` allowlist, `target`                         |
+| Multi-agent layout        | `src/agents/<name>/` with per-agent `skills/`, `tools/`, plus `shared/`                  |
+| Build                     | `vite build` → `dist/server.mjs` (self-starting) + `dist/app.mjs` (embeddable)           |
+| Node server               | Port 3000 / `PORT`; production reads env at startup only — **`.env` is dev-only**        |
+| Ownership                 | One live process owns a conversation; leases + expiry scans; multi-replica needs routing |
+
+**Recommended pattern.** Let convention discover the entries; keep explicit config minimal;
+deploy `dist/server.mjs` with a real `db.ts` adapter (in-memory default loses everything).
+
+**For Brunch.** `apps/brunch-agent` matches: `src/app.ts`, `src/db.ts`, `flue.config.ts` with
+`target: 'node'` + `providers: ['anthropic']`. The multi-agent layout (`src/agents/`) is
+already our shape. _Do not rebuild_: the demo shell should be this same layout, not a custom
+server — `dist/app.mjs` exists precisely for embedding if the shell needs a custom host.
+_Boundary implication_: single-owner-per-conversation is a **deployment** constraint, not a
+harness one — it belongs in demo-shell ops notes, not in the binding.
+
+## 2. Agent definition & loop
+
+[building-agents](https://flueframework.com/docs/guide/building-agents/) ·
+[agent-hooks](https://flueframework.com/docs/guide/agent-hooks/) ·
+[models](https://flueframework.com/docs/guide/models/) ·
+[subagents](https://flueframework.com/docs/guide/subagents/)
+
+**Affordances**
+
+| Hook                                                      | Purpose                                                                                                                                                   | We use      |
+| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
+| `useModel(spec, opts?)`                                   | Declares the LLM; fails fast on unknown specifier; opts: `thinkingLevel`, `compaction` (`reserveTokens`, `keepRecentTokens`, `model`)                     | ✓ (no opts) |
+| `useTool`                                                 | Mount a tool                                                                                                                                              | ✓           |
+| `usePersistentState`                                      | Durable per-conversation state; **updater form documented**: "ensures the callback always accesses the latest written value, not a stale render snapshot" | ✓           |
+| `useAgentStart`                                           | "Runs every time a message is delivered to the agent"; async, pre-inference                                                                               | ✓           |
+| `useAgentFinish`, `useResponseStart`, `useResponseFinish` | Lifecycle; `useResponseFinish` receives the response's aggregate token usage                                                                              | ✗           |
+| `useDataWriter`                                           | One-way agent→client structured stream; model never sees it                                                                                               | ✓           |
+| `useInitialData`                                          | Creation-time structured data, recorded once                                                                                                              | ✗           |
+| `useDelivery`                                             | Metadata of the current delivery (from channels guide)                                                                                                    | ✗           |
+| `useSubagent`                                             | Named delegate; own frame, own context window; parent sees **only the final message** via the `task` tool; per-delegate `model`/`thinkingLevel` override  | ✗           |
+| `useSkill`, `useMcpConnection`, `useSandbox`              | See §3                                                                                                                                                    | ✗           |
+
+Render model: the agent function re-runs before every model call and rebuilds instructions
+from scratch (deliberately React-like). Event hook callbacks run **at-least-once** — the docs
+themselves say to guard non-idempotent side effects with persistent state.
+
+**Two audit ambiguities resolved by this page.** The earlier audit (which read the agent-api
+_reference_, not this guide) filed `useAgentStart` firing and updater composition as
+undocumented semantics pinned only by our integration test. The agent-hooks guide documents
+both: per-delivery firing, and the updater-not-snapshot rule. Downgrade both from
+"undocumented bet" to "documented, keep the test as a pin".
+
+**For Brunch.** Our binding is canonical in every hook it touches. Unused affordances
+that map directly onto roadmap items:
+
+- _FE-1392 (settlement trigger)_: `useAgentFinish`/`useResponseFinish` are the documented
+  seam. At-least-once hook execution is exactly why the store's content-keyed sweep dedup
+  exists — the two designs interlock; say so in the ticket.
+- _Capability 6 (private model call)_ has two non-interchangeable affordances. A harness tool can
+  call `harness.prompt(..., { result })` deterministically for private structured scratch work.
+  `useSubagent` instead declares a model-visible `task` delegate with a fresh frame and optional
+  model override; it does not return a directly callable delegate. FE-1392 uses the first shape
+  for deterministic extraction and does not hand-roll a second model client.
+- _FE-1386 (compaction pin)_: the source read retired the discovery spike; `useModel`'s
+  `compaction` options are the knobs for the one residual behavioral boundary-crossing test.
+
+## 3. Capability surface
+
+[tools](https://flueframework.com/docs/guide/tools/) ·
+[mcp](https://flueframework.com/docs/guide/mcp/) ·
+[skills](https://flueframework.com/docs/guide/skills/)
+
+**Affordances**
+
+- `defineTool({ name, description, input, output, run })` — Valibot schemas both ways;
+  invalid input never reaches `run`; result envelope `{ output?, terminate? }`;
+  `terminate: true` ends the turn after the batch settles. Context: `signal`, `log`,
+  `toolCallId`; flags `harness: true`, **`durable: true`** (adds `step`).
+- **Durable tools**: `step.do(name, fn)` — "exactly-once-recorded, at-least-once-executed";
+  completed steps replay their recorded values on recovery. Ordinary tools are _not_
+  re-executed after crashes; they settle as unknown-outcome errors.
+- **Harness prompts**: a `harness: true` tool receives `harness.prompt(prompt, { result, signal })`
+  for a private structured model call. This is a direct call; `useSubagent` is separately
+  model-driven through the reserved `task` tool.
+- Reserved names: `read`, `write`, `edit`, `bash`, `grep`, `glob`, `task`, `activate_skill`,
+  `read_skill_resource`.
+- **Skills**: markdown expertise loaded on demand. Mounted skills appear as name+description
+  in the prompt; the model calls `activate_skill` for full instructions — progressive
+  disclosure that preserves the cached prompt prefix. Supporting files served read-only.
+  `useSkill(import)` or `defineSkill({...})` inline; auto-discovery from
+  `.agents/skills/<name>/SKILL.md`. `useInstruction()` for always-on content.
+- **MCP**: `useMcpConnection({ name, url, auth, tools?, optional? })`;
+  `createMcpConnection()` returns raw `ToolDefinition`s for filtering/wrapping.
+
+**For Brunch.** The ask tool is canonical (validated output part + `terminate`). Three
+do-not-rebuild warnings, one large:
+
+- **FE-1403/FE-1406 (guidance cards, quiver): Flue skills _are_ the card-delivery
+  mechanism.** A kernel card (Detects / Goal / Questions / Artifacts) is a skill with a
+  when-to-use description and on-activation instructions; the activation-probe economy
+  (penciled item 4 — cheap name-only cards vs. expensive content cards) maps exactly onto
+  name+description-in-prompt vs. full-instructions-on-activation. `defineSkill` gives packs a
+  programmatic authoring path. Do not invent a card loader inside the harness; compile packs
+  _to_ skills in the binding.
+- _FE-1392_: if sweep application does side-effectful writes from inside a tool, mark it
+  `durable: true` and wrap the store write in `step.do` — recorded-once semantics compose
+  with (not replace) the store's own dedup.
+- `useInstruction()` exists — instruction assembly in the binding should route through it
+  rather than string-returning alone, when guidance grows past one page.
+
+## 4. Conversation & UI transport
+
+[channels](https://flueframework.com/docs/guide/channels/) ·
+[react](https://flueframework.com/docs/guide/react/) ·
+[routing](https://flueframework.com/docs/guide/routing/)
+
+**Affordances**
+
+- Routing: `createAgentRouter(agent)`; mount path ≠ identity (documented doctrine);
+  HTTP surface = POST `/:id` (202, fire-and-forget) · GET `/:id` (`history` returns one
+  unpaged materialized-message snapshot; `?view=updates&offset=…` pages 100 durable batches
+  and supports SSE/long-poll) · `/:id/abort` · attachments. The framework cannot discover the
+  host-owned mount, so server-side clients need a full conversation URL; custom `fetch` plus
+  router `.fetch` is the candidate in-process composition and still needs an FE-1391 lifecycle
+  pin. Update chunks are SDK/UI protocol, not the supported app consumption surface.
+  `dispatch()` delivers server-side without a mount. Auth is app middleware in `app.ts`.
+- **React: `useFlueAgent()`** — binds one conversation URL to React state: durable-history
+  reconstruction, live streaming, optimistic sends, `status`/`historyReady`. Messages are
+  parts-based: `text`, `reasoning`, **`dynamic-tool`** (validated tool output on `.output`),
+  `file` (ready `url`). Custom client via memoized `createFlueClient()` passed as
+  `{ client }`; the same client also does `observe()`/`wait()`/`read()`.
+- Channels: inbound-only verified ingress → `dispatch` as `kind: 'signal'` with namespaced
+  `type` and `attributes`; outbound stays in app code via provider SDKs.
+
+**For Brunch.** This section carries the single biggest do-not-rebuild finding:
+**`chat.tsx` is a hand-rolled fraction of `useFlueAgent()`.** Our custom fetch/parse loop,
+message filtering, and affordance extraction re-implement what the React package provides —
+including the part we got wrong (the markdown floor, FE-1420): the affordance _is_ the ask
+tool's validated output, delivered as a `dynamic-tool` part whose `.output` is exactly what a
+renderer should switch on, with text parts as the natural fallback. Rebuilding the dev UI (and
+building FE-1385's gallery/probe surface and the demo shell) on `useFlueAgent` deletes our
+transport code and fixes the floor in the same motion. Recommend: adopt at FE-1385 /
+demo-shell time; fold the note into FE-1420 now so the floor fix isn't built twice.
+
+Also: the kickoff non-utterance (FE-1420 comment) has a canonical answer — creation-time
+intent belongs in `useInitialData` (recorded once, structurally non-user) or a dispatched
+`signal`, per the channels pattern. And the harness's own reply-binding signal already matches
+the channels guide's signal shape — convergent with canon.
+
+## 5. Persistence & durability
+
+[database](https://flueframework.com/docs/guide/database/) ·
+[durability](https://flueframework.com/docs/guide/durability/)
+
+**Affordances / guarantees**
+
+- Flue stores exactly three record families: canonical conversation streams (append-only,
+  including compaction and recovery facts), accepted submissions, persisted-state writes.
+  **"Your application should manage its own data store separately."**
+- `migrate()` provisions Flue's tables idempotently, format-versioned; incompatible versions
+  refuse to start.
+- Accepted-work contract: every submission reaches exactly one durable terminal outcome;
+  per-conversation ordering; "at-least-once execution over exactly-once recording".
+  `usePersistentState` writes commit atomically with their unit of work.
+- Not guaranteed: sandbox files, external side effects, local promises (persist the
+  `DispatchReceipt`, re-attach with `read(receipt)`), arbitrary code checkpointing.
+- Compaction: context-overflow compacts and retries the turn. The guide alone does not state the
+  projection consequence, but the installed 2.0.3 source settles it: compaction appends a
+  canonical record, model-context construction substitutes summary plus kept suffix, and the
+  public history projector still walks every message on the active path. Persistent-state
+  reduction is independent. FE-1386 therefore narrows to a behavioral upgrade pin.
+
+**For Brunch.** Canon explicitly endorses the storage-port split: captures are business
+data, Flue's store is the conversation record — the boundary we drew is the boundary the
+database guide draws. Two implications:
+
+- _FE-1391 (archive)_: the durable entry projection we plan to archive is Flue's **public
+  materialized-message projection**, folded from the canonical stream and read with the SDK's
+  `history()` surface. The raw canonical record schema is intentionally not public.
+  Archive-on-read should consume that projection, never shadow-record entries a second time
+  from inside hooks. The spec's line
+  ("the substrate's conversation store is the live transport copy, never the provenance
+  record") is about _retention authority_, not about re-capturing — the archive copies out of
+  the public projection on read, into the target-document's storage.
+- The capture store should adopt Flue's own persistence manners: a `migrate()`-style
+  idempotent, format-versioned provisioning step is the documented precedent for the schema
+  widening FE-1391 needs (session-log archive slot).
+
+## 6. Orchestration
+
+[workflows](https://flueframework.com/docs/guide/workflows/) ·
+[schedules](https://flueframework.com/docs/guide/schedules/) ·
+[sandboxes](https://flueframework.com/docs/guide/sandboxes/)
+
+- Workflows are a _pattern_, not a primitive — no `defineWorkflow`. Four approaches:
+  `flue run` (CI), the JS API (`start()`/`init()`/`dispatch()`/`read()`) for scripts and
+  cron, the SDK (`createFlueClient`) against deployed agents, external durable platforms
+  (Temporal/Inngest/Cloudflare) when orchestration itself must survive interruption.
+- Schedules: platform cron → `dispatch(agent, { id, message })` (resolves on durable
+  admission, not completion); signal-shaped delivery; fixed vs per-fire conversation ids;
+  node fires are skipped during downtime.
+- Sandboxes: virtual (in-memory bash emulation) / `local()` (no isolation; allowlisted env) /
+  remote providers. Agents without one keep tools, skills, subagents.
+
+**For Brunch.** The baseline runner is the JS-API workflow pattern, independently
+converged. FE-1404 (armed rerun) should be exactly that: a script over `start()` + `init()`
+(fresh ids per condition) + `read()`, with `observe()` doing the accounting (§7). No sandbox
+anywhere in our current or foreseeable surface — elicitation needs no file tools; keep it
+that way (narrowest environment is the documented advice).
+
+## 7. Quality: evals & observability
+
+[evals](https://flueframework.com/docs/guide/evals/) ·
+[observability](https://flueframework.com/docs/guide/observability/)
+
+- Evals: in-process `start()` + `init(agent)` (no id → fresh conversation) + `read()`;
+  `reply.text`, `reply.data` (data-writer output), `onEvent` for tool-call capture;
+  `AgentRunError` on failed runs. HTTP alternative via `createFlueClient` + `history()`.
+  Convention: `src/evals/*.eval.ts`, separate vitest config, longer timeouts; real-model
+  evals assert behavioral contracts, never strings; `vitest-evals` judges
+  (`FactualityJudge`, `createJudge`) for semantic scoring.
+- Observability: `observe()` event stream (in-process, live-only) — model requests, tool
+  executions, logs, **`turn` events with `input`/`output`/`cacheRead`/`cacheWrite`/
+  `totalTokens`/`cost`**; `useResponseFinish` for in-agent aggregate usage;
+  `@flue/opentelemetry` via `instrument(...)`; Sentry/Braintrust integrations.
+
+**For Brunch.** Our faux-provider + fetch-shim + child-process eval is a composition of
+documented parts (audited; the child-process shape was originally forced by the Bun runtime and
+is retained under Node/Vitest). Adoptable affordances we currently ignore:
+`init()` without an id (simpler than UUID mounts for future in-process evals); `onEvent`
+tool capture (stronger than substring checks over stringified history — a direct upgrade
+path for the walking-skeleton's weaker oracles); `observe()` for _all_ token/cost accounting
+in FE-1404 and any experiment runner — never hand-count again; judges for FE-1407's scoring
+instrument (the failure catalogue becomes `createJudge` rubrics). _Do not rebuild_: no custom
+event tap, no custom cost meter, no custom judge harness.
+
+## 8. Cloudflare target (contingency)
+
+[cloudflare-target](https://flueframework.com/docs/guide/cloudflare-target/)
+
+If the demo shell ever deploys there: one generated Durable Object per agent (`agentName`
+pinning matters — already our practice), per-object SQLite replaces `db.ts` (**source-root
+db config is rejected at build time** — our `LocalCaptureStore`'s file-path assumption
+becomes binding-swap territory, which is what the storage port is for), `nodejs_compat`
+required, CPU limits per invocation, schedules move to `wrangler.jsonc` crons in UTC, no
+in-process `observe()` habits — native Workers Traces instead. Spec §12.5's remote-parity
+constraints (pinned identity, storage outside plugin, no dynamic agents) are exactly the
+things this page confirms as load-bearing. Nothing to do now; this section exists so nobody
+builds a node-only assumption into a _harness_ layer — node-only assumptions belong in
+bindings and deployment config.
+
+---
+
+## Boundary design summary
+
+Flue's affordance surface sorts our system into three lanes, and the binding line belongs
+between the second and third:
+
+1. **Consume directly (no wrapping).** UI transport (`useFlueAgent`, `createFlueClient`,
+   the HTTP surface), observability (`observe`, OTel), eval harnessing (`init`/`read`,
+   judges), scheduling, deployment. These are _shell-facing_ affordances: the demo shell,
+   dev app, and experiment scripts should use them natively. Wrapping them in our binding
+   would be a parallel SDK — lens-2 debt at the API level.
+2. **Translate in the binding (current capabilities list — correct).** The agent-loop
+   capabilities: tool registration, instruction assembly, persistent state, affordance
+   emission, suspend-for-reply, private model call (`harness.prompt` for deterministic structured
+   work; `useSubagent` for model-driven delegation), entry-projection read, durable store hosting.
+   The binding's job stays translation of harness semantics into hook
+   dialect — and the hooks guide now documents the two semantics we depend on.
+3. **Own outright (harness + storage port).** Elicitation semantics and the capture store:
+   envelope invariants, settlement judgment, sweep idempotence, provenance verification,
+   completion. Canon agrees — "your application should manage its own data store separately."
+
+**Divergence risks, ranked:**
+
+1. **The parallel chat client.** `chat.tsx` grows feature-by-feature into a hand-rolled
+   `useFlueAgent`. Adopt the React package at FE-1385/demo-shell; route FE-1420's markdown
+   floor through `dynamic-tool` parts.
+2. **Sweep machinery ignoring private harness prompts + durable tools.** FE-1392 built as
+   in-conversation prompting with a bare store write would leak extraction into the interview and
+   discard the crash-safe side-effect boundaries that `harness.prompt` and `step.do` provide.
+3. **Cards as a bespoke loader.** FE-1403/FE-1406 inventing pack-content delivery when
+   skills' `activate_skill` progressive disclosure is the documented mechanism with the right
+   economics.
+4. **The archive shadow-recording the stream.** FE-1391 re-capturing entries inside hooks
+   instead of archiving the public materialized `history()` projection — two copies of the
+   conversation, one drifting. The public projection is not the private canonical record
+   schema; stable message IDs or archive ordinals must supply pointer identity.
+   Repeated snapshots may carry a still-materializing message under the same ID, so the archive
+   also needs identity-keyed merge/version semantics rather than snapshot append.
+5. **Hand-rolled accounting/oracles in experiments.** FE-1404/FE-1407 re-counting tokens or
+   substring-matching histories when `observe()`, `onEvent`, and judge harnesses exist.
+
+## Reconciliation with the Flue-vs-tilde analysis (2026-08-14)
+
+The comparative analysis at [`../../reference/amp-analysis-flue-vs-tilde.md`](../../reference/amp-analysis-flue-vs-tilde.md)
+read Flue's _source and changelog_, not only the guides, so where it speaks it carries higher
+evidence grade than this sheet's paraphrase-level doc reads. Reconciled 2026-08-17; no
+contradictions found — the analysis's verdict (keep Flue; Tilde is a hosted control plane, not
+a runtime; the capture store stays application-owned under any future) matches this sheet's
+boundary summary independently. Four source-level facts it adds that the guides state weakly
+or not at all:
+
+- **Pre-remote-exposure gates.** The mounted Flue route is public — no authentication or
+  per-conversation authorization exists. Before the demo shell is exposed remotely: auth +
+  per-conversation authorization, runtime telemetry, persisted-state versioning/backup
+  expectations, and the restart-durability gap (FE-1396) closed. All four are ticketed as
+  FE-1423 (FE-1396 blocks it), ratified as requirements 2026-08-17. (Routing row: "you're
+  about to expose the demo remotely".)
+- **Churn risk is measured, not vibes.** 2.0.0 was an architectural rewrite days before the
+  current 2.0.3, and persisted beta stores are rejected with **no migration path**. Pin
+  versions deliberately; re-verify the walking-skeleton-pinned semantics at every upgrade;
+  treat docs' future-tense claims as unshipped.
+- **The at-least-once floor is universal.** Exactly-once-_recorded_, at-least-once-_executed_
+  holds on both targets, and `step.do` checkpointing cannot make an external effect
+  once-only — which is the source-level argument for why the capture store's content-keyed
+  dedup is load-bearing rather than defensive.
+- **Skills ride the Vite build graph** (`SKILL.md` imports are build-resolved) and will not
+  load under plain test runners — a real constraint on risk 3's "cards compile to skills"
+  path: FE-1403/FE-1406 card content must stay assertable outside the graph (fixture-grade
+  copies or eval-config runs), or the card tests go vacuous.
+
+## Sources
+
+All fetched 2026-08-17 in `index.md` mirror form; **all 21 succeeded, no failures, no
+retries needed**:
+
+- https://flueframework.com/docs/guide/project-layout/index.md
+- https://flueframework.com/docs/guide/building-agents/index.md
+- https://flueframework.com/docs/guide/agent-hooks/index.md
+- https://flueframework.com/docs/guide/models/index.md
+- https://flueframework.com/docs/guide/tools/index.md
+- https://flueframework.com/docs/guide/mcp/index.md
+- https://flueframework.com/docs/guide/skills/index.md
+- https://flueframework.com/docs/guide/subagents/index.md
+- https://flueframework.com/docs/guide/sandboxes/index.md
+- https://flueframework.com/docs/guide/routing/index.md
+- https://flueframework.com/docs/guide/database/index.md
+- https://flueframework.com/docs/guide/deploy/index.md
+- https://flueframework.com/docs/guide/workflows/index.md
+- https://flueframework.com/docs/guide/schedules/index.md
+- https://flueframework.com/docs/guide/channels/index.md
+- https://flueframework.com/docs/guide/evals/index.md
+- https://flueframework.com/docs/guide/observability/index.md
+- https://flueframework.com/docs/guide/durability/index.md
+- https://flueframework.com/docs/guide/react/index.md
+- https://flueframework.com/docs/guide/cloudflare-target/index.md
+- https://flueframework.com/docs/guide/node-target/index.md
+
+Caveat as ever: WebFetch reads through a summarizing intermediary; API names quoted here
+matched across pages and against our working code, but load-bearing signatures should be
+confirmed against the raw page (or `node_modules` types) before implementation.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/_shared/hash-monorepo-import-plan.md b/libs/@hashintel/brunch-agent/docs/planning/_shared/hash-monorepo-import-plan.md
new file mode 100644
index 00000000000..ef19fcd9196
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/_shared/hash-monorepo-import-plan.md
@@ -0,0 +1,322 @@
+# HASH monorepo import plan
+
+**Status:** recommended execution plan for FE-1437 (the monorepo import). This is a bounded
+cross-effort plan: it settles as a record when `hashintel/hash` is the sole writable authority for
+Brunch. [ADR-0004](../../adr/0004-in-petrinaut-staging-and-the-monorepo-import.md) owns the accepted
+decision to move; [COORDINATION](./COORDINATION.md) owns the live handoff threshold and sequencing.
+
+## Recommendation
+
+Assimilate Brunch into HASH's Yarn/Turbo workspace as native child workspaces of one Brunch
+context root. Preserve the current package boundaries; do not preserve the current Bun workspace
+as a nested monorepo and do not collapse it into one implementation package.
+
+The current workspaces are architectural modules, not a repository boundary that must survive.
+Their tested direction remains useful after HASH becomes their workspace root:
+
+```text
+libs/@hashintel/brunch-agent/                 # context and agent-session root; not a workspace
+├── CONTEXT.md
+├── docs/
+├── .agents/
+├── .claude/
+└── packages/
+    ├── core/                                 # @hashintel/brunch-agent
+    ├── binding-flue/                         # @hashintel/brunch-agent-binding-flue
+    ├── transport-aisdk/                      # @hashintel/brunch-agent-transport-aisdk
+    └── plugin-gherkin/                       # @hashintel/brunch-agent-plugin-gherkin
+
+apps/brunch-agent
+  package: @apps/brunch-agent
+  role: remote server, application wiring, local diagnostics
+                                 |
+                         HTTP / AI SDK stream
+                                 |
+                                 v
+apps/petrinaut-website --------> libs/@hashintel/petrinaut
+```
+
+`apps/petrinaut-website` is the compile-time meeting place. The Brunch packages remain
+renderer-agnostic; `@hashintel/petrinaut` remains elicitor-agnostic; and `@apps/brunch-agent`
+remains Petrinaut-independent. The server and website meet only through the AI SDK/HTTP transport.
+The website owns the client mode, host-supplied interactive tool definitions, and remote transport
+wiring.
+
+## Package ownership and public surface
+
+Use `@hashintel` for every reusable Brunch package whose contract is intended to work outside the
+HASH applications. Use `@local` only for code whose contract is meaningful inside `hashintel/hash`
+and nowhere else. Package scope and publication state are separate decisions: HASH already
+contains private packages under `libs/@hashintel/`, so an `@hashintel` name does not require
+publishing during the import.
+
+Here **supported package** means a named, installable boundary that the Brunch maintainers own,
+document, and include in build and boundary gates. It does not promise publication, semantic
+version stability, or external support while `private: true` remains set.
+
+| HASH path                                               | Package                                   | Owned contract                                                                    | Import posture  |
+| ------------------------------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------- | --------------- |
+| `libs/@hashintel/brunch-agent/packages/core`            | `@hashintel/brunch-agent`                 | Harness mechanism, substrate-neutral protocols, storage port, plugin SDK          | `private: true` |
+| `libs/@hashintel/brunch-agent/packages/binding-flue`    | `@hashintel/brunch-agent-binding-flue`    | Flue binding and current local-file storage implementation                        | `private: true` |
+| `libs/@hashintel/brunch-agent/packages/transport-aisdk` | `@hashintel/brunch-agent-transport-aisdk` | AI SDK UI-message-stream transport                                                | `private: true` |
+| `libs/@hashintel/brunch-agent/packages/plugin-gherkin`  | `@hashintel/brunch-agent-plugin-gherkin`  | Gherkin target plugin and reference implementation                                | `private: true` |
+| `apps/brunch-agent`                                     | `@apps/brunch-agent`                      | Deployment, authentication, environment configuration, HTTP mounting, diagnostics | always private  |
+
+This placement follows the intended portability:
+
+- A consumer should be able to install the harness with only the binding, transport, and plugins
+  its deployment needs.
+- Binding and transport packages are part of how Brunch supports different substrates and UI
+  shells; treating them as `@local` would falsely describe them as HASH-only wiring.
+- FE-1437 moves the existing local-file store with the Flue binding. FE-1441 separately decides and
+  adds the Postgres implementation behind the unchanged storage port. An environment-neutral
+  implementation belongs to the binding; HASH credentials, deployment manifests, and
+  environment-specific composition stay in `@apps/brunch-agent`.
+- No `@local` Brunch package is created during the import merely to defer a publication decision.
+
+### Export and dependency rules
+
+1. `@hashintel/brunch-agent` names the current `core` contract. It does not re-export bindings,
+   transports, plugins, or application code through an umbrella facade.
+2. Each extension package has its own explicit exports and depends inward on
+   `@hashintel/brunch-agent`; core never imports an extension package.
+3. Plugins import core only. Bindings import core and their substrate. Transports import core and
+   their wire library, never a binding.
+4. `apps/brunch-agent` composes the Brunch packages and remains Petrinaut-independent.
+   `apps/petrinaut-website` is the only compile-time Brunch–Petrinaut composition point.
+5. The existing role nouns (`binding-*`, `transport-*`, `plugin-*`) remain in the package names so
+   dependency direction stays legible.
+
+ADR-0004's singular `@hashintel/brunch-agent` name remains the harness package. Its amendment makes
+the companion package family explicit; it does not turn the harness into an umbrella package.
+
+All four libraries remain `private: true` through FE-1437. Publishing is a later, independent
+release decision: remove `private` only when there is a named consumer and a reviewed versioned
+contract. At that point HASH's normal Changesets process and `workspace:^` rule apply. Deferring
+publication must not force another namespace or directory migration.
+
+## Application disposition
+
+The accepted end state re-charters the standalone `apps/dev` as HASH's `apps/brunch-agent`: the
+remote server application carrying forward the target-gallery and diagnostic-surface charter as
+internal operational roles.
+The imported [route map](../../../../../../apps/brunch-agent/src/app.ts) mounts the Flue agent
+router, the Petrinaut chat transport, and the production diagnostic assets. Re-chartering that
+application avoids a second app around those same routes.
+
+ADR-0004, ADR-0002 N3, the kernel spec, and FE-1437 record that re-charter explicitly as of the
+cutover preparation. If the deployed server later proves to require a materially different
+runtime, that evidence can justify a second app then.
+
+## Authority threshold
+
+The import is an authority handoff, not a freeze on all harness development:
+
+```text
+brunch-lite authoritative
+  FE-1434 + FE-1435 verdicts landed
+  FE-1388/1389/1390/1399 review stack merged
+                    |
+                    v
+          == FE-1437 import ==
+                    |
+                    v
+hashintel/hash authoritative
+  FE-1440 website wiring + FE-1441 deployment
+```
+
+FE-1438 (client-tool round-trip) and FE-1439 (private durable sessions) may land before FE-1437 and
+travel with the imported history. The write freeze occurs when the final standalone head SHA is
+recorded and its history-import commit is created on the FE-1437 HASH branch. From that point,
+unfinished work continues only in HASH; after FE-1437 lands, HASH is the canonical repository.
+There is no dual-write period or compatibility bridge between repository layouts.
+
+## Execution plan
+
+### 1. Prepare the cutover
+
+- Satisfy the gates in `COORDINATION.md` and take a final green baseline in `brunch-lite`.
+- Amend ADR-0004 and FE-1437 to clarify the package family and the `apps/dev` re-charter.
+- Record the final standalone `main` SHA, then stop accepting new standalone changes before
+  creating the history-import commit. If that SHA must change, regenerate the import before any
+  HASH-side semantic work proceeds.
+
+### 2. Import history without creating a permanent subtree
+
+- Create a disposable clone of `brunch-lite`; never rewrite the shared checkout. The import input
+  is the complete ancestry of the recorded `main` SHA, including its merge commits. Unmerged
+  branches, pull-request refs, and unrelated tags are not inputs unless the preparation step names
+  one explicitly.
+- Prefix that ancestry under a temporary path such as `imports/brunch-agent` using
+  `git filter-repo --refs refs/heads/main --to-subdirectory-filter imports/brunch-agent`.
+- Merge that history into the FE-1437 branch of `hashintel/hash` without squashing.
+- Format the imported files with HASH's mandatory formatter before moving them; the pre-commit
+  hook otherwise combines formatting with the path change.
+- Move each implementation and test tree to its final
+  `libs/@hashintel/brunch-agent/packages/*` or `apps/brunch-agent` path. Move and convert manifests
+  in the native-workspace registration commit because HASH's pre-commit Yarn validation requires a
+  matching lockfile as soon as a manifest enters workspace discovery.
+- Run `git blame` and `git log --follow` on one pre-existing source file and one pre-existing test
+  file from each of the five moved workspaces. Every sample must reach a pre-import commit.
+
+This is a one-time history merge, not an ongoing `git subtree`, submodule, or synchronization
+relationship.
+
+### 3. Dispose of repository-level material deliberately
+
+- Use `docs/INDEX.md` plus the tracked files outside `apps/`, `packages/`, and `test/` as the
+  disposition inventory. For every entry, record one outcome in the FE-1437 work: move to a named
+  HASH path, retain as an explicitly historical record, or remove after import with a reason.
+- The named context root is `libs/@hashintel/brunch-agent/`; it is not a workspace and has no
+  package manifest or lockfile. Its `docs/` directory is the home for living documentation. Move
+  there
+  everything that still governs the imported code: ADR-0002 (the placement rules behind the
+  boundary gates), ADR-0004, the amended kernel spec, and this plan's own settled record. Keep
+  `CONTEXT.md` at the context root and link this home from every package README.
+- Re-home the cross-effort control surfaces that remain live after the handoff to the same home.
+  At import time FE-1440, FE-1441, and FE-1442 are still open, so `COORDINATION.md` and
+  `SPEC-LEDGER.md` qualify. Historical planning need not remain live.
+- The agent working methods (`AGENTS.md`, `CLAUDE.md`, the `docs/agents/*` protocols, the
+  `arc-close` skill, and the INDEX gate in `test/docs-index.test.ts`) receive an explicit
+  recorded decision rather than disposal by omission: either re-author them under HASH's own
+  agent-guidance conventions, or retire them and restate the practices that outlive this
+  repository — the issue-writing contract, triage roles, and documentation protocol govern the
+  Linear-side work regardless of where the code lives. Re-author them as the context's operating
+  surface without creating a nested package-manager root.
+- Do not carry standalone CI, Bun lockfiles, or repository setup forward.
+- The disposition is complete only when every inventory row resolves to its recorded destination
+  or removal commit. Removing a file after the mechanical import does not remove its Git history.
+
+#### Repository-level disposition inventory
+
+Paths below are relative to the repository root. A directory pattern covers every indexed child;
+the import review checks the expanded tracked-file list against these rows before removal.
+
+| Standalone material                                    | Disposition in `hashintel/hash`                                                                                                                                                                                     |
+| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `CONTEXT.md`                                           | Move to `libs/@hashintel/brunch-agent/CONTEXT.md`; remains the Brunch context glossary.                                                                                                                             |
+| `docs/adr/*.md`                                        | Move to `libs/@hashintel/brunch-agent/docs/adr/`; all four decisions still govern imported code.                                                                                                                    |
+| `docs/planning/elicitation-kernel/spec.md`             | Move to `libs/@hashintel/brunch-agent/docs/spec.md`; remains the package contract.                                                                                                                                  |
+| Other `docs/planning/elicitation-kernel/**`            | Retain under `libs/@hashintel/brunch-agent/docs/history/planning/elicitation-kernel/` as the settled design record.                                                                                                 |
+| `docs/planning/process-model-elicitation/**`           | Move to the same relative path under `libs/@hashintel/brunch-agent/docs/`; the FE-1357 effort and its open issues remain live after import.                                                                         |
+| `docs/planning/_shared/**`                             | Move to the same relative path under `libs/@hashintel/brunch-agent/docs/`; settle this import plan after FE-1437 lands, while the other control documents keep their declared lifetimes.                            |
+| `docs/planning/legibility-sweep/**`                    | Move to the same relative path under `libs/@hashintel/brunch-agent/docs/`; preserve each indexed document's active or settled status until its owning issue closes.                                                 |
+| `docs/reference/**`                                    | Move to `libs/@hashintel/brunch-agent/docs/reference/`; preserve provenance and existing consumers.                                                                                                                 |
+| `docs/INDEX.md`                                        | Re-author as `libs/@hashintel/brunch-agent/docs/INDEX.md` over the moved living and historical set.                                                                                                                 |
+| External canonical entries in `docs/INDEX.md`          | Preserve their URLs and `external` status in the re-authored INDEX; no external document is copied into HASH.                                                                                                       |
+| `docs/agents/**`                                       | Re-author under `libs/@hashintel/brunch-agent/docs/agents/` for HASH paths and `gh stack`; preserve the issue-writing, triage, documentation, domain, posture, legibility, arc-close, and Flue-routing disciplines. |
+| `AGENTS.md`, `CLAUDE.md`                               | Re-author as context-local guidance at `libs/@hashintel/brunch-agent/`; defer to HASH root guidance and link the re-homed agent protocols. Add pointer files under `apps/brunch-agent/`.                            |
+| `.agents/skills/arc-close/SKILL.md`                    | Re-author under the context root and mirror it under `.claude/skills/arc-close/`; the wrapper delegates to the canonical `docs/agents/arc-close.md`.                                                                |
+| `test/docs-index.test.ts`                              | Port to the imported package test suite and point it at the re-authored package index.                                                                                                                              |
+| `scripts/linear-project-graph.ts`                      | Move to `libs/@hashintel/brunch-agent/scripts/linear-project-graph.ts`; retain project-registry auditing while `brunch-agent` remains the Linear ownership boundary.                                                |
+| `.github/workflows/ci.yml`                             | Remove after HASH tasks and CI gates cover the imported workspaces; do not nest standalone CI.                                                                                                                      |
+| `bun.lock`, `bunfig.toml`, root `package.json`         | Remove after HASH manifests and lockfile install successfully; do not retain a nested workspace root.                                                                                                               |
+| `.oxfmtrc.json`, `tsconfig.base.json`, `tsconfig.json` | Remove after each workspace adopts HASH's formatter and TypeScript conventions.                                                                                                                                     |
+| `.gitignore`                                           | Remove after any still-relevant package-local patterns are represented by HASH's ignore rules.                                                                                                                      |
+| `docs/inbox/.gitkeep`                                  | Remove; HASH already supplies the repository root and an empty standalone inbox has no content to preserve.                                                                                                         |
+
+### 4. Adopt the HASH toolchain
+
+- Convert manifests to native HASH workspaces and the package names above.
+- Use `workspace:*` while packages are private. Do not add exceptions to HASH's dependency
+  constraints merely to preserve standalone-repo versions.
+- Replace `bun:test` with Vitest and replace the small number of Bun runtime APIs with Node or web
+  platform equivalents.
+- Adopt HASH's package-level TypeScript, oxlint, Vite/Vitest, and Turbo task conventions rather
+  than wrapping the old root scripts. Every imported library exposes `build`, `lint:eslint`,
+  `lint:tsc`, and `test:unit`; the app exposes the same four tasks plus its normal `dev` task.
+- Reconcile dependency versions through HASH's constraints. The AI SDK wire package already
+  matches the website's AI SDK major. Flue and Valibot do not yet exist in HASH: add their required
+  versions to the imported manifests, run `yarn lint:constraints`, and resolve any conflict rather
+  than adding a Brunch-specific constraint exemption.
+- Remove `bun.lock`, `bunfig.toml`, Bun-specific root configuration, and the old workspace root
+  only after their HASH replacements run.
+
+### 5. Preserve architectural enforcement
+
+Port the current
+[boundary suite](../../../packages/core/test/architecture/boundaries.test.ts) and its
+[workspace scanner](../../../packages/core/test/architecture/workspace.ts) instead of replacing them
+with prose:
+
+- Keep the manifest and source-import checks that enforce plugin/core, binding/core/substrate, and
+  transport/core/wire directions.
+- Adapt package discovery and expected names to HASH paths and scopes.
+- Use `yarn.config.cjs` constraints for declared workspace relationships and the ported source
+  scanner for actual imports.
+- Do not claim that forbidden third-party imports physically cannot resolve under HASH's hoisted
+  `node_modules` linker. The current Bun resolver proof depends on isolated installation; replace
+  that portion with an honest gate over manifests and source imports rather than a green false
+  equivalent.
+- Retain the fail-loud Flue entrypoint checks: directive placement, pinned agent identity, mount,
+  and storage entry. Port the
+  [bundle assertions](../../../../../../apps/brunch-agent/test/build-artifact.test.ts) that prove the
+  emitted server registers every agent, mounts the router and conversation store, carries no model
+  key, and that emitted HTML points to a built client asset.
+- Prove the negative oracle once during the move by temporarily adding an `@flue/runtime` import to
+  the Gherkin plugin in the disposable import worktree: the targeted boundary test must fail, then
+  pass again after the mutation is removed.
+
+### 6. Complete FE-1437 before integrating the applications
+
+FE-1437 is complete when the imported package family builds and tests natively in HASH, history is
+traceable, and the architectural gates hold. The application runtime proof ports
+`apps/dev/test/petrinaut-chat.test.ts`: POST the existing conversation fixture through the mounted
+application route with the faux provider and assert the AI SDK stream, without a Petrinaut website
+checkout. Keep the following in later issues:
+
+- FE-1440 commits the Petrinaut website's elicitor mode and transport switch.
+- FE-1441 adds HASH deployment, Postgres-backed storage, rate limiting, and origin policy.
+- Publication of any Brunch package remains separate from both the import and demo deployment.
+
+### 7. End standalone authority
+
+- Mark `hashintel/hash` as the canonical source in the old repository's landing page.
+- Close or redirect automation that could accept new standalone changes.
+- Archive the old repository only after the HASH branch is landed and the history checks pass.
+
+These are shared-state actions and require explicit approval when FE-1437 executes them.
+
+## Verification gates
+
+| Gate        | Required evidence                                                                                            |
+| ----------- | ------------------------------------------------------------------------------------------------------------ |
+| Baseline    | Standalone lint, format, typecheck, all tests, and build pass at the recorded import SHA                     |
+| Workspace   | HASH install and constraints pass with no Brunch-specific exemption                                          |
+| Packages    | Each Brunch workspace exposes and passes `build`, `lint:eslint`, `lint:tsc`, and `test:unit`                 |
+| Boundaries  | A temporary Gherkin-plugin → Flue import fails the targeted gate; the restored tree passes                   |
+| Runtime     | The application builds both bundles and the faux-provider POST passes through its mounted conversation route |
+| History     | One source and one test file from every moved workspace reach pre-import commits by blame and follow-log     |
+| Removal     | No Bun lockfile, nested workspace root, or Bun runtime/test import remains                                   |
+| Integration | FE-1440 separately proves the real Petrinaut website against the imported server                             |
+
+## Trade-offs
+
+**What native assimilation buys**
+
+- Atomic changes across Brunch, Petrinaut, and the website.
+- One dependency policy, lockfile, CI graph, security-update path, and deployment environment.
+- No publishing or local-link ceremony for product integration work.
+- Package boundaries remain explicit while cross-package refactors become easier.
+
+**What it costs**
+
+- A one-time Bun-to-HASH tooling port.
+- A larger install, CI, and review context for Brunch-only work.
+- Root dependency constraints may expose Flue, Vite, React, or schema-library conflicts.
+- The standalone repository's focused iteration loop is replaced by HASH's broader governance.
+- The history import and document disposition require a deliberately staged review.
+
+## Alternatives not recommended
+
+| Alternative                                            | When it would be better                                                                      | Why it is not the current choice                                                        |
+| ------------------------------------------------------ | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
+| Keep Brunch separate behind HTTP or published packages | Independent ownership, release cadence, deployment lifecycle, or external consumers dominate | Reverses ADR-0004 and loses atomic work across the current product seam                 |
+| Collapse everything into `@hashintel/brunch-agent`     | The package boundaries prove ceremonial and there is one enduring consumer                   | Erases currently tested substrate/plugin/transport directions                           |
+| Nest the Bun monorepo inside HASH                      | Very short-lived import staging only                                                         | Creates two package managers, lockfiles, task graphs, and ambiguous workspace discovery |
+| Git submodule or permanent subtree                     | Source must remain independently authoritative                                               | Preserves the cross-repository coordination cost the move is intended to remove         |
+
+The reconsideration trigger is concrete evidence of independent product life: a separate owner,
+release cadence, external consumer base, or runtime that must deploy independently of HASH. Without
+that evidence, native workspaces with the reusable package family under `@hashintel` are the
+smallest coherent end state.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/_shared/topology.md b/libs/@hashintel/brunch-agent/docs/planning/_shared/topology.md
new file mode 100644
index 00000000000..3d4351c5411
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/_shared/topology.md
@@ -0,0 +1,115 @@
+# Topology: verification and specification
+
+**Status: ratified 2026-08-17 (Lu) — recorded as [ADR-0002](../../adr/0002-topology-and-placement-rules.md);
+this file remains the living reference.** Verifies
+the current app/package topology against the three-lane model (cheatsheet, boundary summary),
+spec §12.2, and Flue's project-layout guide; then specifies where upcoming work lands. Pseudo-
+style: tree nodes with rules; `✓` complies today, `✗` violates, `→` normative rule for what's
+next.
+
+## Verification — the tree as it stands
+
+```text
+packages/core                      LANE 3 (harness; substrate-free)
+├─ capture-store.ts   ✓  the storage port's contract + pure command surface; owns envelope
+│                        invariants. Never: substrate imports, IO, per-substrate shapes.
+├─ session-log.ts     ✓  substrate-neutral archive/version/anchoring rules; archive ordinals
+│                        are evidence identity, substrate ids remain provenance only.
+├─ storage.ts         ✓  binding-only storage support subpath; not part of the plugin SDK.
+├─ affordance.ts      ✓  envelope schemas (free-text form)
+├─ naming.ts          ✓  identity/tool-name policy (ADR-0001)
+├─ plugin.ts          ✓  plugin identity + one declared proposal floor (FE-1392); grows the
+│                        full catalog/tables/ops contract at FE-1393
+├─ testing/           ✓  test utilities subpath (mirrors Flue's own store-contract pattern)
+├─ ask-protocol.ts    ✓  substrate-free ask/suspension mechanism: affordance minting, guard,
+│                        reply-binding signal, and instruction fragments (FE-1422). See N1.
+└─ sweep-protocol.ts  ✓  substrate-free settlement/sweep mechanism: trigger/high-water facts,
+                         replayable settled range, repair continuation, quote-only extraction,
+                         and affordance-bound accounting advisories (FE-1392). See N1.
+
+packages/binding-flue              LANE 2 (translate harness ↔ Flue dialect)
+├─ capabilities.ts    ✓  capability declaration — the binding's contract-of-record
+├─ history-reader.ts  ✓  public SDK `history()` mapping over a host-injected URL resolver/fetch;
+│                        non-writing peek + binding-private archive refresh; no private
+│                        canonical/update-chunk vocabulary.
+├─ archive-capability.ts ✓ binding-private write capability; callers holding `CaptureStore`
+│                        cannot inject pre-classified archive entries.
+├─ capture-accounting.ts ✓ recovers active-session Flue ids from session-qualified archived
+│                        evidence pointers; contains no accounting policy.
+├─ index.ts           ✓  useElicitation is Flue HOOK WIRING (useTool, usePersistentState,
+│                        useAgentStart/useAgentFinish, useDataWriter, harness.prompt, durable
+│                        step.do, ctx.append) and calls core's ask/sweep protocols (FE-1422/92).
+│                        Never: elicitation semantics, store rules, prompt content.
+└─ local-capture-store.ts ✓ versioned storage-port implementation (capture store + session-log
+                         archive, legacy provisioning, parse-on-read, tmp+rename, per-path
+                         queue). One per deploy target per binding. Never: business rules.
+
+packages/transport-aisdk           UI REPLY WIRE (substrate-neutral)
+└─ index.ts            ✓ validates Petrinaut's POST, drives an application-supplied harness turn,
+                         and encodes
+                         harness reply events with `ai` only. Opt-in inspection emits metadata
+                         out-of-band. Never: binding/Flue imports, inference, conversation
+                         rendering, or diagnostics dispatched as user evidence.
+
+packages/plugin-gherkin            LANE 3 (target policy)
+└─ index.ts           ✓  identity + one `statement-noted` ConditionStated verbatim floor;
+                         strict schema forbids parsed structure and silent hardening.
+                         Never: harness mechanism, substrate imports, storage.
+
+apps/brunch-agent                  LANE 1 SHELL + remote server (imported from apps/dev)
+├─ src/app.ts         ✓  single fetch entry; explicit mounts; assets beside agents
+├─ src/routes.ts      ✓  the one shared mount constant (doctrine per routing guide)
+├─ src/agents/gherkin-elicitor.ts ✓ thin directive-marked host (§12.1); flat file OK until
+│                        the second agent (then per-agent folders, FE-1385)
+├─ src/elicitation-session.ts, target-document-path.ts ✓ host-owned session/document binding,
+│                        full mount URL/transport, and opaque local target path
+├─ src/petrinaut-chat.ts ✓ thin Flue→harness-event→AI SDK composition; `/api/chat` mount and
+│                        opt-in JSONL inspection. No second conversation renderer.
+├─ src/db.ts, db-path.ts ✓ convention entry + separately testable path logic, deliberately split
+├─ src/ui/chat.tsx    ~  hand-rolled client; tolerated ONLY until FE-1385 adopts @flue/react
+│                        (divergence risk 1). Never: growing new part-rendering features here.
+└─ test/              ✓  reviewed substrate inventory; child-process eval (audited: composed
+                         from documented parts; do-not-weaken pins live here)
+
+docs/planning/**/baseline/run.ts   EXPERIMENT (JS-API workflow pattern, independently converged)
+```
+
+## Specification — where what's next lands
+
+- **N1 (the structural repair, discharged by FE-1422 + FE-1392).**
+  `packages/core/src/ask-protocol.ts` now owns pure affordance minting, the one-live guard,
+  reply-binding signal payload, and instruction fragments. `packages/core/src/sweep-protocol.ts`
+  owns range selection, trigger/repair decisions (including reopening the loop guard after a
+  refusal), prompt content, and advisory semantics;
+  `useElicitation` contributes only Flue projection, hooks, persistent-state, private-prompt,
+  refresh, and durable-step wiring. A future `binding-pi` reuses both protocol modules.
+- **N2 (packs and cards).** Plugin-owned content lives in plugin packages, exported as
+  `defineSkill`-compatible definitions; the app's agent module _registers_ what the plugin
+  exports. Never per-agent `skills/` dirs holding plugin content in the app — that puts lane-3
+  policy inside lane-1, invisible to the boundary gates. Quiver (FE-1406) content is
+  harness-shipped: same rule, exported from core (or a `packages/quiver`), registered by hosts.
+  Card content stays assertable outside the Vite graph (fixture-grade copies; B4's probe
+  decides the exact shape).
+- **N3 (application composition; amended by ADR-0004 / FE-1437).** There is no dedicated demo
+  shell. The standalone `apps/dev` was imported as `apps/brunch-agent`, which owns the remote
+  Brunch server, target gallery, and diagnostics. `apps/petrinaut-website` owns the user-facing
+  integration.
+  Applications may compose Brunch and Petrinaut public surfaces; reusable libraries may not know
+  about one another.
+- **N4 (experiments).** Experiment runners (FE-1404, future condition reruns) stay beside their
+  planning docs (`docs/planning/**/`), JS-API pattern, `observe()` accounting — never in
+  `packages/` (they are instruments, not product) and never a bespoke daemon.
+- **N5 (storage-port implementations; local target discharged by FE-1391).** One per (binding ×
+  deploy target), always in the binding package, always implementing core's `CaptureStore` +
+  parse-on-read. The local implementation provisions a versioned target-document record around
+  both capture and archive state. The Cloudflare case (per-object SQLite) is a new implementation
+  behind the same port — the file-path assumption never leaks above the binding.
+- **N6 (plugin-assurance, when chartered).** `packages/plugin-assurance`, same shape as
+  gherkin; its existence is FE-1387's contract-freeze instrument, not a feature.
+
+Ratification note: N1 was the only item that changed existing code; FE-1422 extracted the ask
+protocol and FE-1392 continued the same repair for sweep mechanism.
+N2–N6 constrain future placement. ADR-0002 records the ratification. The boundary gates in
+`test/boundaries.test.ts` should learn the enforceable parts as their packages arrive (N2's
+"no plugin content in app skills dirs" and N5's "port implementations only in bindings" are
+both mechanically checkable).
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-entry-projection-source-read-2026-08-18.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-entry-projection-source-read-2026-08-18.md
new file mode 100644
index 00000000000..243f5445625
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-entry-projection-source-read-2026-08-18.md
@@ -0,0 +1,352 @@
+# Flue 2.0.3 entry projection and compaction source read
+
+**Date:** 2026-08-18
+
+**Scope:** FE-1391 (durable entry projection) pre-work; FE-1386 (compaction) triage
+
+**Resolved packages:** `@flue/runtime@2.0.3`, `@flue/sdk@2.0.3`
+
+## Question
+
+Can FE-1391 rely on the installed Flue durable conversation GET surface for archive-on-read and
+harness-resolved evidence anchoring? In particular:
+
+- **B1:** what does the surface guarantee about route discovery, views, paging, offsets, public
+  entry kinds, response types, errors, bounds, and the suspected thousand-entry limit?
+- **B2:** does compaction preserve that public projection and `usePersistentState` state, or does
+  it delete history while rewriting model context?
+
+This is a source-read gate, not an implementation or live compaction experiment.
+
+## Approach
+
+The lockfile is the version authority: `bun.lock:240` resolves `@flue/runtime@2.0.3` and
+`bun.lock:242` resolves `@flue/sdk@2.0.3`. I read the installed packages in this order:
+
+1. exported SDK/runtime types and package-shipped protocol/persistence documentation;
+2. mounted HTTP handlers and SDK client implementation;
+3. canonical record reducer, public projection, compaction runner, and SQL/in-memory stores;
+4. the current brunch-lite spec, capability declaration, open-gap ledger, and FE-1391/FE-1386
+   issue contracts.
+
+Evidence below is labeled **contract** when it is in exported types or package-shipped public
+documentation, **implementation** when it is an installed 2.0.3 implementation fact, and
+**inference** when it combines those facts for brunch-lite. Package `dist` filenames are
+content-hashed and may change on upgrade; the resolved version is therefore part of every
+source claim. Every abbreviated `@flue/...` evidence path below resolves under
+`apps/dev/node_modules/` in this worktree.
+
+## Verdict
+
+**B1 is settled enough to implement FE-1391, but it corrects two premises.** The public GET
+surface is a stable, materialized **message projection**, not the raw canonical entry log.
+`history()` returns the whole projection as one snapshot with no paging parameter or
+thousand-entry bound. The incremental `updates` view pages at 100 **durable batches**, not
+entries or messages; the SDK drains further pages automatically. The framework cannot discover
+an application's mount, and server-side relative URLs are rejected, so a binding reader needs a
+host-supplied full conversation URL (or URL resolver) and may use a host-supplied `fetch` to stay
+in-process.
+
+**B2 is source-settled for Flue 2.0.3.** The authoritative stream is append-only. Compaction
+appends a `compaction` record whose parent is the old active leaf, then rebuilds only the model
+context as summary plus retained suffix. The public history projector independently walks the
+full active path and skips the compaction record itself, so pre-compaction messages remain.
+`state_write` records are reduced in a separate instance-state map and are unaffected.
+
+FE-1386 therefore no longer needs an open-ended discovery spike. It should be reshaped to one
+narrow behavioral/upstream-drift pin, or that pin should be folded into FE-1391. Source evidence
+does not delete the existing §14.5 open gap because the repository deliberately requires a
+behavioral proof to close one.
+
+## B1 — exact public read contract
+
+### Route and base URL ownership
+
+| Finding                                                                                                                          | Evidence quality                                                                       | Evidence                                                                                  |
+| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
+| `createAgentRouter(agent)` serves `GET                                                                                           | HEAD /:id` relative to the caller's mount. The host owns mounting, auth, and exposure. | contract                                                                                  | `@flue/runtime/dist/registration-I-i4wkiu.d.mts:75-90`; `@flue/runtime/docs/reference/streaming-protocol.md:7-19` |
+| A client URL is the application-owned mount plus caller-chosen conversation id. Flue explicitly says it does not know the mount. | contract                                                                               | `@flue/sdk/dist/index.d.mts:5-18,599-657`                                                 |
+| Relative URLs work only against a browser origin. Outside a browser the SDK throws; a URL may not contain a query or fragment.   | implementation                                                                         | `@flue/sdk/dist/index.mjs:26-95`                                                          |
+| The client accepts a custom `fetch`, and the returned Hono router has `.fetch`.                                                  | contract                                                                               | `@flue/sdk/dist/index.d.mts:5-18`; `@flue/runtime/dist/registration-I-i4wkiu.d.mts:84-88` |
+| `start()` intentionally exposes no HTTP surface; its `init()` handle reads one submission reply, not conversation history.       | contract                                                                               | `@flue/runtime/dist/node/index.d.mts:86-124`; `@flue/runtime/dist/index.d.mts:135-172`    |
+
+**Inference for FE-1391:** there is no binding-level base URL discovery contract. The host must
+inject either a complete conversation-URL resolver or `(mount URL, fetch transport)`. An
+in-process reader can pass an absolute placeholder URL plus the mounted Hono app's `.fetch`, but
+the binding must not invent the mount. The type-level composition is available; an FE-1391 test
+must still pin that it is safe from the actual binding/lifecycle call site, including reentrancy
+and mount middleware. Calling this “self-HTTP” describes the protocol boundary, not a
+discoverable server address.
+
+### Views and response shapes
+
+| View                             | Contract                                                                                                                                                                                |
+| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `GET /:id` or `?view=history`    | `200` JSON `FlueConversationSnapshot`; `Cache-Control: no-store`; `Stream-Next-Offset` equals the snapshot offset; `Stream-Up-To-Date: true`. `offset`, `tail`, and `live` are invalid. |
+| `GET /:id?view=updates&offset=…` | `200` JSON update chunks, or long-poll/SSE when `live` is set. Exactly one offset is required. `tail` is invalid.                                                                       |
+| `HEAD /:id`                      | No body; head offset and up-to-date status in headers.                                                                                                                                  |
+
+The route dispatch and validation are public and implemented at
+`@flue/runtime/docs/reference/streaming-protocol.md:105-203` and
+`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:3068-3185,3253-3264`.
+
+The public history response is:
+
+```ts
+interface FlueConversationSnapshot {
+  v: 1;
+  conversationId: string;
+  offset: string;
+  incarnation?: string;
+  messages: FlueConversationMessage[];
+  settlements: FlueConversationSettlement[];
+}
+```
+
+This is an exported **contract** at `@flue/sdk/dist/index.d.mts:195-228`. `history()` has only an
+optional abort signal and issues `?view=history` directly
+(`@flue/sdk/dist/index.mjs:1202-1228`).
+
+The updates wire union discriminates `conversation-reset`, `message-appended`,
+`message-started`, `message-metadata`, `data-part`, `message-delta`, `tool-input`, `tool-output`,
+`tool-output-error`, `message-completed`, `submission-settled`, and `stream-checkpoint`
+(`@flue/sdk/dist/index.d.mts:230-361`). The same declaration explicitly calls these chunks an
+internal, UI-only projection protocol: application code is expected to consume `observe()` or
+materialized messages, not chunks. The wire shapes explain paging and recovery, but they are
+**not** the supported FE-1391 application contract.
+
+### Public message discriminators
+
+`FlueConversationMessage` is the supported consumption surface, exported at
+`@flue/sdk/dist/index.d.mts:39-218`:
+
+- `role`: `user | assistant | system`;
+- `purpose`: `user | assistant | dispatch | advisory` (the type notes that this union may widen);
+- `display`: `visible | hidden | diagnostic`;
+- stable `id`, optional `submissionId`, `turnId`, `signal`, `settlement`, and agent-authored
+  `metadata`;
+- parts discriminated as `text`, `reasoning`, `data-${string}`, `file`, or `dynamic-tool`; tool
+  parts further discriminate `input-available | output-available | output-error`.
+
+The projector maps canonical user messages to `role: 'user', purpose: 'user'`, signals to
+`role: 'system', purpose: 'dispatch' | 'advisory'`, and assistant steps/tool outcomes into one
+assistant response message (`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:1726-1767,1795-1830,
+1911-1988`).
+
+Two limits matter for anchoring:
+
+1. **Contract:** the canonical record schema and child conversations are intentionally not
+   exposed; only the default root conversation's materialized messages and update chunks are
+   public (`@flue/runtime/docs/reference/streaming-protocol.md:175-185`).
+2. **Inference:** `role: 'user'` plus `purpose: 'user'` is an adequate structural true-user
+   discriminator against signals and runtime advisories. It does **not** distinguish a typed
+   user-affordance reply from any other user delivery. That distinction remains harness-owned
+   through the pending-affordance protocol and reply encoding.
+
+The public stable `message.id` is not a canonical sequence number or entry range. Assistant
+steps are coalesced, tool results become parts, and compaction records disappear from the
+projection. FE-1391 must therefore choose whether the archive pointer stores stable Flue message
+IDs or harness-minted archive ordinals/ranges; it cannot derive the spec's current entry range
+from a public raw-entry sequence because no such sequence is exposed.
+
+A history snapshot is also materialized **at its read offset**, not an immutable list of finished
+objects. Repeated reads may return the same assistant message ID with additional parts or a part
+whose state advanced from `streaming` to `done` (`@flue/sdk/dist/index.d.mts:39-49,139-180`).
+**Inference:** archive-on-read needs identity-keyed merge/version semantics; blindly appending
+each snapshot duplicates messages, while first-write-wins can freeze a partial response. This is
+a third FE-1391 implementation decision alongside URL/transport injection and pointer identity.
+
+### Offsets, paging, and the “thousand entries” premise
+
+- **Contract:** offsets are opaque, exclusive resume tokens over durable **batches**, not
+  messages. `-1` means before the first batch. Clients must not construct or interpret them
+  (`@flue/runtime/docs/reference/streaming-protocol.md:21-34`).
+- **Contract:** a history snapshot is one whole materialized snapshot. It has no paging or
+  limit parameter (`@flue/sdk/dist/index.d.mts:225-228`).
+- **Contract:** one updates response covers at most 100 durable batches; there is no wire
+  parameter to change it. Absence of `Stream-Up-To-Date` means continue from
+  `Stream-Next-Offset` (`@flue/runtime/docs/reference/streaming-protocol.md:187-203`).
+- **Implementation:** the SDK automatically reconnects a non-live stream until it reaches the
+  head (`@flue/sdk/dist/index.mjs:717-745,878-885`).
+- **Implementation:** the store defaults to 100 batches and clamps an internal adapter read to
+  1,000 (`@flue/runtime/dist/stream-offsets-sRUtb-M2.d.mts:29-32`;
+  `@flue/runtime/dist/conversation-stream-store-CXwRWonS.mjs:5508-5533,5662-5689`). The HTTP
+  handler passes no `limit`, so the wire page is the 100-batch default
+  (`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:3144-3160`).
+
+**Verdict:** neither the public contract nor the 2.0.3 handler imposes a thousand-entry limit on
+history, and there is no thousand-message limit on updates. This is not a promise of unbounded
+response size; it means no semantic count cap is exposed. The suspected number belongs to the
+internal store adapter's maximum batch read. For FE-1391 archive-on-read, `history()` avoids
+paging entirely. If FE-1391 later consumes updates, the SDK already owns page draining;
+hand-built offset arithmetic would diverge from contract.
+
+### Errors and bounds
+
+| Condition                                                                                            | Result                                                                     | Quality                   |
+| ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
+| Unknown conversation/read before first POST                                                          | `404 stream_not_found`                                                     | contract + implementation |
+| Invalid view, history query combination, missing/repeated/malformed update offset, invalid live mode | `400 invalid_request`                                                      | contract + implementation |
+| Unsupported method                                                                                   | `405 method_not_allowed` with `Allow`                                      | contract                  |
+| Update offset beyond current head                                                                    | `416 stream_offset_gone`, with instruction to re-read history              | implementation            |
+| Any non-2xx SDK JSON request                                                                         | `FlueApiError` with status, parsed body/text, and optional correlation ref | contract + implementation |
+
+Evidence: `@flue/runtime/dist/errors-CsDcT_C4.mjs:383-442`,
+`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:3130-3160`, and
+`@flue/sdk/dist/index.d.mts:20-35` / `index.mjs:97-121`.
+
+The package-shipped protocol page says an offset beyond head returns `500`
+(`streaming-protocol.md:34`), while the installed 2.0.3 handler and typed error implement `416`.
+That is a documentation/source discrepancy. Treat `416` as **2.0.3 implementation evidence**,
+not a stable public promise, and let `FlueApiError` carry the exact status rather than branching
+archive correctness on it.
+
+## B2 — storage ownership and compaction trace
+
+### Durable ownership
+
+The package documentation calls each agent instance's canonical conversation an ordered,
+append-only stream and the sole authoritative transcript. State writes live in that same stream;
+fold checkpoints are explicitly non-authoritative caches
+(`@flue/runtime/docs/guide/database.md:11-21`,
+`@flue/runtime/docs/reference/data-persistence-api.md:140-179`). This is the public adapter
+**contract**.
+
+The 2.0.3 implementation matches it:
+
+- SQL stores each batch under `(path, seq)` and appends with `INSERT`, then increments the head
+  (`@flue/runtime/dist/conversation-stream-store-CXwRWonS.mjs:5302-5333,5635-5657`).
+- The in-memory adapter likewise pushes a new batch; reads slice without mutating prior batches
+  (`...:5490-5533`).
+- `CompactionRecord` carries its own `entryId`, old active `parentId`/`sourceLeafId`, and a
+  `firstKeptEntryId`; `StateWriteRecord` is separately defined as last-write-wins state across
+  the instance stream (`@flue/runtime/dist/attachment-store-CukHsFkd.d.mts:263-276,318-329`).
+
+### What compaction changes
+
+The implementation trace is decisive:
+
+1. The reducer validates that `firstKeptEntryId` and `sourceLeafId` already exist, then **appends**
+   the compaction entry as a child of the active leaf. It deletes no conversation entry
+   (`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:538-556`).
+2. The compaction runner builds a summarization input from canonical context, generates a
+   summary, appends that compaction record with the old active leaf as parent, and rebuilds model
+   context (`@flue/runtime/dist/conversation-stream-store-CXwRWonS.mjs:4039-4138`).
+3. Only `buildConversationContextEntries` substitutes the latest summary plus kept suffix for
+   older messages (`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:698-734`). This function feeds
+   `agentLoop.state.messages` (`@flue/runtime/dist/conversation-stream-store-CXwRWonS.mjs:
+3908-3916`).
+4. The public history projector takes a different path: it walks the full active path and emits
+   every message entry, skipping only non-message entries such as the compaction record
+   (`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:1795-1816,2028-2038`). An incremental reader gets a
+   `conversation-reset` carrying that same full snapshot when a compaction record lands
+   (`...:2040-2053,2092-2094`).
+
+**Inference:** for the installed 2.0.3 graph shape, a history snapshot after compaction contains
+the same pre-compaction public messages (and IDs), plus anything appended afterward. Its durable
+offset changes because the compaction itself is a durable batch. Compaction rewrites model
+context, not durable history.
+
+### What happens to per-session state
+
+`state_write` reduction updates a state map independently of message/compaction handling
+(`@flue/runtime/dist/dispatch-nU3cIlT-.mjs:585-587`). Root-harness initialization loads that
+reduced state and gives it to the hook state buffer
+(`@flue/runtime/dist/builtin-providers-DW08g5fh.mjs:464-480`). The public durability guide also
+states that every persistent-state write is a canonical record and survives for the life of the
+conversation (`@flue/runtime/docs/guide/durability.md:109-113`).
+
+**Verdict:** compaction preserves the state used for brunch-lite's pending-affordance slot and
+future swept high-water mark. The state is scoped to the agent instance/root harness, not to the
+model-context message array that compaction rewrites.
+
+## Confidence shift
+
+| Claim                                       | Before           | After source read                                                              |
+| ------------------------------------------- | ---------------- | ------------------------------------------------------------------------------ |
+| A supported conversation read exists        | paraphrase-grade | high; public exported types and wire docs                                      |
+| Binding can discover its own route/base URL | assumed          | contradicted; host owns and must inject it                                     |
+| GET exposes raw canonical entries/ranges    | assumed          | contradicted; public surface is materialized messages                          |
+| A thousand-entry page must be handled       | open gap         | contradicted; history is unpaged, updates are 100 batches, 1,000 is internal   |
+| True user can be separated from signals     | unverified       | high for `role/purpose`; affordance subtype remains harness-owned              |
+| Compaction might prune durable history      | open             | high-confidence false for 2.0.3; append-only contract plus direct source trace |
+| Compaction might reset persistent state     | open             | high-confidence false; independent state-write reduction                       |
+
+The only non-contractual part of the B2 verdict is the exact guarantee that the _public message
+projection_ remains byte-for-byte stable across compaction. Public docs promise an append-only
+canonical source of truth, and implementation makes the projection consequence clear, but they
+do not state that consequence as a named compatibility guarantee. That is why a behavioral pin
+still has value at Flue upgrades.
+
+The settled elicitation-kernel spec remains the historical decision record, so its §14.5 text
+still names the pre-read `>1000` and compaction unknowns. Current truth lives in SPEC-LEDGER,
+the remediation ledger, and `test/open-gaps.ts`. Capability 8's metadata is reconciled in this
+change; FE-1391 still owns its implementation.
+
+## Recommendation and residual experiment
+
+Proceed with FE-1391 using the public `FlueConversationSnapshot`/`history()` surface, a
+host-supplied conversation URL resolver and optional in-process `fetch`, stable public message
+discriminators, and archive-owned pointer identity. Do not consume private canonical record
+types or shadow-copy entries from hooks.
+
+Reshape FE-1386 from discovery into the smallest behavioral pin:
+
+1. seed one real runtime conversation with a user message, a signal, an assistant response with
+   a tool part, and persistent state;
+2. read and retain the complete public `messages` and `settlements` projections plus state;
+3. call the public `session.compact()` surface once after enough history exists (it is the same
+   compaction path with `reason: 'manual'`; `@flue/runtime/dist/types-CVx9SjIx.d.mts:877-892`
+   and `conversation-stream-store-CXwRWonS.mjs:3079-3083`);
+4. deep-compare `messages` and `settlements` after compaction (excluding only snapshot
+   `offset`/`incarnation`), assert the same state, then assert an FE-1391 archive pointer still
+   resolves.
+
+Do not run a broad compaction matrix. One real boundary crossing is enough to pin the source-read
+conclusion and satisfy the repository's behavioral-proof rule. If FE-1391 can host that test,
+FE-1386 can be canceled after the pin lands; until then, keep it as the narrowly reshaped owner.
+
+## Disposition
+
+- **B1:** resolved; FE-1391 now has three implementation decisions, not substrate unknowns:
+  host-injected URL/transport, archive pointer identity, and identity-keyed merge/version
+  semantics for repeated materialized snapshots.
+- **B2:** source-settled for 2.0.3; open-ended FE-1386 spike canceled in shape, narrow behavioral
+  pin retained.
+- **No runtime, archive, HTTP, or compaction implementation and no live spike performed.** Only
+  capability metadata and planning records were reconciled.
+
+## Implementation follow-through (2026-08-18)
+
+FE-1391 subsequently implemented the source-read recommendation without changing its Flue
+contract findings except for one identity distinction found by the real mounted-router test:
+
+- `packages/binding-flue/src/history-reader.ts` consumes only the public SDK `history()` snapshot
+  through a host-injected full URL resolver and `fetch`, then archives before returning;
+- the host's route/session id and `FlueConversationSnapshot.conversationId` are not equal in the
+  actual `start()` lifecycle. The former remains the domain session/archive key; the latter is an
+  opaque public-projection identity retained in the materialized snapshot, not reinterpreted as
+  the evidence pointer's session id;
+- `packages/core/src/session-log.ts` assigns stable one-based archive ordinals, retains distinct
+  materialized versions under each public message identity, and derives evidence source from the
+  archived entry kind;
+- the local binding store provisions a format-versioned target-document record around capture and
+  archive state, reads the legacy capture-only shape, and fails loudly when either persisted half
+  does not parse;
+- caller evidence inputs now contain verbatim quotes only. Application resolves and stores the
+  existing session-id-plus-entry-range pointer once; a range or source assertion supplied beside a
+  quote is rejected.
+
+The custom-transport reader, evolving-message versioning, latest-match advisory, non-user refusal,
+and archive-pointer retrieval are behaviorally pinned under `packages/binding-flue/test`,
+`packages/core/test`, and the real mounted-router walking skeleton. The obsolete
+`history-projection-paging` gap was removed. FE-1392 then split non-writing public-history peeks
+from binding-private archive refresh: its mounted oracle starts with the quote absent from the
+archive, permits no intervening archive writes, and proves the refresh adjacent to apply makes
+that quote resolvable and storable.
+
+The FE-1386 behavioral pin did not fold into FE-1391. A genuine main-conversation compaction is not
+reachable from the new read/archive seam without additional test-agent and summarizer setup, which
+would widen this slice. Its smallest remaining experiment is unchanged: one real compaction,
+deep-compare complete public `messages`/`settlements` except offset/incarnation, assert persistent
+state, then resolve a pre-compaction FE-1391 archive pointer.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-patterns-audit-2026-08-17.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-patterns-audit-2026-08-17.md
new file mode 100644
index 00000000000..96782e4c33b
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/flue-patterns-audit-2026-08-17.md
@@ -0,0 +1,187 @@
+# Flue patterns audit — 2026-08-17
+
+Audit of brunch-lite's Flue usage against the official docs (project-layout, routing, database,
+configuration, models, agent-api reference, evals guide — fetched 2026-08-17; the framework's
+`.../index.md` markdown mirrors). Produced during the FE-1401 remediation sweep. One empirical
+probe was run where the docs were silent (noted inline).
+
+**Verdict.** The repo's Flue usage is substantially canonical — in several places the docs
+retroactively bless choices the deep-reads had marked as judgment calls (the mount-path/identity
+split most notably), and in one place canon _downgrades_ a known finding's severity (the faux
+model-id coupling fails fast at resolution, not silently over the network). Nothing audited is
+outright wrong. The divergences that exist are all in the eval harness, all forced by the same
+root fact (the Flue node runtime cannot be driven under `bun test`), and all composed from
+documented parts rather than invented mechanisms. The genuinely load-bearing risks are two
+places where the binding relies on runtime semantics the docs state only vaguely — both pinned
+by the walking-skeleton integration test, which this audit therefore marks as a
+do-not-weaken oracle.
+
+## Wrong-or-fragile
+
+1. **Faux model id silently coupled to the agent's `useModel` string — fragile, but louder
+   than we recorded.** `walking-skeleton.integration.ts:20` declares
+   `models: [{ id: 'claude-haiku-4-5' }]`, which must match
+   `gherkin-elicitor.ts:28`'s `useModel('anthropic/claude-haiku-4-5')`. The FE-1389 deep-read
+   feared drift "falls through to a real provider or fails obscurely". Canon corrects half of
+   that: registering a provider under a built-in's id **overrides** it (models guide, custom
+   provider registration), and "an unknown specifier fails fast: the run errors with the
+   unresolved provider and model ID before any request is sent". So drift is a loud resolution
+   error, not a network call. Still fragile — nothing ties the two strings. Fix: one shared
+   constant (or derive the faux model list from the agent module's specifier). Cheap; belongs
+   with FE-1420-adjacent test hardening.
+2. **`providers` left unrestricted in the build.** `flue.config.ts` declares only
+   `target: 'node'`; canon offers `providers: ['anthropic']` to make the registered set
+   exhaustive, so "a specifier naming any other provider fails at resolution". As is, every
+   built-in provider ships and a typo'd provider id in a future `useModel` resolves against a
+   provider we never intend to credential. One line, matches the repo's fail-fast posture
+   (docs/agents/posture.md). Recommended.
+
+## Divergent with defensible reason
+
+1. **Eval harness shape.** Canon (evals guide): Vitest, separate `vitest.evals.config.ts`,
+   `src/evals/*.eval.ts`, extended timeouts, one runtime per process. Repo:
+   `apps/dev/test/walking-skeleton.test.ts` under `bun test` spawning
+   `node --experimental-strip-types` for the integration file. The docs "do not address Bun
+   test" (their words); the child process _honors_ the one-runtime-one-process rule by giving
+   the runtime a process of its own; and the canonical reason evals live in a separate suite —
+   they spend real tokens and real time — does not apply to a faux-provider run that costs
+   nothing and finishes in ~500ms, so folding it into the ordinary test gate is sound, not lazy.
+   Stay divergent; revisit only if paid-model evals arrive (those should follow canon's
+   separate-suite shape).
+2. **Hybrid in-process + HTTP coverage.** Canon presents `start()` (in-process) and
+   `createFlueClient` (HTTP against a running server) as alternatives; the repo composes them —
+   `start()` boots the runtime, `createFlueClient({ url, fetch: fetchApp })` drives the real
+   `app.ts` through a fetch shim (`walking-skeleton.integration.ts:51-59`). The `fetch` option
+   is typed SDK surface, so this is composed from documented parts, and it captures precisely
+   what canon says direct-import testing misses ("agents depending on build-resolved features
+   require HTTP evaluation"): route wiring is covered without a socket. Stay divergent —
+   arguably this is the better pattern and worth upstreaming as a docs suggestion.
+3. **`db.ts` path anchored to the module, env-overridable.** Canon's example is a bare relative
+   `'./data/flue.db'` and never says relative-to-what; the repo anchors via `import.meta.url`
+   with the failure mode documented at the site (`db-path.ts`). The `BRUNCH_DEV_DB_PATH`
+   override is app convention, not a Flue one — fine, since canon's `db` config field names the
+   module, not the file. Stay divergent; docs are silent.
+4. **Flat agent file rather than per-agent folder.** Canon's multi-agent layout nests
+   `src/agents/<agent>/` folders; the repo has one agent as a flat file
+   (`src/agents/gherkin-elicitor.ts`). Right-sized today; adopt folders when the target gallery
+   (FE-1385) adds the second agent.
+
+## Canonical — confirmed against the docs
+
+1. **`'use agent'` directive discipline.** First statement before imports, exported capitalized
+   function, `agentName` as a pinned string-literal static (`gherkin-elicitor.ts:1,27,48`) —
+   matches the directive scan, the identity-resolution order (build-stamped binding →
+   `agentName` → function name), and the identity regex. The pinning is _more_ load-bearing
+   than the comment even claims: under `start()`'s direct module import (evals), the
+   build-stamped binding may be absent, and `agentName` is the next resolution step — the
+   static is what keeps eval and production conversations keyed identically.
+2. **Mount path ≠ agent identity.** `routes.ts` + `app.ts:23` mount at a route constant while
+   storage keys on the pinned identity. Canon, verbatim: "The mount path is not the agent's
+   identity… never by the URL." The FE-1389 deep-read defended this as a judgment call; it is
+   documented doctrine. (SPEC-LEDGER note: no row change needed, but the deep-read's
+   "newcomer would misunderstand" entry can cite the routing guide.)
+3. **`app.ts` as the single fetch-compatible entry, Hono by convention, assets composed
+   alongside agents, auth-by-middleware-not-framework.** All as the routing guide draws it.
+4. **Tool contract.** Inline `useTool` with valibot `input`/`output`, `run` returning
+    `{ output, terminate: true }`, affordance id minted from `toolCallId`, tool errors thrown to
+    the model (the second-ask rejection) — every element is documented surface, including
+    `terminate` ("ends the agent's turn once the tool batch settles").
+5. **Signals.** `ctx.append({ kind: 'signal', type, tagName, body, attributes })` matches the
+    `DeliveredMessage` contract; `affordance-reply-bound` is not in the reserved-type list;
+    signals render as XML-tagged blocks, not chat turns — which is the §9.4
+    structurally-non-user property the binding depends on.
+6. **Instruction assembly.** Agent returns the binding's string; canon composes "your returned
+    string first". The no-interpolation rule (nothing pending in the instruction string) is
+    exactly what avoids the documented `instructions` signal ("System instructions updated.") —
+    the docs confirm both the advisory's existence and its trigger (composed-instruction digest
+    change).
+7. **`initialData`.** Valibot schema validated once at first contact, immutable — canon's
+    AgentStatics lane, used for the session→document binding. Observation, not a violation: the
+    parsed value is never read back yet (`useInitialData()` has no caller); FE-1392's sweep
+    wiring is the intended consumer.
+8. **`db.ts` shape.** Default-exports `sqlite(path)` from `@flue/runtime/node` — canon's
+    exact idiom, WAL mode, auto-created directories, boot-time `migrate()`/`connect()` meaning
+    a bad path fails at startup, which is the fail-loud behavior FE-1400's fixes wanted.
+9. **Version hygiene.** All `@flue/*` packages pinned to one version line (`^2.0.3`);
+    `pi-ai` (faux provider) a devDependency only.
+
+## Docs-are-silent — verified empirically or accepted
+
+1. **`start()` does not auto-discover `db.ts` (probed).** The docs say `db.ts` is "discovered
+    by convention from the source directory" but never say whether `start()` (evals) performs
+    that discovery. Probed: ran the walking-skeleton suite and compared
+    `apps/dev/.data-wipe-me/conversations.db` mtime — unchanged. Explicit `start()` config
+    keeps conversations in memory; the test's no-disk hermeticity claim holds. The existing db
+    file is `vite dev` residue. Worth one sentence in the substrate-inventory review note so
+    the claim's evidence is named.
+2. **Monorepo/workspace composition.** Canon has no monorepo story (its own admission). The
+    repo's composition — library packages export hooks (`useElicitation`), the app owns the
+    directive-marked agent module — is forced by the scan being source-root-scoped and matches
+    the gherkin-elicitor comment ("a library cannot ship a pre-registered agent"). Accepted;
+    this is the §12.1 thin-host doctrine and Flue's layout constraint agreeing.
+
+## Known workarounds, cross-checked
+
+- **Child process because "`@flue/runtime/node` cannot be driven under `bun test`"** — docs
+  confirm only Vitest is addressed; no contradiction, no better documented mechanism. Keep.
+- **`db.ts` as build-time convention file kept apart from `db-path.ts`** — consistent with
+  canon's convention-discovery model; the split exists so the path logic stays `bun test`-able.
+  Keep.
+- **No-db in-memory eval trick** — canon confirms in-memory default _for the no-`db.ts` case_;
+  the start()-doesn't-discover-db.ts half was undocumented and is now probed true (item 16).
+
+## Strain report
+
+Places where the docs are ambiguous or our architecture has no canonical answer — inputs to the
+second-binding question (spec §14.2), not defects:
+
+1. **`useAgentStart` firing semantics.** ~~Undocumented~~ **Resolved 2026-08-17**: the
+   agent-hooks _guide_ (a page this audit did not fetch — it read the agent-api reference
+   instead) states the hook "runs every time a message is delivered to the agent" —
+   per-delivery, exactly what the binding relies on (`binding-flue/src/index.ts:47`). The
+   agent-api reference's "once per agent instance at first contact" wording is the misleading
+   text. Downgraded from undocumented-bet to documented-semantics; the walking-skeleton test
+   stays as the pin (cheatsheet, §2). The audit's miss is itself a finding: sampling the
+   reference without the guide produced a false "docs are silent".
+2. **State-updater composition within a tool batch.** ~~Undocumented~~ **Resolved 2026-08-17**:
+   the agent-hooks guide documents the updater rule — the callback "always accesses the latest
+   written value, not a stale render snapshot" — which is precisely what the one-live-affordance
+   guard depends on. Same downgrade, same retained pin (`secondAskRejected`). Cite the guide at
+   the guard when that file is next touched.
+3. **The evals guide's provider-credentials assumption.** Canon's eval story assumes real
+   provider credentials from the environment; the faux-provider pattern the repo uses (and
+   pi-ai ships for exactly this) is undocumented in Flue's own guide. Our CI-hermeticity
+   posture therefore rests on pi-ai's contract, not Flue's. Acceptable — pi-ai is the substrate
+   family's own test double — but it is a dependency the docs don't underwrite.
+4. **Capability 8 (durable entry projection over self-HTTP)** remains the binding's biggest
+   docs-unsupported bet: the history projection is documented as an SDK read surface, but
+   "read your own projection over self-HTTP from inside the process" appears nowhere in canon.
+   FE-1391 will land on this; expect to either find a native lane or write the strain down.
+
+> **Reflection:** The audit's most useful output is a reclassification: the eval harness — the
+> part of the repo that _feels_ most improvised — is composed entirely of documented parts and
+> honors canon's one constraint (one runtime, one process) more carefully than the canonical
+> shape does under a different test runner. Meanwhile the two real risks are invisible in any
+> file diff: they are reliance on under-documented runtime semantics, and their only guardrail
+> is one integration test. That inverts the usual review instinct — the weird-looking code is
+> fine; the ordinary-looking hooks are where the substrate could move under us.
+
+## Sources
+
+Fetched 2026-08-17, all in the framework's `index.md` markdown-mirror form; all eight succeeded:
+
+- https://flueframework.com/docs/guide/project-layout/index.md
+- https://flueframework.com/docs/ecosystem/index.md (thin: integration-category directory only)
+- https://flueframework.com/docs/reference/agent-api/index.md
+- https://flueframework.com/docs/guide/routing/index.md
+- https://flueframework.com/docs/guide/database/index.md
+- https://flueframework.com/docs/guide/evals/index.md
+- https://flueframework.com/docs/reference/configuration/index.md
+- https://flueframework.com/docs/guide/models/index.md
+
+Deliberately skipped as not load-bearing for the audited surfaces: getting-started, CLI
+overview, SDK overview (its relevant `createFlueClient` options are covered by the evals
+guide), cloudflare-target, deploy — node target only, no CLI-driven patterns in this repo.
+Caveat: fetches were read through a summarizing intermediary, so doc quotes are close
+paraphrases unless marked verbatim; the two strain-report ambiguities (useAgentStart firing,
+updater composition) are flagged as ambiguities partly for exactly that reason.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/README.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/README.md
new file mode 100644
index 00000000000..843f491fa76
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/README.md
@@ -0,0 +1,144 @@
+# Issue and PR legibility migration package
+
+This package freezes the 20 August 2026 source records and proposed legibility edits for the
+`brunch-agent` Linear project and its `brunch-lite` pull requests. Preparing and committing the
+package did not write to Linear or GitHub. Application began only after separate approval;
+[`apply-log.jsonl`](apply-log.jsonl) is its append-only audit record.
+
+The migration completed on 20 August 2026. Final reconciliation verified all 67 Linear targets,
+all 25 GitHub targets, and the title, body, and URL of all six excluded issues against the
+frozen source. FE-1333's `updatedAt` moved to `2026-08-20T10:50:17.548Z` while the first FE-1357
+write was in flight; FE-1333 is the duplicate issue tied to FE-1357, and no excluded content
+changed. The other five excluded timestamps remain exact.
+
+## Scope
+
+The Linear snapshot contains 73 issues. The proposals cover all 67 Lu Nelson-authored issues,
+including sub-issues. FE-1328, FE-1329, FE-1330, FE-1331, FE-1333, and FE-1334 are Dora
+Ma-authored and have no proposal. The migration has 67 issue targets. It changes 65 titles and
+writes 66 bodies; FE-1451 already has the exact canonical stored body and is verified without a
+write.
+
+The GitHub snapshot contains 25 pull requests. The proposals change 24 titles and eight bodies;
+the remaining bodies already have the required structure. Historical issue and pull-request
+comments are outside the migration and remain untouched.
+
+For each proposed body, the short outer prose may change while the existing detailed record is
+preserved inside one canonical `🏗️ Agent notes` wrapper. PR #23 is the sole normalization case:
+its accidentally nested standalone wrapper lines are removed, while every other byte of its
+inner record remains in source order.
+
+The reviewed Linear proposal files remain frozen as approved. A trial write showed that Linear
+requires a space after the `+++` opener and blank separator lines around the folded content;
+both its issue CLI and raw GraphQL API canonicalize absent whitespace. The exact stored bodies
+are therefore derived from each approved `proposedOuter` and byte-preserved `innerRecord`, with
+their hashes frozen in `data/linear-canonical-target-hashes.json`. Linear also expands the bare
+`demo.petrinaut.org` domain in the FE-1433 and FE-1440 outers into its stored Markdown-link
+syntax; those two exact replacements live beside their target hashes. No inner-record byte
+changes. The wrapper format matches the body Linear already stores for FE-1451.
+
+## Review surfaces
+
+- [`review/linear-FE-1357.md`](review/linear-FE-1357.md),
+  [`review/linear-FE-1366.md`](review/linear-FE-1366.md),
+  [`review/linear-FE-1383.md`](review/linear-FE-1383.md),
+  [`review/linear-FE-1401.md`](review/linear-FE-1401.md), and
+  [`review/linear-FE-1406.md`](review/linear-FE-1406.md) show each issue title and outer-prose
+  change without repeating the detailed record.
+- [`review/github.md`](review/github.md) shows the equivalent pull-request changes.
+- [`review/linear-editorial-review.md`](review/linear-editorial-review.md) and
+  [`review/github-editorial-review.md`](review/github-editorial-review.md) record the independent
+  editorial and fidelity passes.
+- [`data/`](data/) holds the byte-exact source snapshots, reviewed proposals, exact Linear stored
+  target hashes, and per-record source hashes. The source snapshots include records that are
+  intentionally excluded from the migration.
+
+## Frozen data
+
+| File                                       | SHA-256                                                            |
+| ------------------------------------------ | ------------------------------------------------------------------ |
+| `data/linear-source.json`                  | `863ba1deb87718cf3ba3c2accf70ac11cbe7b51a479aff9d9f1bf2719f26f152` |
+| `data/linear-canonical-target-hashes.json` | `2368d1d7a6d63193b981757e713148f8c155fb29e3ae68c1c805a03b1e338b25` |
+| `data/linear-proposals-FE-1366.json`       | `2473f32ebe5a4ef59f11d910e1ccf57f9eb22df60a9de40440652509e61bc327` |
+| `data/linear-proposals-FE-1383.json`       | `80146357d942c89602a3bbe74a31efa2f2c47556988c10c37c291d2778ae9ea7` |
+| `data/linear-proposals-FE-1401.json`       | `acdc70da63e7d8d74bff8aa736aa903978c695134e9f828e23419d7f4fa3a3d8` |
+| `data/linear-proposals-FE-1406.json`       | `87324f17f294996c8dcf0fc9ba92c76c51554ee0f7c48082f404e966e7275fbf` |
+| `data/github-source.json`                  | `ff209f957d17fb3c3049a3c19845b2c3f2310c88cda88d01712a2a3ab67c5113` |
+| `data/github-proposals.json`               | `5c77c007537c15357a2d482c51bc933bc61b7727a6982e8324851d007e55adcc` |
+
+Two later, deliberate departures from the original freeze, both made after the migration was
+applied and both preserved in git history:
+
+- `data/linear-proposals-FE-1357.json` (frozen as
+  `3832104ff8079ff56102235d86c1982970bfb5752e508baa4fc4646a69162985`) was removed from the
+  repository: its issue-URL-adjacent prose tripped hashintel/hash's preflight scan that blocks
+  merging any pull request whose title names a ticket still referenced beside a task marker,
+  for every ticket from FE-1437 through FE-1441. The
+  validator's `REMOVED_LINEAR_PROPOSAL_TITLES` map carries the 29 removed proposals'
+  identifiers and applied titles, so coverage and the PR title checks still account for the
+  whole subtree. The canonical target hashes for those issues remain in
+  `data/linear-canonical-target-hashes.json`.
+- `data/linear-source.json` and `data/github-source.json` were captured minified
+  (`1a7200ac…`, `2d00d591…`) and were pretty-printed by the monorepo formatter when Brunch was
+  assimilated into hashintel/hash. The parsed content is unchanged; the table above pins the
+  reformatted bytes, and `source-record-hashes.json` keeps the capture-time hashes in its
+  `generatedFrom` block.
+
+[`data/source-record-hashes.json`](data/source-record-hashes.json) records the source
+`updatedAt`, title hash, and body hash for every one of the 73 issues and 25 pull requests. Its
+SHA-256 is `15ff2f72cd7e49a6d3d20f3a71ebbf6f583573f384700a68775f1a4390c31717`.
+
+Run the deterministic validator from the repository root:
+
+```sh
+node --experimental-strip-types docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/validate.ts
+```
+
+It checks the frozen file hashes, source coverage, authorship exclusions, per-record source and
+proposal hashes, byte-exact inner-record preservation, Linear canonical target hashes, wrapper
+shape, and issue-to-PR title links.
+
+## Apply protocol
+
+Application requires separate, explicit approval. Apply Linear issues in identifier order, then
+GitHub pull requests in number order, one record at a time. For each record:
+
+1. Fetch its raw title, body, and `updatedAt` immediately before writing. Require all three to
+   equal the frozen source values and recompute the title and body hashes. Any difference is
+   drift: do not write that record. Rebuild and review its proposal from the fresh content.
+   FE-1357 and FE-1433 are the documented exceptions: failed trial writes and byte-exact
+   rollbacks changed only their immutable `updatedAt` history. Require their frozen title/body
+   hashes and the last recovered timestamps recorded in the apply log instead.
+2. For Linear, write the exact `proposedTitle` and derive the stored body only from the approved
+   `proposedOuter` and `innerRecord` using the canonical wrapper and two declared bare-domain
+   replacements above; require its hash to match `linear-canonical-target-hashes.json` before
+   writing. For GitHub, write the exact `proposedTitle` and `proposedBody`. Do not reconstruct
+   editorial content from a compact review manifest.
+3. Fetch the raw record again. Require exact title and body equality with the system-specific
+   target and recompute its hashes. Any mismatch is a failed verification: stop before touching
+   the next record.
+4. Append one result to `apply-log.jsonl` in this directory: record id and URL, pre-fetch time,
+   source `updatedAt` and hashes, proposed hashes, post-fetch time and hashes, and pass/fail. A
+   failed or drifting record stops the run.
+
+After the last record, fetch the complete scope again and reconcile it with the proposals and
+the apply log. The six excluded Dora-authored issues must still match the source snapshot in
+title, body, and URL. Require the source `updatedAt` too, except for FE-1333's exact documented
+metadata-only side effect above. No step in this protocol calls a comment-writing endpoint, so
+historical comments remain outside the operation.
+
+## Rollback
+
+The raw snapshots are the rollback authority. To emit their original titles and bodies without
+adding or removing a newline, choose an empty destination and run:
+
+```sh
+bun docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/validate.ts \
+  --emit-originals /tmp/brunch-legibility-originals
+```
+
+This creates `title.txt` and `body.md` for all 73 issues and 25 pull requests and reads every
+file back to prove byte equality. Before restoring a record, fresh-fetch it and require it to
+match the applied system-specific target; otherwise stop for review. After restoring,
+fresh-fetch again and require its title and body hashes to match
+`data/source-record-hashes.json`.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/apply-log.jsonl b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/apply-log.jsonl
new file mode 100644
index 00000000000..455f1ae3fca
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/apply-log.jsonl
@@ -0,0 +1,249 @@
+{"event":"attempt","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","preFetchAt":"2026-08-20T10:50:17.191Z","sourceUpdatedAt":"2026-08-19T16:26:28.291Z","sourceTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","sourceBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"813d332b818faef209bb08cf6d6c84f8a6c3a0531aad23ff3978d4c087d16ab2"}
+{"event":"result","status":"verification-failed","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","postFetchAt":"2026-08-20T10:50:18.365Z","postUpdatedAt":"2026-08-20T10:50:17.829Z","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","actualTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"813d332b818faef209bb08cf6d6c84f8a6c3a0531aad23ff3978d4c087d16ab2","actualBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98","writeExitCode":0,"writeStderr":""}
+{"event":"recovery","status":"restored-to-source","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","recordedAt":"2026-08-20T10:51:52Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.291Z","restoredUpdatedAt":"2026-08-20T10:51:25.480Z","sourceTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","restoredTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","sourceBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","restoredBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","cause":"linear issue update normalized the proposed Markdown; raw GraphQL restored the frozen title and body byte-exactly"}
+{"event":"attempt","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","preFetchAt":"2026-08-20T10:53:00.554Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.291Z","sourceUpdatedAt":"2026-08-20T10:51:25.480Z","sourceTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","sourceBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"813d332b818faef209bb08cf6d6c84f8a6c3a0531aad23ff3978d4c087d16ab2"}
+{"event":"result","status":"verification-failed","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-plugin-specification","postFetchAt":"2026-08-20T10:53:01.565Z","postUpdatedAt":"2026-08-20T10:53:01.084Z","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","actualTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"813d332b818faef209bb08cf6d6c84f8a6c3a0531aad23ff3978d4c087d16ab2","actualBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98","writeExitCode":0,"writeStderr":""}
+{"event":"recovery","status":"restored-to-source","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","recordedAt":"2026-08-20T10:53:58Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.291Z","restoredUpdatedAt":"2026-08-20T10:53:47.086Z","sourceTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","restoredTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","sourceBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","restoredBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","cause":"Linear canonicalized the fold delimiters through raw GraphQL as well; the frozen title and body were restored byte-exactly and the migration remains halted"}
+{"event":"attempt","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it","preFetchAt":"2026-08-20T11:00:48.082Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.291Z","sourceUpdatedAt":"2026-08-20T10:53:47.086Z","sourceTitleSha256":"83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84","sourceBodySha256":"70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-plugin-specification","postFetchAt":"2026-08-20T11:00:49.389Z","postUpdatedAt":"2026-08-20T11:00:48.864Z","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","actualTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98","actualBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1358","url":"https://linear.app/hash/issue/FE-1358/survey-petrinaut-architecture-dependencies-assistant-implementation","preFetchAt":"2026-08-20T11:00:49.634Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.268Z","sourceUpdatedAt":"2026-08-19T16:20:27.268Z","sourceTitleSha256":"f0ba585b8182ae752cbf2efffaabe8e3e805dedd6e0c9fe4712c01dda18c2366","sourceBodySha256":"db2735d101439db145bdceb1a38b8e290487853806a91464677bfb650d4d4b5d","proposedTitleSha256":"92a7187c58c6662981c602d001ed28e1088a40f24a05befdaae9b399816cb9c4","proposedBodySha256":"08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1358","url":"https://linear.app/hash/issue/FE-1358/survey-petrinaut-for-the-september-integration","postFetchAt":"2026-08-20T11:00:50.778Z","postUpdatedAt":"2026-08-20T11:00:50.413Z","proposedTitleSha256":"92a7187c58c6662981c602d001ed28e1088a40f24a05befdaae9b399816cb9c4","actualTitleSha256":"92a7187c58c6662981c602d001ed28e1088a40f24a05befdaae9b399816cb9c4","proposedBodySha256":"08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899","actualBodySha256":"08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1359","url":"https://linear.app/hash/issue/FE-1359/voice-interviewing-bolt-on-adapter-or-architectural-rewrite","preFetchAt":"2026-08-20T11:00:51.012Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.307Z","sourceUpdatedAt":"2026-08-19T16:20:27.307Z","sourceTitleSha256":"90f6a9c3c8a4623f3635441de84273aab1c8639d9630ecef4b98d16d0623ffcd","sourceBodySha256":"2bfe24356304af451f85f6518453b9b202a67d301b76f9c42fc50fead0b7776b","proposedTitleSha256":"24fe52139a5192afa3a13f0264dd052c25b64dd721942d2e3bfd24b1f0d4137c","proposedBodySha256":"5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1359","url":"https://linear.app/hash/issue/FE-1359/decide-whether-voice-changes-the-elicitor-architecture","postFetchAt":"2026-08-20T11:00:51.885Z","postUpdatedAt":"2026-08-20T11:00:51.481Z","proposedTitleSha256":"24fe52139a5192afa3a13f0264dd052c25b64dd721942d2e3bfd24b1f0d4137c","actualTitleSha256":"24fe52139a5192afa3a13f0264dd052c25b64dd721942d2e3bfd24b1f0d4137c","proposedBodySha256":"5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b","actualBodySha256":"5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1360","url":"https://linear.app/hash/issue/FE-1360/ground-elicitation-strategy-in-the-literature","preFetchAt":"2026-08-20T11:00:52.695Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.656Z","sourceUpdatedAt":"2026-08-19T16:20:27.656Z","sourceTitleSha256":"f9b6d463b4fbd91c31446559b1cb91cb27a2f6080e416c5758e20c81040ea6f9","sourceBodySha256":"25c76c4fe5da56fbfd6fbd123e84e8c544fcb09e3e455ae0924f3924aadebca9","proposedTitleSha256":"7e705b33a3fc5c880137fa49b8805afc4d1d547dd75063206fbb9c64d867c97d","proposedBodySha256":"a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1360","url":"https://linear.app/hash/issue/FE-1360/derive-elicitation-guidance-from-published-research","postFetchAt":"2026-08-20T11:00:53.350Z","postUpdatedAt":"2026-08-20T11:00:53.056Z","proposedTitleSha256":"7e705b33a3fc5c880137fa49b8805afc4d1d547dd75063206fbb9c64d867c97d","actualTitleSha256":"7e705b33a3fc5c880137fa49b8805afc4d1d547dd75063206fbb9c64d867c97d","proposedBodySha256":"a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19","actualBodySha256":"a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1361","url":"https://linear.app/hash/issue/FE-1361/baseline-control-what-does-one-shot-ai-elicitation-already-achieve","preFetchAt":"2026-08-20T11:00:53.647Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.021Z","sourceUpdatedAt":"2026-08-19T16:20:28.021Z","sourceTitleSha256":"89252bf7368aae36924c6a2fb34ace7477a76199a34255b373bda2440a4e9010","sourceBodySha256":"95f7163a475614b062c16230b0ef576e624ead0280d702b97dcac9deb8d575f0","proposedTitleSha256":"af5b3693ff1fe6a3345539ae08530bafa9b2df8a60e5ba708d7833ba963d2a71","proposedBodySha256":"5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1361","url":"https://linear.app/hash/issue/FE-1361/measure-the-one-shot-ai-elicitation-baseline","postFetchAt":"2026-08-20T11:00:54.284Z","postUpdatedAt":"2026-08-20T11:00:53.931Z","proposedTitleSha256":"af5b3693ff1fe6a3345539ae08530bafa9b2df8a60e5ba708d7833ba963d2a71","actualTitleSha256":"af5b3693ff1fe6a3345539ae08530bafa9b2df8a60e5ba708d7833ba963d2a71","proposedBodySha256":"5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8","actualBodySha256":"5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1362","url":"https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle","preFetchAt":"2026-08-20T11:00:54.552Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.338Z","sourceUpdatedAt":"2026-08-19T16:26:28.338Z","sourceTitleSha256":"cdb93df46f8071efeb92a153b4eadcae8d65a4c301e9ab8c5985a2da0576886a","sourceBodySha256":"b7a1b6eea883a9151ce69a93149934c588deeb33fcaf97f19bdc97957d45c230","proposedTitleSha256":"703de24bb88a4bc6802a75b8dca0e0c7d4a09fb93f72aa8c532d8c5853326959","proposedBodySha256":"9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1362","url":"https://linear.app/hash/issue/FE-1362/decide-the-september-demo-architecture","postFetchAt":"2026-08-20T11:00:55.168Z","postUpdatedAt":"2026-08-20T11:00:54.835Z","proposedTitleSha256":"703de24bb88a4bc6802a75b8dca0e0c7d4a09fb93f72aa8c532d8c5853326959","actualTitleSha256":"703de24bb88a4bc6802a75b8dca0e0c7d4a09fb93f72aa8c532d8c5853326959","proposedBodySha256":"9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993","actualBodySha256":"9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1363","url":"https://linear.app/hash/issue/FE-1363/choose-the-reference-use-case-settle-the-sdcpn-showcase-criterion","preFetchAt":"2026-08-20T11:00:55.410Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.274Z","sourceUpdatedAt":"2026-08-19T16:20:28.274Z","sourceTitleSha256":"5a20ee169ead5fc437c962db1ff0db13adc0d1c46776cb8862b5f3a25830c0a7","sourceBodySha256":"ffa0d06dc4022dd33a5921e8c3e2e741f8f9599b632bc6734e051256a5140509","proposedTitleSha256":"d14ab7a091020ba12c4c7eeacc619c18f3099e57703e8ba5cf68efbe17328b8a","proposedBodySha256":"4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1363","url":"https://linear.app/hash/issue/FE-1363/choose-the-demo-use-case-and-modelling-criteria","postFetchAt":"2026-08-20T11:00:56.486Z","postUpdatedAt":"2026-08-20T11:00:56.060Z","proposedTitleSha256":"d14ab7a091020ba12c4c7eeacc619c18f3099e57703e8ba5cf68efbe17328b8a","actualTitleSha256":"d14ab7a091020ba12c4c7eeacc619c18f3099e57703e8ba5cf68efbe17328b8a","proposedBodySha256":"4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97","actualBodySha256":"4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1364","url":"https://linear.app/hash/issue/FE-1364/define-the-intermediate-representation-for-process-model-elicitation","preFetchAt":"2026-08-20T11:00:56.722Z","frozenSourceUpdatedAt":"2026-08-19T16:26:27.321Z","sourceUpdatedAt":"2026-08-19T16:26:27.321Z","sourceTitleSha256":"aa12482b696cc600940045a86c3fdfc36df84ff3e463c29bc2184fbefde75d1e","sourceBodySha256":"a468c2c80f6e27f387ae7cb76493f6cba7f974099060b2617a105535244de04b","proposedTitleSha256":"7ca4533b4bb0e42d0a310e72c5a9a8aae181115af2ad1ffcc85587f49437a3a1","proposedBodySha256":"454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1364","url":"https://linear.app/hash/issue/FE-1364/define-the-process-model-elicitation-representation","postFetchAt":"2026-08-20T11:00:57.380Z","postUpdatedAt":"2026-08-20T11:00:56.995Z","proposedTitleSha256":"7ca4533b4bb0e42d0a310e72c5a9a8aae181115af2ad1ffcc85587f49437a3a1","actualTitleSha256":"7ca4533b4bb0e42d0a310e72c5a9a8aae181115af2ad1ffcc85587f49437a3a1","proposedBodySha256":"454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24","actualBodySha256":"454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1366","url":"https://linear.app/hash/issue/FE-1366/spec-the-elicitation-harness-architecture-archived-wayfinder-map","preFetchAt":"2026-08-20T11:00:57.618Z","frozenSourceUpdatedAt":"2026-08-19T16:26:24.440Z","sourceUpdatedAt":"2026-08-19T16:26:24.440Z","sourceTitleSha256":"3cd9b3e42040c5bd4f19c7ccb505e838266683b4098bb7d02934b03c8df8f6b5","sourceBodySha256":"991af4e8570535aa208f829fd81107ebcf5163186d25837f78746cee7ed77015","proposedTitleSha256":"ecd6270308cb53c1cddecbd489543f583a9d2850c1bcb29aa919e7fcf0c588dd","proposedBodySha256":"d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1366","url":"https://linear.app/hash/issue/FE-1366/document-the-elicitation-harness-architecture","postFetchAt":"2026-08-20T11:00:58.405Z","postUpdatedAt":"2026-08-20T11:00:58.023Z","proposedTitleSha256":"ecd6270308cb53c1cddecbd489543f583a9d2850c1bcb29aa919e7fcf0c588dd","actualTitleSha256":"ecd6270308cb53c1cddecbd489543f583a9d2850c1bcb29aa919e7fcf0c588dd","proposedBodySha256":"d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d","actualBodySha256":"d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1367","url":"https://linear.app/hash/issue/FE-1367/flue-architecture-deep-read-archive","preFetchAt":"2026-08-20T11:00:58.661Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.414Z","sourceUpdatedAt":"2026-08-19T16:20:27.414Z","sourceTitleSha256":"d56adb14bff1dbfe03cac1c1c2a312d5fc3ac3693b36a8324c59c080ef5aea2a","sourceBodySha256":"5f6506ff45d1964c8545e824d2c5b8f989410ac176bfa5fef6b9cfe150109239","proposedTitleSha256":"56a728873a351ffa5abcb9e165694d1c6a882e43fc29d126ab46598a482465aa","proposedBodySha256":"0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1367","url":"https://linear.app/hash/issue/FE-1367/define-how-the-elicitation-harness-uses-flue","postFetchAt":"2026-08-20T11:00:59.398Z","postUpdatedAt":"2026-08-20T11:00:59.003Z","proposedTitleSha256":"56a728873a351ffa5abcb9e165694d1c6a882e43fc29d126ab46598a482465aa","actualTitleSha256":"56a728873a351ffa5abcb9e165694d1c6a882e43fc29d126ab46598a482465aa","proposedBodySha256":"0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2","actualBodySha256":"0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1368","url":"https://linear.app/hash/issue/FE-1368/zil-lean-survey-archive","preFetchAt":"2026-08-20T11:00:59.662Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.450Z","sourceUpdatedAt":"2026-08-19T16:20:27.450Z","sourceTitleSha256":"aa2bdea3725452e09651b2a77e90deef72ab518995b82968d256935035bf1dad","sourceBodySha256":"a34174377a2da0548781191d7cbb33e606fb329065a5f14afe4d22454917596f","proposedTitleSha256":"671c8d7d2ec1d02dd04e6791f04e91d907c514f38ea3e8bbf371757bcd44d183","proposedBodySha256":"58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1368","url":"https://linear.app/hash/issue/FE-1368/assess-zil-lean-as-an-elicitation-subject","postFetchAt":"2026-08-20T11:01:00.564Z","postUpdatedAt":"2026-08-20T11:01:00.028Z","proposedTitleSha256":"671c8d7d2ec1d02dd04e6791f04e91d907c514f38ea3e8bbf371757bcd44d183","actualTitleSha256":"671c8d7d2ec1d02dd04e6791f04e91d907c514f38ea3e8bbf371757bcd44d183","proposedBodySha256":"58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70","actualBodySha256":"58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1369","url":"https://linear.app/hash/issue/FE-1369/brunch-exchange-schema-audit-archive","preFetchAt":"2026-08-20T11:01:00.827Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.340Z","sourceUpdatedAt":"2026-08-19T16:20:27.340Z","sourceTitleSha256":"dfdef0d5ba4e9548fd25e728e40fb8685c0bd6e0daa4432d3793d8d5d6cb85e6","sourceBodySha256":"1fd94e7b433040097a806d169e9cd702bb67db2dcbf906a5e197e678ed4249c2","proposedTitleSha256":"ad51b1463946bcbcf00e57b7bffac75180cde408d6db865a9c2bf8349597a4d2","proposedBodySha256":"f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1369","url":"https://linear.app/hash/issue/FE-1369/classify-brunch-exchange-structures-for-reuse","postFetchAt":"2026-08-20T11:01:02.019Z","postUpdatedAt":"2026-08-20T11:01:01.421Z","proposedTitleSha256":"ad51b1463946bcbcf00e57b7bffac75180cde408d6db865a9c2bf8349597a4d2","actualTitleSha256":"ad51b1463946bcbcf00e57b7bffac75180cde408d6db865a9c2bf8349597a4d2","proposedBodySha256":"f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d","actualBodySha256":"f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1370","url":"https://linear.app/hash/issue/FE-1370/contract-decomposition-kernel-host-plugin-pack-boundary-archive","preFetchAt":"2026-08-20T11:01:02.268Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.501Z","sourceUpdatedAt":"2026-08-19T16:20:27.501Z","sourceTitleSha256":"e26e5d7d5c992fae3d3148ce48e892d0f0246c65aace5cb2f76f686181b778a8","sourceBodySha256":"2234383db65ad51aafd0ef50877851b0449988ebd0e1c57173120549a6f95c11","proposedTitleSha256":"fff1e6cd68dee8290e99e3b5a27ef3e63a5a20a6f634b058724ca33d08cb32aa","proposedBodySha256":"586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1370","url":"https://linear.app/hash/issue/FE-1370/define-the-harness-and-plugin-responsibilities","postFetchAt":"2026-08-20T11:01:03.027Z","postUpdatedAt":"2026-08-20T11:01:02.574Z","proposedTitleSha256":"fff1e6cd68dee8290e99e3b5a27ef3e63a5a20a6f634b058724ca33d08cb32aa","actualTitleSha256":"fff1e6cd68dee8290e99e3b5a27ef3e63a5a20a6f634b058724ca33d08cb32aa","proposedBodySha256":"586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b","actualBodySha256":"586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1371","url":"https://linear.app/hash/issue/FE-1371/questioning-ux-contract-archive","preFetchAt":"2026-08-20T11:01:03.774Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.539Z","sourceUpdatedAt":"2026-08-19T16:20:27.539Z","sourceTitleSha256":"9c5bb4c0020f39dc129390162dbb882bf463fa6e089c5000047f64924d49f497","sourceBodySha256":"7ec025083f39f180878790e096ec19c369a7d4120c839730dacc7fe7980cc9fb","proposedTitleSha256":"6df3270da2d36b2ce6b9f28706d1d60830de04f2a7284ce91e04bab6c5440116","proposedBodySha256":"8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1371","url":"https://linear.app/hash/issue/FE-1371/define-structured-questions-within-conversation","postFetchAt":"2026-08-20T11:01:04.601Z","postUpdatedAt":"2026-08-20T11:01:04.082Z","proposedTitleSha256":"6df3270da2d36b2ce6b9f28706d1d60830de04f2a7284ce91e04bab6c5440116","actualTitleSha256":"6df3270da2d36b2ce6b9f28706d1d60830de04f2a7284ce91e04bab6c5440116","proposedBodySha256":"8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f","actualBodySha256":"8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1372","url":"https://linear.app/hash/issue/FE-1372/shipping-shape-kernel-library-vs-flue-agent-archive","preFetchAt":"2026-08-20T11:01:04.940Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.583Z","sourceUpdatedAt":"2026-08-19T16:20:27.583Z","sourceTitleSha256":"1dab9baee26c9752955fa86d601f08aed2a362b5cf4c721084b6f2259ab68b68","sourceBodySha256":"b0f7c959583b663416d505a36c08f6db34f037d1bf8842b950cddce5797462c5","proposedTitleSha256":"f62fc5f62252c5cd20b94fe9527ab32111d710f20b95513c430b0b89e389a89d","proposedBodySha256":"4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1372","url":"https://linear.app/hash/issue/FE-1372/choose-how-the-elicitation-harness-ships","postFetchAt":"2026-08-20T11:01:05.553Z","postUpdatedAt":"2026-08-20T11:01:05.224Z","proposedTitleSha256":"f62fc5f62252c5cd20b94fe9527ab32111d710f20b95513c430b0b89e389a89d","actualTitleSha256":"f62fc5f62252c5cd20b94fe9527ab32111d710f20b95513c430b0b89e389a89d","proposedBodySha256":"4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e","actualBodySha256":"4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1373","url":"https://linear.app/hash/issue/FE-1373/dev-target-portfolio-confirmation-archive","preFetchAt":"2026-08-20T11:01:05.978Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.618Z","sourceUpdatedAt":"2026-08-19T16:20:27.618Z","sourceTitleSha256":"f716acc84bd7e8b18c26d9f5020804c103bd5a28cd5f957f643d47885903a973","sourceBodySha256":"a1a499c06b23735a1b16cabcc6c787f35c1e3fda3af30f09c87927173b54f426","proposedTitleSha256":"49526b09da7cea4f956b0fc97da3a537287b6e1dc0a5599a0dc744273bbd4057","proposedBodySha256":"3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1373","url":"https://linear.app/hash/issue/FE-1373/choose-the-initial-elicitation-subjects","postFetchAt":"2026-08-20T11:01:06.579Z","postUpdatedAt":"2026-08-20T11:01:06.262Z","proposedTitleSha256":"49526b09da7cea4f956b0fc97da3a537287b6e1dc0a5599a0dc744273bbd4057","actualTitleSha256":"49526b09da7cea4f956b0fc97da3a537287b6e1dc0a5599a0dc744273bbd4057","proposedBodySha256":"3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03","actualBodySha256":"3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1374","url":"https://linear.app/hash/issue/FE-1374/assemble-the-spec-archive","preFetchAt":"2026-08-20T11:01:06.811Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.406Z","sourceUpdatedAt":"2026-08-19T16:20:26.406Z","sourceTitleSha256":"e0ef68909d31cd8e17da3910dd6beb59c3fd02068b82f7a8179a35a498f40f44","sourceBodySha256":"a61865e7695eb3e3170612f0101ffd8bf4dd97c8322fc08c4bd129d2ea0828c1","proposedTitleSha256":"a8d6e8af11c31f8e0b937ba43b6d758e79988d751f29a1222bb5097e33ce4f78","proposedBodySha256":"cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1374","url":"https://linear.app/hash/issue/FE-1374/assemble-the-elicitation-harness-specification","postFetchAt":"2026-08-20T11:01:07.440Z","postUpdatedAt":"2026-08-20T11:01:07.086Z","proposedTitleSha256":"a8d6e8af11c31f8e0b937ba43b6d758e79988d751f29a1222bb5097e33ce4f78","actualTitleSha256":"a8d6e8af11c31f8e0b937ba43b6d758e79988d751f29a1222bb5097e33ce4f78","proposedBodySha256":"cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0","actualBodySha256":"cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1375","url":"https://linear.app/hash/issue/FE-1375/formal-verification-canon-survey-archive","preFetchAt":"2026-08-20T11:01:07.745Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.379Z","sourceUpdatedAt":"2026-08-19T16:20:27.379Z","sourceTitleSha256":"686845995b96dbb4605c51d32a3db23e65fe13afab1b3d29fb71ac0f3aa751f5","sourceBodySha256":"da21a9ce028674fd3a68be0b7b6401585fa9af23cd013781a53c1d1a8a1a787c","proposedTitleSha256":"1014535547f1f5612dda184fea1218227d4b4674f4bf9b18fa3c9d9841c9740a","proposedBodySha256":"f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1375","url":"https://linear.app/hash/issue/FE-1375/align-the-assurance-subject-with-verification-practice","postFetchAt":"2026-08-20T11:01:08.495Z","postUpdatedAt":"2026-08-20T11:01:08.093Z","proposedTitleSha256":"1014535547f1f5612dda184fea1218227d4b4674f4bf9b18fa3c9d9841c9740a","actualTitleSha256":"1014535547f1f5612dda184fea1218227d4b4674f4bf9b18fa3c9d9841c9740a","proposedBodySha256":"f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c","actualBodySha256":"f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1376","url":"https://linear.app/hash/issue/FE-1376/walking-skeleton-flue-question-round-trip-archive","preFetchAt":"2026-08-20T11:01:09.596Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.447Z","sourceUpdatedAt":"2026-08-19T16:20:26.447Z","sourceTitleSha256":"b44606046ef4f88db1c99ea98b64ca1c22da4d2dbe757268232851b775131f77","sourceBodySha256":"ed9a8f3a2277d2bbb6122af8c449793c65672faa235173b5d51d657f8e5dc3c6","proposedTitleSha256":"780a9ff8453c76d6b8fd253a634ef6049f1ef97808e74451361e164bac65ab98","proposedBodySha256":"3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1376","url":"https://linear.app/hash/issue/FE-1376/prove-a-flue-question-round-trip","postFetchAt":"2026-08-20T11:01:10.379Z","postUpdatedAt":"2026-08-20T11:01:09.911Z","proposedTitleSha256":"780a9ff8453c76d6b8fd253a634ef6049f1ef97808e74451361e164bac65ab98","actualTitleSha256":"780a9ff8453c76d6b8fd253a634ef6049f1ef97808e74451361e164bac65ab98","proposedBodySha256":"3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec","actualBodySha256":"3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1377","url":"https://linear.app/hash/issue/FE-1377/logic-prototype-capture-sweep-and-settlement-archive","preFetchAt":"2026-08-20T11:01:10.649Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.491Z","sourceUpdatedAt":"2026-08-19T16:20:26.491Z","sourceTitleSha256":"37acb34d281af002054f9c0cecaececb353463f7bd3f37b592c050efcb5076f7","sourceBodySha256":"1f7efed2a48a98b6b9ddb02cce3aef6afedb49aeb7ba33415ca5a32dfc38b908","proposedTitleSha256":"5679461ba36f1b7ddc1d98c64e7f54b59038d3e217d0722c2953b1f2044b99bd","proposedBodySha256":"fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1377","url":"https://linear.app/hash/issue/FE-1377/prove-repeatable-conversation-capture","postFetchAt":"2026-08-20T11:01:11.338Z","postUpdatedAt":"2026-08-20T11:01:10.954Z","proposedTitleSha256":"5679461ba36f1b7ddc1d98c64e7f54b59038d3e217d0722c2953b1f2044b99bd","actualTitleSha256":"5679461ba36f1b7ddc1d98c64e7f54b59038d3e217d0722c2953b1f2044b99bd","proposedBodySha256":"fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba","actualBodySha256":"fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1378","url":"https://linear.app/hash/issue/FE-1378/multi-session-elicitation-and-durable-target-state-archive","preFetchAt":"2026-08-20T11:01:11.645Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.948Z","sourceUpdatedAt":"2026-08-19T16:20:26.948Z","sourceTitleSha256":"a0a6d108d755c05072d5afcc84ed4ebddb1d01b3b55c339dbfb22662c6bad90a","sourceBodySha256":"4a2e6fa5bc9e664bf7fed660d561ed2a843aa2f99509734de0773e29b169c8ca","proposedTitleSha256":"442998135a28eb368d03b58a5ec32ff9fbd4ee0743b7afc16030e3dac70494cf","proposedBodySha256":"77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1378","url":"https://linear.app/hash/issue/FE-1378/define-durable-state-across-elicitation-sessions","postFetchAt":"2026-08-20T11:01:12.266Z","postUpdatedAt":"2026-08-20T11:01:11.912Z","proposedTitleSha256":"442998135a28eb368d03b58a5ec32ff9fbd4ee0743b7afc16030e3dac70494cf","actualTitleSha256":"442998135a28eb368d03b58a5ec32ff9fbd4ee0743b7afc16030e3dac70494cf","proposedBodySha256":"77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065","actualBodySha256":"77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1379","url":"https://linear.app/hash/issue/FE-1379/walking-skeleton-sweep-seam-on-flue-archive","preFetchAt":"2026-08-20T11:01:12.503Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.560Z","sourceUpdatedAt":"2026-08-19T16:20:26.560Z","sourceTitleSha256":"4508ec17020f4110e54e4fd9bb6409653fa6051f503485280387d982b90eae6f","sourceBodySha256":"77ba77f249d1d1e88dda09de03554a2672f52d91e2e75261cfdbe0520f3c4cb7","proposedTitleSha256":"d11a2dcabcaa56f89789e629bc0d41d5d4756ee3702e7cff79bea4e6f2074ad5","proposedBodySha256":"3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1379","url":"https://linear.app/hash/issue/FE-1379/prove-the-remaining-flue-capabilities","postFetchAt":"2026-08-20T11:01:13.338Z","postUpdatedAt":"2026-08-20T11:01:12.831Z","proposedTitleSha256":"d11a2dcabcaa56f89789e629bc0d41d5d4756ee3702e7cff79bea4e6f2074ad5","actualTitleSha256":"d11a2dcabcaa56f89789e629bc0d41d5d4756ee3702e7cff79bea4e6f2074ad5","proposedBodySha256":"3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c","actualBodySha256":"3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1382","url":"https://linear.app/hash/issue/FE-1382/source-dossier-published-fleet-maintenance-models-operational-data-for","preFetchAt":"2026-08-20T11:01:13.582Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.109Z","sourceUpdatedAt":"2026-08-19T16:20:26.109Z","sourceTitleSha256":"8789e5d3309cda42c6acf9fc2fb9ed8f3fd7f223fd4c9a5b31475a5f39510bca","sourceBodySha256":"98a2f626e1fc039a1f81b0d0fa6ecdf6a39c1fa525a4494097e78c3fb3688c34","proposedTitleSha256":"cca762a296ff0a645b3398b349a1aba34b009e2a72520cd6ca50a1995ecbf782","proposedBodySha256":"dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1382","url":"https://linear.app/hash/issue/FE-1382/compile-the-truck-fleet-source-dossier","postFetchAt":"2026-08-20T11:01:14.272Z","postUpdatedAt":"2026-08-20T11:01:13.930Z","proposedTitleSha256":"cca762a296ff0a645b3398b349a1aba34b009e2a72520cd6ca50a1995ecbf782","actualTitleSha256":"cca762a296ff0a645b3398b349a1aba34b009e2a72520cd6ca50a1995ecbf782","proposedBodySha256":"dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f","actualBodySha256":"dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1383","url":"https://linear.app/hash/issue/FE-1383/build-the-elicitation-harness-to-milestone-one-an-interview-that","preFetchAt":"2026-08-20T11:01:14.575Z","frozenSourceUpdatedAt":"2026-08-19T16:26:28.251Z","sourceUpdatedAt":"2026-08-19T16:26:28.251Z","sourceTitleSha256":"d5fbe781b6392a20e99ebbcd938e2556a3591b1eec6b089aa46e450fc54abd2b","sourceBodySha256":"6ffa6c3bd7e56e39402e2b9b3c4a6dca3a3d926202fcfa19b6d41feecdadf78d","proposedTitleSha256":"e16c710e0bf421f6afd4e73b0924ece8d021e65511fe57aef680f3f7854d0577","proposedBodySha256":"3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1383","url":"https://linear.app/hash/issue/FE-1383/build-the-first-complete-elicitation-interview","postFetchAt":"2026-08-20T11:01:15.204Z","postUpdatedAt":"2026-08-20T11:01:14.845Z","proposedTitleSha256":"e16c710e0bf421f6afd4e73b0924ece8d021e65511fe57aef680f3f7854d0577","actualTitleSha256":"e16c710e0bf421f6afd4e73b0924ece8d021e65511fe57aef680f3f7854d0577","proposedBodySha256":"3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb","actualBodySha256":"3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1384","url":"https://linear.app/hash/issue/FE-1384/generative-test-corpus-over-the-replay-driver","preFetchAt":"2026-08-20T11:01:15.595Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.528Z","sourceUpdatedAt":"2026-08-19T16:20:26.528Z","sourceTitleSha256":"34fd893cbe8f38105a28d034e986b36d093d2bb616f11fd3705d9a89ca11a606","sourceBodySha256":"dc23151710c724730fd5e28460cf1e18ad96ee9b6faf63acf4c4385c7b963ab8","proposedTitleSha256":"d578f097f2c89e3b8d52f319f960726bafe7bdf786a8ee7cd7613c52cc1708ed","proposedBodySha256":"bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1384","url":"https://linear.app/hash/issue/FE-1384/generate-replay-tests-for-the-harness-rules","postFetchAt":"2026-08-20T11:01:16.386Z","postUpdatedAt":"2026-08-20T11:01:15.906Z","proposedTitleSha256":"d578f097f2c89e3b8d52f319f960726bafe7bdf786a8ee7cd7613c52cc1708ed","actualTitleSha256":"d578f097f2c89e3b8d52f319f960726bafe7bdf786a8ee7cd7613c52cc1708ed","proposedBodySha256":"bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c","actualBodySha256":"bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1385","url":"https://linear.app/hash/issue/FE-1385/dev-app-target-gallery-and-diagnostic-probe-surface","preFetchAt":"2026-08-20T11:01:16.680Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.147Z","sourceUpdatedAt":"2026-08-19T16:20:26.147Z","sourceTitleSha256":"7e4a538631309c52c61b4d6d4e1d405aa54ba435c20f18e8684b3f2a020ceedb","sourceBodySha256":"1bd36079855c694a19c2c16781b8fe79cb03ea9ed3cd3bbce9b31f3ba0993cb4","proposedTitleSha256":"735ae093eeaea26baacee13aa32bf1a2903b9ea666421c903d460c1987a63543","proposedBodySha256":"9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1385","url":"https://linear.app/hash/issue/FE-1385/expand-the-dev-app-into-a-target-gallery-and-diagnostic-view","postFetchAt":"2026-08-20T11:01:17.304Z","postUpdatedAt":"2026-08-20T11:01:16.969Z","proposedTitleSha256":"735ae093eeaea26baacee13aa32bf1a2903b9ea666421c903d460c1987a63543","actualTitleSha256":"735ae093eeaea26baacee13aa32bf1a2903b9ea666421c903d460c1987a63543","proposedBodySha256":"9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6","actualBodySha256":"9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1386","url":"https://linear.app/hash/issue/FE-1386/verify-compaction-leaves-the-durable-entry-projection-intact","preFetchAt":"2026-08-20T11:01:17.544Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.302Z","sourceUpdatedAt":"2026-08-19T16:20:26.302Z","sourceTitleSha256":"e290d7dbfc6823fb2391b9835c7851aac4dcfd7266cbcca1076a83916a843bc0","sourceBodySha256":"b032d11e90f77e094632a0437a00a3b19ba43f3b74d851fda5f9983d7059a675","proposedTitleSha256":"828d7efb7c4bde98357f8ea410087cc82d009524241bc6f8a4dbab46d701c2a0","proposedBodySha256":"6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1386","url":"https://linear.app/hash/issue/FE-1386/test-durable-history-across-transcript-compaction","postFetchAt":"2026-08-20T11:01:18.172Z","postUpdatedAt":"2026-08-20T11:01:17.820Z","proposedTitleSha256":"828d7efb7c4bde98357f8ea410087cc82d009524241bc6f8a4dbab46d701c2a0","actualTitleSha256":"828d7efb7c4bde98357f8ea410087cc82d009524241bc6f8a4dbab46d701c2a0","proposedBodySha256":"6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f","actualBodySha256":"6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1387","url":"https://linear.app/hash/issue/FE-1387/author-the-second-pack-and-freeze-the-plugin-contract","preFetchAt":"2026-08-20T11:01:18.441Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.344Z","sourceUpdatedAt":"2026-08-19T16:20:26.344Z","sourceTitleSha256":"1e34347c94852da08269de757dd7c58086a76b740fcff0e69c8104de4853eff7","sourceBodySha256":"0e246edd61bf61e1ca4ca67103d4f396f0d7b1d11611474727197431788ca94b","proposedTitleSha256":"37bf181908327ddd86b0e09bc446b5eb02383a441693d6a9fa604d7455756205","proposedBodySha256":"e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1387","url":"https://linear.app/hash/issue/FE-1387/choose-a-second-target-and-stabilize-the-plugin-interface","postFetchAt":"2026-08-20T11:01:19.040Z","postUpdatedAt":"2026-08-20T11:01:18.698Z","proposedTitleSha256":"37bf181908327ddd86b0e09bc446b5eb02383a441693d6a9fa604d7455756205","actualTitleSha256":"37bf181908327ddd86b0e09bc446b5eb02383a441693d6a9fa604d7455756205","proposedBodySha256":"e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a","actualBodySha256":"e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1388","url":"https://linear.app/hash/issue/FE-1388/scaffold-the-bun-workspace-and-prove-the-ci-smoke","preFetchAt":"2026-08-20T11:01:19.362Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.054Z","sourceUpdatedAt":"2026-08-19T16:20:27.054Z","sourceTitleSha256":"1f553d53fd1c4493bf1808505a85c8275a908f377cc646c3d822d7ee9cc4a4b7","sourceBodySha256":"5b79a1a15bf83d384bc11b114188db2252eeec734c0299f196f56f83c59a4d94","proposedTitleSha256":"cba702bfe08fbfe6c118f53f94058b89f4e279b1e65f7eaec8f8a764dcc99249","proposedBodySha256":"09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1388","url":"https://linear.app/hash/issue/FE-1388/create-the-bun-workspace-and-enforce-dependency-boundaries","postFetchAt":"2026-08-20T11:01:19.949Z","postUpdatedAt":"2026-08-20T11:01:19.623Z","proposedTitleSha256":"cba702bfe08fbfe6c118f53f94058b89f4e279b1e65f7eaec8f8a764dcc99249","actualTitleSha256":"cba702bfe08fbfe6c118f53f94058b89f4e279b1e65f7eaec8f8a764dcc99249","proposedBodySha256":"09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b","actualBodySha256":"09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1389","url":"https://linear.app/hash/issue/FE-1389/walking-skeleton-the-harness-asks-a-free-text-question-and-binds-the","preFetchAt":"2026-08-20T11:01:20.312Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.046Z","sourceUpdatedAt":"2026-08-19T16:20:28.046Z","sourceTitleSha256":"02a0530dca8c589424e2bc9a4813afe1a1cf33887212424ba50fdeba8cb20a49","sourceBodySha256":"3623852992eec05f9567c745d0d253773713feb486dbef929fc28db16f7a317c","proposedTitleSha256":"671d58f11fdffe9a2aef0c9355b44e9b1e5c66d0c25504369b6a25de54e0a6b3","proposedBodySha256":"61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1389","url":"https://linear.app/hash/issue/FE-1389/implement-the-first-suspended-free-text-question","postFetchAt":"2026-08-20T11:01:20.990Z","postUpdatedAt":"2026-08-20T11:01:20.583Z","proposedTitleSha256":"671d58f11fdffe9a2aef0c9355b44e9b1e5c66d0c25504369b6a25de54e0a6b3","actualTitleSha256":"671d58f11fdffe9a2aef0c9355b44e9b1e5c66d0c25504369b6a25de54e0a6b3","proposedBodySha256":"61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80","actualBodySha256":"61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1390","url":"https://linear.app/hash/issue/FE-1390/capture-envelope-storage-port-and-the-local-capture-store","preFetchAt":"2026-08-20T11:01:21.270Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.947Z","sourceUpdatedAt":"2026-08-19T16:20:27.947Z","sourceTitleSha256":"79014f58a3fcbcbe710117e024203f408d2c85b31178827f4e2a1f2f7c50d74b","sourceBodySha256":"dce103e6c13f999a39d866e51e61826185cc97f34dd221baa2a8b8f55bf77826","proposedTitleSha256":"4f9a2a6a52ee76fc88cf973ed854c90d5a3425c1b81d444fdee080bb2736c392","proposedBodySha256":"6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1390","url":"https://linear.app/hash/issue/FE-1390/implement-capture-history-and-local-persistence","postFetchAt":"2026-08-20T11:01:22.191Z","postUpdatedAt":"2026-08-20T11:01:21.541Z","proposedTitleSha256":"4f9a2a6a52ee76fc88cf973ed854c90d5a3425c1b81d444fdee080bb2736c392","actualTitleSha256":"4f9a2a6a52ee76fc88cf973ed854c90d5a3425c1b81d444fdee080bb2736c392","proposedBodySha256":"6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad","actualBodySha256":"6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1391","url":"https://linear.app/hash/issue/FE-1391/durable-entry-projection-harness-resolved-anchoring-and-the-session","preFetchAt":"2026-08-20T11:01:22.490Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.636Z","sourceUpdatedAt":"2026-08-20T08:02:56.636Z","sourceTitleSha256":"64ec7826e8f32ec6ab84c8a8b36879fb5b9b6c7153d9f5ff3fca2616a42ff230","sourceBodySha256":"464a7faf1c52aa7bbc16b542aee5d1085fff78cd671575e61dd832e2ec6295d0","proposedTitleSha256":"cc41527c73a8817b0d2f23773f40b6d72de92f3d91a5a2c6b5259a68861de1c8","proposedBodySha256":"a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1391","url":"https://linear.app/hash/issue/FE-1391/resolve-evidence-quotes-to-durable-conversation-entries","postFetchAt":"2026-08-20T11:01:23.150Z","postUpdatedAt":"2026-08-20T11:01:22.808Z","proposedTitleSha256":"cc41527c73a8817b0d2f23773f40b6d72de92f3d91a5a2c6b5259a68861de1c8","actualTitleSha256":"cc41527c73a8817b0d2f23773f40b6d72de92f3d91a5a2c6b5259a68861de1c8","proposedBodySha256":"a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683","actualBodySha256":"a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1392","url":"https://linear.app/hash/issue/FE-1392/settlement-trigger-and-sweep-the-first-captured-statement","preFetchAt":"2026-08-20T11:01:23.399Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.825Z","sourceUpdatedAt":"2026-08-20T08:02:56.825Z","sourceTitleSha256":"dc560fe9d1bf4ae882310eb8563baa90c49375e0ab8009a2069bddb5877fe98f","sourceBodySha256":"7a58e8a4d7e8960c3b41b0b0a91396e7c14f002f3fbf68ec63aa3dfdc8e46b3b","proposedTitleSha256":"e5bc000d22834d39bfc4daefdec98c8bca2cb0883dc5d4e2a4e44b0f47e7d8a6","proposedBodySha256":"71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1392","url":"https://linear.app/hash/issue/FE-1392/capture-settled-conversation-statements-safely","postFetchAt":"2026-08-20T11:01:24.048Z","postUpdatedAt":"2026-08-20T11:01:23.655Z","proposedTitleSha256":"e5bc000d22834d39bfc4daefdec98c8bca2cb0883dc5d4e2a4e44b0f47e7d8a6","actualTitleSha256":"e5bc000d22834d39bfc4daefdec98c8bca2cb0883dc5d4e2a4e44b0f47e7d8a6","proposedBodySha256":"71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d","actualBodySha256":"71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1393","url":"https://linear.app/hash/issue/FE-1393/plugin-sdk-and-the-gherkin-plugin-the-first-projected-artifact","preFetchAt":"2026-08-20T11:01:24.375Z","frozenSourceUpdatedAt":"2026-08-19T16:20:25.951Z","sourceUpdatedAt":"2026-08-19T16:20:25.951Z","sourceTitleSha256":"c19a8e89dc13b6eb7cf8b1e023e20a8f82ef1d254ab865caf2fdea5e2a463a3a","sourceBodySha256":"eb4be2fba6a05bdbcdace930230c21ca24be097e2d707bcbf8441cebeb1367c8","proposedTitleSha256":"a7ae805905d5b1a216a522c1492669e21aca11ab15eb0892cbcd4a44e84d6dec","proposedBodySha256":"9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1393","url":"https://linear.app/hash/issue/FE-1393/produce-the-first-gherkin-artifact-through-the-plugin-sdk","postFetchAt":"2026-08-20T11:01:25.046Z","postUpdatedAt":"2026-08-20T11:01:24.693Z","proposedTitleSha256":"a7ae805905d5b1a216a522c1492669e21aca11ab15eb0892cbcd4a44e84d6dec","actualTitleSha256":"a7ae805905d5b1a216a522c1492669e21aca11ab15eb0892cbcd4a44e84d6dec","proposedBodySha256":"9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe","actualBodySha256":"9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1394","url":"https://linear.app/hash/issue/FE-1394/conflict-supersession-and-the-interpretation-render","preFetchAt":"2026-08-20T11:01:25.293Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.378Z","sourceUpdatedAt":"2026-08-19T16:20:26.378Z","sourceTitleSha256":"300684bbdff69dcc7f9ee11eb17102a826a7e24bfd5cc9b47d7c2cc6fa5c6693","sourceBodySha256":"59342c6a55a213c528d8566c757ac6a85af9a08819e19af57664798e93b8d2ef","proposedTitleSha256":"8e8cc690f434c0e6b827fec9acd5887087cd5e638347b55a486eab0b5139a497","proposedBodySha256":"3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1394","url":"https://linear.app/hash/issue/FE-1394/preserve-conflicts-until-the-user-resolves-them","postFetchAt":"2026-08-20T11:01:26.341Z","postUpdatedAt":"2026-08-20T11:01:25.600Z","proposedTitleSha256":"8e8cc690f434c0e6b827fec9acd5887087cd5e638347b55a486eab0b5139a497","actualTitleSha256":"8e8cc690f434c0e6b827fec9acd5887087cd5e638347b55a486eab0b5139a497","proposedBodySha256":"3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1","actualBodySha256":"3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1395","url":"https://linear.app/hash/issue/FE-1395/the-full-affordance-set-choices-questionnaire-chaining-and-the-absence","preFetchAt":"2026-08-20T11:01:26.699Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.675Z","sourceUpdatedAt":"2026-08-19T16:20:26.675Z","sourceTitleSha256":"3c8ed19b489983343fae2ea6dcbced4c87330e476f984fb75fa9937fb1974f67","sourceBodySha256":"2a5426c3cda4bfd5d3b5e7451880acfb2000efd8f906ae9512651fa23aa94d01","proposedTitleSha256":"9142527acadbf1d1d8d0a777a129404cc15df6c4471aacc2fe91601b2c470397","proposedBodySha256":"325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1395","url":"https://linear.app/hash/issue/FE-1395/add-choices-questionnaires-and-explicit-absence-replies","postFetchAt":"2026-08-20T11:01:27.305Z","postUpdatedAt":"2026-08-20T11:01:26.966Z","proposedTitleSha256":"9142527acadbf1d1d8d0a777a129404cc15df6c4471aacc2fe91601b2c470397","actualTitleSha256":"9142527acadbf1d1d8d0a777a129404cc15df6c4471aacc2fe91601b2c470397","proposedBodySha256":"325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318","actualBodySha256":"325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1396","url":"https://linear.app/hash/issue/FE-1396/re-entry-briefing-resume-reconciliation-and-restart-durability","preFetchAt":"2026-08-20T11:01:27.814Z","frozenSourceUpdatedAt":"2026-08-19T16:20:25.918Z","sourceUpdatedAt":"2026-08-19T16:20:25.918Z","sourceTitleSha256":"81da9d71280d7fa1fd21ba19d101e1cd02d113fd2e626f425d50ea302efe93f8","sourceBodySha256":"a107fcbcc646a6054c66bd208141252bda7298308546c689e1fcf9d0ff79d797","proposedTitleSha256":"66b2c12e3036f132c63ee071cd1e98f126bccccf9223062effe4e2f9c3658084","proposedBodySha256":"60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1396","url":"https://linear.app/hash/issue/FE-1396/restore-interview-context-after-resume-and-restart","postFetchAt":"2026-08-20T11:01:28.444Z","postUpdatedAt":"2026-08-20T11:01:28.090Z","proposedTitleSha256":"66b2c12e3036f132c63ee071cd1e98f126bccccf9223062effe4e2f9c3658084","actualTitleSha256":"66b2c12e3036f132c63ee071cd1e98f126bccccf9223062effe4e2f9c3658084","proposedBodySha256":"60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59","actualBodySha256":"60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1397","url":"https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-definition-against-worked-payload-designs","preFetchAt":"2026-08-20T11:01:28.694Z","frozenSourceUpdatedAt":"2026-08-19T16:19:46.091Z","sourceUpdatedAt":"2026-08-19T16:19:46.091Z","sourceTitleSha256":"57101af27a029ed36c454595d43f1a63d722dc7fecde14313f61c122f3ff195b","sourceBodySha256":"676e3faa8b8d4801db351f8c82bdf8899036df30c8a5b2789d9a3f3e2b2ca534","proposedTitleSha256":"f07438c59634073e97ad1225c8b971ececa39d27ebd19aa27958da8e4eb11bf6","proposedBodySha256":"728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1397","url":"https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-against-worked-plugin-payloads","postFetchAt":"2026-08-20T11:01:29.298Z","postUpdatedAt":"2026-08-20T11:01:28.974Z","proposedTitleSha256":"f07438c59634073e97ad1225c8b971ececa39d27ebd19aa27958da8e4eb11bf6","actualTitleSha256":"f07438c59634073e97ad1225c8b971ececa39d27ebd19aa27958da8e4eb11bf6","proposedBodySha256":"728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf","actualBodySha256":"728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1399","url":"https://linear.app/hash/issue/FE-1399/make-the-ci-gates-and-dev-app-fail-loudly-where-review-found-they-fail","preFetchAt":"2026-08-20T11:01:29.565Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.590Z","sourceUpdatedAt":"2026-08-19T16:20:26.590Z","sourceTitleSha256":"2dccdd3bedc0bb7b28b086c4a1c0c8da6c68a894767abe0713ba8b3550a581d7","sourceBodySha256":"6b0a691af9b858b532b0ac30b62f352fcf19afc87071534e5f6ea25b13cc6379","proposedTitleSha256":"a376b90e615f99d8f593ca82d7aebcf143ae49697119f3126cf511dea4242c64","proposedBodySha256":"93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1399","url":"https://linear.app/hash/issue/FE-1399/fix-verified-silent-failures-in-ci-and-the-dev-app","postFetchAt":"2026-08-20T11:01:30.247Z","postUpdatedAt":"2026-08-20T11:01:29.815Z","proposedTitleSha256":"a376b90e615f99d8f593ca82d7aebcf143ae49697119f3126cf511dea4242c64","actualTitleSha256":"a376b90e615f99d8f593ca82d7aebcf143ae49697119f3126cf511dea4242c64","proposedBodySha256":"93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221","actualBodySha256":"93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1400","url":"https://linear.app/hash/issue/FE-1400/close-the-review-found-gaps-where-the-gates-dev-app-and-baseline","preFetchAt":"2026-08-20T11:01:30.508Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.709Z","sourceUpdatedAt":"2026-08-19T16:20:26.709Z","sourceTitleSha256":"4e4a7a42972cd87205b806f4c89d7ba44e0ab2ddb6efa1abbab18de34022ed39","sourceBodySha256":"ea04928499443681cda2c797a268fe7c62b970dacb49d787ada0a84d2e516257","proposedTitleSha256":"26fb6f297b802aab16e250ef0aa30c16815e5b2f894b7c6dbc8666e569344e65","proposedBodySha256":"096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1400","url":"https://linear.app/hash/issue/FE-1400/strengthen-verification-dev-storage-and-the-baseline-runner","postFetchAt":"2026-08-20T11:01:31.131Z","postUpdatedAt":"2026-08-20T11:01:30.774Z","proposedTitleSha256":"26fb6f297b802aab16e250ef0aa30c16815e5b2f894b7c6dbc8666e569344e65","actualTitleSha256":"26fb6f297b802aab16e250ef0aa30c16815e5b2f894b7c6dbc8666e569344e65","proposedBodySha256":"096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204","actualBodySha256":"096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1401","url":"https://linear.app/hash/issue/FE-1401/resolve-the-follow-ups-from-the-stack-legibility-session","preFetchAt":"2026-08-20T11:01:32.778Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.561Z","sourceUpdatedAt":"2026-08-19T16:20:28.561Z","sourceTitleSha256":"3eb163af50263452be68f66950600c587100fa854645791d88be95fddb53e306","sourceBodySha256":"add5a3da06b366dbc9fe4cdc44b9ce161d2775c8b43fb18af380b2fe2c9c9d5e","proposedTitleSha256":"b8874647b7f094aff4db44c720b9053d7f2c155ea641aea541bcc35728b18b60","proposedBodySha256":"9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1401","url":"https://linear.app/hash/issue/FE-1401/resolve-the-stack-legibility-follow-ups","postFetchAt":"2026-08-20T11:01:34.369Z","postUpdatedAt":"2026-08-20T11:01:33.059Z","proposedTitleSha256":"b8874647b7f094aff4db44c720b9053d7f2c155ea641aea541bcc35728b18b60","actualTitleSha256":"b8874647b7f094aff4db44c720b9053d7f2c155ea641aea541bcc35728b18b60","proposedBodySha256":"9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20","actualBodySha256":"9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1402","url":"https://linear.app/hash/issue/FE-1402/decide-when-an-elicitation-is-complete-or-should-stop","preFetchAt":"2026-08-20T11:01:34.672Z","frozenSourceUpdatedAt":"2026-08-19T16:19:47.912Z","sourceUpdatedAt":"2026-08-19T16:19:47.912Z","sourceTitleSha256":"518f7d5cf52ba2195138f03237f8cebbff16622631fd34f3d96e68e9066fc5db","sourceBodySha256":"0443796ebe3de81af985a3621799610618b8f020b26ee7e4558e237ea1752df1","proposedTitleSha256":"91d4dd660323d85121bb7cc935e581934239bac3ec00303ec944077276a33f34","proposedBodySha256":"b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1402","url":"https://linear.app/hash/issue/FE-1402/define-and-rehearse-the-elicitation-completion-contract","postFetchAt":"2026-08-20T11:01:35.451Z","postUpdatedAt":"2026-08-20T11:01:35.015Z","proposedTitleSha256":"91d4dd660323d85121bb7cc935e581934239bac3ec00303ec944077276a33f34","actualTitleSha256":"91d4dd660323d85121bb7cc935e581934239bac3ec00303ec944077276a33f34","proposedBodySha256":"b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa","actualBodySha256":"b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1403","url":"https://linear.app/hash/issue/FE-1403/assemble-the-cps-packs-interviewing-guidance-and-desk-test-it-where","preFetchAt":"2026-08-20T11:01:35.692Z","frozenSourceUpdatedAt":"2026-08-19T16:19:48.641Z","sourceUpdatedAt":"2026-08-19T16:19:48.641Z","sourceTitleSha256":"76a2a8c3c3f4070aa4979a9414bd2d22eca8e87303966a2377bf17fc8a417196","sourceBodySha256":"0f8b52a00cb0756e5a5175f053ee2911bca209347466334d61f9f7607f78ccdc","proposedTitleSha256":"c2dd05ba5210b2e540bc4f337998070f3341f1bdaf3d14bdfdeca4526924de72","proposedBodySha256":"d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1403","url":"https://linear.app/hash/issue/FE-1403/assemble-and-test-the-cps-interview-guidance","postFetchAt":"2026-08-20T11:01:36.290Z","postUpdatedAt":"2026-08-20T11:01:35.971Z","proposedTitleSha256":"c2dd05ba5210b2e540bc4f337998070f3341f1bdaf3d14bdfdeca4526924de72","actualTitleSha256":"c2dd05ba5210b2e540bc4f337998070f3341f1bdaf3d14bdfdeca4526924de72","proposedBodySha256":"d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240","actualBodySha256":"d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1404","url":"https://linear.app/hash/issue/FE-1404/run-the-armed-baseline-condition-3-completion-contract-and-pack","preFetchAt":"2026-08-20T11:01:36.723Z","frozenSourceUpdatedAt":"2026-08-19T16:19:48.957Z","sourceUpdatedAt":"2026-08-19T16:19:48.957Z","sourceTitleSha256":"dc85e7886b6e6ba00a4848394abc5de81f7592f16cfdd8db8291d6586675e22f","sourceBodySha256":"f88abfbaa37d65613194b26c3c52b12356af84b1bd39e5b8b062b86d03fefd85","proposedTitleSha256":"cbed4c76e448b5ccb190c628bbd109a0c35dbfabe879716ff24ebb8c061e732b","proposedBodySha256":"0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1404","url":"https://linear.app/hash/issue/FE-1404/run-the-third-baseline-with-completion-and-interview-guidance","postFetchAt":"2026-08-20T11:01:37.377Z","postUpdatedAt":"2026-08-20T11:01:37.001Z","proposedTitleSha256":"cbed4c76e448b5ccb190c628bbd109a0c35dbfabe879716ff24ebb8c061e732b","actualTitleSha256":"cbed4c76e448b5ccb190c628bbd109a0c35dbfabe879716ff24ebb8c061e732b","proposedBodySha256":"0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d","actualBodySha256":"0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1405","url":"https://linear.app/hash/issue/FE-1405/draft-the-cps-payload-interiors-annotated-shapes-for-the-ten-kinds","preFetchAt":"2026-08-20T11:01:37.619Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.864Z","sourceUpdatedAt":"2026-08-20T08:02:56.864Z","sourceTitleSha256":"6684fe28ff26349efddef701756334dbc89e05ad594c401f49a8b0f575f0845a","sourceBodySha256":"42b2be3331cc53b8d4f319769fc410edee6afe23b96111e1f79cc3adf9c59785","proposedTitleSha256":"67364fd5e5963238cb0aea5624374d9a6c0d81adeb00f213467ca08100955034","proposedBodySha256":"cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1405","url":"https://linear.app/hash/issue/FE-1405/draft-and-test-the-cps-payload-schemas","postFetchAt":"2026-08-20T11:01:38.202Z","postUpdatedAt":"2026-08-20T11:01:37.874Z","proposedTitleSha256":"67364fd5e5963238cb0aea5624374d9a6c0d81adeb00f213467ca08100955034","actualTitleSha256":"67364fd5e5963238cb0aea5624374d9a6c0d81adeb00f213467ca08100955034","proposedBodySha256":"cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517","actualBodySha256":"cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1406","url":"https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies","preFetchAt":"2026-08-20T11:01:38.460Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.749Z","sourceUpdatedAt":"2026-08-19T16:20:27.749Z","sourceTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","sourceBodySha256":"c5698449d7a48b8b4f4f1b3f9dead3407ae1a737b26c62c6034528c809b993f9","proposedTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","proposedBodySha256":"25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1406","url":"https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies","postFetchAt":"2026-08-20T11:01:39.149Z","postUpdatedAt":"2026-08-20T11:01:38.757Z","proposedTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","actualTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","proposedBodySha256":"25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4","actualBodySha256":"25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1407","url":"https://linear.app/hash/issue/FE-1407/catalogue-the-frontier-elicitor-failure-modes-the-published","preFetchAt":"2026-08-20T11:01:39.410Z","frozenSourceUpdatedAt":"2026-08-19T16:19:49.974Z","sourceUpdatedAt":"2026-08-19T16:19:49.974Z","sourceTitleSha256":"20bc9b033919f9de69d2601587094279f30a7542246f0b91a234fc77247e5500","sourceBodySha256":"147f3f51d5bb84c4d365fcbeb62793a602f48218bcfa36358fb2179f38e737cd","proposedTitleSha256":"168b66b77c82a14116e0f84ad35b26a630d9d70155415c6117cac5b8cabcf3de","proposedBodySha256":"58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1407","url":"https://linear.app/hash/issue/FE-1407/catalogue-elicitor-failures-that-published-measures-miss","postFetchAt":"2026-08-20T11:01:40.049Z","postUpdatedAt":"2026-08-20T11:01:39.687Z","proposedTitleSha256":"168b66b77c82a14116e0f84ad35b26a630d9d70155415c6117cac5b8cabcf3de","actualTitleSha256":"168b66b77c82a14116e0f84ad35b26a630d9d70155415c6117cac5b8cabcf3de","proposedBodySha256":"58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f","actualBodySha256":"58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1419","url":"https://linear.app/hash/issue/FE-1419/close-the-seams-where-the-capture-store-and-verification-gates-claim","preFetchAt":"2026-08-20T11:01:40.294Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.978Z","sourceUpdatedAt":"2026-08-19T16:20:27.978Z","sourceTitleSha256":"c7839e241c62f56c68fa6c425f55035423c76bda7a42bdbb9916214a3d0ffdca","sourceBodySha256":"8943da27bdc24725789f0721adc47978caad9bc3dc841c5086d8bd7860c07b59","proposedTitleSha256":"bee550820a6ba0ba0d693aa7f58f0ade1b3deeb5c0871290f3ebbd71a16fe342","proposedBodySha256":"cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1419","url":"https://linear.app/hash/issue/FE-1419/align-capture-store-rules-and-verification-claims","postFetchAt":"2026-08-20T11:01:40.891Z","postUpdatedAt":"2026-08-20T11:01:40.563Z","proposedTitleSha256":"bee550820a6ba0ba0d693aa7f58f0ade1b3deeb5c0871290f3ebbd71a16fe342","actualTitleSha256":"bee550820a6ba0ba0d693aa7f58f0ade1b3deeb5c0871290f3ebbd71a16fe342","proposedBodySha256":"cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e","actualBodySha256":"cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1420","url":"https://linear.app/hash/issue/FE-1420/the-affordance-protocol-survives-retries-unknown-forms-and-abandoned","preFetchAt":"2026-08-20T11:01:41.158Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.642Z","sourceUpdatedAt":"2026-08-19T16:20:26.642Z","sourceTitleSha256":"3bfff13eaf86dd08b581c3c256de11384d3a0322712bec45e72909d23488c045","sourceBodySha256":"81b2a078103ec981c418c6d8583f31e301dd47b5025e06e967b13f9143b7123c","proposedTitleSha256":"3520d374d5f0b363f505c96c37efeeed65db0724230dccf71150240faec331c5","proposedBodySha256":"316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1420","url":"https://linear.app/hash/issue/FE-1420/make-affordance-handling-safe-under-retries-and-abandonment","postFetchAt":"2026-08-20T11:01:41.862Z","postUpdatedAt":"2026-08-20T11:01:41.516Z","proposedTitleSha256":"3520d374d5f0b363f505c96c37efeeed65db0724230dccf71150240faec331c5","actualTitleSha256":"3520d374d5f0b363f505c96c37efeeed65db0724230dccf71150240faec331c5","proposedBodySha256":"316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f","actualBodySha256":"316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1422","url":"https://linear.app/hash/issue/FE-1422/the-ask-protocol-is-substrate-portable-mechanism-moves-from-the-flue","preFetchAt":"2026-08-20T11:01:42.740Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.900Z","sourceUpdatedAt":"2026-08-20T08:02:56.900Z","sourceTitleSha256":"2f1e7a4a1dc36d322f689117372148fc36b8b32010e7c5a83ad8b5164882edd3","sourceBodySha256":"896c07b62ab8f586a5b0a3e91d47dd2227e5e69ab4b76c60e2ee33afea3de43d","proposedTitleSha256":"21ba840643993170f966a14395f4216a18910b1215ddb901ddef073977bbeded","proposedBodySha256":"e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1422","url":"https://linear.app/hash/issue/FE-1422/move-the-portable-ask-protocol-into-core","postFetchAt":"2026-08-20T11:01:43.540Z","postUpdatedAt":"2026-08-20T11:01:43.248Z","proposedTitleSha256":"21ba840643993170f966a14395f4216a18910b1215ddb901ddef073977bbeded","actualTitleSha256":"21ba840643993170f966a14395f4216a18910b1215ddb901ddef073977bbeded","proposedBodySha256":"e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029","actualBodySha256":"e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1423","url":"https://linear.app/hash/issue/FE-1423/the-demo-shell-is-safe-to-expose-beyond-localhost","preFetchAt":"2026-08-20T11:01:43.789Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.185Z","sourceUpdatedAt":"2026-08-19T16:20:27.185Z","sourceTitleSha256":"20bfcf5adb6266e8a21935a7059acb2f2b3a72b6a45328d5a666febdbd322a07","sourceBodySha256":"5a59b5eb9a3ef99c1232b3833764309a3a4523371cc3d50f17b733daf28e9cde","proposedTitleSha256":"3197d4c558ec40f05879656ee185fd8ece13a4af7ecdde2bd829f66f613e0455","proposedBodySha256":"7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1423","url":"https://linear.app/hash/issue/FE-1423/require-safe-remote-access-to-the-elicitor-server","postFetchAt":"2026-08-20T11:01:44.347Z","postUpdatedAt":"2026-08-20T11:01:44.049Z","proposedTitleSha256":"3197d4c558ec40f05879656ee185fd8ece13a4af7ecdde2bd829f66f613e0455","actualTitleSha256":"3197d4c558ec40f05879656ee185fd8ece13a4af7ecdde2bd829f66f613e0455","proposedBodySha256":"7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68","actualBodySha256":"7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1424","url":"https://linear.app/hash/issue/FE-1424/the-documentation-protocol-runs-end-to-end-inbox-settled-planning","preFetchAt":"2026-08-20T11:01:44.574Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.935Z","sourceUpdatedAt":"2026-08-20T08:02:56.935Z","sourceTitleSha256":"4ba41dff52f65d73eb3a91251a5f2f5593dd20f33ee17b935bd4f4fa0a53f03c","sourceBodySha256":"25338da8862bddb99fe1703004fd71da6f90c544df8a3026c5ac2db39bdc8451","proposedTitleSha256":"9d149563aa0cf572f52328468ca36ce12d2d7847126bd31dcd3d4be88323db6d","proposedBodySha256":"de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1424","url":"https://linear.app/hash/issue/FE-1424/complete-the-documentation-protocol","postFetchAt":"2026-08-20T11:01:45.149Z","postUpdatedAt":"2026-08-20T11:01:44.836Z","proposedTitleSha256":"9d149563aa0cf572f52328468ca36ce12d2d7847126bd31dcd3d4be88323db6d","actualTitleSha256":"9d149563aa0cf572f52328468ca36ce12d2d7847126bd31dcd3d4be88323db6d","proposedBodySha256":"de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3","actualBodySha256":"de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1431","url":"https://linear.app/hash/issue/FE-1431/plugin-authoring-becomes-declarative-a-domain-is-two-schemas-and-two","preFetchAt":"2026-08-20T11:01:45.394Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.703Z","sourceUpdatedAt":"2026-08-19T16:20:27.703Z","sourceTitleSha256":"9a7bf9004f09c283ea30033b983064c6ad1e6bf7b90b688aacce0a9b641271f6","sourceBodySha256":"5d4914829c96abbd9cb90a8868e87372ae837b5ac05404f6824b4c7d97e6c381","proposedTitleSha256":"8adc89529c6163c0e84be414ec2bd0c409106370dc848093e1483df64faf5602","proposedBodySha256":"99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1431","url":"https://linear.app/hash/issue/FE-1431/define-declarative-plugin-authoring","postFetchAt":"2026-08-20T11:01:46.191Z","postUpdatedAt":"2026-08-20T11:01:45.761Z","proposedTitleSha256":"8adc89529c6163c0e84be414ec2bd0c409106370dc848093e1483df64faf5602","actualTitleSha256":"8adc89529c6163c0e84be414ec2bd0c409106370dc848093e1483df64faf5602","proposedBodySha256":"99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef","actualBodySha256":"99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1432","url":"https://linear.app/hash/issue/FE-1432/the-stacks-open-review-threads-are-adjudicated-fixed-owned-or-refused","preFetchAt":"2026-08-20T11:01:46.454Z","frozenSourceUpdatedAt":"2026-08-20T08:02:56.984Z","sourceUpdatedAt":"2026-08-20T08:02:56.984Z","sourceTitleSha256":"87232791cdfbe95bb69b3bcb846ca1a9b0057306d8b5c372fcd11b3336da9a43","sourceBodySha256":"4280899d06e4ac85fef832eaaaa5f9bb08c388105125b5369808b5c7354d0688","proposedTitleSha256":"da13f8170a751acd91029656dec286426fa2b75ae5b8d0d1b0abcbf657d2c3fa","proposedBodySha256":"f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1432","url":"https://linear.app/hash/issue/FE-1432/resolve-the-stacks-open-review-threads","postFetchAt":"2026-08-20T11:01:47.149Z","postUpdatedAt":"2026-08-20T11:01:46.819Z","proposedTitleSha256":"da13f8170a751acd91029656dec286426fa2b75ae5b8d0d1b0abcbf657d2c3fa","actualTitleSha256":"da13f8170a751acd91029656dec286426fa2b75ae5b8d0d1b0abcbf657d2c3fa","proposedBodySha256":"f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb","actualBodySha256":"f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1433","url":"https://linear.app/hash/issue/FE-1433/the-elicitor-serves-demopetrinautorgs-chat-panel-from-a-remote-brunch","preFetchAt":"2026-08-20T11:01:47.393Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.029Z","sourceUpdatedAt":"2026-08-20T08:02:57.029Z","sourceTitleSha256":"281967069fd5f9b5bfe6d27dabf982004c1f5b8286312ca546001f8466c87c7e","sourceBodySha256":"327f6f24386c6636bd8b52e557f1164e6483a8bd4804355cdca32d1f612d1b1d","proposedTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","proposedBodySha256":"a1c39a62c72181356f54ea088fc917134242eb5cf78b222ffd0a8f86256c8b28"}
+{"event":"result","status":"verification-failed","system":"linear","id":"FE-1433","url":"https://linear.app/hash/issue/FE-1433/deliver-the-remote-petrinaut-elicitor-integration","postFetchAt":"2026-08-20T11:01:48.986Z","postUpdatedAt":"2026-08-20T11:01:48.457Z","proposedTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","actualTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","proposedBodySha256":"a1c39a62c72181356f54ea088fc917134242eb5cf78b222ffd0a8f86256c8b28","actualBodySha256":"7ae7b7bace6b2c93833b7c71c5dbf7625d409543b73f451cbeaf52d995e727f0","writeExitCode":0,"writeStderr":""}
+{"event":"recovery","status":"restored-to-source","system":"linear","id":"FE-1433","url":"https://linear.app/hash/issue/FE-1433/the-elicitor-serves-demopetrinautorgs-chat-panel-from-a-remote-brunch","recordedAt":"2026-08-20T11:03:34Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.029Z","restoredUpdatedAt":"2026-08-20T11:03:19.733Z","sourceTitleSha256":"281967069fd5f9b5bfe6d27dabf982004c1f5b8286312ca546001f8466c87c7e","restoredTitleSha256":"281967069fd5f9b5bfe6d27dabf982004c1f5b8286312ca546001f8466c87c7e","sourceBodySha256":"327f6f24386c6636bd8b52e557f1164e6483a8bd4804355cdca32d1f612d1b1d","restoredBodySha256":"327f6f24386c6636bd8b52e557f1164e6483a8bd4804355cdca32d1f612d1b1d","cause":"Linear canonicalized the bare demo.petrinaut.org domain in the approved outer prose; the frozen title and body were restored byte-exactly before adding the two known outer-domain target replacements"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1357","url":"https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-plugin-specification","fetchAt":"2026-08-20T11:06:24.073Z","postUpdatedAt":"2026-08-20T11:00:48.864Z","proposedTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","actualTitleSha256":"edb56b437c811cec397eeb6940f63cac99f3ebd29bbf371c3378e0184e50bffe","proposedBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98","actualBodySha256":"af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1358","url":"https://linear.app/hash/issue/FE-1358/survey-petrinaut-for-the-september-integration","fetchAt":"2026-08-20T11:06:24.302Z","postUpdatedAt":"2026-08-20T11:00:50.413Z","proposedTitleSha256":"92a7187c58c6662981c602d001ed28e1088a40f24a05befdaae9b399816cb9c4","actualTitleSha256":"92a7187c58c6662981c602d001ed28e1088a40f24a05befdaae9b399816cb9c4","proposedBodySha256":"08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899","actualBodySha256":"08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1359","url":"https://linear.app/hash/issue/FE-1359/decide-whether-voice-changes-the-elicitor-architecture","fetchAt":"2026-08-20T11:06:24.593Z","postUpdatedAt":"2026-08-20T11:00:51.481Z","proposedTitleSha256":"24fe52139a5192afa3a13f0264dd052c25b64dd721942d2e3bfd24b1f0d4137c","actualTitleSha256":"24fe52139a5192afa3a13f0264dd052c25b64dd721942d2e3bfd24b1f0d4137c","proposedBodySha256":"5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b","actualBodySha256":"5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1360","url":"https://linear.app/hash/issue/FE-1360/derive-elicitation-guidance-from-published-research","fetchAt":"2026-08-20T11:06:24.864Z","postUpdatedAt":"2026-08-20T11:00:53.056Z","proposedTitleSha256":"7e705b33a3fc5c880137fa49b8805afc4d1d547dd75063206fbb9c64d867c97d","actualTitleSha256":"7e705b33a3fc5c880137fa49b8805afc4d1d547dd75063206fbb9c64d867c97d","proposedBodySha256":"a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19","actualBodySha256":"a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1361","url":"https://linear.app/hash/issue/FE-1361/measure-the-one-shot-ai-elicitation-baseline","fetchAt":"2026-08-20T11:06:25.100Z","postUpdatedAt":"2026-08-20T11:00:53.931Z","proposedTitleSha256":"af5b3693ff1fe6a3345539ae08530bafa9b2df8a60e5ba708d7833ba963d2a71","actualTitleSha256":"af5b3693ff1fe6a3345539ae08530bafa9b2df8a60e5ba708d7833ba963d2a71","proposedBodySha256":"5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8","actualBodySha256":"5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1362","url":"https://linear.app/hash/issue/FE-1362/decide-the-september-demo-architecture","fetchAt":"2026-08-20T11:06:25.344Z","postUpdatedAt":"2026-08-20T11:00:54.835Z","proposedTitleSha256":"703de24bb88a4bc6802a75b8dca0e0c7d4a09fb93f72aa8c532d8c5853326959","actualTitleSha256":"703de24bb88a4bc6802a75b8dca0e0c7d4a09fb93f72aa8c532d8c5853326959","proposedBodySha256":"9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993","actualBodySha256":"9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1363","url":"https://linear.app/hash/issue/FE-1363/choose-the-demo-use-case-and-modelling-criteria","fetchAt":"2026-08-20T11:06:25.600Z","postUpdatedAt":"2026-08-20T11:00:56.060Z","proposedTitleSha256":"d14ab7a091020ba12c4c7eeacc619c18f3099e57703e8ba5cf68efbe17328b8a","actualTitleSha256":"d14ab7a091020ba12c4c7eeacc619c18f3099e57703e8ba5cf68efbe17328b8a","proposedBodySha256":"4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97","actualBodySha256":"4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1364","url":"https://linear.app/hash/issue/FE-1364/define-the-process-model-elicitation-representation","fetchAt":"2026-08-20T11:06:26.025Z","postUpdatedAt":"2026-08-20T11:00:56.995Z","proposedTitleSha256":"7ca4533b4bb0e42d0a310e72c5a9a8aae181115af2ad1ffcc85587f49437a3a1","actualTitleSha256":"7ca4533b4bb0e42d0a310e72c5a9a8aae181115af2ad1ffcc85587f49437a3a1","proposedBodySha256":"454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24","actualBodySha256":"454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1366","url":"https://linear.app/hash/issue/FE-1366/document-the-elicitation-harness-architecture","fetchAt":"2026-08-20T11:06:26.291Z","postUpdatedAt":"2026-08-20T11:00:58.023Z","proposedTitleSha256":"ecd6270308cb53c1cddecbd489543f583a9d2850c1bcb29aa919e7fcf0c588dd","actualTitleSha256":"ecd6270308cb53c1cddecbd489543f583a9d2850c1bcb29aa919e7fcf0c588dd","proposedBodySha256":"d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d","actualBodySha256":"d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1367","url":"https://linear.app/hash/issue/FE-1367/define-how-the-elicitation-harness-uses-flue","fetchAt":"2026-08-20T11:06:26.735Z","postUpdatedAt":"2026-08-20T11:00:59.003Z","proposedTitleSha256":"56a728873a351ffa5abcb9e165694d1c6a882e43fc29d126ab46598a482465aa","actualTitleSha256":"56a728873a351ffa5abcb9e165694d1c6a882e43fc29d126ab46598a482465aa","proposedBodySha256":"0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2","actualBodySha256":"0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1368","url":"https://linear.app/hash/issue/FE-1368/assess-zil-lean-as-an-elicitation-subject","fetchAt":"2026-08-20T11:06:26.988Z","postUpdatedAt":"2026-08-20T11:01:00.028Z","proposedTitleSha256":"671c8d7d2ec1d02dd04e6791f04e91d907c514f38ea3e8bbf371757bcd44d183","actualTitleSha256":"671c8d7d2ec1d02dd04e6791f04e91d907c514f38ea3e8bbf371757bcd44d183","proposedBodySha256":"58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70","actualBodySha256":"58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1369","url":"https://linear.app/hash/issue/FE-1369/classify-brunch-exchange-structures-for-reuse","fetchAt":"2026-08-20T11:06:27.233Z","postUpdatedAt":"2026-08-20T11:01:01.421Z","proposedTitleSha256":"ad51b1463946bcbcf00e57b7bffac75180cde408d6db865a9c2bf8349597a4d2","actualTitleSha256":"ad51b1463946bcbcf00e57b7bffac75180cde408d6db865a9c2bf8349597a4d2","proposedBodySha256":"f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d","actualBodySha256":"f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1370","url":"https://linear.app/hash/issue/FE-1370/define-the-harness-and-plugin-responsibilities","fetchAt":"2026-08-20T11:06:27.489Z","postUpdatedAt":"2026-08-20T11:01:02.574Z","proposedTitleSha256":"fff1e6cd68dee8290e99e3b5a27ef3e63a5a20a6f634b058724ca33d08cb32aa","actualTitleSha256":"fff1e6cd68dee8290e99e3b5a27ef3e63a5a20a6f634b058724ca33d08cb32aa","proposedBodySha256":"586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b","actualBodySha256":"586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1371","url":"https://linear.app/hash/issue/FE-1371/define-structured-questions-within-conversation","fetchAt":"2026-08-20T11:06:27.735Z","postUpdatedAt":"2026-08-20T11:01:04.082Z","proposedTitleSha256":"6df3270da2d36b2ce6b9f28706d1d60830de04f2a7284ce91e04bab6c5440116","actualTitleSha256":"6df3270da2d36b2ce6b9f28706d1d60830de04f2a7284ce91e04bab6c5440116","proposedBodySha256":"8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f","actualBodySha256":"8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1372","url":"https://linear.app/hash/issue/FE-1372/choose-how-the-elicitation-harness-ships","fetchAt":"2026-08-20T11:06:27.980Z","postUpdatedAt":"2026-08-20T11:01:05.224Z","proposedTitleSha256":"f62fc5f62252c5cd20b94fe9527ab32111d710f20b95513c430b0b89e389a89d","actualTitleSha256":"f62fc5f62252c5cd20b94fe9527ab32111d710f20b95513c430b0b89e389a89d","proposedBodySha256":"4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e","actualBodySha256":"4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1373","url":"https://linear.app/hash/issue/FE-1373/choose-the-initial-elicitation-subjects","fetchAt":"2026-08-20T11:06:28.226Z","postUpdatedAt":"2026-08-20T11:01:06.262Z","proposedTitleSha256":"49526b09da7cea4f956b0fc97da3a537287b6e1dc0a5599a0dc744273bbd4057","actualTitleSha256":"49526b09da7cea4f956b0fc97da3a537287b6e1dc0a5599a0dc744273bbd4057","proposedBodySha256":"3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03","actualBodySha256":"3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1374","url":"https://linear.app/hash/issue/FE-1374/assemble-the-elicitation-harness-specification","fetchAt":"2026-08-20T11:06:28.478Z","postUpdatedAt":"2026-08-20T11:01:07.086Z","proposedTitleSha256":"a8d6e8af11c31f8e0b937ba43b6d758e79988d751f29a1222bb5097e33ce4f78","actualTitleSha256":"a8d6e8af11c31f8e0b937ba43b6d758e79988d751f29a1222bb5097e33ce4f78","proposedBodySha256":"cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0","actualBodySha256":"cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1375","url":"https://linear.app/hash/issue/FE-1375/align-the-assurance-subject-with-verification-practice","fetchAt":"2026-08-20T11:06:28.716Z","postUpdatedAt":"2026-08-20T11:01:08.093Z","proposedTitleSha256":"1014535547f1f5612dda184fea1218227d4b4674f4bf9b18fa3c9d9841c9740a","actualTitleSha256":"1014535547f1f5612dda184fea1218227d4b4674f4bf9b18fa3c9d9841c9740a","proposedBodySha256":"f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c","actualBodySha256":"f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1376","url":"https://linear.app/hash/issue/FE-1376/prove-a-flue-question-round-trip","fetchAt":"2026-08-20T11:06:28.969Z","postUpdatedAt":"2026-08-20T11:01:09.911Z","proposedTitleSha256":"780a9ff8453c76d6b8fd253a634ef6049f1ef97808e74451361e164bac65ab98","actualTitleSha256":"780a9ff8453c76d6b8fd253a634ef6049f1ef97808e74451361e164bac65ab98","proposedBodySha256":"3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec","actualBodySha256":"3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1377","url":"https://linear.app/hash/issue/FE-1377/prove-repeatable-conversation-capture","fetchAt":"2026-08-20T11:06:29.207Z","postUpdatedAt":"2026-08-20T11:01:10.954Z","proposedTitleSha256":"5679461ba36f1b7ddc1d98c64e7f54b59038d3e217d0722c2953b1f2044b99bd","actualTitleSha256":"5679461ba36f1b7ddc1d98c64e7f54b59038d3e217d0722c2953b1f2044b99bd","proposedBodySha256":"fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba","actualBodySha256":"fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1378","url":"https://linear.app/hash/issue/FE-1378/define-durable-state-across-elicitation-sessions","fetchAt":"2026-08-20T11:06:29.446Z","postUpdatedAt":"2026-08-20T11:01:11.912Z","proposedTitleSha256":"442998135a28eb368d03b58a5ec32ff9fbd4ee0743b7afc16030e3dac70494cf","actualTitleSha256":"442998135a28eb368d03b58a5ec32ff9fbd4ee0743b7afc16030e3dac70494cf","proposedBodySha256":"77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065","actualBodySha256":"77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1379","url":"https://linear.app/hash/issue/FE-1379/prove-the-remaining-flue-capabilities","fetchAt":"2026-08-20T11:06:29.720Z","postUpdatedAt":"2026-08-20T11:01:12.831Z","proposedTitleSha256":"d11a2dcabcaa56f89789e629bc0d41d5d4756ee3702e7cff79bea4e6f2074ad5","actualTitleSha256":"d11a2dcabcaa56f89789e629bc0d41d5d4756ee3702e7cff79bea4e6f2074ad5","proposedBodySha256":"3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c","actualBodySha256":"3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1382","url":"https://linear.app/hash/issue/FE-1382/compile-the-truck-fleet-source-dossier","fetchAt":"2026-08-20T11:06:30.527Z","postUpdatedAt":"2026-08-20T11:01:13.930Z","proposedTitleSha256":"cca762a296ff0a645b3398b349a1aba34b009e2a72520cd6ca50a1995ecbf782","actualTitleSha256":"cca762a296ff0a645b3398b349a1aba34b009e2a72520cd6ca50a1995ecbf782","proposedBodySha256":"dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f","actualBodySha256":"dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1383","url":"https://linear.app/hash/issue/FE-1383/build-the-first-complete-elicitation-interview","fetchAt":"2026-08-20T11:06:30.772Z","postUpdatedAt":"2026-08-20T11:01:14.845Z","proposedTitleSha256":"e16c710e0bf421f6afd4e73b0924ece8d021e65511fe57aef680f3f7854d0577","actualTitleSha256":"e16c710e0bf421f6afd4e73b0924ece8d021e65511fe57aef680f3f7854d0577","proposedBodySha256":"3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb","actualBodySha256":"3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1384","url":"https://linear.app/hash/issue/FE-1384/generate-replay-tests-for-the-harness-rules","fetchAt":"2026-08-20T11:06:31.018Z","postUpdatedAt":"2026-08-20T11:01:15.906Z","proposedTitleSha256":"d578f097f2c89e3b8d52f319f960726bafe7bdf786a8ee7cd7613c52cc1708ed","actualTitleSha256":"d578f097f2c89e3b8d52f319f960726bafe7bdf786a8ee7cd7613c52cc1708ed","proposedBodySha256":"bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c","actualBodySha256":"bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1385","url":"https://linear.app/hash/issue/FE-1385/expand-the-dev-app-into-a-target-gallery-and-diagnostic-view","fetchAt":"2026-08-20T11:06:31.254Z","postUpdatedAt":"2026-08-20T11:01:16.969Z","proposedTitleSha256":"735ae093eeaea26baacee13aa32bf1a2903b9ea666421c903d460c1987a63543","actualTitleSha256":"735ae093eeaea26baacee13aa32bf1a2903b9ea666421c903d460c1987a63543","proposedBodySha256":"9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6","actualBodySha256":"9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1386","url":"https://linear.app/hash/issue/FE-1386/test-durable-history-across-transcript-compaction","fetchAt":"2026-08-20T11:06:31.490Z","postUpdatedAt":"2026-08-20T11:01:17.820Z","proposedTitleSha256":"828d7efb7c4bde98357f8ea410087cc82d009524241bc6f8a4dbab46d701c2a0","actualTitleSha256":"828d7efb7c4bde98357f8ea410087cc82d009524241bc6f8a4dbab46d701c2a0","proposedBodySha256":"6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f","actualBodySha256":"6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1387","url":"https://linear.app/hash/issue/FE-1387/choose-a-second-target-and-stabilize-the-plugin-interface","fetchAt":"2026-08-20T11:06:31.720Z","postUpdatedAt":"2026-08-20T11:01:18.698Z","proposedTitleSha256":"37bf181908327ddd86b0e09bc446b5eb02383a441693d6a9fa604d7455756205","actualTitleSha256":"37bf181908327ddd86b0e09bc446b5eb02383a441693d6a9fa604d7455756205","proposedBodySha256":"e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a","actualBodySha256":"e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1388","url":"https://linear.app/hash/issue/FE-1388/create-the-bun-workspace-and-enforce-dependency-boundaries","fetchAt":"2026-08-20T11:06:31.970Z","postUpdatedAt":"2026-08-20T11:01:19.623Z","proposedTitleSha256":"cba702bfe08fbfe6c118f53f94058b89f4e279b1e65f7eaec8f8a764dcc99249","actualTitleSha256":"cba702bfe08fbfe6c118f53f94058b89f4e279b1e65f7eaec8f8a764dcc99249","proposedBodySha256":"09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b","actualBodySha256":"09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1389","url":"https://linear.app/hash/issue/FE-1389/implement-the-first-suspended-free-text-question","fetchAt":"2026-08-20T11:06:32.221Z","postUpdatedAt":"2026-08-20T11:01:20.583Z","proposedTitleSha256":"671d58f11fdffe9a2aef0c9355b44e9b1e5c66d0c25504369b6a25de54e0a6b3","actualTitleSha256":"671d58f11fdffe9a2aef0c9355b44e9b1e5c66d0c25504369b6a25de54e0a6b3","proposedBodySha256":"61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80","actualBodySha256":"61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1390","url":"https://linear.app/hash/issue/FE-1390/implement-capture-history-and-local-persistence","fetchAt":"2026-08-20T11:06:33.054Z","postUpdatedAt":"2026-08-20T11:01:21.541Z","proposedTitleSha256":"4f9a2a6a52ee76fc88cf973ed854c90d5a3425c1b81d444fdee080bb2736c392","actualTitleSha256":"4f9a2a6a52ee76fc88cf973ed854c90d5a3425c1b81d444fdee080bb2736c392","proposedBodySha256":"6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad","actualBodySha256":"6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1391","url":"https://linear.app/hash/issue/FE-1391/resolve-evidence-quotes-to-durable-conversation-entries","fetchAt":"2026-08-20T11:06:33.306Z","postUpdatedAt":"2026-08-20T11:01:22.808Z","proposedTitleSha256":"cc41527c73a8817b0d2f23773f40b6d72de92f3d91a5a2c6b5259a68861de1c8","actualTitleSha256":"cc41527c73a8817b0d2f23773f40b6d72de92f3d91a5a2c6b5259a68861de1c8","proposedBodySha256":"a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683","actualBodySha256":"a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1392","url":"https://linear.app/hash/issue/FE-1392/capture-settled-conversation-statements-safely","fetchAt":"2026-08-20T11:06:33.566Z","postUpdatedAt":"2026-08-20T11:01:23.655Z","proposedTitleSha256":"e5bc000d22834d39bfc4daefdec98c8bca2cb0883dc5d4e2a4e44b0f47e7d8a6","actualTitleSha256":"e5bc000d22834d39bfc4daefdec98c8bca2cb0883dc5d4e2a4e44b0f47e7d8a6","proposedBodySha256":"71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d","actualBodySha256":"71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1393","url":"https://linear.app/hash/issue/FE-1393/produce-the-first-gherkin-artifact-through-the-plugin-sdk","fetchAt":"2026-08-20T11:06:33.809Z","postUpdatedAt":"2026-08-20T11:01:24.693Z","proposedTitleSha256":"a7ae805905d5b1a216a522c1492669e21aca11ab15eb0892cbcd4a44e84d6dec","actualTitleSha256":"a7ae805905d5b1a216a522c1492669e21aca11ab15eb0892cbcd4a44e84d6dec","proposedBodySha256":"9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe","actualBodySha256":"9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1394","url":"https://linear.app/hash/issue/FE-1394/preserve-conflicts-until-the-user-resolves-them","fetchAt":"2026-08-20T11:06:34.038Z","postUpdatedAt":"2026-08-20T11:01:25.600Z","proposedTitleSha256":"8e8cc690f434c0e6b827fec9acd5887087cd5e638347b55a486eab0b5139a497","actualTitleSha256":"8e8cc690f434c0e6b827fec9acd5887087cd5e638347b55a486eab0b5139a497","proposedBodySha256":"3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1","actualBodySha256":"3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1395","url":"https://linear.app/hash/issue/FE-1395/add-choices-questionnaires-and-explicit-absence-replies","fetchAt":"2026-08-20T11:06:34.342Z","postUpdatedAt":"2026-08-20T11:01:26.966Z","proposedTitleSha256":"9142527acadbf1d1d8d0a777a129404cc15df6c4471aacc2fe91601b2c470397","actualTitleSha256":"9142527acadbf1d1d8d0a777a129404cc15df6c4471aacc2fe91601b2c470397","proposedBodySha256":"325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318","actualBodySha256":"325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1396","url":"https://linear.app/hash/issue/FE-1396/restore-interview-context-after-resume-and-restart","fetchAt":"2026-08-20T11:06:34.592Z","postUpdatedAt":"2026-08-20T11:01:28.090Z","proposedTitleSha256":"66b2c12e3036f132c63ee071cd1e98f126bccccf9223062effe4e2f9c3658084","actualTitleSha256":"66b2c12e3036f132c63ee071cd1e98f126bccccf9223062effe4e2f9c3658084","proposedBodySha256":"60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59","actualBodySha256":"60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1397","url":"https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-against-worked-plugin-payloads","fetchAt":"2026-08-20T11:06:34.821Z","postUpdatedAt":"2026-08-20T11:01:28.974Z","proposedTitleSha256":"f07438c59634073e97ad1225c8b971ececa39d27ebd19aa27958da8e4eb11bf6","actualTitleSha256":"f07438c59634073e97ad1225c8b971ececa39d27ebd19aa27958da8e4eb11bf6","proposedBodySha256":"728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf","actualBodySha256":"728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1399","url":"https://linear.app/hash/issue/FE-1399/fix-verified-silent-failures-in-ci-and-the-dev-app","fetchAt":"2026-08-20T11:06:35.233Z","postUpdatedAt":"2026-08-20T11:01:29.815Z","proposedTitleSha256":"a376b90e615f99d8f593ca82d7aebcf143ae49697119f3126cf511dea4242c64","actualTitleSha256":"a376b90e615f99d8f593ca82d7aebcf143ae49697119f3126cf511dea4242c64","proposedBodySha256":"93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221","actualBodySha256":"93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1400","url":"https://linear.app/hash/issue/FE-1400/strengthen-verification-dev-storage-and-the-baseline-runner","fetchAt":"2026-08-20T11:06:35.475Z","postUpdatedAt":"2026-08-20T11:01:30.774Z","proposedTitleSha256":"26fb6f297b802aab16e250ef0aa30c16815e5b2f894b7c6dbc8666e569344e65","actualTitleSha256":"26fb6f297b802aab16e250ef0aa30c16815e5b2f894b7c6dbc8666e569344e65","proposedBodySha256":"096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204","actualBodySha256":"096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1401","url":"https://linear.app/hash/issue/FE-1401/resolve-the-stack-legibility-follow-ups","fetchAt":"2026-08-20T11:06:35.936Z","postUpdatedAt":"2026-08-20T11:01:33.059Z","proposedTitleSha256":"b8874647b7f094aff4db44c720b9053d7f2c155ea641aea541bcc35728b18b60","actualTitleSha256":"b8874647b7f094aff4db44c720b9053d7f2c155ea641aea541bcc35728b18b60","proposedBodySha256":"9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20","actualBodySha256":"9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1402","url":"https://linear.app/hash/issue/FE-1402/define-and-rehearse-the-elicitation-completion-contract","fetchAt":"2026-08-20T11:06:36.202Z","postUpdatedAt":"2026-08-20T11:01:35.015Z","proposedTitleSha256":"91d4dd660323d85121bb7cc935e581934239bac3ec00303ec944077276a33f34","actualTitleSha256":"91d4dd660323d85121bb7cc935e581934239bac3ec00303ec944077276a33f34","proposedBodySha256":"b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa","actualBodySha256":"b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1403","url":"https://linear.app/hash/issue/FE-1403/assemble-and-test-the-cps-interview-guidance","fetchAt":"2026-08-20T11:06:36.436Z","postUpdatedAt":"2026-08-20T11:01:35.971Z","proposedTitleSha256":"c2dd05ba5210b2e540bc4f337998070f3341f1bdaf3d14bdfdeca4526924de72","actualTitleSha256":"c2dd05ba5210b2e540bc4f337998070f3341f1bdaf3d14bdfdeca4526924de72","proposedBodySha256":"d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240","actualBodySha256":"d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1404","url":"https://linear.app/hash/issue/FE-1404/run-the-third-baseline-with-completion-and-interview-guidance","fetchAt":"2026-08-20T11:06:36.665Z","postUpdatedAt":"2026-08-20T11:01:37.001Z","proposedTitleSha256":"cbed4c76e448b5ccb190c628bbd109a0c35dbfabe879716ff24ebb8c061e732b","actualTitleSha256":"cbed4c76e448b5ccb190c628bbd109a0c35dbfabe879716ff24ebb8c061e732b","proposedBodySha256":"0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d","actualBodySha256":"0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1405","url":"https://linear.app/hash/issue/FE-1405/draft-and-test-the-cps-payload-schemas","fetchAt":"2026-08-20T11:06:36.895Z","postUpdatedAt":"2026-08-20T11:01:37.874Z","proposedTitleSha256":"67364fd5e5963238cb0aea5624374d9a6c0d81adeb00f213467ca08100955034","actualTitleSha256":"67364fd5e5963238cb0aea5624374d9a6c0d81adeb00f213467ca08100955034","proposedBodySha256":"cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517","actualBodySha256":"cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1406","url":"https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies","fetchAt":"2026-08-20T11:06:37.136Z","postUpdatedAt":"2026-08-20T11:01:38.757Z","proposedTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","actualTitleSha256":"9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2","proposedBodySha256":"25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4","actualBodySha256":"25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1407","url":"https://linear.app/hash/issue/FE-1407/catalogue-elicitor-failures-that-published-measures-miss","fetchAt":"2026-08-20T11:06:37.376Z","postUpdatedAt":"2026-08-20T11:01:39.687Z","proposedTitleSha256":"168b66b77c82a14116e0f84ad35b26a630d9d70155415c6117cac5b8cabcf3de","actualTitleSha256":"168b66b77c82a14116e0f84ad35b26a630d9d70155415c6117cac5b8cabcf3de","proposedBodySha256":"58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f","actualBodySha256":"58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1419","url":"https://linear.app/hash/issue/FE-1419/align-capture-store-rules-and-verification-claims","fetchAt":"2026-08-20T11:06:37.620Z","postUpdatedAt":"2026-08-20T11:01:40.563Z","proposedTitleSha256":"bee550820a6ba0ba0d693aa7f58f0ade1b3deeb5c0871290f3ebbd71a16fe342","actualTitleSha256":"bee550820a6ba0ba0d693aa7f58f0ade1b3deeb5c0871290f3ebbd71a16fe342","proposedBodySha256":"cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e","actualBodySha256":"cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1420","url":"https://linear.app/hash/issue/FE-1420/make-affordance-handling-safe-under-retries-and-abandonment","fetchAt":"2026-08-20T11:06:37.870Z","postUpdatedAt":"2026-08-20T11:01:41.516Z","proposedTitleSha256":"3520d374d5f0b363f505c96c37efeeed65db0724230dccf71150240faec331c5","actualTitleSha256":"3520d374d5f0b363f505c96c37efeeed65db0724230dccf71150240faec331c5","proposedBodySha256":"316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f","actualBodySha256":"316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1422","url":"https://linear.app/hash/issue/FE-1422/move-the-portable-ask-protocol-into-core","fetchAt":"2026-08-20T11:06:38.114Z","postUpdatedAt":"2026-08-20T11:01:43.248Z","proposedTitleSha256":"21ba840643993170f966a14395f4216a18910b1215ddb901ddef073977bbeded","actualTitleSha256":"21ba840643993170f966a14395f4216a18910b1215ddb901ddef073977bbeded","proposedBodySha256":"e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029","actualBodySha256":"e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1423","url":"https://linear.app/hash/issue/FE-1423/require-safe-remote-access-to-the-elicitor-server","fetchAt":"2026-08-20T11:06:38.366Z","postUpdatedAt":"2026-08-20T11:01:44.049Z","proposedTitleSha256":"3197d4c558ec40f05879656ee185fd8ece13a4af7ecdde2bd829f66f613e0455","actualTitleSha256":"3197d4c558ec40f05879656ee185fd8ece13a4af7ecdde2bd829f66f613e0455","proposedBodySha256":"7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68","actualBodySha256":"7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1424","url":"https://linear.app/hash/issue/FE-1424/complete-the-documentation-protocol","fetchAt":"2026-08-20T11:06:38.667Z","postUpdatedAt":"2026-08-20T11:01:44.836Z","proposedTitleSha256":"9d149563aa0cf572f52328468ca36ce12d2d7847126bd31dcd3d4be88323db6d","actualTitleSha256":"9d149563aa0cf572f52328468ca36ce12d2d7847126bd31dcd3d4be88323db6d","proposedBodySha256":"de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3","actualBodySha256":"de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1431","url":"https://linear.app/hash/issue/FE-1431/define-declarative-plugin-authoring","fetchAt":"2026-08-20T11:06:38.919Z","postUpdatedAt":"2026-08-20T11:01:45.761Z","proposedTitleSha256":"8adc89529c6163c0e84be414ec2bd0c409106370dc848093e1483df64faf5602","actualTitleSha256":"8adc89529c6163c0e84be414ec2bd0c409106370dc848093e1483df64faf5602","proposedBodySha256":"99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef","actualBodySha256":"99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef"}
+{"event":"resume-check","status":"pass","system":"linear","id":"FE-1432","url":"https://linear.app/hash/issue/FE-1432/resolve-the-stacks-open-review-threads","fetchAt":"2026-08-20T11:06:39.161Z","postUpdatedAt":"2026-08-20T11:01:46.819Z","proposedTitleSha256":"da13f8170a751acd91029656dec286426fa2b75ae5b8d0d1b0abcbf657d2c3fa","actualTitleSha256":"da13f8170a751acd91029656dec286426fa2b75ae5b8d0d1b0abcbf657d2c3fa","proposedBodySha256":"f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb","actualBodySha256":"f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb"}
+{"event":"attempt","system":"linear","id":"FE-1433","url":"https://linear.app/hash/issue/FE-1433/the-elicitor-serves-demopetrinautorgs-chat-panel-from-a-remote-brunch","preFetchAt":"2026-08-20T11:06:39.904Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.029Z","sourceUpdatedAt":"2026-08-20T11:03:19.733Z","sourceTitleSha256":"281967069fd5f9b5bfe6d27dabf982004c1f5b8286312ca546001f8466c87c7e","sourceBodySha256":"327f6f24386c6636bd8b52e557f1164e6483a8bd4804355cdca32d1f612d1b1d","proposedTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","proposedBodySha256":"7ae7b7bace6b2c93833b7c71c5dbf7625d409543b73f451cbeaf52d995e727f0"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1433","url":"https://linear.app/hash/issue/FE-1433/deliver-the-remote-petrinaut-elicitor-integration","postFetchAt":"2026-08-20T11:06:40.505Z","postUpdatedAt":"2026-08-20T11:06:40.179Z","proposedTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","actualTitleSha256":"a0a676a0955943bf0c3ba501347dd8ffdd05dbe8c62bb3660f31fc449280e5e2","proposedBodySha256":"7ae7b7bace6b2c93833b7c71c5dbf7625d409543b73f451cbeaf52d995e727f0","actualBodySha256":"7ae7b7bace6b2c93833b7c71c5dbf7625d409543b73f451cbeaf52d995e727f0","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1434","url":"https://linear.app/hash/issue/FE-1434/spike-does-flue-turn-suspension-carry-batched-client-tool-round-trips","preFetchAt":"2026-08-20T11:06:40.733Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.068Z","sourceUpdatedAt":"2026-08-20T08:02:57.068Z","sourceTitleSha256":"c10af0cac7faccaeac3f161ec242d94fc92549f164b8e885a6305159115d58c8","sourceBodySha256":"fac188333116b05f6764814ccb6ed97bd003e182bc45132c2d39c932440b5bb2","proposedTitleSha256":"5e494b4c27b36bb0ae657fde9e024ae844cd63d2318cc373af2544753be56168","proposedBodySha256":"f997a348580b20b35f3c843b022988b459306c159d91a012fce1170a2ae80a6f"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1434","url":"https://linear.app/hash/issue/FE-1434/test-whether-flue-resumes-batched-client-tool-results","postFetchAt":"2026-08-20T11:06:41.287Z","postUpdatedAt":"2026-08-20T11:06:40.981Z","proposedTitleSha256":"5e494b4c27b36bb0ae657fde9e024ae844cd63d2318cc373af2544753be56168","actualTitleSha256":"5e494b4c27b36bb0ae657fde9e024ae844cd63d2318cc373af2544753be56168","proposedBodySha256":"f997a348580b20b35f3c843b022988b459306c159d91a012fce1170a2ae80a6f","actualBodySha256":"f997a348580b20b35f3c843b022988b459306c159d91a012fce1170a2ae80a6f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1435","url":"https://linear.app/hash/issue/FE-1435/spike-does-a-harness-driven-stream-drive-petrinauts-real-chat-panel","preFetchAt":"2026-08-20T11:06:41.580Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.126Z","sourceUpdatedAt":"2026-08-20T08:02:57.126Z","sourceTitleSha256":"2c301f3965071e2bfb773497b119bfe4e616ef41902a611005f2061854523f84","sourceBodySha256":"a157fa152e18f4783339cc49e56ac61a608e57ce097cac34502e7a3acec17698","proposedTitleSha256":"d84da3a82a51c50109aa4457adbf40e581fd49c4a2f24b73f6772a063c70196f","proposedBodySha256":"14076be75535ff5dbf12d8f68bb41a8292fed3a98bb41f1eb65eea02de3cf524"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1435","url":"https://linear.app/hash/issue/FE-1435/test-whether-the-elicitor-stream-drives-petrinauts-chat-panel","postFetchAt":"2026-08-20T11:06:42.305Z","postUpdatedAt":"2026-08-20T11:06:41.948Z","proposedTitleSha256":"d84da3a82a51c50109aa4457adbf40e581fd49c4a2f24b73f6772a063c70196f","actualTitleSha256":"d84da3a82a51c50109aa4457adbf40e581fd49c4a2f24b73f6772a063c70196f","proposedBodySha256":"14076be75535ff5dbf12d8f68bb41a8292fed3a98bb41f1eb65eea02de3cf524","actualBodySha256":"14076be75535ff5dbf12d8f68bb41a8292fed3a98bb41f1eb65eea02de3cf524","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1436","url":"https://linear.app/hash/issue/FE-1436/the-elicitor-answers-conversation-turns-in-petrinauts-real-chat-panel","preFetchAt":"2026-08-20T11:06:42.555Z","frozenSourceUpdatedAt":"2026-08-20T08:02:57.380Z","sourceUpdatedAt":"2026-08-20T08:02:57.380Z","sourceTitleSha256":"a5958e22310b6c5fa71520b3c9e0c5e27b41bf557cbcf54c0d423297a0a9a6b4","sourceBodySha256":"b07965244f137a1844adffb0b30dce5130cd4e8555f2e139579a6bc8456d0e69","proposedTitleSha256":"c12d85230f11c97cfb9a097351dbfb248e936c364441c6e63410c6f285693717","proposedBodySha256":"8f8e69c34fc30483f729716e87f695f62bfcf63cb383250b0635a809ef478103"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1436","url":"https://linear.app/hash/issue/FE-1436/connect-the-elicitor-to-petrinauts-real-chat-panel","postFetchAt":"2026-08-20T11:06:43.150Z","postUpdatedAt":"2026-08-20T11:06:42.812Z","proposedTitleSha256":"c12d85230f11c97cfb9a097351dbfb248e936c364441c6e63410c6f285693717","actualTitleSha256":"c12d85230f11c97cfb9a097351dbfb248e936c364441c6e63410c6f285693717","proposedBodySha256":"8f8e69c34fc30483f729716e87f695f62bfcf63cb383250b0635a809ef478103","actualBodySha256":"8f8e69c34fc30483f729716e87f695f62bfcf63cb383250b0635a809ef478103","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1437","url":"https://linear.app/hash/issue/FE-1437/hashintelbrunch-agent-lives-in-hashintelhash-with-its-history","preFetchAt":"2026-08-20T11:06:43.395Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.220Z","sourceUpdatedAt":"2026-08-19T16:20:27.220Z","sourceTitleSha256":"75970ac9d4456f223830b137b2f74eab7999fb8e35f2216057966b99c9bc03ce","sourceBodySha256":"cbe7b6d050e3486f8e1649848516b240c282e85f601a56f693f095059902a476","proposedTitleSha256":"c44d0b68dd8c9f0f8f5bd048e952056d7fd85af4407a9faaea78b4481e9828d1","proposedBodySha256":"ca9ca144d3aa18223c7141542955d1c39b805323030bce4a25b948a854de5bbf"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1437","url":"https://linear.app/hash/issue/FE-1437/move-brunch-agent-into-hashintelhash-with-its-history","postFetchAt":"2026-08-20T11:06:44.001Z","postUpdatedAt":"2026-08-20T11:06:43.671Z","proposedTitleSha256":"c44d0b68dd8c9f0f8f5bd048e952056d7fd85af4407a9faaea78b4481e9828d1","actualTitleSha256":"c44d0b68dd8c9f0f8f5bd048e952056d7fd85af4407a9faaea78b4481e9828d1","proposedBodySha256":"ca9ca144d3aa18223c7141542955d1c39b805323030bce4a25b948a854de5bbf","actualBodySha256":"ca9ca144d3aa18223c7141542955d1c39b805323030bce4a25b948a854de5bbf","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1438","url":"https://linear.app/hash/issue/FE-1438/the-elicitor-builds-and-repairs-the-net-through-petrinauts-client","preFetchAt":"2026-08-20T11:06:44.236Z","frozenSourceUpdatedAt":"2026-08-19T16:26:26.410Z","sourceUpdatedAt":"2026-08-19T16:26:26.410Z","sourceTitleSha256":"fab2a16c55c83622257f80bc3c8d2bafe38e778c7618766f473a51fbbdbfde5c","sourceBodySha256":"4b1de406e41f3b22fd6fa75888723caa04bceb2fd97bf01d359a4f52cb9a8c0f","proposedTitleSha256":"eb60af0a2f4f44163191b1254c09757ced2afa1b55d98ac566771107ff95dbd9","proposedBodySha256":"47857e1be8bc182f3954b31aac4e7cd10265e00458549bf0bcc47484cf2d6410"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1438","url":"https://linear.app/hash/issue/FE-1438/build-and-repair-petrinaut-nets-through-client-tools","postFetchAt":"2026-08-20T11:06:45.505Z","postUpdatedAt":"2026-08-20T11:06:45.008Z","proposedTitleSha256":"eb60af0a2f4f44163191b1254c09757ced2afa1b55d98ac566771107ff95dbd9","actualTitleSha256":"eb60af0a2f4f44163191b1254c09757ced2afa1b55d98ac566771107ff95dbd9","proposedBodySha256":"47857e1be8bc182f3954b31aac4e7cd10265e00458549bf0bcc47484cf2d6410","actualBodySha256":"47857e1be8bc182f3954b31aac4e7cd10265e00458549bf0bcc47484cf2d6410","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1439","url":"https://linear.app/hash/issue/FE-1439/elicitation-sessions-are-private-per-browser-and-survive-a-reload","preFetchAt":"2026-08-20T11:06:45.958Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.834Z","sourceUpdatedAt":"2026-08-19T16:20:26.834Z","sourceTitleSha256":"a52fa9f76201b88dac7f36951eb5cf70a0fbe75b77812e21ebc5ef0f904747bc","sourceBodySha256":"c98a5d0620887f1d30a07eb63f16d2d76d7dace03784a3b3d11e63f3874a8d5f","proposedTitleSha256":"83badee7b36397901779775d5c61784d988598414276c7fc7688524a5412816d","proposedBodySha256":"98c4a00fd0ed5d31948361198b25bdc575fd637e9f2553049511f9b5c7ddcc9a"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1439","url":"https://linear.app/hash/issue/FE-1439/keep-elicitation-sessions-private-and-durable-per-browser","postFetchAt":"2026-08-20T11:06:46.568Z","postUpdatedAt":"2026-08-20T11:06:46.228Z","proposedTitleSha256":"83badee7b36397901779775d5c61784d988598414276c7fc7688524a5412816d","actualTitleSha256":"83badee7b36397901779775d5c61784d988598414276c7fc7688524a5412816d","proposedBodySha256":"98c4a00fd0ed5d31948361198b25bdc575fd637e9f2553049511f9b5c7ddcc9a","actualBodySha256":"98c4a00fd0ed5d31948361198b25bdc575fd637e9f2553049511f9b5c7ddcc9a","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1440","url":"https://linear.app/hash/issue/FE-1440/demopetrinautorg-ships-the-elicitor-behind-its-chat-panel","preFetchAt":"2026-08-20T11:06:46.796Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.864Z","sourceUpdatedAt":"2026-08-19T16:20:26.864Z","sourceTitleSha256":"c963a4b6c2fd98029b5e8c57e30e341a983769da62cec64af0236ba081293204","sourceBodySha256":"697595134f5edfbfb98ca3046f039abca72047f4bf214916d4abcff9d41f04e5","proposedTitleSha256":"d882e519616af05bc1151622a8b41998f60086c3f34c03054700d640abb8639b","proposedBodySha256":"1770a1db71c34b2e7f1de875342f58b3212cdcd7d8c386653675f87b80f34622"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1440","url":"https://linear.app/hash/issue/FE-1440/ship-the-elicitor-in-demopetrinautorgs-chat-panel","postFetchAt":"2026-08-20T11:06:47.404Z","postUpdatedAt":"2026-08-20T11:06:47.047Z","proposedTitleSha256":"d882e519616af05bc1151622a8b41998f60086c3f34c03054700d640abb8639b","actualTitleSha256":"d882e519616af05bc1151622a8b41998f60086c3f34c03054700d640abb8639b","proposedBodySha256":"1770a1db71c34b2e7f1de875342f58b3212cdcd7d8c386653675f87b80f34622","actualBodySha256":"1770a1db71c34b2e7f1de875342f58b3212cdcd7d8c386653675f87b80f34622","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1441","url":"https://linear.app/hash/issue/FE-1441/the-elicitor-server-runs-on-hash-infrastructure-behind-the-pre-remote","preFetchAt":"2026-08-20T11:06:47.654Z","frozenSourceUpdatedAt":"2026-08-19T16:20:26.907Z","sourceUpdatedAt":"2026-08-19T16:20:26.907Z","sourceTitleSha256":"7857490e95bf278812b8552e2ed55d21146842212873364d9369fb83a55afeb2","sourceBodySha256":"2ddc691ac9f44ccc31fab6071cefa9c67942c94a358e3f4805da80d61fc19eb0","proposedTitleSha256":"2a684083abe883d56c05cfb528991e06968ddc3ae642725a685a2b8856552838","proposedBodySha256":"56da85ce45688f08c3c9bcc75a1feb6c66c33c364d7d956ab864b4dc6ac7e09c"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1441","url":"https://linear.app/hash/issue/FE-1441/deploy-the-elicitor-server-behind-the-remote-release-checks","postFetchAt":"2026-08-20T11:06:48.297Z","postUpdatedAt":"2026-08-20T11:06:47.912Z","proposedTitleSha256":"2a684083abe883d56c05cfb528991e06968ddc3ae642725a685a2b8856552838","actualTitleSha256":"2a684083abe883d56c05cfb528991e06968ddc3ae642725a685a2b8856552838","proposedBodySha256":"56da85ce45688f08c3c9bcc75a1feb6c66c33c364d7d956ab864b4dc6ac7e09c","actualBodySha256":"56da85ce45688f08c3c9bcc75a1feb6c66c33c364d7d956ab864b4dc6ac7e09c","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1442","url":"https://linear.app/hash/issue/FE-1442/captures-and-completion-accounting-render-live-in-the-demo-site","preFetchAt":"2026-08-20T11:06:48.546Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.003Z","sourceUpdatedAt":"2026-08-19T16:20:27.003Z","sourceTitleSha256":"aed7b19ffd731679630103fc8bee5d7cc962a5e2a54f6fb0d7336651c883bc1a","sourceBodySha256":"864ae481d518556b75611b62baf28fb2de7df4d8db340d87de86942ccea9130f","proposedTitleSha256":"5616c1839456f14a8a810e55e73ab6b6cd733e9a7a7734c09e4237b70fedd226","proposedBodySha256":"e9c8f5050856192989f953358829fce6ace7b563471ee3e2661d9f2fd80b050e"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1442","url":"https://linear.app/hash/issue/FE-1442/show-live-captures-and-completion-accounting-in-the-demo","postFetchAt":"2026-08-20T11:06:49.096Z","postUpdatedAt":"2026-08-20T11:06:48.796Z","proposedTitleSha256":"5616c1839456f14a8a810e55e73ab6b6cd733e9a7a7734c09e4237b70fedd226","actualTitleSha256":"5616c1839456f14a8a810e55e73ab6b6cd733e9a7a7734c09e4237b70fedd226","proposedBodySha256":"e9c8f5050856192989f953358829fce6ace7b563471ee3e2661d9f2fd80b050e","actualBodySha256":"e9c8f5050856192989f953358829fce6ace7b563471ee3e2661d9f2fd80b050e","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1448","url":"https://linear.app/hash/issue/FE-1448/petrinaut-hosts-render-their-own-interactive-chat-tools","preFetchAt":"2026-08-20T11:06:49.330Z","frozenSourceUpdatedAt":"2026-08-19T16:20:27.813Z","sourceUpdatedAt":"2026-08-19T16:20:27.813Z","sourceTitleSha256":"675c39fa590ebda855c128a3837f13a98d557cce9fda8da734e5e4efe36d9b18","sourceBodySha256":"d3722991fd835760a4d8a24c5822e68439a3860fb2308a354812cfafea0bf73e","proposedTitleSha256":"58f4d49b2319314a9ecad6dc0804e4883addf7a1135a04cd778f1a3808639503","proposedBodySha256":"95b45fea18fcca04ab562f60798aed01189c4b3010184d8eb011bd026c701d37"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1448","url":"https://linear.app/hash/issue/FE-1448/let-petrinaut-hosts-render-interactive-chat-tools","postFetchAt":"2026-08-20T11:06:50.015Z","postUpdatedAt":"2026-08-20T11:06:49.651Z","proposedTitleSha256":"58f4d49b2319314a9ecad6dc0804e4883addf7a1135a04cd778f1a3808639503","actualTitleSha256":"58f4d49b2319314a9ecad6dc0804e4883addf7a1135a04cd778f1a3808639503","proposedBodySha256":"95b45fea18fcca04ab562f60798aed01189c4b3010184d8eb011bd026c701d37","actualBodySha256":"95b45fea18fcca04ab562f60798aed01189c4b3010184d8eb011bd026c701d37","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1449","url":"https://linear.app/hash/issue/FE-1449/a-structured-brunch-question-suspends-and-resumes-visibly-in-petrinaut","preFetchAt":"2026-08-20T11:06:50.260Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.606Z","sourceUpdatedAt":"2026-08-19T16:20:28.606Z","sourceTitleSha256":"2b666da1c16c40eefa3542811dce3f24da1d9e005261fba747aace65a9fdb67c","sourceBodySha256":"acd7ce7b5b6bf664d57404bd478ac63a98039fa232ad5832d2706f11a3a4dbd0","proposedTitleSha256":"0d9a62e5831bbe93393b16af03d8f817c49c7e96f21e17d1c8311599b7db78cd","proposedBodySha256":"1981c5120550d60e77ee6d16355b06cf7eeaacaeee9e7e16432422dfcb4606e3"}
+{"event":"result","status":"pass","system":"linear","id":"FE-1449","url":"https://linear.app/hash/issue/FE-1449/prove-a-structured-brunch-question-suspends-and-resumes-in-petrinaut","postFetchAt":"2026-08-20T11:06:51.596Z","postUpdatedAt":"2026-08-20T11:06:50.620Z","proposedTitleSha256":"0d9a62e5831bbe93393b16af03d8f817c49c7e96f21e17d1c8311599b7db78cd","actualTitleSha256":"0d9a62e5831bbe93393b16af03d8f817c49c7e96f21e17d1c8311599b7db78cd","proposedBodySha256":"1981c5120550d60e77ee6d16355b06cf7eeaacaeee9e7e16432422dfcb4606e3","actualBodySha256":"1981c5120550d60e77ee6d16355b06cf7eeaacaeee9e7e16432422dfcb4606e3","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"linear","id":"FE-1451","url":"https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan","preFetchAt":"2026-08-20T11:06:51.842Z","frozenSourceUpdatedAt":"2026-08-19T16:20:28.510Z","sourceUpdatedAt":"2026-08-19T16:20:28.510Z","sourceTitleSha256":"37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c","sourceBodySha256":"91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb","proposedTitleSha256":"37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c","proposedBodySha256":"91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb"}
+{"event":"result","status":"pass-no-write","system":"linear","id":"FE-1451","url":"https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan","postFetchAt":"2026-08-20T11:06:51.842Z","postUpdatedAt":"2026-08-19T16:20:28.510Z","proposedTitleSha256":"37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c","actualTitleSha256":"37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c","proposedBodySha256":"91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb","actualBodySha256":"91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb"}
+{"event":"attempt","system":"github","id":"1","url":"https://github.com/hashintel/brunch-lite/pull/1","preFetchAt":"2026-08-20T11:06:52.231Z","frozenSourceUpdatedAt":"2026-08-19T13:59:58Z","sourceUpdatedAt":"2026-08-19T13:59:58Z","sourceTitleSha256":"2349400d04eb80fe6d4f1253ea64eecc37cc01df5cc71141a92dbc1839396dbc","sourceBodySha256":"b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51","proposedTitleSha256":"a8f91f538eeab4311fa3335a16ca25fec9b7947f3fa92482ea23445e1fc16ee2","proposedBodySha256":"0979c93127052da2249f61275c1bdc3d9b77744bb39473f37b45268c9ba56e27"}
+{"event":"result","status":"pass","system":"github","id":"1","url":"https://github.com/hashintel/brunch-lite/pull/1","postFetchAt":"2026-08-20T11:06:54.381Z","postUpdatedAt":"2026-08-20T11:06:53Z","proposedTitleSha256":"a8f91f538eeab4311fa3335a16ca25fec9b7947f3fa92482ea23445e1fc16ee2","actualTitleSha256":"a8f91f538eeab4311fa3335a16ca25fec9b7947f3fa92482ea23445e1fc16ee2","proposedBodySha256":"0979c93127052da2249f61275c1bdc3d9b77744bb39473f37b45268c9ba56e27","actualBodySha256":"0979c93127052da2249f61275c1bdc3d9b77744bb39473f37b45268c9ba56e27","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"2","url":"https://github.com/hashintel/brunch-lite/pull/2","preFetchAt":"2026-08-20T11:06:54.768Z","frozenSourceUpdatedAt":"2026-08-19T14:00:01Z","sourceUpdatedAt":"2026-08-19T14:00:01Z","sourceTitleSha256":"213035e657b4ee4135ccdf4f4781e3b7a94d4a42d404ced75c5f821df9c4b371","sourceBodySha256":"def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce","proposedTitleSha256":"458af585ac43810b677bbdfe77441117a25d8071bfe5a8d069b3879b23fa0417","proposedBodySha256":"def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce"}
+{"event":"result","status":"pass","system":"github","id":"2","url":"https://github.com/hashintel/brunch-lite/pull/2","postFetchAt":"2026-08-20T11:06:57.003Z","postUpdatedAt":"2026-08-20T11:06:55Z","proposedTitleSha256":"458af585ac43810b677bbdfe77441117a25d8071bfe5a8d069b3879b23fa0417","actualTitleSha256":"458af585ac43810b677bbdfe77441117a25d8071bfe5a8d069b3879b23fa0417","proposedBodySha256":"def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce","actualBodySha256":"def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"3","url":"https://github.com/hashintel/brunch-lite/pull/3","preFetchAt":"2026-08-20T11:06:57.383Z","frozenSourceUpdatedAt":"2026-08-19T14:00:02Z","sourceUpdatedAt":"2026-08-19T14:00:02Z","sourceTitleSha256":"479fc988f738df20272d535d4cdec59affba9e2c782f716ba8b2c1077966ece0","sourceBodySha256":"c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00","proposedTitleSha256":"7598d7609bc76a5d78feb41eeac4bbcc1db8d0c985950181ae0fe83d6c6ba673","proposedBodySha256":"c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00"}
+{"event":"result","status":"pass","system":"github","id":"3","url":"https://github.com/hashintel/brunch-lite/pull/3","postFetchAt":"2026-08-20T11:06:59.286Z","postUpdatedAt":"2026-08-20T11:06:58Z","proposedTitleSha256":"7598d7609bc76a5d78feb41eeac4bbcc1db8d0c985950181ae0fe83d6c6ba673","actualTitleSha256":"7598d7609bc76a5d78feb41eeac4bbcc1db8d0c985950181ae0fe83d6c6ba673","proposedBodySha256":"c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00","actualBodySha256":"c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"4","url":"https://github.com/hashintel/brunch-lite/pull/4","preFetchAt":"2026-08-20T11:06:59.824Z","frozenSourceUpdatedAt":"2026-08-19T14:00:04Z","sourceUpdatedAt":"2026-08-19T14:00:04Z","sourceTitleSha256":"d1e15580b5ebf90f1be401019c3b33876f59f9aabe23a0424ee5b0688b15a628","sourceBodySha256":"b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d","proposedTitleSha256":"cc1738d69bc2a0bf6d4a0f4f5f784f693fd5e6dbe17dc6feb725d0a4e118c00c","proposedBodySha256":"b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d"}
+{"event":"result","status":"pass","system":"github","id":"4","url":"https://github.com/hashintel/brunch-lite/pull/4","postFetchAt":"2026-08-20T11:07:01.775Z","postUpdatedAt":"2026-08-20T11:07:00Z","proposedTitleSha256":"cc1738d69bc2a0bf6d4a0f4f5f784f693fd5e6dbe17dc6feb725d0a4e118c00c","actualTitleSha256":"cc1738d69bc2a0bf6d4a0f4f5f784f693fd5e6dbe17dc6feb725d0a4e118c00c","proposedBodySha256":"b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d","actualBodySha256":"b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"5","url":"https://github.com/hashintel/brunch-lite/pull/5","preFetchAt":"2026-08-20T11:07:02.333Z","frozenSourceUpdatedAt":"2026-08-19T14:00:05Z","sourceUpdatedAt":"2026-08-19T14:00:05Z","sourceTitleSha256":"229ac27a91eab0e70254f9a283f3ef6a9f8d375bbf17fffdb8f7d04d2ac59603","sourceBodySha256":"e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc","proposedTitleSha256":"7e6aa2e05b76ccab92408f3a06e373916fa4a381d00bcfb1ee2f35bebbbb2fce","proposedBodySha256":"e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc"}
+{"event":"result","status":"pass","system":"github","id":"5","url":"https://github.com/hashintel/brunch-lite/pull/5","postFetchAt":"2026-08-20T11:07:04.424Z","postUpdatedAt":"2026-08-20T11:07:03Z","proposedTitleSha256":"7e6aa2e05b76ccab92408f3a06e373916fa4a381d00bcfb1ee2f35bebbbb2fce","actualTitleSha256":"7e6aa2e05b76ccab92408f3a06e373916fa4a381d00bcfb1ee2f35bebbbb2fce","proposedBodySha256":"e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc","actualBodySha256":"e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"6","url":"https://github.com/hashintel/brunch-lite/pull/6","preFetchAt":"2026-08-20T11:07:04.927Z","frozenSourceUpdatedAt":"2026-08-19T14:00:06Z","sourceUpdatedAt":"2026-08-19T14:00:06Z","sourceTitleSha256":"49a7e617a4276a193a7ac78578d95fb09586d2fd660232472afb83eaa2c81739","sourceBodySha256":"a504f8f2a3ac48ec0599e2f1bf0a8d9968e94dbbd04eb6d8b23d200966e8bbb6","proposedTitleSha256":"bdc8e582d944ef44c03f78151f32661499c5215a2f327e39174752accf901a04","proposedBodySha256":"d83c7fcbbec74341c2a25153d3146f0bd579d0c4f60794b634a3aaf73c472bcf"}
+{"event":"result","status":"pass","system":"github","id":"6","url":"https://github.com/hashintel/brunch-lite/pull/6","postFetchAt":"2026-08-20T11:07:06.908Z","postUpdatedAt":"2026-08-20T11:07:05Z","proposedTitleSha256":"bdc8e582d944ef44c03f78151f32661499c5215a2f327e39174752accf901a04","actualTitleSha256":"bdc8e582d944ef44c03f78151f32661499c5215a2f327e39174752accf901a04","proposedBodySha256":"d83c7fcbbec74341c2a25153d3146f0bd579d0c4f60794b634a3aaf73c472bcf","actualBodySha256":"d83c7fcbbec74341c2a25153d3146f0bd579d0c4f60794b634a3aaf73c472bcf","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"7","url":"https://github.com/hashintel/brunch-lite/pull/7","preFetchAt":"2026-08-20T11:07:07.476Z","frozenSourceUpdatedAt":"2026-08-19T14:00:08Z","sourceUpdatedAt":"2026-08-19T14:00:08Z","sourceTitleSha256":"09929e03f4a76113a051454c63fd0fdad8466e536a83e0e3f13e4a817672c64c","sourceBodySha256":"23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119","proposedTitleSha256":"9e63a535656da4e9bbe1c7957f4bfb59f90355f87f2ce4e9de37710a82389bf4","proposedBodySha256":"23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119"}
+{"event":"result","status":"pass","system":"github","id":"7","url":"https://github.com/hashintel/brunch-lite/pull/7","postFetchAt":"2026-08-20T11:07:09.303Z","postUpdatedAt":"2026-08-20T11:07:08Z","proposedTitleSha256":"9e63a535656da4e9bbe1c7957f4bfb59f90355f87f2ce4e9de37710a82389bf4","actualTitleSha256":"9e63a535656da4e9bbe1c7957f4bfb59f90355f87f2ce4e9de37710a82389bf4","proposedBodySha256":"23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119","actualBodySha256":"23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"8","url":"https://github.com/hashintel/brunch-lite/pull/8","preFetchAt":"2026-08-20T11:07:09.957Z","frozenSourceUpdatedAt":"2026-08-19T14:00:10Z","sourceUpdatedAt":"2026-08-19T14:00:10Z","sourceTitleSha256":"bb81d98a6ecb4ad55e7dddaf963f52da31c86a14e7cb652ee63e46396ee2867e","sourceBodySha256":"e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0","proposedTitleSha256":"bae06a837f10393b559487334471689c1caec1bc3b2679307399a9c3b2bf8dd6","proposedBodySha256":"e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0"}
+{"event":"result","status":"pass","system":"github","id":"8","url":"https://github.com/hashintel/brunch-lite/pull/8","postFetchAt":"2026-08-20T11:07:12.738Z","postUpdatedAt":"2026-08-20T11:07:11Z","proposedTitleSha256":"bae06a837f10393b559487334471689c1caec1bc3b2679307399a9c3b2bf8dd6","actualTitleSha256":"bae06a837f10393b559487334471689c1caec1bc3b2679307399a9c3b2bf8dd6","proposedBodySha256":"e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0","actualBodySha256":"e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"9","url":"https://github.com/hashintel/brunch-lite/pull/9","preFetchAt":"2026-08-20T11:07:13.222Z","frozenSourceUpdatedAt":"2026-08-19T14:00:12Z","sourceUpdatedAt":"2026-08-19T14:00:12Z","sourceTitleSha256":"438c3f68d2d61c5975585c864f38610d5e0899e9f6d1aea28d3091b82f63bb71","sourceBodySha256":"3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869","proposedTitleSha256":"faa8423c1089c9e54da238b96e560b9f51d59753911795f70e02404c4330c2ad","proposedBodySha256":"3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869"}
+{"event":"result","status":"pass","system":"github","id":"9","url":"https://github.com/hashintel/brunch-lite/pull/9","postFetchAt":"2026-08-20T11:07:15.457Z","postUpdatedAt":"2026-08-20T11:07:14Z","proposedTitleSha256":"faa8423c1089c9e54da238b96e560b9f51d59753911795f70e02404c4330c2ad","actualTitleSha256":"faa8423c1089c9e54da238b96e560b9f51d59753911795f70e02404c4330c2ad","proposedBodySha256":"3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869","actualBodySha256":"3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"10","url":"https://github.com/hashintel/brunch-lite/pull/10","preFetchAt":"2026-08-20T11:07:15.813Z","frozenSourceUpdatedAt":"2026-08-19T14:00:14Z","sourceUpdatedAt":"2026-08-19T14:00:14Z","sourceTitleSha256":"9aa634521196bc66ad8a36254eb995aee3b484177468d0bb0e007fb358ffb8b7","sourceBodySha256":"f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69","proposedTitleSha256":"9f9d804c351ad92f5aa55b524422d7f06ebfe17f1303afed89d45504f08c24c5","proposedBodySha256":"f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69"}
+{"event":"result","status":"pass","system":"github","id":"10","url":"https://github.com/hashintel/brunch-lite/pull/10","postFetchAt":"2026-08-20T11:07:17.856Z","postUpdatedAt":"2026-08-20T11:07:16Z","proposedTitleSha256":"9f9d804c351ad92f5aa55b524422d7f06ebfe17f1303afed89d45504f08c24c5","actualTitleSha256":"9f9d804c351ad92f5aa55b524422d7f06ebfe17f1303afed89d45504f08c24c5","proposedBodySha256":"f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69","actualBodySha256":"f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"11","url":"https://github.com/hashintel/brunch-lite/pull/11","preFetchAt":"2026-08-20T11:07:18.221Z","frozenSourceUpdatedAt":"2026-08-19T14:00:15Z","sourceUpdatedAt":"2026-08-19T14:00:15Z","sourceTitleSha256":"710989fa7a8870a91ba1e36447c52327068378fbb13bc879314f367363dc3f6c","sourceBodySha256":"a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0","proposedTitleSha256":"22595d4a7cabef17857419e2dbf83063fe24ac0901cd30e437194d4ed67a8760","proposedBodySha256":"a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0"}
+{"event":"result","status":"pass","system":"github","id":"11","url":"https://github.com/hashintel/brunch-lite/pull/11","postFetchAt":"2026-08-20T11:07:20.140Z","postUpdatedAt":"2026-08-20T11:07:19Z","proposedTitleSha256":"22595d4a7cabef17857419e2dbf83063fe24ac0901cd30e437194d4ed67a8760","actualTitleSha256":"22595d4a7cabef17857419e2dbf83063fe24ac0901cd30e437194d4ed67a8760","proposedBodySha256":"a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0","actualBodySha256":"a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"12","url":"https://github.com/hashintel/brunch-lite/pull/12","preFetchAt":"2026-08-20T11:07:20.543Z","frozenSourceUpdatedAt":"2026-08-19T14:00:17Z","sourceUpdatedAt":"2026-08-19T14:00:17Z","sourceTitleSha256":"0451f66a36602e806df9c2112c1121521b94245613ec8efffb621bb83695c9d0","sourceBodySha256":"cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3","proposedTitleSha256":"7e725384f146f7ebb36106ec02c07afc099ce5cdc2f930ba4071360521075864","proposedBodySha256":"cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3"}
+{"event":"result","status":"pass","system":"github","id":"12","url":"https://github.com/hashintel/brunch-lite/pull/12","postFetchAt":"2026-08-20T11:07:22.630Z","postUpdatedAt":"2026-08-20T11:07:21Z","proposedTitleSha256":"7e725384f146f7ebb36106ec02c07afc099ce5cdc2f930ba4071360521075864","actualTitleSha256":"7e725384f146f7ebb36106ec02c07afc099ce5cdc2f930ba4071360521075864","proposedBodySha256":"cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3","actualBodySha256":"cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"13","url":"https://github.com/hashintel/brunch-lite/pull/13","preFetchAt":"2026-08-20T11:07:23.079Z","frozenSourceUpdatedAt":"2026-08-19T14:00:18Z","sourceUpdatedAt":"2026-08-19T14:00:18Z","sourceTitleSha256":"fb7a8ac27ea24f41a79d749ca20733e2c25c4b1cee170719bc02ce0d241ad260","sourceBodySha256":"f9ab772a065145e23ed733c85c63888b8319ec31e8b04db7b281917372d796d4","proposedTitleSha256":"c43385e89922f03a26c6c15c89a3c7dc189fb95b3ccf2a94a808413977a5a242","proposedBodySha256":"7c6d072833c15450fddbb3e102cf9b39e7aeb2af621c1090a990f5c6894e0b14"}
+{"event":"result","status":"pass","system":"github","id":"13","url":"https://github.com/hashintel/brunch-lite/pull/13","postFetchAt":"2026-08-20T11:07:25.419Z","postUpdatedAt":"2026-08-20T11:07:24Z","proposedTitleSha256":"c43385e89922f03a26c6c15c89a3c7dc189fb95b3ccf2a94a808413977a5a242","actualTitleSha256":"c43385e89922f03a26c6c15c89a3c7dc189fb95b3ccf2a94a808413977a5a242","proposedBodySha256":"7c6d072833c15450fddbb3e102cf9b39e7aeb2af621c1090a990f5c6894e0b14","actualBodySha256":"7c6d072833c15450fddbb3e102cf9b39e7aeb2af621c1090a990f5c6894e0b14","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"14","url":"https://github.com/hashintel/brunch-lite/pull/14","preFetchAt":"2026-08-20T11:07:25.832Z","frozenSourceUpdatedAt":"2026-08-19T14:00:20Z","sourceUpdatedAt":"2026-08-19T14:00:20Z","sourceTitleSha256":"23fbf383a72d5bb528910b8067ebd01c3aef2aad088e7404b1c19f5a196b894e","sourceBodySha256":"c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1","proposedTitleSha256":"4d0da7c37b1220355532b1062a9574928d56585c3adccc46db85993296d42775","proposedBodySha256":"c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1"}
+{"event":"result","status":"pass","system":"github","id":"14","url":"https://github.com/hashintel/brunch-lite/pull/14","postFetchAt":"2026-08-20T11:07:27.663Z","postUpdatedAt":"2026-08-20T11:07:26Z","proposedTitleSha256":"4d0da7c37b1220355532b1062a9574928d56585c3adccc46db85993296d42775","actualTitleSha256":"4d0da7c37b1220355532b1062a9574928d56585c3adccc46db85993296d42775","proposedBodySha256":"c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1","actualBodySha256":"c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"15","url":"https://github.com/hashintel/brunch-lite/pull/15","preFetchAt":"2026-08-20T11:07:28.028Z","frozenSourceUpdatedAt":"2026-08-19T14:00:22Z","sourceUpdatedAt":"2026-08-19T14:00:22Z","sourceTitleSha256":"9b957cd8c760d786142e94469da03e59648c0835a5a54a7ec59204f86372f2dd","sourceBodySha256":"105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa","proposedTitleSha256":"e01c6144680b6cd34c16ff1fe903b519508ac67a92e8685b10c958da998646d0","proposedBodySha256":"105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa"}
+{"event":"result","status":"pass","system":"github","id":"15","url":"https://github.com/hashintel/brunch-lite/pull/15","postFetchAt":"2026-08-20T11:07:29.914Z","postUpdatedAt":"2026-08-20T11:07:29Z","proposedTitleSha256":"e01c6144680b6cd34c16ff1fe903b519508ac67a92e8685b10c958da998646d0","actualTitleSha256":"e01c6144680b6cd34c16ff1fe903b519508ac67a92e8685b10c958da998646d0","proposedBodySha256":"105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa","actualBodySha256":"105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"16","url":"https://github.com/hashintel/brunch-lite/pull/16","preFetchAt":"2026-08-20T11:07:30.263Z","frozenSourceUpdatedAt":"2026-08-19T14:00:24Z","sourceUpdatedAt":"2026-08-19T14:00:24Z","sourceTitleSha256":"57533df404cf90eb95676d0223056011c73aa2ab89bacfeb6ebc12e5e91d1703","sourceBodySha256":"1fc9f55dcaded9b23be43b01e2fe6961b26a0bf5556f802ddfc7d1066846c05d","proposedTitleSha256":"c4f73648953a1017375d057a002e7e9e5e54ec125908d71ac88751df04e3cece","proposedBodySha256":"b8d8aeb75c6e9c3d29795bf1328907df38da7a1c5b213991077340cd533fef60"}
+{"event":"result","status":"pass","system":"github","id":"16","url":"https://github.com/hashintel/brunch-lite/pull/16","postFetchAt":"2026-08-20T11:07:32.544Z","postUpdatedAt":"2026-08-20T11:07:31Z","proposedTitleSha256":"c4f73648953a1017375d057a002e7e9e5e54ec125908d71ac88751df04e3cece","actualTitleSha256":"c4f73648953a1017375d057a002e7e9e5e54ec125908d71ac88751df04e3cece","proposedBodySha256":"b8d8aeb75c6e9c3d29795bf1328907df38da7a1c5b213991077340cd533fef60","actualBodySha256":"b8d8aeb75c6e9c3d29795bf1328907df38da7a1c5b213991077340cd533fef60","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"17","url":"https://github.com/hashintel/brunch-lite/pull/17","preFetchAt":"2026-08-20T11:07:33.041Z","frozenSourceUpdatedAt":"2026-08-19T14:00:26Z","sourceUpdatedAt":"2026-08-19T14:00:26Z","sourceTitleSha256":"8df88b0ce1d3b89975c44cc7efb9d680d2cbda6518cf08c0af135ab15e663dae","sourceBodySha256":"08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84","proposedTitleSha256":"9954744d1e7f83e9cf2e0790c7f4fef2053bae828b5b404a6907e0d5fa7993d8","proposedBodySha256":"08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84"}
+{"event":"result","status":"pass","system":"github","id":"17","url":"https://github.com/hashintel/brunch-lite/pull/17","postFetchAt":"2026-08-20T11:07:35.132Z","postUpdatedAt":"2026-08-20T11:07:34Z","proposedTitleSha256":"9954744d1e7f83e9cf2e0790c7f4fef2053bae828b5b404a6907e0d5fa7993d8","actualTitleSha256":"9954744d1e7f83e9cf2e0790c7f4fef2053bae828b5b404a6907e0d5fa7993d8","proposedBodySha256":"08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84","actualBodySha256":"08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"18","url":"https://github.com/hashintel/brunch-lite/pull/18","preFetchAt":"2026-08-20T11:07:35.562Z","frozenSourceUpdatedAt":"2026-08-19T14:00:27Z","sourceUpdatedAt":"2026-08-19T14:00:27Z","sourceTitleSha256":"e2af4a86d0444c15a7135f477591b390b36fff479e0915de853efc36b4e36ec9","sourceBodySha256":"74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062","proposedTitleSha256":"f698116a5d502505cf06eee2c881152aacff9a5dc62dd50ce994097d89e26504","proposedBodySha256":"74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062"}
+{"event":"result","status":"pass","system":"github","id":"18","url":"https://github.com/hashintel/brunch-lite/pull/18","postFetchAt":"2026-08-20T11:07:37.675Z","postUpdatedAt":"2026-08-20T11:07:36Z","proposedTitleSha256":"f698116a5d502505cf06eee2c881152aacff9a5dc62dd50ce994097d89e26504","actualTitleSha256":"f698116a5d502505cf06eee2c881152aacff9a5dc62dd50ce994097d89e26504","proposedBodySha256":"74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062","actualBodySha256":"74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"19","url":"https://github.com/hashintel/brunch-lite/pull/19","preFetchAt":"2026-08-20T11:07:38.047Z","frozenSourceUpdatedAt":"2026-08-19T14:00:29Z","sourceUpdatedAt":"2026-08-19T14:00:29Z","sourceTitleSha256":"8baa3f7952c774fe17d2c91f5700063fa8e11047b193813df55b11766fee8eab","sourceBodySha256":"ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172","proposedTitleSha256":"8ccaf0c07e327041d4668ce81044910a1a8aad1a972fea9a58cb4712248b55d5","proposedBodySha256":"ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172"}
+{"event":"result","status":"pass","system":"github","id":"19","url":"https://github.com/hashintel/brunch-lite/pull/19","postFetchAt":"2026-08-20T11:07:39.948Z","postUpdatedAt":"2026-08-20T11:07:38Z","proposedTitleSha256":"8ccaf0c07e327041d4668ce81044910a1a8aad1a972fea9a58cb4712248b55d5","actualTitleSha256":"8ccaf0c07e327041d4668ce81044910a1a8aad1a972fea9a58cb4712248b55d5","proposedBodySha256":"ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172","actualBodySha256":"ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"20","url":"https://github.com/hashintel/brunch-lite/pull/20","preFetchAt":"2026-08-20T11:07:40.388Z","frozenSourceUpdatedAt":"2026-08-19T14:00:30Z","sourceUpdatedAt":"2026-08-19T14:00:30Z","sourceTitleSha256":"f994067680a1d677c1289baa403f1b2db4452f64845198006fd1c337648d7e81","sourceBodySha256":"c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64","proposedTitleSha256":"d9f075f2ac5533ff46283090cb71614d94d646c35770bc576fc4e0ef56cc8fac","proposedBodySha256":"c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64"}
+{"event":"result","status":"pass","system":"github","id":"20","url":"https://github.com/hashintel/brunch-lite/pull/20","postFetchAt":"2026-08-20T11:07:42.332Z","postUpdatedAt":"2026-08-20T11:07:41Z","proposedTitleSha256":"d9f075f2ac5533ff46283090cb71614d94d646c35770bc576fc4e0ef56cc8fac","actualTitleSha256":"d9f075f2ac5533ff46283090cb71614d94d646c35770bc576fc4e0ef56cc8fac","proposedBodySha256":"c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64","actualBodySha256":"c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"21","url":"https://github.com/hashintel/brunch-lite/pull/21","preFetchAt":"2026-08-20T11:07:42.941Z","frozenSourceUpdatedAt":"2026-08-19T14:00:32Z","sourceUpdatedAt":"2026-08-19T14:00:32Z","sourceTitleSha256":"c47a125d640ac02cb20d9907f82c7d3612121c3ba6b574f4fa7560dc2d4e30d7","sourceBodySha256":"037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4","proposedTitleSha256":"9b1c3bca7e522d63f672b120d90915ffef92a352e80ff04cfa830132675fbaf8","proposedBodySha256":"037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4"}
+{"event":"result","status":"pass","system":"github","id":"21","url":"https://github.com/hashintel/brunch-lite/pull/21","postFetchAt":"2026-08-20T11:07:45.001Z","postUpdatedAt":"2026-08-20T11:07:44Z","proposedTitleSha256":"9b1c3bca7e522d63f672b120d90915ffef92a352e80ff04cfa830132675fbaf8","actualTitleSha256":"9b1c3bca7e522d63f672b120d90915ffef92a352e80ff04cfa830132675fbaf8","proposedBodySha256":"037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4","actualBodySha256":"037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"22","url":"https://github.com/hashintel/brunch-lite/pull/22","preFetchAt":"2026-08-20T11:07:45.382Z","frozenSourceUpdatedAt":"2026-08-19T14:00:35Z","sourceUpdatedAt":"2026-08-19T14:00:35Z","sourceTitleSha256":"ea8d78aaeef51c451235b2dcd2e5aef2459dfa218dae80928968f5499c0408ea","sourceBodySha256":"985fc49182ce7429b93462cb72bd5124b6f77a2c66a3f554e63ebd1c5a3a44b5","proposedTitleSha256":"a41b16dba248a6166529bffabfe03285094f31eb035eb04f7fdde9ca318f4fe2","proposedBodySha256":"0027d14716564d6aa96a13fa64814e364773ecaac6b3a5e2fd3fbf5cf5f51049"}
+{"event":"result","status":"pass","system":"github","id":"22","url":"https://github.com/hashintel/brunch-lite/pull/22","postFetchAt":"2026-08-20T11:07:47.636Z","postUpdatedAt":"2026-08-20T11:07:46Z","proposedTitleSha256":"a41b16dba248a6166529bffabfe03285094f31eb035eb04f7fdde9ca318f4fe2","actualTitleSha256":"a41b16dba248a6166529bffabfe03285094f31eb035eb04f7fdde9ca318f4fe2","proposedBodySha256":"0027d14716564d6aa96a13fa64814e364773ecaac6b3a5e2fd3fbf5cf5f51049","actualBodySha256":"0027d14716564d6aa96a13fa64814e364773ecaac6b3a5e2fd3fbf5cf5f51049","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"23","url":"https://github.com/hashintel/brunch-lite/pull/23","preFetchAt":"2026-08-20T11:07:48.029Z","frozenSourceUpdatedAt":"2026-08-19T14:00:37Z","sourceUpdatedAt":"2026-08-19T14:00:37Z","sourceTitleSha256":"51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e","sourceBodySha256":"c0634fcf88f0fb7c9428da627183b68b53d13023a55153fb1649230f5717ede3","proposedTitleSha256":"51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e","proposedBodySha256":"4a6f614020fc7358da54c5ee3c60b5be98b61a8b38a6ea36d6ddcbbcc948cd3f"}
+{"event":"result","status":"pass","system":"github","id":"23","url":"https://github.com/hashintel/brunch-lite/pull/23","postFetchAt":"2026-08-20T11:07:50.024Z","postUpdatedAt":"2026-08-20T11:07:49Z","proposedTitleSha256":"51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e","actualTitleSha256":"51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e","proposedBodySha256":"4a6f614020fc7358da54c5ee3c60b5be98b61a8b38a6ea36d6ddcbbcc948cd3f","actualBodySha256":"4a6f614020fc7358da54c5ee3c60b5be98b61a8b38a6ea36d6ddcbbcc948cd3f","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"24","url":"https://github.com/hashintel/brunch-lite/pull/24","preFetchAt":"2026-08-20T11:07:50.407Z","frozenSourceUpdatedAt":"2026-08-19T14:00:38Z","sourceUpdatedAt":"2026-08-19T14:00:38Z","sourceTitleSha256":"bd9e156289c48be8bc090b55ed791baa949ca60fa375428e1ce44cefdee10367","sourceBodySha256":"e1027892dd6c1a87afc8f7922fc51a997066da09baf710a15c05aa24a9c5c283","proposedTitleSha256":"de0d1aadfb9abaa4ddf82a39384235745c19d1059cc27cf1abd1cb163ceb67d1","proposedBodySha256":"240284375b0b085d4b4315a13ffb2eed87affa8b36f03c73757cb6f23fc841ca"}
+{"event":"result","status":"pass","system":"github","id":"24","url":"https://github.com/hashintel/brunch-lite/pull/24","postFetchAt":"2026-08-20T11:07:52.516Z","postUpdatedAt":"2026-08-20T11:07:51Z","proposedTitleSha256":"de0d1aadfb9abaa4ddf82a39384235745c19d1059cc27cf1abd1cb163ceb67d1","actualTitleSha256":"de0d1aadfb9abaa4ddf82a39384235745c19d1059cc27cf1abd1cb163ceb67d1","proposedBodySha256":"240284375b0b085d4b4315a13ffb2eed87affa8b36f03c73757cb6f23fc841ca","actualBodySha256":"240284375b0b085d4b4315a13ffb2eed87affa8b36f03c73757cb6f23fc841ca","writeExitCode":0,"writeStderr":""}
+{"event":"attempt","system":"github","id":"25","url":"https://github.com/hashintel/brunch-lite/pull/25","preFetchAt":"2026-08-20T11:07:52.940Z","frozenSourceUpdatedAt":"2026-08-20T08:46:31Z","sourceUpdatedAt":"2026-08-20T08:46:31Z","sourceTitleSha256":"92298a4ff0ba866ac7de95fa5ae22a2be4d911f4e3ef9db4a562987660d684bb","sourceBodySha256":"37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851","proposedTitleSha256":"ef0946c7b52dd74664a885cb423b8c3571349fe4b24b9390bde97b05c235a710","proposedBodySha256":"dbb0116f134378a4b1b42607319fe88abf91f7b1c618ccaaea20fada9a24dc72"}
+{"event":"result","status":"pass","system":"github","id":"25","url":"https://github.com/hashintel/brunch-lite/pull/25","postFetchAt":"2026-08-20T11:07:55.173Z","postUpdatedAt":"2026-08-20T11:07:54Z","proposedTitleSha256":"ef0946c7b52dd74664a885cb423b8c3571349fe4b24b9390bde97b05c235a710","actualTitleSha256":"ef0946c7b52dd74664a885cb423b8c3571349fe4b24b9390bde97b05c235a710","proposedBodySha256":"dbb0116f134378a4b1b42607319fe88abf91f7b1c618ccaaea20fada9a24dc72","actualBodySha256":"dbb0116f134378a4b1b42607319fe88abf91f7b1c618ccaaea20fada9a24dc72","writeExitCode":0,"writeStderr":""}
+{"event":"final-reconciliation","status":"pass","reconciledAt":"2026-08-20T11:13:01.978Z","linearTargets":67,"linearExcluded":6,"githubTargets":25,"integrationUpdatedLinearIssues":["FE-1361","FE-1362","FE-1363","FE-1364","FE-1374","FE-1388","FE-1389","FE-1390","FE-1391","FE-1392","FE-1397","FE-1399","FE-1400","FE-1401","FE-1405","FE-1419","FE-1422","FE-1424","FE-1432","FE-1433","FE-1434","FE-1435","FE-1436","FE-1449"],"metadataUpdatedExcludedLinearIssues":["FE-1333"],"finalStateSha256":"57aa5ae047cd041d203301877a7f6fb8afb7de878ae1f5d101e39d7b84afa535"}
+{"event":"final-reconciliation","status":"pass","reconciledAt":"2026-08-20T11:16:44.819Z","linearTargets":67,"linearExcluded":6,"githubTargets":25,"integrationUpdatedLinearIssues":["FE-1361","FE-1362","FE-1363","FE-1364","FE-1374","FE-1388","FE-1389","FE-1390","FE-1391","FE-1392","FE-1397","FE-1399","FE-1400","FE-1401","FE-1405","FE-1419","FE-1422","FE-1424","FE-1432","FE-1433","FE-1434","FE-1435","FE-1436","FE-1449"],"metadataUpdatedExcludedLinearIssues":["FE-1333"],"finalStateSha256":"57aa5ae047cd041d203301877a7f6fb8afb7de878ae1f5d101e39d7b84afa535"}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-proposals.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-proposals.json
new file mode 100644
index 00000000000..70bd0a6fb33
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-proposals.json
@@ -0,0 +1,656 @@
+{
+  "generatedAt": "2026-08-20T09:19:39.051896Z",
+  "prCount": 25,
+  "prs": [
+    {
+      "number": 25,
+      "url": "https://github.com/hashintel/brunch-lite/pull/25",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1449-structured-ask",
+      "linkedIssue": "FE-1449",
+      "sourceUpdatedAt": "2026-08-20T08:46:31Z",
+      "sourceTitle": "FE-1449: A structured brunch question suspends and resumes visibly in Petrinaut",
+      "sourceTitleSha256": "92298a4ff0ba866ac7de95fa5ae22a2be4d911f4e3ef9db4a562987660d684bb",
+      "sourceBodySha256": "37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851",
+      "proposedTitle": "FE-1449: Prove a structured brunch question suspends and resumes in Petrinaut",
+      "oldOuter": "",
+      "proposedOuter": "This branch keeps a structured brunch question open on the AI SDK wire and resumes the same Flue conversation when the matching human answer arrives through the committed application route. It validates the reply against durable conversation history and rejects stale, duplicate, forged, malformed, and machine-only submissions before dispatch. Petrinaut component registration through FE-1448 remains required for full acceptance.",
+      "extractionMethod": "whole source body treated as authoritative inner record and wrapped once",
+      "sourceInnerRecord": "## Stack Context\n\nFE-1433 sequences the Petrinaut integration from the proven Flue suspension and AI SDK seams. This branch is the ask suspend/return slice, stacked on FE-1436's durable transport; its panel-side counterpart is the FE-1448 host interactive-tool API in hashintel/hash (PR hashintel/hash#9249).\n\n## What?\n\n- `transport-aisdk` holds a `brunch_ask` open on the wire: awaiting client tool with a stable `toolCallId`, the harness's minted affordance output withheld\n- the tool-result follow-up POST — previously refused wholesale — is admitted exactly when it carries the pending ask's correlated `{ answer }` submission\n- `@brunch/core` gains the pure protocol: `pendingAskAffordanceId`, `decideAskReplyAdmission`, and the `AskSubmission` submitted-output contract\n- the application's new `askReply` seam admits against durable Flue history before any dispatch, then resumes the conversation as a fresh user dispatch that the binding binds as the user-affordance reply\n- opt-in inspection gains `ask-await`, `ask-reply-admitted`, `ask-reply-refused`\n\n## Why?\n\nFE-1449 requires provenance to settle at the wire boundary: a human answer travels tool-output-shaped but is not a machine tool result. Only the currently pending ask's correlated submission may become user evidence — stale/duplicate submissions get `409 ask_not_pending`, forged ids `409 ask_mismatch`, malformed submissions `400 invalid_ask_submission`, and machine-only follow-ups (mutation outputs, diagnostics) keep FE-1436's `422`. Concurrent duplicates collapse at the substrate via the `{conversationId}:ask:{toolCallId}` idempotency key.\n\nRemaining for full FE-1449 acceptance: petrinaut-website registers the ask component through the FE-1448 `aiAssistant` API (hash-side branch); the implementation record names it.\n\n## Verification\n\n- `bun run smoke` — lint, fmt, typecheck, 163 tests\n- `bun run build`\n- wire contract tests for the translated ask part and each refusal class\n- end-to-end run over the committed application route: the actual elicitor asks, the correlated answer resumes the same Flue conversation, a replayed duplicate is refused before dispatch\n",
+      "sourceInnerSha256": "37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851",
+      "innerRecord": "## Stack Context\n\nFE-1433 sequences the Petrinaut integration from the proven Flue suspension and AI SDK seams. This branch is the ask suspend/return slice, stacked on FE-1436's durable transport; its panel-side counterpart is the FE-1448 host interactive-tool API in hashintel/hash (PR hashintel/hash#9249).\n\n## What?\n\n- `transport-aisdk` holds a `brunch_ask` open on the wire: awaiting client tool with a stable `toolCallId`, the harness's minted affordance output withheld\n- the tool-result follow-up POST — previously refused wholesale — is admitted exactly when it carries the pending ask's correlated `{ answer }` submission\n- `@brunch/core` gains the pure protocol: `pendingAskAffordanceId`, `decideAskReplyAdmission`, and the `AskSubmission` submitted-output contract\n- the application's new `askReply` seam admits against durable Flue history before any dispatch, then resumes the conversation as a fresh user dispatch that the binding binds as the user-affordance reply\n- opt-in inspection gains `ask-await`, `ask-reply-admitted`, `ask-reply-refused`\n\n## Why?\n\nFE-1449 requires provenance to settle at the wire boundary: a human answer travels tool-output-shaped but is not a machine tool result. Only the currently pending ask's correlated submission may become user evidence — stale/duplicate submissions get `409 ask_not_pending`, forged ids `409 ask_mismatch`, malformed submissions `400 invalid_ask_submission`, and machine-only follow-ups (mutation outputs, diagnostics) keep FE-1436's `422`. Concurrent duplicates collapse at the substrate via the `{conversationId}:ask:{toolCallId}` idempotency key.\n\nRemaining for full FE-1449 acceptance: petrinaut-website registers the ask component through the FE-1448 `aiAssistant` API (hash-side branch); the implementation record names it.\n\n## Verification\n\n- `bun run smoke` — lint, fmt, typecheck, 163 tests\n- `bun run build`\n- wire contract tests for the translated ask part and each refusal class\n- end-to-end run over the committed application route: the actual elicitor asks, the correlated answer resumes the same Flue conversation, a replayed duplicate is refused before dispatch\n",
+      "innerSha256": "37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851",
+      "normalizationNotes": "Added one canonical Agent-notes wrapper around the unchanged source body.",
+      "proposedBody": "This branch keeps a structured brunch question open on the AI SDK wire and resumes the same Flue conversation when the matching human answer arrives through the committed application route. It validates the reply against durable conversation history and rejects stale, duplicate, forged, malformed, and machine-only submissions before dispatch. Petrinaut component registration through FE-1448 remains required for full acceptance.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Stack Context\n\nFE-1433 sequences the Petrinaut integration from the proven Flue suspension and AI SDK seams. This branch is the ask suspend/return slice, stacked on FE-1436's durable transport; its panel-side counterpart is the FE-1448 host interactive-tool API in hashintel/hash (PR hashintel/hash#9249).\n\n## What?\n\n- `transport-aisdk` holds a `brunch_ask` open on the wire: awaiting client tool with a stable `toolCallId`, the harness's minted affordance output withheld\n- the tool-result follow-up POST — previously refused wholesale — is admitted exactly when it carries the pending ask's correlated `{ answer }` submission\n- `@brunch/core` gains the pure protocol: `pendingAskAffordanceId`, `decideAskReplyAdmission`, and the `AskSubmission` submitted-output contract\n- the application's new `askReply` seam admits against durable Flue history before any dispatch, then resumes the conversation as a fresh user dispatch that the binding binds as the user-affordance reply\n- opt-in inspection gains `ask-await`, `ask-reply-admitted`, `ask-reply-refused`\n\n## Why?\n\nFE-1449 requires provenance to settle at the wire boundary: a human answer travels tool-output-shaped but is not a machine tool result. Only the currently pending ask's correlated submission may become user evidence — stale/duplicate submissions get `409 ask_not_pending`, forged ids `409 ask_mismatch`, malformed submissions `400 invalid_ask_submission`, and machine-only follow-ups (mutation outputs, diagnostics) keep FE-1436's `422`. Concurrent duplicates collapse at the substrate via the `{conversationId}:ask:{toolCallId}` idempotency key.\n\nRemaining for full FE-1449 acceptance: petrinaut-website registers the ask component through the FE-1448 `aiAssistant` API (hash-side branch); the implementation record names it.\n\n## Verification\n\n- `bun run smoke` — lint, fmt, typecheck, 163 tests\n- `bun run build`\n- wire contract tests for the translated ask part and each refusal class\n- end-to-end run over the committed application route: the actual elicitor asks, the correlated answer resumes the same Flue conversation, a replayed duplicate is refused before dispatch\n\n\n</details>",
+      "proposedBodySha256": "dbb0116f134378a4b1b42607319fe88abf91f7b1c618ccaaea20fada9a24dc72",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The source had no Agent-notes wrapper, as specified for this migration."
+    },
+    {
+      "number": 24,
+      "url": "https://github.com/hashintel/brunch-lite/pull/24",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1436-transport-aisdk",
+      "linkedIssue": "FE-1436",
+      "sourceUpdatedAt": "2026-08-19T14:00:38Z",
+      "sourceTitle": "FE-1436: The elicitor answers conversation turns in Petrinaut's real chat panel",
+      "sourceTitleSha256": "bd9e156289c48be8bc090b55ed791baa949ca60fa375428e1ce44cefdee10367",
+      "sourceBodySha256": "e1027892dd6c1a87afc8f7922fc51a997066da09baf710a15c05aa24a9c5c283",
+      "proposedTitle": "FE-1436: Connect the elicitor to Petrinaut’s real chat panel",
+      "oldOuter": "The spikes proved the required seams separately, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.",
+      "proposedOuter": "Separate spikes proved Flue suspension and AI SDK panel streaming, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "## Stack Context\n\nFE-1433 sequences a durable Petrinaut integration from the proven Flue suspension and AI SDK panel seams. This branch is the first production-intent transport slice, stacked on FE-1435.\n\n## What?\n\n- adds a substrate-neutral harness reply protocol and `transport-aisdk` encoder\n- mounts the actual elicitor behind Petrinaut's `/api/chat` contract\n- commits the local Petrinaut launcher, opt-in JSONL inspector, and wire fixtures\n- validates external chat requests with Valibot and keeps transport diagnostics outside user evidence\n- records one truthful terminal sequence for completed, failed, and aborted turns\n\n## Why?\n\nLater structured-ask and editor-tool slices need a durable, inspectable server path rather than the spike's disposable replay harness. The committed application-route golden now crosses the real application, Flue projector, and transport while normalizing only dynamic identifiers and delta segmentation.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` — 152 passed, 0 failed\n- `bun run build`\n- independent standards/spec review plus focused remediation closure review",
+      "sourceInnerSha256": "10e4f1c874197ab56e237d4d4ffbe11ff3b8a286a3b0a7f3036cdbc4a23ff8aa",
+      "innerRecord": "## Stack Context\n\nFE-1433 sequences a durable Petrinaut integration from the proven Flue suspension and AI SDK panel seams. This branch is the first production-intent transport slice, stacked on FE-1435.\n\n## What?\n\n- adds a substrate-neutral harness reply protocol and `transport-aisdk` encoder\n- mounts the actual elicitor behind Petrinaut's `/api/chat` contract\n- commits the local Petrinaut launcher, opt-in JSONL inspector, and wire fixtures\n- validates external chat requests with Valibot and keeps transport diagnostics outside user evidence\n- records one truthful terminal sequence for completed, failed, and aborted turns\n\n## Why?\n\nLater structured-ask and editor-tool slices need a durable, inspectable server path rather than the spike's disposable replay harness. The committed application-route golden now crosses the real application, Flue projector, and transport while normalizing only dynamic identifiers and delta segmentation.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` — 152 passed, 0 failed\n- `bun run build`\n- independent standards/spec review plus focused remediation closure review",
+      "innerSha256": "10e4f1c874197ab56e237d4d4ffbe11ff3b8a286a3b0a7f3036cdbc4a23ff8aa",
+      "normalizationNotes": "The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.",
+      "proposedBody": "Separate spikes proved Flue suspension and AI SDK panel streaming, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Stack Context\n\nFE-1433 sequences a durable Petrinaut integration from the proven Flue suspension and AI SDK panel seams. This branch is the first production-intent transport slice, stacked on FE-1435.\n\n## What?\n\n- adds a substrate-neutral harness reply protocol and `transport-aisdk` encoder\n- mounts the actual elicitor behind Petrinaut's `/api/chat` contract\n- commits the local Petrinaut launcher, opt-in JSONL inspector, and wire fixtures\n- validates external chat requests with Valibot and keeps transport diagnostics outside user evidence\n- records one truthful terminal sequence for completed, failed, and aborted turns\n\n## Why?\n\nLater structured-ask and editor-tool slices need a durable, inspectable server path rather than the spike's disposable replay harness. The committed application-route golden now crosses the real application, Flue projector, and transport while normalizing only dynamic identifiers and delta segmentation.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` — 152 passed, 0 failed\n- `bun run build`\n- independent standards/spec review plus focused remediation closure review\n\n</details>",
+      "proposedBodySha256": "240284375b0b085d4b4315a13ffb2eed87affa8b36f03c73757cb6f23fc841ca",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "Replaced the unspecific “seams” with the proved mechanisms: Flue suspension and AI SDK panel streaming."
+    },
+    {
+      "number": 23,
+      "url": "https://github.com/hashintel/brunch-lite/pull/23",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1451-fold-protocol",
+      "linkedIssue": "FE-1451",
+      "sourceUpdatedAt": "2026-08-19T14:00:37Z",
+      "sourceTitle": "FE-1451: Keep issues, comments, and PRs easy to scan",
+      "sourceTitleSha256": "51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e",
+      "sourceBodySha256": "c0634fcf88f0fb7c9428da627183b68b53d13023a55153fb1649230f5717ede3",
+      "proposedTitle": "FE-1451: Keep issues, comments, and PRs easy to scan",
+      "oldOuter": "Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.",
+      "proposedOuter": "Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.",
+      "extractionMethod": "outer canonical wrapper extracted; nested standalone wrapper tags removed from source inner",
+      "sourceInnerRecord": "Agent-written issues, comments, and PR descriptions had become hard to scan. This PR gives issues compact, active-verb task titles and a human-owned plain-language summary, with agent working detail in a collapsed `🏗️ Agent notes` section. It applies the same rules to [FE-1451](https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan), which serves as a live example.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## What changed\n\n- `docs/agents/issue-writing.md` defines compact task-shaped titles, the collapsed section, visible comments limited to one decision or change, and vocabulary rules by audience.\n- The human driving the work owns the visible summary. An agent fetches and preserves that text before writing on the person's behalf; `🏗️ Agent notes` remains agent-maintained.\n- Issues quote and link user, stakeholder, or teammate feedback when the issue's audience can read the source.\n- The org technical-writing rules apply to all prose. The earlier draft applied the word list only to visible summaries.\n- The coined name \"the fold\" was removed rather than added to the glossary. The house word list asks writers to use \"collapsed section,\" and formalizing the coined term would have preserved the conflict.\n- `docs/agents/issue-tracker.md` records the safe raw-description edit process and the shorter project-update format.\n- `AGENTS.md`, `docs/INDEX.md`, and `docs/planning/_shared/CONVERGENCE.md` point to the current rules and state.\n\n## Verification\n\n- `bun run smoke`: 138 tests passed.\n- `bun run build`: passed.\n- Focused document-index and formatting checks passed after the final wording changes.\n- Linear round-trip: FE-1451 retains its human-owned summary and collapsed `🏗️ Agent notes` after update and read-back.\n\n## Arc close\n\n- Inbox sweep: clean.\n- INDEX pass: the CONVERGENCE digest matches the seventh evaluation.\n- CONVERGENCE re-evaluation: FE-1451 changes reporting and does not change the delivery order.\n- Registry audit: FE-1451 is a child of FE-1401; this branch introduces no orphan.\n- Tense repair: the living record says the rules are implemented on this branch.\n- Plain-language review: the required forked reviewer could not start because the subagent service failed twice. A manual strain read found and repaired the coined term, the partial application of the house word list, and the unsupported claim that an audit already checks the label bytes.\n\n</details>",
+      "sourceInnerSha256": "7d0c7197002a2bd29907e73de006782e60a3104da9f54a8082d12c3d88fc3899",
+      "innerRecord": "Agent-written issues, comments, and PR descriptions had become hard to scan. This PR gives issues compact, active-verb task titles and a human-owned plain-language summary, with agent working detail in a collapsed `🏗️ Agent notes` section. It applies the same rules to [FE-1451](https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan), which serves as a live example.\n\n\n## What changed\n\n- `docs/agents/issue-writing.md` defines compact task-shaped titles, the collapsed section, visible comments limited to one decision or change, and vocabulary rules by audience.\n- The human driving the work owns the visible summary. An agent fetches and preserves that text before writing on the person's behalf; `🏗️ Agent notes` remains agent-maintained.\n- Issues quote and link user, stakeholder, or teammate feedback when the issue's audience can read the source.\n- The org technical-writing rules apply to all prose. The earlier draft applied the word list only to visible summaries.\n- The coined name \"the fold\" was removed rather than added to the glossary. The house word list asks writers to use \"collapsed section,\" and formalizing the coined term would have preserved the conflict.\n- `docs/agents/issue-tracker.md` records the safe raw-description edit process and the shorter project-update format.\n- `AGENTS.md`, `docs/INDEX.md`, and `docs/planning/_shared/CONVERGENCE.md` point to the current rules and state.\n\n## Verification\n\n- `bun run smoke`: 138 tests passed.\n- `bun run build`: passed.\n- Focused document-index and formatting checks passed after the final wording changes.\n- Linear round-trip: FE-1451 retains its human-owned summary and collapsed `🏗️ Agent notes` after update and read-back.\n\n## Arc close\n\n- Inbox sweep: clean.\n- INDEX pass: the CONVERGENCE digest matches the seventh evaluation.\n- CONVERGENCE re-evaluation: FE-1451 changes reporting and does not change the delivery order.\n- Registry audit: FE-1451 is a child of FE-1401; this branch introduces no orphan.\n- Tense repair: the living record says the rules are implemented on this branch.\n- Plain-language review: the required forked reviewer could not start because the subagent service failed twice. A manual strain read found and repaired the coined term, the partial application of the house word list, and the unsupported claim that an audit already checks the label bytes.\n\n",
+      "innerSha256": "14c689899a8f5687c0f26293949b64974adc409de4379339d847a0356991b723",
+      "normalizationNotes": "Removed the nested standalone details opener and closer only. All non-structural bytes remain in source order; the final body has one canonical wrapper.",
+      "proposedBody": "Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.\n\n<details><summary>🏗️ Agent notes</summary>\n\nAgent-written issues, comments, and PR descriptions had become hard to scan. This PR gives issues compact, active-verb task titles and a human-owned plain-language summary, with agent working detail in a collapsed `🏗️ Agent notes` section. It applies the same rules to [FE-1451](https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan), which serves as a live example.\n\n\n## What changed\n\n- `docs/agents/issue-writing.md` defines compact task-shaped titles, the collapsed section, visible comments limited to one decision or change, and vocabulary rules by audience.\n- The human driving the work owns the visible summary. An agent fetches and preserves that text before writing on the person's behalf; `🏗️ Agent notes` remains agent-maintained.\n- Issues quote and link user, stakeholder, or teammate feedback when the issue's audience can read the source.\n- The org technical-writing rules apply to all prose. The earlier draft applied the word list only to visible summaries.\n- The coined name \"the fold\" was removed rather than added to the glossary. The house word list asks writers to use \"collapsed section,\" and formalizing the coined term would have preserved the conflict.\n- `docs/agents/issue-tracker.md` records the safe raw-description edit process and the shorter project-update format.\n- `AGENTS.md`, `docs/INDEX.md`, and `docs/planning/_shared/CONVERGENCE.md` point to the current rules and state.\n\n## Verification\n\n- `bun run smoke`: 138 tests passed.\n- `bun run build`: passed.\n- Focused document-index and formatting checks passed after the final wording changes.\n- Linear round-trip: FE-1451 retains its human-owned summary and collapsed `🏗️ Agent notes` after update and read-back.\n\n## Arc close\n\n- Inbox sweep: clean.\n- INDEX pass: the CONVERGENCE digest matches the seventh evaluation.\n- CONVERGENCE re-evaluation: FE-1451 changes reporting and does not change the delivery order.\n- Registry audit: FE-1451 is a child of FE-1401; this branch introduces no orphan.\n- Tense repair: the living record says the rules are implemented on this branch.\n- Plain-language review: the required forked reviewer could not start because the subagent service failed twice. A manual strain read found and repaired the coined term, the partial application of the house word list, and the unsupported claim that an audit already checks the label bytes.\n\n\n\n</details>",
+      "proposedBodySha256": "4a6f614020fc7358da54c5ee3c60b5be98b61a8b38a6ea36d6ddcbbcc948cd3f",
+      "bodyChanged": true,
+      "titleChanged": false,
+      "ambiguity": null,
+      "notes": "Raw source-inner and normalized-inner hashes are both recorded."
+    },
+    {
+      "number": 22,
+      "url": "https://github.com/hashintel/brunch-lite/pull/22",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1435-aisdk-panel-spike",
+      "linkedIssue": "FE-1435",
+      "sourceUpdatedAt": "2026-08-19T14:00:35Z",
+      "sourceTitle": "FE-1435: Spike: does a harness-driven stream drive Petrinaut's real chat panel?",
+      "sourceTitleSha256": "ea8d78aaeef51c451235b2dcd2e5aef2459dfa218dae80928968f5499c0408ea",
+      "sourceBodySha256": "985fc49182ce7429b93462cb72bd5124b6f77a2c66a3f554e63ebd1c5a3a44b5",
+      "proposedTitle": "FE-1435: Test whether the elicitor stream drives Petrinaut’s chat panel",
+      "oldOuter": "The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production slice builds on it.",
+      "proposedOuter": "The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production integration builds on it.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "## Outcome\n\nProves that harness-level parts translated to AI SDK v6 UI-message-stream frames can drive Petrinaut's real, unmodified chat panel at the pinned dependency versions.\n\nThe live panel rendered reasoning, text, and a provider-executed server tool; executed two client tools against the editor; posted both outputs together in one automatic follow-up; and added diagnostics context through its existing transport decorator. The complete two POST bodies and two SSE streams are frozen as fixtures with semantic golden tests.\n\nThe external `hashintel/hash` checkout remained clean at `1046b5c881cd00cf205b4895348b022934d66b4a`; no prototype source was retained.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (142 tests)\n- `bun run build`",
+      "sourceInnerSha256": "9e78b931b4c73c4fa061c49db1121b77958f68707520b3ba33ffeffba819e3fe",
+      "innerRecord": "## Outcome\n\nProves that harness-level parts translated to AI SDK v6 UI-message-stream frames can drive Petrinaut's real, unmodified chat panel at the pinned dependency versions.\n\nThe live panel rendered reasoning, text, and a provider-executed server tool; executed two client tools against the editor; posted both outputs together in one automatic follow-up; and added diagnostics context through its existing transport decorator. The complete two POST bodies and two SSE streams are frozen as fixtures with semantic golden tests.\n\nThe external `hashintel/hash` checkout remained clean at `1046b5c881cd00cf205b4895348b022934d66b4a`; no prototype source was retained.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (142 tests)\n- `bun run build`",
+      "innerSha256": "9e78b931b4c73c4fa061c49db1121b77958f68707520b3ba33ffeffba819e3fe",
+      "normalizationNotes": "The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.",
+      "proposedBody": "The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production integration builds on it.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Outcome\n\nProves that harness-level parts translated to AI SDK v6 UI-message-stream frames can drive Petrinaut's real, unmodified chat panel at the pinned dependency versions.\n\nThe live panel rendered reasoning, text, and a provider-executed server tool; executed two client tools against the editor; posted both outputs together in one automatic follow-up; and added diagnostics context through its existing transport decorator. The complete two POST bodies and two SSE streams are frozen as fixtures with semantic golden tests.\n\nThe external `hashintel/hash` checkout remained clean at `1046b5c881cd00cf205b4895348b022934d66b4a`; no prototype source was retained.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (142 tests)\n- `bun run build`\n\n</details>",
+      "proposedBodySha256": "0027d14716564d6aa96a13fa64814e364773ecaac6b3a5e2fd3fbf5cf5f51049",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "Replaced the figurative “slice” with “production integration”."
+    },
+    {
+      "number": 21,
+      "url": "https://github.com/hashintel/brunch-lite/pull/21",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1434-suspension-spike",
+      "linkedIssue": "FE-1434",
+      "sourceUpdatedAt": "2026-08-19T14:00:32Z",
+      "sourceTitle": "FE-1434: Spike: does Flue turn suspension carry batched client-tool round-trips?",
+      "sourceTitleSha256": "c47a125d640ac02cb20d9907f82c7d3612121c3ba6b574f4fa7560dc2d4e30d7",
+      "sourceBodySha256": "037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4",
+      "proposedTitle": "FE-1434: Test whether Flue resumes batched client-tool results",
+      "oldOuter": "The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.",
+      "proposedOuter": "The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "## Outcome\n\nProves that Flue 2.0.3 can terminate with a batched client-tool interaction pending and resume through one later non-user `signal` dispatch with per-session state and every tool-call ID intact.\n\nThe durable verdict selects a batch-as-pending-slot variant. It records 3-result and 100-result evidence, two dispatches and two model turns in both cases, rejection of native `tool-result` admission, non-user capture-store refusal, and the remaining retry/mismatch obligations for FE-1438.\n\nThe disposable probe was removed after capture; the verdict and normalized JSON evidence retain its source commit and exact command.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (138 tests)\n- `bun run build`",
+      "sourceInnerSha256": "75374819449c6180ad66bdbce8100715a814735ed9812ee909cbe7de36831b0a",
+      "innerRecord": "## Outcome\n\nProves that Flue 2.0.3 can terminate with a batched client-tool interaction pending and resume through one later non-user `signal` dispatch with per-session state and every tool-call ID intact.\n\nThe durable verdict selects a batch-as-pending-slot variant. It records 3-result and 100-result evidence, two dispatches and two model turns in both cases, rejection of native `tool-result` admission, non-user capture-store refusal, and the remaining retry/mismatch obligations for FE-1438.\n\nThe disposable probe was removed after capture; the verdict and normalized JSON evidence retain its source commit and exact command.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (138 tests)\n- `bun run build`",
+      "innerSha256": "75374819449c6180ad66bdbce8100715a814735ed9812ee909cbe7de36831b0a",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Outcome\n\nProves that Flue 2.0.3 can terminate with a batched client-tool interaction pending and resume through one later non-user `signal` dispatch with per-session state and every tool-call ID intact.\n\nThe durable verdict selects a batch-as-pending-slot variant. It records 3-result and 100-result evidence, two dispatches and two model turns in both cases, rejection of native `tool-result` admission, non-user capture-store refusal, and the remaining retry/mismatch obligations for FE-1438.\n\nThe disposable probe was removed after capture; the verdict and normalized JSON evidence retain its source commit and exact command.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (138 tests)\n- `bun run build`\n\n</details>\n",
+      "proposedBodySha256": "037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 20,
+      "url": "https://github.com/hashintel/brunch-lite/pull/20",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1433-petrinaut-integration-spec",
+      "linkedIssue": "FE-1433",
+      "sourceUpdatedAt": "2026-08-19T14:00:30Z",
+      "sourceTitle": "FE-1433: The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server",
+      "sourceTitleSha256": "f994067680a1d677c1289baa403f1b2db4452f64845198006fd1c337648d7e81",
+      "sourceBodySha256": "c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64",
+      "proposedTitle": "FE-1433: Deliver the remote Petrinaut elicitor integration",
+      "oldOuter": "The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.",
+      "proposedOuter": "The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "FE-1433: Record the in-Petrinaut staging decision and its integration spec\n\nThe 2026-08-18 integration meeting overturned the demo-shell recommendation:\nthe September demo stages inside demo.petrinaut.org, with the elicitor as a\nremote server behind the chat panel's host-pluggable aiAssistant transport.\nADR-0004 records the decision (staging, the @hashintel/brunch-agent rename and\nmonorepo import, the apps-are-the-only-meeting-point boundary discipline, the\nui-shell principal, the N3 amendment retiring the demo shell) and supersedes\nrecommendation-demo-vehicle.md.\n\nThe integration spec (FE-1433) specifies the build: one primary test seam (the\nAI SDK UI-message-stream wire contract), the external-tool round-trip protocol\nsharing the ask protocol's suspension floor while differing in cardinality,\nbinding, and provenance (tool outputs are machine entries, never anchorable\nevidence), the transport-aisdk package, the opaque owner key on the storage\nport, and the two gating spikes (Flue suspension carrying batched client-tool\nround-trips; the Pi-to-AI-SDK stream adapter, whose transcript becomes the\nwire seam's golden fixtures).\n\nINDEX updated: recommendation-demo-vehicle marked superseded; both new\ndocuments indexed; docs gate green.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nFE-1433: File the integration delivery graph — sixth cross-map evaluation\n\nThe ds-write-tickets pass over the integration spec published nine execution\ntickets under FE-1433 (FE-1434–FE-1442) with native blocking relations, and\nthis change deposits the coordination record: the sixth evaluation paragraph\n(the sub-graph joins the strategy without displacing the spine; the spikes\njoin the now-band beside FE-1393/FE-1422), the delivery graph itself (mirrored\nin FE-1433's execution record), the FE-1423 re-scope (gates survive the demo\nshell's retirement and now guard the remote elicitor server; auth → FE-1439,\ndeployment → FE-1441), and the N3 watch-item repair (ADR-0004 amended N3, so\nthe living-prototype charter would shape apps/dev or the deployed server, not\nan apps/demo).\n\nThe one fog-sensitive edge is recorded as such: FE-1438 and FE-1395 share the\npending-slot batching ground, held apart by a coordination edge rather than a\nblocker — whichever lands first writes the §7.3/§7.4 amendment.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "sourceInnerSha256": "9ca3adac2b7d307ec1440ef7d27bd38111d069641c9c688cd9a931f3e2af7ce9",
+      "innerRecord": "FE-1433: Record the in-Petrinaut staging decision and its integration spec\n\nThe 2026-08-18 integration meeting overturned the demo-shell recommendation:\nthe September demo stages inside demo.petrinaut.org, with the elicitor as a\nremote server behind the chat panel's host-pluggable aiAssistant transport.\nADR-0004 records the decision (staging, the @hashintel/brunch-agent rename and\nmonorepo import, the apps-are-the-only-meeting-point boundary discipline, the\nui-shell principal, the N3 amendment retiring the demo shell) and supersedes\nrecommendation-demo-vehicle.md.\n\nThe integration spec (FE-1433) specifies the build: one primary test seam (the\nAI SDK UI-message-stream wire contract), the external-tool round-trip protocol\nsharing the ask protocol's suspension floor while differing in cardinality,\nbinding, and provenance (tool outputs are machine entries, never anchorable\nevidence), the transport-aisdk package, the opaque owner key on the storage\nport, and the two gating spikes (Flue suspension carrying batched client-tool\nround-trips; the Pi-to-AI-SDK stream adapter, whose transcript becomes the\nwire seam's golden fixtures).\n\nINDEX updated: recommendation-demo-vehicle marked superseded; both new\ndocuments indexed; docs gate green.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nFE-1433: File the integration delivery graph — sixth cross-map evaluation\n\nThe ds-write-tickets pass over the integration spec published nine execution\ntickets under FE-1433 (FE-1434–FE-1442) with native blocking relations, and\nthis change deposits the coordination record: the sixth evaluation paragraph\n(the sub-graph joins the strategy without displacing the spine; the spikes\njoin the now-band beside FE-1393/FE-1422), the delivery graph itself (mirrored\nin FE-1433's execution record), the FE-1423 re-scope (gates survive the demo\nshell's retirement and now guard the remote elicitor server; auth → FE-1439,\ndeployment → FE-1441), and the N3 watch-item repair (ADR-0004 amended N3, so\nthe living-prototype charter would shape apps/dev or the deployed server, not\nan apps/demo).\n\nThe one fog-sensitive edge is recorded as such: FE-1438 and FE-1395 share the\npending-slot batching ground, held apart by a coordination edge rather than a\nblocker — whichever lands first writes the §7.3/§7.4 amendment.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "innerSha256": "9ca3adac2b7d307ec1440ef7d27bd38111d069641c9c688cd9a931f3e2af7ce9",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1433: Record the in-Petrinaut staging decision and its integration spec\n\nThe 2026-08-18 integration meeting overturned the demo-shell recommendation:\nthe September demo stages inside demo.petrinaut.org, with the elicitor as a\nremote server behind the chat panel's host-pluggable aiAssistant transport.\nADR-0004 records the decision (staging, the @hashintel/brunch-agent rename and\nmonorepo import, the apps-are-the-only-meeting-point boundary discipline, the\nui-shell principal, the N3 amendment retiring the demo shell) and supersedes\nrecommendation-demo-vehicle.md.\n\nThe integration spec (FE-1433) specifies the build: one primary test seam (the\nAI SDK UI-message-stream wire contract), the external-tool round-trip protocol\nsharing the ask protocol's suspension floor while differing in cardinality,\nbinding, and provenance (tool outputs are machine entries, never anchorable\nevidence), the transport-aisdk package, the opaque owner key on the storage\nport, and the two gating spikes (Flue suspension carrying batched client-tool\nround-trips; the Pi-to-AI-SDK stream adapter, whose transcript becomes the\nwire seam's golden fixtures).\n\nINDEX updated: recommendation-demo-vehicle marked superseded; both new\ndocuments indexed; docs gate green.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nFE-1433: File the integration delivery graph — sixth cross-map evaluation\n\nThe ds-write-tickets pass over the integration spec published nine execution\ntickets under FE-1433 (FE-1434–FE-1442) with native blocking relations, and\nthis change deposits the coordination record: the sixth evaluation paragraph\n(the sub-graph joins the strategy without displacing the spine; the spikes\njoin the now-band beside FE-1393/FE-1422), the delivery graph itself (mirrored\nin FE-1433's execution record), the FE-1423 re-scope (gates survive the demo\nshell's retirement and now guard the remote elicitor server; auth → FE-1439,\ndeployment → FE-1441), and the N3 watch-item repair (ADR-0004 amended N3, so\nthe living-prototype charter would shape apps/dev or the deployed server, not\nan apps/demo).\n\nThe one fog-sensitive edge is recorded as such: FE-1438 and FE-1395 share the\npending-slot batching ground, held apart by a coordination edge rather than a\nblocker — whichever lands first writes the §7.3/§7.4 amendment.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+      "proposedBodySha256": "c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 19,
+      "url": "https://github.com/hashintel/brunch-lite/pull/19",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1432-review-remediation",
+      "linkedIssue": "FE-1432",
+      "sourceUpdatedAt": "2026-08-19T14:00:29Z",
+      "sourceTitle": "FE-1432: The stack's open review threads are adjudicated: fixed, owned, or refused on the record",
+      "sourceTitleSha256": "8baa3f7952c774fe17d2c91f5700063fa8e11047b193813df55b11766fee8eab",
+      "sourceBodySha256": "ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172",
+      "proposedTitle": "FE-1432: Resolve the stack's open review threads",
+      "oldOuter": "The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.",
+      "proposedOuter": "The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "FE-1432 executes the 2026-08-18 cross-stack review-remediation queue and closes its capture channel.\n\nWhat this establishes:\n\n- Capture-store command admission and persisted parsing share the same closure rules: one terminal event per issue, pairwise-disjoint open conflicts, and active references for every open conflict.\n- Baseline interviewer and expert truncation survives in checkpoint metadata; partial output stops before downstream model consumption, and expert resume regenerates the incomplete reply.\n- Valibot declarations and imports agree in both directions, while the walking-skeleton oracle reports absent context as `false` instead of throwing.\n- New dependency resolutions observe a seven-day release-age quarantine.\n- All 15 residual review threads were replied to and resolved: 7 fixes, 2 findings owned by FE-1385/FE-1393, and 6 evidence-backed refusals.\n- The three tooling-side graduation proposals remain owned by FE-1401's `ds-induct`/lens-registry lane.\n\nCommits:\n\n- `380411f` — preserve capture-store closure and prove local-store setup\n- `f71aa9e` — retain baseline completion metadata\n- `bb46941` — make capability and walking-skeleton gates honest\n- `2814090` — quarantine fresh dependency releases\n- `74b535c` — settle the remediation ledger\n\nVerification: OxLint, Oxfmt, TypeScript, 138 tests, workspace build, and an independent adversarial review of the capture lifecycle. A live review-thread refresh found zero unresolved FE-1432 threads; the sole repository-wide unresolved thread is on child PR #20 and belongs to FE-1433.",
+      "sourceInnerSha256": "19f5f98e93e5519ab3b1bc2ece5499a459022157087eec5015c58a9c56d17d6b",
+      "innerRecord": "FE-1432 executes the 2026-08-18 cross-stack review-remediation queue and closes its capture channel.\n\nWhat this establishes:\n\n- Capture-store command admission and persisted parsing share the same closure rules: one terminal event per issue, pairwise-disjoint open conflicts, and active references for every open conflict.\n- Baseline interviewer and expert truncation survives in checkpoint metadata; partial output stops before downstream model consumption, and expert resume regenerates the incomplete reply.\n- Valibot declarations and imports agree in both directions, while the walking-skeleton oracle reports absent context as `false` instead of throwing.\n- New dependency resolutions observe a seven-day release-age quarantine.\n- All 15 residual review threads were replied to and resolved: 7 fixes, 2 findings owned by FE-1385/FE-1393, and 6 evidence-backed refusals.\n- The three tooling-side graduation proposals remain owned by FE-1401's `ds-induct`/lens-registry lane.\n\nCommits:\n\n- `380411f` — preserve capture-store closure and prove local-store setup\n- `f71aa9e` — retain baseline completion metadata\n- `bb46941` — make capability and walking-skeleton gates honest\n- `2814090` — quarantine fresh dependency releases\n- `74b535c` — settle the remediation ledger\n\nVerification: OxLint, Oxfmt, TypeScript, 138 tests, workspace build, and an independent adversarial review of the capture lifecycle. A live review-thread refresh found zero unresolved FE-1432 threads; the sole repository-wide unresolved thread is on child PR #20 and belongs to FE-1433.",
+      "innerSha256": "19f5f98e93e5519ab3b1bc2ece5499a459022157087eec5015c58a9c56d17d6b",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1432 executes the 2026-08-18 cross-stack review-remediation queue and closes its capture channel.\n\nWhat this establishes:\n\n- Capture-store command admission and persisted parsing share the same closure rules: one terminal event per issue, pairwise-disjoint open conflicts, and active references for every open conflict.\n- Baseline interviewer and expert truncation survives in checkpoint metadata; partial output stops before downstream model consumption, and expert resume regenerates the incomplete reply.\n- Valibot declarations and imports agree in both directions, while the walking-skeleton oracle reports absent context as `false` instead of throwing.\n- New dependency resolutions observe a seven-day release-age quarantine.\n- All 15 residual review threads were replied to and resolved: 7 fixes, 2 findings owned by FE-1385/FE-1393, and 6 evidence-backed refusals.\n- The three tooling-side graduation proposals remain owned by FE-1401's `ds-induct`/lens-registry lane.\n\nCommits:\n\n- `380411f` — preserve capture-store closure and prove local-store setup\n- `f71aa9e` — retain baseline completion metadata\n- `bb46941` — make capability and walking-skeleton gates honest\n- `2814090` — quarantine fresh dependency releases\n- `74b535c` — settle the remediation ledger\n\nVerification: OxLint, Oxfmt, TypeScript, 138 tests, workspace build, and an independent adversarial review of the capture lifecycle. A live review-thread refresh found zero unresolved FE-1432 threads; the sole repository-wide unresolved thread is on child PR #20 and belongs to FE-1433.\n\n</details>\n",
+      "proposedBodySha256": "ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 18,
+      "url": "https://github.com/hashintel/brunch-lite/pull/18",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1392-settlement-sweep",
+      "linkedIssue": "FE-1392",
+      "sourceUpdatedAt": "2026-08-19T14:00:27Z",
+      "sourceTitle": "FE-1392: Settlement trigger and sweep — the first captured statement",
+      "sourceTitleSha256": "e2af4a86d0444c15a7135f477591b390b36fff479e0915de853efc36b4e36ec9",
+      "sourceBodySha256": "74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062",
+      "proposedTitle": "FE-1392: Capture settled conversation statements safely",
+      "oldOuter": "This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.",
+      "proposedOuter": "This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Trigger settlement from the finish hook, extract against the plugin-declared grade floor, refresh archived history adjacent to atomic application, and reopen refused ranges without weakening session-qualified provenance.",
+      "sourceInnerSha256": "df3111e4b7761fa8032c600be382986205f9317ed03564010aa4b5e8172b2986",
+      "innerRecord": "Trigger settlement from the finish hook, extract against the plugin-declared grade floor, refresh archived history adjacent to atomic application, and reopen refused ranges without weakening session-qualified provenance.",
+      "innerSha256": "df3111e4b7761fa8032c600be382986205f9317ed03564010aa4b5e8172b2986",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.\n\n<details><summary>🏗️ Agent notes</summary>\n\nTrigger settlement from the finish hook, extract against the plugin-declared grade floor, refresh archived history adjacent to atomic application, and reopen refused ranges without weakening session-qualified provenance.\n\n</details>\n",
+      "proposedBodySha256": "74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 17,
+      "url": "https://github.com/hashintel/brunch-lite/pull/17",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1391-entry-projection",
+      "linkedIssue": "FE-1391",
+      "sourceUpdatedAt": "2026-08-19T14:00:26Z",
+      "sourceTitle": "FE-1391: Durable entry projection, harness-resolved anchoring, and the session-log archive",
+      "sourceTitleSha256": "8df88b0ce1d3b89975c44cc7efb9d680d2cbda6518cf08c0af135ab15e663dae",
+      "sourceBodySha256": "08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84",
+      "proposedTitle": "FE-1391: Resolve evidence quotes to durable conversation entries",
+      "oldOuter": "Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.",
+      "proposedOuter": "Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "docs: settle Flue projection and compaction\n\nRecord the installed @flue/runtime and @flue/sdk 2.0.3 contract and implementation evidence for FE-1391 B1/B2. Correct the archive premise to the materialized history surface with host-owned routing and evolving-message merge semantics. Trace append-only compaction and state ownership, then reshape FE-1386 to one behavioral upgrade pin and reconcile the living ledgers.\n\nfeat: anchor captures to archived Flue history\n\nRead the public materialized history through a host-supplied URL resolver and transport, and co-locate a versioned session log with capture state behind a binding-private archive capability. Archive ordinals preserve the session-plus-range pointer while Flue identities remain provenance and evolving messages retain distinct versions.\n\nReplace caller-supplied spans with quote-only evidence commands resolved atomically against the archive. Pin mounted in-process routing, affordance classification, non-user refusal, legacy provisioning, parse-on-read, and independent pointer retrieval. Keep the real-compaction compatibility pin with FE-1386 and move refresh-before-sweep orchestration to FE-1392.",
+      "sourceInnerSha256": "aa0dc9d30893dc7c516127e3e33517a0cee1493d257d73d835e9ec3ad0840d23",
+      "innerRecord": "docs: settle Flue projection and compaction\n\nRecord the installed @flue/runtime and @flue/sdk 2.0.3 contract and implementation evidence for FE-1391 B1/B2. Correct the archive premise to the materialized history surface with host-owned routing and evolving-message merge semantics. Trace append-only compaction and state ownership, then reshape FE-1386 to one behavioral upgrade pin and reconcile the living ledgers.\n\nfeat: anchor captures to archived Flue history\n\nRead the public materialized history through a host-supplied URL resolver and transport, and co-locate a versioned session log with capture state behind a binding-private archive capability. Archive ordinals preserve the session-plus-range pointer while Flue identities remain provenance and evolving messages retain distinct versions.\n\nReplace caller-supplied spans with quote-only evidence commands resolved atomically against the archive. Pin mounted in-process routing, affordance classification, non-user refusal, legacy provisioning, parse-on-read, and independent pointer retrieval. Keep the real-compaction compatibility pin with FE-1386 and move refresh-before-sweep orchestration to FE-1392.",
+      "innerSha256": "aa0dc9d30893dc7c516127e3e33517a0cee1493d257d73d835e9ec3ad0840d23",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.\n\n<details><summary>🏗️ Agent notes</summary>\n\ndocs: settle Flue projection and compaction\n\nRecord the installed @flue/runtime and @flue/sdk 2.0.3 contract and implementation evidence for FE-1391 B1/B2. Correct the archive premise to the materialized history surface with host-owned routing and evolving-message merge semantics. Trace append-only compaction and state ownership, then reshape FE-1386 to one behavioral upgrade pin and reconcile the living ledgers.\n\nfeat: anchor captures to archived Flue history\n\nRead the public materialized history through a host-supplied URL resolver and transport, and co-locate a versioned session log with capture state behind a binding-private archive capability. Archive ordinals preserve the session-plus-range pointer while Flue identities remain provenance and evolving messages retain distinct versions.\n\nReplace caller-supplied spans with quote-only evidence commands resolved atomically against the archive. Pin mounted in-process routing, affordance classification, non-user refusal, legacy provisioning, parse-on-read, and independent pointer retrieval. Keep the real-compaction compatibility pin with FE-1386 and move refresh-before-sweep orchestration to FE-1392.\n\n</details>\n",
+      "proposedBodySha256": "08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 16,
+      "url": "https://github.com/hashintel/brunch-lite/pull/16",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1422-ask-protocol",
+      "linkedIssue": "FE-1422",
+      "sourceUpdatedAt": "2026-08-19T14:00:24Z",
+      "sourceTitle": "FE-1422: The ask protocol is substrate-portable: mechanism moves from the Flue binding into core",
+      "sourceTitleSha256": "57533df404cf90eb95676d0223056011c73aa2ab89bacfeb6ebc12e5e91d1703",
+      "sourceBodySha256": "1fc9f55dcaded9b23be43b01e2fe6961b26a0bf5556f802ddfc7d1066846c05d",
+      "proposedTitle": "FE-1422: Move the portable ask protocol into core",
+      "oldOuter": "The question-and-reply behavior was tied too closely to one runtime binding. This branch moves the portable part into the core so other application surfaces can use the same protocol.",
+      "proposedOuter": "The question-and-reply behavior was tied too closely to the Flue runtime binding. This branch moves the portable part into core so other applications can use the same protocol.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Move affordance minting, the one-live-affordance decision and refusal, reply-binding signal construction, and render-invariant instruction fragments into a pure core module. The Flue binding now translates hooks, state updates, data writes, and turn termination through that protocol instead of owning its decisions.\n\nCharacterization tests pin every extracted value and branch, while the unchanged walking-skeleton integration test continues to prove the real substrate path, duplicate-ask rejection, durable output, reply binding, and absence of instruction wakes.",
+      "sourceInnerSha256": "59fdea11ba00ea9f408a7936f5f48176856261837a2957afbd506aa653c88008",
+      "innerRecord": "Move affordance minting, the one-live-affordance decision and refusal, reply-binding signal construction, and render-invariant instruction fragments into a pure core module. The Flue binding now translates hooks, state updates, data writes, and turn termination through that protocol instead of owning its decisions.\n\nCharacterization tests pin every extracted value and branch, while the unchanged walking-skeleton integration test continues to prove the real substrate path, duplicate-ask rejection, durable output, reply binding, and absence of instruction wakes.",
+      "innerSha256": "59fdea11ba00ea9f408a7936f5f48176856261837a2957afbd506aa653c88008",
+      "normalizationNotes": "The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.",
+      "proposedBody": "The question-and-reply behavior was tied too closely to the Flue runtime binding. This branch moves the portable part into core so other applications can use the same protocol.\n\n<details><summary>🏗️ Agent notes</summary>\n\nMove affordance minting, the one-live-affordance decision and refusal, reply-binding signal construction, and render-invariant instruction fragments into a pure core module. The Flue binding now translates hooks, state updates, data writes, and turn termination through that protocol instead of owning its decisions.\n\nCharacterization tests pin every extracted value and branch, while the unchanged walking-skeleton integration test continues to prove the real substrate path, duplicate-ask rejection, durable output, reply binding, and absence of instruction wakes.\n\n</details>",
+      "proposedBodySha256": "b8d8aeb75c6e9c3d29795bf1328907df38da7a1c5b213991077340cd533fef60",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "Replaced the figurative noun “surfaces” with the concrete reader “applications” and named the Flue runtime binding."
+    },
+    {
+      "number": 15,
+      "url": "https://github.com/hashintel/brunch-lite/pull/15",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1405-payload-interiors",
+      "linkedIssue": "FE-1405",
+      "sourceUpdatedAt": "2026-08-19T14:00:22Z",
+      "sourceTitle": "FE-1405: Draft the CPS payload interiors: annotated shapes for the ten kinds, worked from baseline utterances",
+      "sourceTitleSha256": "9b957cd8c760d786142e94469da03e59648c0835a5a54a7ec59204f86372f2dd",
+      "sourceBodySha256": "105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa",
+      "proposedTitle": "FE-1405: Draft and test the CPS payload schemas",
+      "oldOuter": "The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.",
+      "proposedOuter": "The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "This branch settles the FE-1405 payload-interiors arc and closes it.\n\n**What it establishes.** The session found that Layer A's definition sentence (\"active captures read through the payload type system\") describes an evidence ledger, not a model of the domain. Two artifacts fix that:\n\n- **ADR-0003 (three-register IR)**: typed assertions (active captures) are folded by a pure, plugin-declared fold into the elicited model — the IR proper — which projections consume without rereading the transcript. All interpretation happens at write time as contestable captures; promotion never refusal; an acceptance oracle (a second projection consumes the model alone) keeps the read path semantics-free. \"No second store\" survives: the model is a derivation, never a persistence surface.\n- **Provisional plugin-contract spec** (`docs/planning/process-model-elicitation/plugin-contract-spec.md`, published as FE-1431): a plugin is two schemas and two small tables — model schema, proposal catalog (typed proposals with interiors from a standard library), fold table (overrides only; rules mostly derive), demand table. Harness machinery is pure functions classified by which declaration each reads. The provisional marker comes off after a full worked pass across three plugin targets (the FE-1397 precedent); the open strains (grade sources, support closure, temporal patterns, sweep-time concentration, the absence-locator envelope pressure) are first-class sections with owning tickets, not folded into the design.\n\nThe capture envelope is untouched — the one confirmed pressure (absence captures carry no locator) is recorded at the FE-1383/FE-1357 seam in CONVERGENCE, not forked around.\n\n**Arc close** (second commit): SDCPN inbox arrival settled to `docs/reference/` with a skeptical digest; INDEX trued; CONVERGENCE re-evaluated with a dated third sequencing pass (the convergence collision now waits only on the build spine reaching FE-1392); registry audit re-parented two orphans (FE-1399/FE-1400 → FE-1383); CONTEXT.md's IR entry rewritten per ADR-0003 and a Grade entry added.\n\nGates: oxlint clean, oxfmt clean, typecheck clean, 100/100 tests, build green.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "c9864945e962b46747bac5d78ecf91947d3ed95f4ae9cd3f7e7e22fecf363083",
+      "innerRecord": "This branch settles the FE-1405 payload-interiors arc and closes it.\n\n**What it establishes.** The session found that Layer A's definition sentence (\"active captures read through the payload type system\") describes an evidence ledger, not a model of the domain. Two artifacts fix that:\n\n- **ADR-0003 (three-register IR)**: typed assertions (active captures) are folded by a pure, plugin-declared fold into the elicited model — the IR proper — which projections consume without rereading the transcript. All interpretation happens at write time as contestable captures; promotion never refusal; an acceptance oracle (a second projection consumes the model alone) keeps the read path semantics-free. \"No second store\" survives: the model is a derivation, never a persistence surface.\n- **Provisional plugin-contract spec** (`docs/planning/process-model-elicitation/plugin-contract-spec.md`, published as FE-1431): a plugin is two schemas and two small tables — model schema, proposal catalog (typed proposals with interiors from a standard library), fold table (overrides only; rules mostly derive), demand table. Harness machinery is pure functions classified by which declaration each reads. The provisional marker comes off after a full worked pass across three plugin targets (the FE-1397 precedent); the open strains (grade sources, support closure, temporal patterns, sweep-time concentration, the absence-locator envelope pressure) are first-class sections with owning tickets, not folded into the design.\n\nThe capture envelope is untouched — the one confirmed pressure (absence captures carry no locator) is recorded at the FE-1383/FE-1357 seam in CONVERGENCE, not forked around.\n\n**Arc close** (second commit): SDCPN inbox arrival settled to `docs/reference/` with a skeptical digest; INDEX trued; CONVERGENCE re-evaluated with a dated third sequencing pass (the convergence collision now waits only on the build spine reaching FE-1392); registry audit re-parented two orphans (FE-1399/FE-1400 → FE-1383); CONTEXT.md's IR entry rewritten per ADR-0003 and a Grade entry added.\n\nGates: oxlint clean, oxfmt clean, typecheck clean, 100/100 tests, build green.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "c9864945e962b46747bac5d78ecf91947d3ed95f4ae9cd3f7e7e22fecf363083",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.\n\n<details><summary>🏗️ Agent notes</summary>\n\nThis branch settles the FE-1405 payload-interiors arc and closes it.\n\n**What it establishes.** The session found that Layer A's definition sentence (\"active captures read through the payload type system\") describes an evidence ledger, not a model of the domain. Two artifacts fix that:\n\n- **ADR-0003 (three-register IR)**: typed assertions (active captures) are folded by a pure, plugin-declared fold into the elicited model — the IR proper — which projections consume without rereading the transcript. All interpretation happens at write time as contestable captures; promotion never refusal; an acceptance oracle (a second projection consumes the model alone) keeps the read path semantics-free. \"No second store\" survives: the model is a derivation, never a persistence surface.\n- **Provisional plugin-contract spec** (`docs/planning/process-model-elicitation/plugin-contract-spec.md`, published as FE-1431): a plugin is two schemas and two small tables — model schema, proposal catalog (typed proposals with interiors from a standard library), fold table (overrides only; rules mostly derive), demand table. Harness machinery is pure functions classified by which declaration each reads. The provisional marker comes off after a full worked pass across three plugin targets (the FE-1397 precedent); the open strains (grade sources, support closure, temporal patterns, sweep-time concentration, the absence-locator envelope pressure) are first-class sections with owning tickets, not folded into the design.\n\nThe capture envelope is untouched — the one confirmed pressure (absence captures carry no locator) is recorded at the FE-1383/FE-1357 seam in CONVERGENCE, not forked around.\n\n**Arc close** (second commit): SDCPN inbox arrival settled to `docs/reference/` with a skeptical digest; INDEX trued; CONVERGENCE re-evaluated with a dated third sequencing pass (the convergence collision now waits only on the build spine reaching FE-1392); registry audit re-parented two orphans (FE-1399/FE-1400 → FE-1383); CONTEXT.md's IR entry rewritten per ADR-0003 and a Grade entry added.\n\nGates: oxlint clean, oxfmt clean, typecheck clean, 100/100 tests, build green.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 14,
+      "url": "https://github.com/hashintel/brunch-lite/pull/14",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1424-docs-housekeeping",
+      "linkedIssue": "FE-1424",
+      "sourceUpdatedAt": "2026-08-19T14:00:20Z",
+      "sourceTitle": "FE-1424: The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable",
+      "sourceTitleSha256": "23fbf383a72d5bb528910b8067ebd01c3aef2aad088e7404b1c19f5a196b894e",
+      "sourceBodySha256": "c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1",
+      "proposedTitle": "FE-1424: Complete the documentation protocol",
+      "oldOuter": "The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.",
+      "proposedOuter": "The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "## What this establishes\n\nCloses FE-1424. The documentation protocol (`docs/agents/documentation.md`) specified zones and a settle sweep that were never executed; this branch runs it, amends it where practice had outgrown it, and makes the parts that can be mechanical, mechanical. Ratified by Lu 2026-08-17.\n\n**Commit 1 — settle + reshape.** The seven inbox documents settle into `docs/reference/` (the protocol's specified-but-never-created destination). `docs/planning/` splits by kind: cross-effort living documents (`CONVERGENCE`, `topology`, the Flue cheatsheet) into `_shared/`; dated arc records into `legibility-sweep/`. The planning top level now holds only directories, so living-vs-record is structural, not judged. All links re-pathed in both directions (14 files, verified by walking every relative link); Linear descriptions carrying old paths repaired (FE-1357/59/66/70, FE-1419, FE-1422/23).\n\n**Commit 2 — arc-close.** Three protocols each carried an arc-close step in prose with nothing firing them together; `docs/agents/arc-close.md` is now the single triggerable checklist (inbox sweep → INDEX pass → CONVERGENCE re-evaluation → registry audit → tense repair), with a content-free `/arc-close` skill wrapper. `documentation.md` gains the `_shared/` zone, the living-vs-record rule, the flattened drafts convention (`docs/planning/<effort>/drafts/`), and the ephemera-reference convention (issue IDs glossed at first mention; load-bearing only in the tracking layer; tense repair at arc close).\n\n**Commit 3 — the gate.** `test/docs-index.test.ts`: every file under `docs/` covered by an INDEX row, every row resolves, planning top level directories-only, every `docs/agents/` protocol named in `AGENTS.md`. Enumerated live, vacuous-pass guarded, red-proved in both directions per rule. Freshness deliberately stays procedural — mechanizing it would build a dead gate.\n\n## Not done here\n\nOld Linear *comments* citing pre-move paths are left as historical record (descriptions were repaired); git log resolves the moves. Two pre-existing broken links found and left: the never-committed prototype HTML in `elicitation-kernel/issues/11`, and links inside the Amp transcript's embedded skill text (verbatim record, unfixable without corrupting it).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "901600f53a27bda06c361821ab502ea6e0e30a5c279c9503fd5f0ea6ca13c050",
+      "innerRecord": "## What this establishes\n\nCloses FE-1424. The documentation protocol (`docs/agents/documentation.md`) specified zones and a settle sweep that were never executed; this branch runs it, amends it where practice had outgrown it, and makes the parts that can be mechanical, mechanical. Ratified by Lu 2026-08-17.\n\n**Commit 1 — settle + reshape.** The seven inbox documents settle into `docs/reference/` (the protocol's specified-but-never-created destination). `docs/planning/` splits by kind: cross-effort living documents (`CONVERGENCE`, `topology`, the Flue cheatsheet) into `_shared/`; dated arc records into `legibility-sweep/`. The planning top level now holds only directories, so living-vs-record is structural, not judged. All links re-pathed in both directions (14 files, verified by walking every relative link); Linear descriptions carrying old paths repaired (FE-1357/59/66/70, FE-1419, FE-1422/23).\n\n**Commit 2 — arc-close.** Three protocols each carried an arc-close step in prose with nothing firing them together; `docs/agents/arc-close.md` is now the single triggerable checklist (inbox sweep → INDEX pass → CONVERGENCE re-evaluation → registry audit → tense repair), with a content-free `/arc-close` skill wrapper. `documentation.md` gains the `_shared/` zone, the living-vs-record rule, the flattened drafts convention (`docs/planning/<effort>/drafts/`), and the ephemera-reference convention (issue IDs glossed at first mention; load-bearing only in the tracking layer; tense repair at arc close).\n\n**Commit 3 — the gate.** `test/docs-index.test.ts`: every file under `docs/` covered by an INDEX row, every row resolves, planning top level directories-only, every `docs/agents/` protocol named in `AGENTS.md`. Enumerated live, vacuous-pass guarded, red-proved in both directions per rule. Freshness deliberately stays procedural — mechanizing it would build a dead gate.\n\n## Not done here\n\nOld Linear *comments* citing pre-move paths are left as historical record (descriptions were repaired); git log resolves the moves. Two pre-existing broken links found and left: the never-committed prototype HTML in `elicitation-kernel/issues/11`, and links inside the Amp transcript's embedded skill text (verbatim record, unfixable without corrupting it).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "901600f53a27bda06c361821ab502ea6e0e30a5c279c9503fd5f0ea6ca13c050",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## What this establishes\n\nCloses FE-1424. The documentation protocol (`docs/agents/documentation.md`) specified zones and a settle sweep that were never executed; this branch runs it, amends it where practice had outgrown it, and makes the parts that can be mechanical, mechanical. Ratified by Lu 2026-08-17.\n\n**Commit 1 — settle + reshape.** The seven inbox documents settle into `docs/reference/` (the protocol's specified-but-never-created destination). `docs/planning/` splits by kind: cross-effort living documents (`CONVERGENCE`, `topology`, the Flue cheatsheet) into `_shared/`; dated arc records into `legibility-sweep/`. The planning top level now holds only directories, so living-vs-record is structural, not judged. All links re-pathed in both directions (14 files, verified by walking every relative link); Linear descriptions carrying old paths repaired (FE-1357/59/66/70, FE-1419, FE-1422/23).\n\n**Commit 2 — arc-close.** Three protocols each carried an arc-close step in prose with nothing firing them together; `docs/agents/arc-close.md` is now the single triggerable checklist (inbox sweep → INDEX pass → CONVERGENCE re-evaluation → registry audit → tense repair), with a content-free `/arc-close` skill wrapper. `documentation.md` gains the `_shared/` zone, the living-vs-record rule, the flattened drafts convention (`docs/planning/<effort>/drafts/`), and the ephemera-reference convention (issue IDs glossed at first mention; load-bearing only in the tracking layer; tense repair at arc close).\n\n**Commit 3 — the gate.** `test/docs-index.test.ts`: every file under `docs/` covered by an INDEX row, every row resolves, planning top level directories-only, every `docs/agents/` protocol named in `AGENTS.md`. Enumerated live, vacuous-pass guarded, red-proved in both directions per rule. Freshness deliberately stays procedural — mechanizing it would build a dead gate.\n\n## Not done here\n\nOld Linear *comments* citing pre-move paths are left as historical record (descriptions were repaired); git log resolves the moves. Two pre-existing broken links found and left: the never-committed prototype HTML in `elicitation-kernel/issues/11`, and links inside the Amp transcript's embedded skill text (verbatim record, unfixable without corrupting it).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 13,
+      "url": "https://github.com/hashintel/brunch-lite/pull/13",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1419-contract-closure",
+      "linkedIssue": "FE-1419",
+      "sourceUpdatedAt": "2026-08-19T14:00:18Z",
+      "sourceTitle": "FE-1419: Close the seams where the capture store and verification gates claim more than they enforce",
+      "sourceTitleSha256": "fb7a8ac27ea24f41a79d749ca20733e2c25c4b1cee170719bc02ce0d241ad260",
+      "sourceBodySha256": "f9ab772a065145e23ed733c85c63888b8319ec31e8b04db7b281917372d796d4",
+      "proposedTitle": "FE-1419: Align capture-store rules and verification claims",
+      "oldOuter": "This branch closes places where the capture store and verification checks promised stronger guarantees than they actually enforced. It aligns the implementation and the checks with the properties the stack relies on.",
+      "proposedOuter": "This branch closes places where the capture store and verification checks promised stronger guarantees than they enforced. It aligns the implementation and the checks with the properties the stack relies on.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Executes the FE-1419 refactor queue (`docs/planning/refactor-queue-2026-08-14.md`) — nine commits that give each contract one owner and make negative results precise, so green gates and successful commands stop claiming more than their implementations support.\n\nVerification layer: known-gap closure becomes an explicit ledger whose entries the proof commit deletes (no more citation-token inference); CI gates match exact declared commands; substrate access in tests is a reviewed inventory asserted as set equality; resolver probes classify only module-not-found as \"no\" and carry positive controls; asset serving accepts the producer's real name space behind property checks and per-segment encoding (closing a latent backslash-traversal path a probe found), translating exactly four absence errnos and propagating everything else.\n\nCapture store: evidence-range ordering, the issue contract, and set-equality resolution accounting each live in one definition enforced at command time and parse time alike; all event write paths deep-copy (the aliasing hole is closed); conflicts open only over two-plus distinct active captures and pin them until a user-cited resolution frees them — jointly, every open conflict is resolvable and stays resolvable, closing the invariant-2 bypass. Commit 9 locks the closure property totally: every command any test accepts round-trips through the persisted parser (an injected fault fails 19 of 21 tests), and refused commands leave the store file byte-identical.\n\nEvery commit was red-proved in both directions and independently reviewed before landing. Known residue, deliberately out of scope for a test-only commit: a `-0` capture value survives the command surface but returns as `0` through JSON — recorded on FE-1419. Fixes four refusal messages to state what was checked rather than what a reader might hope was verified.\n\nAlso carries the FE-1401 remediation-sweep docs that landed during execution: the two-map CONVERGENCE record with seam section, issue glosses, and ordering strategies; the registry rule in issue-tracker.md; the Flue canonical-patterns audit; and the deep-read records.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "03aaf220ef749b0fcb9a0b8a846cc9670fd135f285e682acaf84c04dc77759a0",
+      "innerRecord": "Executes the FE-1419 refactor queue (`docs/planning/refactor-queue-2026-08-14.md`) — nine commits that give each contract one owner and make negative results precise, so green gates and successful commands stop claiming more than their implementations support.\n\nVerification layer: known-gap closure becomes an explicit ledger whose entries the proof commit deletes (no more citation-token inference); CI gates match exact declared commands; substrate access in tests is a reviewed inventory asserted as set equality; resolver probes classify only module-not-found as \"no\" and carry positive controls; asset serving accepts the producer's real name space behind property checks and per-segment encoding (closing a latent backslash-traversal path a probe found), translating exactly four absence errnos and propagating everything else.\n\nCapture store: evidence-range ordering, the issue contract, and set-equality resolution accounting each live in one definition enforced at command time and parse time alike; all event write paths deep-copy (the aliasing hole is closed); conflicts open only over two-plus distinct active captures and pin them until a user-cited resolution frees them — jointly, every open conflict is resolvable and stays resolvable, closing the invariant-2 bypass. Commit 9 locks the closure property totally: every command any test accepts round-trips through the persisted parser (an injected fault fails 19 of 21 tests), and refused commands leave the store file byte-identical.\n\nEvery commit was red-proved in both directions and independently reviewed before landing. Known residue, deliberately out of scope for a test-only commit: a `-0` capture value survives the command surface but returns as `0` through JSON — recorded on FE-1419. Fixes four refusal messages to state what was checked rather than what a reader might hope was verified.\n\nAlso carries the FE-1401 remediation-sweep docs that landed during execution: the two-map CONVERGENCE record with seam section, issue glosses, and ordering strategies; the registry rule in issue-tracker.md; the Flue canonical-patterns audit; and the deep-read records.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "03aaf220ef749b0fcb9a0b8a846cc9670fd135f285e682acaf84c04dc77759a0",
+      "normalizationNotes": "The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.",
+      "proposedBody": "This branch closes places where the capture store and verification checks promised stronger guarantees than they enforced. It aligns the implementation and the checks with the properties the stack relies on.\n\n<details><summary>🏗️ Agent notes</summary>\n\nExecutes the FE-1419 refactor queue (`docs/planning/refactor-queue-2026-08-14.md`) — nine commits that give each contract one owner and make negative results precise, so green gates and successful commands stop claiming more than their implementations support.\n\nVerification layer: known-gap closure becomes an explicit ledger whose entries the proof commit deletes (no more citation-token inference); CI gates match exact declared commands; substrate access in tests is a reviewed inventory asserted as set equality; resolver probes classify only module-not-found as \"no\" and carry positive controls; asset serving accepts the producer's real name space behind property checks and per-segment encoding (closing a latent backslash-traversal path a probe found), translating exactly four absence errnos and propagating everything else.\n\nCapture store: evidence-range ordering, the issue contract, and set-equality resolution accounting each live in one definition enforced at command time and parse time alike; all event write paths deep-copy (the aliasing hole is closed); conflicts open only over two-plus distinct active captures and pin them until a user-cited resolution frees them — jointly, every open conflict is resolvable and stays resolvable, closing the invariant-2 bypass. Commit 9 locks the closure property totally: every command any test accepts round-trips through the persisted parser (an injected fault fails 19 of 21 tests), and refused commands leave the store file byte-identical.\n\nEvery commit was red-proved in both directions and independently reviewed before landing. Known residue, deliberately out of scope for a test-only commit: a `-0` capture value survives the command surface but returns as `0` through JSON — recorded on FE-1419. Fixes four refusal messages to state what was checked rather than what a reader might hope was verified.\n\nAlso carries the FE-1401 remediation-sweep docs that landed during execution: the two-map CONVERGENCE record with seam section, issue glosses, and ordering strategies; the registry rule in issue-tracker.md; the Flue canonical-patterns audit; and the deep-read records.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>",
+      "proposedBodySha256": "7c6d072833c15450fddbb3e102cf9b39e7aeb2af621c1090a990f5c6894e0b14",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "Removed “actually”; the sentence now names what the checks failed to enforce."
+    },
+    {
+      "number": 12,
+      "url": "https://github.com/hashintel/brunch-lite/pull/12",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1401-legibility-sweep",
+      "linkedIssue": "FE-1401",
+      "sourceUpdatedAt": "2026-08-19T14:00:17Z",
+      "sourceTitle": "FE-1401: Resolve the follow-ups from the stack legibility session",
+      "sourceTitleSha256": "0451f66a36602e806df9c2112c1121521b94245613ec8efffb621bb83695c9d0",
+      "sourceBodySha256": "cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3",
+      "proposedTitle": "FE-1401: Resolve the stack legibility follow-ups",
+      "oldOuter": "The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.",
+      "proposedOuter": "The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "FE-1401: Land the legibility session's renderings, audit, and penciled directions\n\nThree documents promoted from drafts/ by Lu, with their post-move repairs\n(self-descriptions, relative links) and editorial additions:\n\n- ir-design-plain.md — plain-prose rendering of the IR design (same content\n  commitments; original authoritative). The rendering pass doubled as review:\n  seven strain findings on FE-1401, the load-bearing one being the loss\n  report's unresolved unit of loss (capture vs. capture-facet).\n- notes/research-patterns-audit.md — ~30 research imports in 7 families,\n  each with plain explanation, provenance, evidence grade, and where it\n  landed; strain appendix (8 findings, incl. the betting-questions\n  misattribution and the v0-vs-IDEA quantile divergence).\n- notes/penciled-directions-2026-08-14.md — 8 penciled directions with\n  firming actions and marked editorial reflections (schema as forcing\n  function, plugin manifest sketch, mode oscillation, activation probes,\n  incorporation rubric, super-map question, write-time check tiers,\n  per-domain machinery inventory).\n\nINDEX.md gains rows for all three plus two pre-existing gaps: ir-design.md\nand ir-worked-examples.md were never indexed.\n\nSession record: FE-1401 and its accrual comments; new tickets FE-1402–1407.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nprep refactor queue, and flue analysis\n\nSigned-off-by: Lu Nelson <ln@hash.ai>",
+      "sourceInnerSha256": "deb834741c2f9b93ca8d47f6032007240f2aeafb09d79b6e6593f4d11f61226a",
+      "innerRecord": "FE-1401: Land the legibility session's renderings, audit, and penciled directions\n\nThree documents promoted from drafts/ by Lu, with their post-move repairs\n(self-descriptions, relative links) and editorial additions:\n\n- ir-design-plain.md — plain-prose rendering of the IR design (same content\n  commitments; original authoritative). The rendering pass doubled as review:\n  seven strain findings on FE-1401, the load-bearing one being the loss\n  report's unresolved unit of loss (capture vs. capture-facet).\n- notes/research-patterns-audit.md — ~30 research imports in 7 families,\n  each with plain explanation, provenance, evidence grade, and where it\n  landed; strain appendix (8 findings, incl. the betting-questions\n  misattribution and the v0-vs-IDEA quantile divergence).\n- notes/penciled-directions-2026-08-14.md — 8 penciled directions with\n  firming actions and marked editorial reflections (schema as forcing\n  function, plugin manifest sketch, mode oscillation, activation probes,\n  incorporation rubric, super-map question, write-time check tiers,\n  per-domain machinery inventory).\n\nINDEX.md gains rows for all three plus two pre-existing gaps: ir-design.md\nand ir-worked-examples.md were never indexed.\n\nSession record: FE-1401 and its accrual comments; new tickets FE-1402–1407.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nprep refactor queue, and flue analysis\n\nSigned-off-by: Lu Nelson <ln@hash.ai>",
+      "innerSha256": "deb834741c2f9b93ca8d47f6032007240f2aeafb09d79b6e6593f4d11f61226a",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1401: Land the legibility session's renderings, audit, and penciled directions\n\nThree documents promoted from drafts/ by Lu, with their post-move repairs\n(self-descriptions, relative links) and editorial additions:\n\n- ir-design-plain.md — plain-prose rendering of the IR design (same content\n  commitments; original authoritative). The rendering pass doubled as review:\n  seven strain findings on FE-1401, the load-bearing one being the loss\n  report's unresolved unit of loss (capture vs. capture-facet).\n- notes/research-patterns-audit.md — ~30 research imports in 7 families,\n  each with plain explanation, provenance, evidence grade, and where it\n  landed; strain appendix (8 findings, incl. the betting-questions\n  misattribution and the v0-vs-IDEA quantile divergence).\n- notes/penciled-directions-2026-08-14.md — 8 penciled directions with\n  firming actions and marked editorial reflections (schema as forcing\n  function, plugin manifest sketch, mode oscillation, activation probes,\n  incorporation rubric, super-map question, write-time check tiers,\n  per-domain machinery inventory).\n\nINDEX.md gains rows for all three plus two pre-existing gaps: ir-design.md\nand ir-worked-examples.md were never indexed.\n\nSession record: FE-1401 and its accrual comments; new tickets FE-1402–1407.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nprep refactor queue, and flue analysis\n\nSigned-off-by: Lu Nelson <ln@hash.ai>\n\n</details>\n",
+      "proposedBodySha256": "cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 11,
+      "url": "https://github.com/hashintel/brunch-lite/pull/11",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1390-capture-store",
+      "linkedIssue": "FE-1390",
+      "sourceUpdatedAt": "2026-08-19T14:00:15Z",
+      "sourceTitle": "FE-1390: Capture envelope, storage port, and the local capture store",
+      "sourceTitleSha256": "710989fa7a8870a91ba1e36447c52327068378fbb13bc879314f367363dc3f6c",
+      "sourceBodySha256": "a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0",
+      "proposedTitle": "FE-1390: Implement capture history and local persistence",
+      "oldOuter": "This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.",
+      "proposedOuter": "This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Adds the capture store — the durable, session-independent truth of a target-document — as an append-only snapshot of captures, issues, and events, with every status derived at read time instead of stored. Writes go through one pure command function that returns either a whole new snapshot or a typed refusal, so a sweep applies completely or not at all, and the Flue binding implements the storage port over it with a JSON file, tmp-and-rename, and per-path serialized writes. Capture identity is content-keyed with epistemic status excluded, which makes re-sweeps idempotent and forces revised readings through explicit supersession. The session-log-archive half of the storage port (spec §9.6) and write-time verification of evidence pointers are not in this branch, and nothing consumes the store yet.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md` (FE-1401 remediation sweep); the plain rendering with strain report is `docs/planning/process-model-elicitation/capture-store-plain.md`; contract-closure work is queued as FE-1419.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "dd6b285545fcc139792afefef315c9c22acc0e2f1b1d08a9a80b9198b98a46ba",
+      "innerRecord": "Adds the capture store — the durable, session-independent truth of a target-document — as an append-only snapshot of captures, issues, and events, with every status derived at read time instead of stored. Writes go through one pure command function that returns either a whole new snapshot or a typed refusal, so a sweep applies completely or not at all, and the Flue binding implements the storage port over it with a JSON file, tmp-and-rename, and per-path serialized writes. Capture identity is content-keyed with epistemic status excluded, which makes re-sweeps idempotent and forces revised readings through explicit supersession. The session-log-archive half of the storage port (spec §9.6) and write-time verification of evidence pointers are not in this branch, and nothing consumes the store yet.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md` (FE-1401 remediation sweep); the plain rendering with strain report is `docs/planning/process-model-elicitation/capture-store-plain.md`; contract-closure work is queued as FE-1419.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "dd6b285545fcc139792afefef315c9c22acc0e2f1b1d08a9a80b9198b98a46ba",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.\n\n<details><summary>🏗️ Agent notes</summary>\n\nAdds the capture store — the durable, session-independent truth of a target-document — as an append-only snapshot of captures, issues, and events, with every status derived at read time instead of stored. Writes go through one pure command function that returns either a whole new snapshot or a typed refusal, so a sweep applies completely or not at all, and the Flue binding implements the storage port over it with a JSON file, tmp-and-rename, and per-path serialized writes. Capture identity is content-keyed with epistemic status excluded, which makes re-sweeps idempotent and forces revised readings through explicit supersession. The session-log-archive half of the storage port (spec §9.6) and write-time verification of evidence pointers are not in this branch, and nothing consumes the store yet.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md` (FE-1401 remediation sweep); the plain rendering with strain report is `docs/planning/process-model-elicitation/capture-store-plain.md`; contract-closure work is queued as FE-1419.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 10,
+      "url": "https://github.com/hashintel/brunch-lite/pull/10",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1389-walking-skeleton",
+      "linkedIssue": "FE-1389",
+      "sourceUpdatedAt": "2026-08-19T14:00:14Z",
+      "sourceTitle": "FE-1389: Walking skeleton — the harness asks a free-text question and binds the reply",
+      "sourceTitleSha256": "9aa634521196bc66ad8a36254eb995aee3b484177468d0bb0e007fb358ffb8b7",
+      "sourceBodySha256": "f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69",
+      "proposedTitle": "FE-1389: Implement the first suspended free-text question",
+      "oldOuter": "This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.",
+      "proposedOuter": "This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "This turns the ask seam into a working turn-suspension protocol: the tool mints a free-text affordance, parks it in the pending-affordance slot, returns it on the tool output part where its identity is durable, and terminates the turn — then the next user dispatch clears the slot and gets bound to that affordance by the harness itself, announced to the model as a signal rather than left to the model's memory. Because the pending question is never interpolated into the instructions, the instruction string cannot change between turns, which is what removes the wasted \"instructions updated\" wake turn the ticket-10 prototype hit once per question. The dev app is the proof: a chat UI plus an integration test that boots the real Flue runtime and the real Hono app in one process, drives them over a fetch shim with a scripted faux provider, and asserts in one shot that the reply binding reached the model, the affordance survived durably, no advisory wake appeared, and a second ask in the same batch was refused.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md` (FE-1401 remediation sweep); hardening follow-ups filed as FE-1420.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "f5792d146c557204d975fa7c7b4cacc298cced709faec5fe5cd951c46b0e7ea4",
+      "innerRecord": "This turns the ask seam into a working turn-suspension protocol: the tool mints a free-text affordance, parks it in the pending-affordance slot, returns it on the tool output part where its identity is durable, and terminates the turn — then the next user dispatch clears the slot and gets bound to that affordance by the harness itself, announced to the model as a signal rather than left to the model's memory. Because the pending question is never interpolated into the instructions, the instruction string cannot change between turns, which is what removes the wasted \"instructions updated\" wake turn the ticket-10 prototype hit once per question. The dev app is the proof: a chat UI plus an integration test that boots the real Flue runtime and the real Hono app in one process, drives them over a fetch shim with a scripted faux provider, and asserts in one shot that the reply binding reached the model, the affordance survived durably, no advisory wake appeared, and a second ask in the same batch was refused.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md` (FE-1401 remediation sweep); hardening follow-ups filed as FE-1420.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "f5792d146c557204d975fa7c7b4cacc298cced709faec5fe5cd951c46b0e7ea4",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.\n\n<details><summary>🏗️ Agent notes</summary>\n\nThis turns the ask seam into a working turn-suspension protocol: the tool mints a free-text affordance, parks it in the pending-affordance slot, returns it on the tool output part where its identity is durable, and terminates the turn — then the next user dispatch clears the slot and gets bound to that affordance by the harness itself, announced to the model as a signal rather than left to the model's memory. Because the pending question is never interpolated into the instructions, the instruction string cannot change between turns, which is what removes the wasted \"instructions updated\" wake turn the ticket-10 prototype hit once per question. The dev app is the proof: a chat UI plus an integration test that boots the real Flue runtime and the real Hono app in one process, drives them over a fetch shim with a scripted faux provider, and asserts in one shot that the reply binding reached the model, the affordance survived durably, no advisory wake appeared, and a second ask in the same batch was refused.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md` (FE-1401 remediation sweep); hardening follow-ups filed as FE-1420.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 9,
+      "url": "https://github.com/hashintel/brunch-lite/pull/9",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1400-close-silent-gaps",
+      "linkedIssue": "FE-1400",
+      "sourceUpdatedAt": "2026-08-19T14:00:12Z",
+      "sourceTitle": "FE-1400: Close the review-found gaps where the gates, dev app, and baseline runner still fail silently",
+      "sourceTitleSha256": "438c3f68d2d61c5975585c864f38610d5e0899e9f6d1aea28d3091b82f63bb71",
+      "sourceBodySha256": "3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869",
+      "proposedTitle": "FE-1400: Strengthen verification, dev storage, and the baseline runner",
+      "oldOuter": "This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.",
+      "proposedOuter": "This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Executes the FE-1400 bundle: the ten verified findings from the FE-1397 tie-off review, plus the cleanup tail, as small always-green commits. Each strengthened gate was red-proved — the violation it guards against was temporarily introduced and the gate watched go red — before restoring green.\n\n**Docs truth:** the AGENTS.md triage one-liner now matches the triage doc's state/label mapping.\n\n**Test integrity:** build-artifact witnesses are now strings unique to the guarded modules (`createAgentRouter`/`sqlite` both matched bootstrap code regardless of what bundled); the first-statement check reuses the shared directive pattern instead of a literal compare; the workspace walker's source/test partition is total (nested `src/test/` files no longer escape every invariant); the CI-gate check parses the workflow so commented-out or `if: false` gates read as absent; known-gaps predicates require an explicit `closes-gap: <id>` citation in a real test instead of `existsSync` on a guessed path — a stub can't close a gap, a differently-named real closure can. FWIW the citation-token design earned its keep immediately: the first draft accepted any prose mention of the gap id, and a doc comment in this branch's own new test closed a gap.\n\n**Dev app:** the conversation store's default path anchors to the module (`db-path.ts`) instead of the launch directory, with tests for cwd-independence and the set-but-empty env override (which would have opened an anonymous temp database).\n\n**Baseline runner:** the hand-rolled HTTP client is gone in favor of `@anthropic-ai/sdk` (network-error retries, retry-after, cache-token usage in the totals); truncation survives continuation stitching and is reported with the `--continue-final` escape hatch; fence matching tolerates the info-string forms real runs produce, and a delivered run that yields no extractable artifact — or an ambiguous multi-block one — says so loudly. The post-review pass also added an explicit SDK timeout (the doubled retry budget tripped the SDK's 10-minute non-streaming guard), no-clobber guards for fresh/`--resume` runs, and seam-exact stitching.\n\n**Cleanup tail:** assets serve via a `/assets/*` wildcard and hono's MIME table (nested paths now work); CI builds once (root build inside `bun test`'s artifact suite, exercising every package's build script) and caches bun installs; the root build filter is `@brunch/*`; the runner's parallel `expertMessages` array and dead checkpoint field are gone; the boundary suite derives its topology pin from the spec's §12.2 block and its physical-resolution probes from the tree.\n\nTwo review findings deliberately not taken: swapping the hand-rolled asset handler for hono's `serveStatic` middleware (the strict dotfile/extension refusal semantics are pinned by tests and the ticket asked for framework routing + MIME table, both done), and de-obfuscating the composed `MODEL_KEY_NAME` pattern (an exclusion list for pattern-defining files has its own silent-failure mode; the composition predates this branch and is documented in place).\n\nCloses FE-1400.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "417c1c5f7a1e36797056a57c4926ece639a5b1194698472254dc2bb5269d8de9",
+      "innerRecord": "Executes the FE-1400 bundle: the ten verified findings from the FE-1397 tie-off review, plus the cleanup tail, as small always-green commits. Each strengthened gate was red-proved — the violation it guards against was temporarily introduced and the gate watched go red — before restoring green.\n\n**Docs truth:** the AGENTS.md triage one-liner now matches the triage doc's state/label mapping.\n\n**Test integrity:** build-artifact witnesses are now strings unique to the guarded modules (`createAgentRouter`/`sqlite` both matched bootstrap code regardless of what bundled); the first-statement check reuses the shared directive pattern instead of a literal compare; the workspace walker's source/test partition is total (nested `src/test/` files no longer escape every invariant); the CI-gate check parses the workflow so commented-out or `if: false` gates read as absent; known-gaps predicates require an explicit `closes-gap: <id>` citation in a real test instead of `existsSync` on a guessed path — a stub can't close a gap, a differently-named real closure can. FWIW the citation-token design earned its keep immediately: the first draft accepted any prose mention of the gap id, and a doc comment in this branch's own new test closed a gap.\n\n**Dev app:** the conversation store's default path anchors to the module (`db-path.ts`) instead of the launch directory, with tests for cwd-independence and the set-but-empty env override (which would have opened an anonymous temp database).\n\n**Baseline runner:** the hand-rolled HTTP client is gone in favor of `@anthropic-ai/sdk` (network-error retries, retry-after, cache-token usage in the totals); truncation survives continuation stitching and is reported with the `--continue-final` escape hatch; fence matching tolerates the info-string forms real runs produce, and a delivered run that yields no extractable artifact — or an ambiguous multi-block one — says so loudly. The post-review pass also added an explicit SDK timeout (the doubled retry budget tripped the SDK's 10-minute non-streaming guard), no-clobber guards for fresh/`--resume` runs, and seam-exact stitching.\n\n**Cleanup tail:** assets serve via a `/assets/*` wildcard and hono's MIME table (nested paths now work); CI builds once (root build inside `bun test`'s artifact suite, exercising every package's build script) and caches bun installs; the root build filter is `@brunch/*`; the runner's parallel `expertMessages` array and dead checkpoint field are gone; the boundary suite derives its topology pin from the spec's §12.2 block and its physical-resolution probes from the tree.\n\nTwo review findings deliberately not taken: swapping the hand-rolled asset handler for hono's `serveStatic` middleware (the strict dotfile/extension refusal semantics are pinned by tests and the ticket asked for framework routing + MIME table, both done), and de-obfuscating the composed `MODEL_KEY_NAME` pattern (an exclusion list for pattern-defining files has its own silent-failure mode; the composition predates this branch and is documented in place).\n\nCloses FE-1400.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "417c1c5f7a1e36797056a57c4926ece639a5b1194698472254dc2bb5269d8de9",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.\n\n<details><summary>🏗️ Agent notes</summary>\n\nExecutes the FE-1400 bundle: the ten verified findings from the FE-1397 tie-off review, plus the cleanup tail, as small always-green commits. Each strengthened gate was red-proved — the violation it guards against was temporarily introduced and the gate watched go red — before restoring green.\n\n**Docs truth:** the AGENTS.md triage one-liner now matches the triage doc's state/label mapping.\n\n**Test integrity:** build-artifact witnesses are now strings unique to the guarded modules (`createAgentRouter`/`sqlite` both matched bootstrap code regardless of what bundled); the first-statement check reuses the shared directive pattern instead of a literal compare; the workspace walker's source/test partition is total (nested `src/test/` files no longer escape every invariant); the CI-gate check parses the workflow so commented-out or `if: false` gates read as absent; known-gaps predicates require an explicit `closes-gap: <id>` citation in a real test instead of `existsSync` on a guessed path — a stub can't close a gap, a differently-named real closure can. FWIW the citation-token design earned its keep immediately: the first draft accepted any prose mention of the gap id, and a doc comment in this branch's own new test closed a gap.\n\n**Dev app:** the conversation store's default path anchors to the module (`db-path.ts`) instead of the launch directory, with tests for cwd-independence and the set-but-empty env override (which would have opened an anonymous temp database).\n\n**Baseline runner:** the hand-rolled HTTP client is gone in favor of `@anthropic-ai/sdk` (network-error retries, retry-after, cache-token usage in the totals); truncation survives continuation stitching and is reported with the `--continue-final` escape hatch; fence matching tolerates the info-string forms real runs produce, and a delivered run that yields no extractable artifact — or an ambiguous multi-block one — says so loudly. The post-review pass also added an explicit SDK timeout (the doubled retry budget tripped the SDK's 10-minute non-streaming guard), no-clobber guards for fresh/`--resume` runs, and seam-exact stitching.\n\n**Cleanup tail:** assets serve via a `/assets/*` wildcard and hono's MIME table (nested paths now work); CI builds once (root build inside `bun test`'s artifact suite, exercising every package's build script) and caches bun installs; the root build filter is `@brunch/*`; the runner's parallel `expertMessages` array and dead checkpoint field are gone; the boundary suite derives its topology pin from the spec's §12.2 block and its physical-resolution probes from the tree.\n\nTwo review findings deliberately not taken: swapping the hand-rolled asset handler for hono's `serveStatic` middleware (the strict dotfile/extension refusal semantics are pinned by tests and the ticket asked for framework routing + MIME table, both done), and de-obfuscating the composed `MODEL_KEY_NAME` pattern (an exclusion list for pattern-defining files has its own silent-failure mode; the composition predates this branch and is documented in place).\n\nCloses FE-1400.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 8,
+      "url": "https://github.com/hashintel/brunch-lite/pull/8",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1397-worked-examples",
+      "linkedIssue": "FE-1397",
+      "sourceUpdatedAt": "2026-08-19T14:00:10Z",
+      "sourceTitle": "FE-1397: Validate the generic IR definition against worked payload designs (Gherkin, CPS, +1)",
+      "sourceTitleSha256": "bb81d98a6ecb4ad55e7dddaf963f52da31c86a14e7cb652ee63e46396ee2867e",
+      "sourceBodySha256": "e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0",
+      "proposedTitle": "FE-1397: Validate the generic IR against worked plugin payloads",
+      "oldOuter": "The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.",
+      "proposedOuter": "The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Discharges the ratification condition on the generic IR definition (`ir-design.md`, Layer A): speculative payload type systems drafted for Gherkin (thin) and BPMN/process-mining (mid, the kernel spec's named third target), checked property-by-property alongside CPS (Layer B) and the assurance plugin from spec canon.\n\n**New:** `docs/planning/process-model-elicitation/ir-worked-examples.md` — the two drafted payload designs, per-property verdict table, sublimation findings, and the handoff list for plugin-spec authoring.\n\n**Amended:** `ir-design.md` —\n- All five MUST properties survive; property 2 generalized from statement granularity to **evidence granularity** (log-derived `external-lookup` captures have no user statement), property 3 restated operatively (its bite is proportional to domain–format distance; the enforceable content is IR-legitimacy of unconsumed kinds + the honest loss report).\n- Symbolic name references promoted MAY → SHOULD (all four designs use them); the objective-kind pattern generalized to completion-anchor kinds; motif annotations demoted to a named escape hatch (zero uptake); **source-regime** promoted from Layer B to a Layer-A MAY pattern for process-shaped domains.\n- Status: conditionally ratified → **ratified on worked examples**, still provisional until the September harness run.\n\nStacked on `ln/fe-1399-fail-loudly` because `ir-design.md` is not on main yet.\n\nCloses FE-1397.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "bf06af3e6f96d849b4c1be53c8a5d9a6d3d750d4f8fdd6ddd6cac5444ec17d8a",
+      "innerRecord": "Discharges the ratification condition on the generic IR definition (`ir-design.md`, Layer A): speculative payload type systems drafted for Gherkin (thin) and BPMN/process-mining (mid, the kernel spec's named third target), checked property-by-property alongside CPS (Layer B) and the assurance plugin from spec canon.\n\n**New:** `docs/planning/process-model-elicitation/ir-worked-examples.md` — the two drafted payload designs, per-property verdict table, sublimation findings, and the handoff list for plugin-spec authoring.\n\n**Amended:** `ir-design.md` —\n- All five MUST properties survive; property 2 generalized from statement granularity to **evidence granularity** (log-derived `external-lookup` captures have no user statement), property 3 restated operatively (its bite is proportional to domain–format distance; the enforceable content is IR-legitimacy of unconsumed kinds + the honest loss report).\n- Symbolic name references promoted MAY → SHOULD (all four designs use them); the objective-kind pattern generalized to completion-anchor kinds; motif annotations demoted to a named escape hatch (zero uptake); **source-regime** promoted from Layer B to a Layer-A MAY pattern for process-shaped domains.\n- Status: conditionally ratified → **ratified on worked examples**, still provisional until the September harness run.\n\nStacked on `ln/fe-1399-fail-loudly` because `ir-design.md` is not on main yet.\n\nCloses FE-1397.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "bf06af3e6f96d849b4c1be53c8a5d9a6d3d750d4f8fdd6ddd6cac5444ec17d8a",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.\n\n<details><summary>🏗️ Agent notes</summary>\n\nDischarges the ratification condition on the generic IR definition (`ir-design.md`, Layer A): speculative payload type systems drafted for Gherkin (thin) and BPMN/process-mining (mid, the kernel spec's named third target), checked property-by-property alongside CPS (Layer B) and the assurance plugin from spec canon.\n\n**New:** `docs/planning/process-model-elicitation/ir-worked-examples.md` — the two drafted payload designs, per-property verdict table, sublimation findings, and the handoff list for plugin-spec authoring.\n\n**Amended:** `ir-design.md` —\n- All five MUST properties survive; property 2 generalized from statement granularity to **evidence granularity** (log-derived `external-lookup` captures have no user statement), property 3 restated operatively (its bite is proportional to domain–format distance; the enforceable content is IR-legitimacy of unconsumed kinds + the honest loss report).\n- Symbolic name references promoted MAY → SHOULD (all four designs use them); the objective-kind pattern generalized to completion-anchor kinds; motif annotations demoted to a named escape hatch (zero uptake); **source-regime** promoted from Layer B to a Layer-A MAY pattern for process-shaped domains.\n- Status: conditionally ratified → **ratified on worked examples**, still provisional until the September harness run.\n\nStacked on `ln/fe-1399-fail-loudly` because `ir-design.md` is not on main yet.\n\nCloses FE-1397.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+      "proposedBodySha256": "e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 7,
+      "url": "https://github.com/hashintel/brunch-lite/pull/7",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1399-fail-loudly",
+      "linkedIssue": "FE-1399",
+      "sourceUpdatedAt": "2026-08-19T14:00:08Z",
+      "sourceTitle": "FE-1399: Make the CI gates and dev app fail loudly where review found they fail silently",
+      "sourceTitleSha256": "09929e03f4a76113a051454c63fd0fdad8466e536a83e0e3f13e4a817672c64c",
+      "sourceBodySha256": "23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119",
+      "proposedTitle": "FE-1399: Fix verified silent failures in CI and the dev app",
+      "oldOuter": "Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.",
+      "proposedOuter": "Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "FE-1399: Make the CI gates and dev app fail loudly where review found they fail silently\n\nThe five verified findings from the FE-1361 review sweep:\n\n- Agent-module detection is statement-anchored (shared in test/workspace.ts,\n  unit-tested), so a comment mentioning 'use agent' no longer turns a file\n  into an agent module — while a misplaced or comment-trailed directive is\n  still detected and failed loudly.\n- workspacePackages() derives its groups from the root manifest's workspaces\n  globs; an unknown group, unreadable glob shape, or missing directory now\n  throws instead of passing every boundary invariant vacuously.\n- toolName() takes the Operation union instead of string, so a misspelled\n  operation is a compile error; a @ts-expect-error test pins the narrowing.\n- The dev app's mount path derives from GherkinElicitor.agentName, and a new\n  boundary test forbids a pinned identity being duplicated as a string\n  literal outside its agent module.\n- The production /assets/:file route serves everything the client build can\n  emit — bytes, not UTF-8; case-folded extensions; content-type map failing\n  open to octet-stream — with the handler extracted to assets.ts and driven\n  as a real Hono route over binary fixtures.\n\nReview fixes folded in: trailing-comment directives still detected,\nidentity scan matches quoted literals only (no comment cry-wolf),\nuppercase extensions serve.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nsymlink CLAUDE.md from AGENTS.md",
+      "sourceInnerSha256": "4fb763857dc7d92796d5c5100d3a1569bbe3e42455521a70c011b9fecfeafb2e",
+      "innerRecord": "FE-1399: Make the CI gates and dev app fail loudly where review found they fail silently\n\nThe five verified findings from the FE-1361 review sweep:\n\n- Agent-module detection is statement-anchored (shared in test/workspace.ts,\n  unit-tested), so a comment mentioning 'use agent' no longer turns a file\n  into an agent module — while a misplaced or comment-trailed directive is\n  still detected and failed loudly.\n- workspacePackages() derives its groups from the root manifest's workspaces\n  globs; an unknown group, unreadable glob shape, or missing directory now\n  throws instead of passing every boundary invariant vacuously.\n- toolName() takes the Operation union instead of string, so a misspelled\n  operation is a compile error; a @ts-expect-error test pins the narrowing.\n- The dev app's mount path derives from GherkinElicitor.agentName, and a new\n  boundary test forbids a pinned identity being duplicated as a string\n  literal outside its agent module.\n- The production /assets/:file route serves everything the client build can\n  emit — bytes, not UTF-8; case-folded extensions; content-type map failing\n  open to octet-stream — with the handler extracted to assets.ts and driven\n  as a real Hono route over binary fixtures.\n\nReview fixes folded in: trailing-comment directives still detected,\nidentity scan matches quoted literals only (no comment cry-wolf),\nuppercase extensions serve.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nsymlink CLAUDE.md from AGENTS.md",
+      "innerSha256": "4fb763857dc7d92796d5c5100d3a1569bbe3e42455521a70c011b9fecfeafb2e",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1399: Make the CI gates and dev app fail loudly where review found they fail silently\n\nThe five verified findings from the FE-1361 review sweep:\n\n- Agent-module detection is statement-anchored (shared in test/workspace.ts,\n  unit-tested), so a comment mentioning 'use agent' no longer turns a file\n  into an agent module — while a misplaced or comment-trailed directive is\n  still detected and failed loudly.\n- workspacePackages() derives its groups from the root manifest's workspaces\n  globs; an unknown group, unreadable glob shape, or missing directory now\n  throws instead of passing every boundary invariant vacuously.\n- toolName() takes the Operation union instead of string, so a misspelled\n  operation is a compile error; a @ts-expect-error test pins the narrowing.\n- The dev app's mount path derives from GherkinElicitor.agentName, and a new\n  boundary test forbids a pinned identity being duplicated as a string\n  literal outside its agent module.\n- The production /assets/:file route serves everything the client build can\n  emit — bytes, not UTF-8; case-folded extensions; content-type map failing\n  open to octet-stream — with the handler extracted to assets.ts and driven\n  as a real Hono route over binary fixtures.\n\nReview fixes folded in: trailing-comment directives still detected,\nidentity scan matches quoted literals only (no comment cry-wolf),\nuppercase extensions serve.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nsymlink CLAUDE.md from AGENTS.md\n\n</details>\n",
+      "proposedBodySha256": "23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 6,
+      "url": "https://github.com/hashintel/brunch-lite/pull/6",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1361-baseline-control",
+      "linkedIssue": "FE-1361",
+      "sourceUpdatedAt": "2026-08-19T14:00:06Z",
+      "sourceTitle": "FE-1361: Baseline control — what does one-shot AI elicitation already achieve?",
+      "sourceTitleSha256": "49a7e617a4276a193a7ac78578d95fb09586d2fd660232472afb83eaa2c81739",
+      "sourceBodySha256": "a504f8f2a3ac48ec0599e2f1bf0a8d9968e94dbbd04eb6d8b23d200966e8bbb6",
+      "proposedTitle": "FE-1361: Measure the one-shot AI elicitation baseline",
+      "oldOuter": "This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is actually needed.",
+      "proposedOuter": "This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is needed.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Resolves [FE-1361](https://linear.app/hash/issue/FE-1361): the baseline-control experiment — what does one-shot / lightly-prompted AI elicitation already achieve?\n\nTwo conditions ran against the same simulated master scheduler (Production Scheduling testbed case): bare `claude-opus-5`, and the same model armed with the seven-category v0 prompt. Everything lives under `docs/planning/process-model-elicitation/baseline/` — protocol, situation pack, v0 prompt, runner, both full transcripts, and the scored read-out (`readout.md`).\n\nHeadline findings (details and scores in the read-out, gist on the ticket):\n\n- The bare baseline interviews far better than the positioning assumed — objectives-first, unwritten-rules probing, refusal to invent values, and an unprompted assumptions register. The differentiation story must rest on machinery, and now has evidence to rest on.\n- Neither condition can end the engagement: one novel deliverable-deferral failure, one sophisticated budget-exhaustion. Completion has to be an adjudicated contract.\n- The v0 prompt buys interaction shape, quantile elicitation, live category accounting, conflict-point depth, and penalty-weight co-construction; its residual gaps are the evidence-derived plugin requirements.\n\nAlso on this branch, from the review pass: the typecheck gate now covers `docs/planning/**` scripts (which surfaced and fixed a real narrowing error in the runner), and five off-by-one relative links left by the docs migration are repaired. The review's remaining repo-wide findings are filed as [FE-1399](https://linear.app/hash/issue/FE-1399).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "sourceInnerSha256": "fb6a119b6a835d5db47ffc75c42aa42213d0e7dc5b224fbccffeb462fb126408",
+      "innerRecord": "Resolves [FE-1361](https://linear.app/hash/issue/FE-1361): the baseline-control experiment — what does one-shot / lightly-prompted AI elicitation already achieve?\n\nTwo conditions ran against the same simulated master scheduler (Production Scheduling testbed case): bare `claude-opus-5`, and the same model armed with the seven-category v0 prompt. Everything lives under `docs/planning/process-model-elicitation/baseline/` — protocol, situation pack, v0 prompt, runner, both full transcripts, and the scored read-out (`readout.md`).\n\nHeadline findings (details and scores in the read-out, gist on the ticket):\n\n- The bare baseline interviews far better than the positioning assumed — objectives-first, unwritten-rules probing, refusal to invent values, and an unprompted assumptions register. The differentiation story must rest on machinery, and now has evidence to rest on.\n- Neither condition can end the engagement: one novel deliverable-deferral failure, one sophisticated budget-exhaustion. Completion has to be an adjudicated contract.\n- The v0 prompt buys interaction shape, quantile elicitation, live category accounting, conflict-point depth, and penalty-weight co-construction; its residual gaps are the evidence-derived plugin requirements.\n\nAlso on this branch, from the review pass: the typecheck gate now covers `docs/planning/**` scripts (which surfaced and fixed a real narrowing error in the runner), and five off-by-one relative links left by the docs migration are repaired. The review's remaining repo-wide findings are filed as [FE-1399](https://linear.app/hash/issue/FE-1399).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)",
+      "innerSha256": "fb6a119b6a835d5db47ffc75c42aa42213d0e7dc5b224fbccffeb462fb126408",
+      "normalizationNotes": "The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.",
+      "proposedBody": "This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is needed.\n\n<details><summary>🏗️ Agent notes</summary>\n\nResolves [FE-1361](https://linear.app/hash/issue/FE-1361): the baseline-control experiment — what does one-shot / lightly-prompted AI elicitation already achieve?\n\nTwo conditions ran against the same simulated master scheduler (Production Scheduling testbed case): bare `claude-opus-5`, and the same model armed with the seven-category v0 prompt. Everything lives under `docs/planning/process-model-elicitation/baseline/` — protocol, situation pack, v0 prompt, runner, both full transcripts, and the scored read-out (`readout.md`).\n\nHeadline findings (details and scores in the read-out, gist on the ticket):\n\n- The bare baseline interviews far better than the positioning assumed — objectives-first, unwritten-rules probing, refusal to invent values, and an unprompted assumptions register. The differentiation story must rest on machinery, and now has evidence to rest on.\n- Neither condition can end the engagement: one novel deliverable-deferral failure, one sophisticated budget-exhaustion. Completion has to be an adjudicated contract.\n- The v0 prompt buys interaction shape, quantile elicitation, live category accounting, conflict-point depth, and penalty-weight co-construction; its residual gaps are the evidence-derived plugin requirements.\n\nAlso on this branch, from the review pass: the typecheck gate now covers `docs/planning/**` scripts (which surfaced and fixed a real narrowing error in the runner), and five off-by-one relative links left by the docs migration are repaired. The review's remaining repo-wide findings are filed as [FE-1399](https://linear.app/hash/issue/FE-1399).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>",
+      "proposedBodySha256": "d83c7fcbbec74341c2a25153d3146f0bd579d0c4f60794b634a3aaf73c472bcf",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "Removed “actually”; the factual baseline claim is unchanged."
+    },
+    {
+      "number": 5,
+      "url": "https://github.com/hashintel/brunch-lite/pull/5",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1364-intermediate-representation",
+      "linkedIssue": "FE-1364",
+      "sourceUpdatedAt": "2026-08-19T14:00:05Z",
+      "sourceTitle": "FE-1364: Define the intermediate representation for process-model elicitation",
+      "sourceTitleSha256": "229ac27a91eab0e70254f9a283f3ef6a9f8d375bbf17fffdb8f7d04d2ac59603",
+      "sourceBodySha256": "e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc",
+      "proposedTitle": "FE-1364: Define the process-model elicitation representation",
+      "oldOuter": "This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.",
+      "proposedOuter": "This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Resolution of the wayfinder ticket: the IR is the set of active captures\nread through the plugin's declared payload type system — no second store;\nthe net is one projection. Layer A (architecture-level definition) is\nconditionally ratified pending worked-examples validation (FE-1397);\nLayer B is the CPS plugin's ten-kind payload design for the truck-fleet\nSeptember case. Adds the IR glossary entry to CONTEXT.md.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "sourceInnerSha256": "5855717a5f072802db5ab6383077122e4599d0435709ea2222b1da1006ba5d89",
+      "innerRecord": "Resolution of the wayfinder ticket: the IR is the set of active captures\nread through the plugin's declared payload type system — no second store;\nthe net is one projection. Layer A (architecture-level definition) is\nconditionally ratified pending worked-examples validation (FE-1397);\nLayer B is the CPS plugin's ten-kind payload design for the truck-fleet\nSeptember case. Adds the IR glossary entry to CONTEXT.md.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "innerSha256": "5855717a5f072802db5ab6383077122e4599d0435709ea2222b1da1006ba5d89",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.\n\n<details><summary>🏗️ Agent notes</summary>\n\nResolution of the wayfinder ticket: the IR is the set of active captures\nread through the plugin's declared payload type system — no second store;\nthe net is one projection. Layer A (architecture-level definition) is\nconditionally ratified pending worked-examples validation (FE-1397);\nLayer B is the CPS plugin's ten-kind payload design for the truck-fleet\nSeptember case. Adds the IR glossary entry to CONTEXT.md.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+      "proposedBodySha256": "e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 4,
+      "url": "https://github.com/hashintel/brunch-lite/pull/4",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1388-scaffold-workspace",
+      "linkedIssue": "FE-1388",
+      "sourceUpdatedAt": "2026-08-19T14:00:04Z",
+      "sourceTitle": "FE-1388: Scaffold the Bun workspace and prove the CI smoke",
+      "sourceTitleSha256": "d1e15580b5ebf90f1be401019c3b33876f59f9aabe23a0424ee5b0688b15a628",
+      "sourceBodySha256": "b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d",
+      "proposedTitle": "FE-1388: Create the Bun workspace and enforce dependency boundaries",
+      "oldOuter": "The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.",
+      "proposedOuter": "The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "FE-1388: Scaffold the Bun workspace and prove the CI smoke\n\nThe repo held planning documents and no code. This lands the package\ntopology of spec §12.2 with its dependency direction enforced from the\nfirst commit rather than retrofitted later, so every later slice arrives\ninto a structure that already refuses the wrong import.\n\nPackages: core (plugin SDK as its export surface, with a core/testing\nsubpath), binding-flue, plugin-gherkin, and a dev app owning the agent\nmodule, the mount, and the conversation store.\n\nThe direction is enforced twice over. Bun's isolated linker gives each\npackage only what it declares, so plugin-gherkin cannot resolve Flue or\nthe binding even if someone writes the import; test/boundaries.test.ts\nasserts that property still holds, alongside the declared-dependency and\nsource-import checks, so a hoisted node_modules could not quietly restore\nevery forbidden path.\n\nTwo recorded Flue constraints needed opposite treatment. A computed\nagentName already fails the build loudly. A 'use agent' directive that is\nnot the file's first statement does NOT: the build stays green and the\nmodule simply stops being an agent, which nothing would notice until a\nconversation failed to start. That one is the load-bearing check in the\nboundary suite.\n\nNothing here ratifies the SDK export surface. Spec §13's two-targets rule\nkeeps the plugin contract unfrozen until the hard target has stressed it,\nso the plugin descriptor carries identity only and the ask tool fixes its\nname and schema seam while its behaviour waits for FE-1389.\n\nThe product name stays provisional in one constant, and the tool prefix\nderives from it — the name-fog costs one edit rather than a rename.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\nFE-1388: Close the review findings — make the gates able to fail\n\nReview found that three of the guards this ticket added could not\nactually go red, which is the same failure mode as a green build that\ncompiled nothing.\n\n- The CI lint step was decorative. oxlint reports its default rules at\n  warning severity and exits 0 for them, so `oxlint .` passed whatever\n  landed; it now runs with --deny-warnings, and a test asserts that.\n- The boundary suite was never typechecked: the root tsconfig included\n  every package's src and test but not the repo-root test/ directory, so\n  a type error in the file that enforces the architecture shipped green.\n- sourceFiles() scanned src/ only and returned [] for anything else, so a\n  package laid out differently would pass every file-level invariant\n  vacuously. The scan now covers the whole package directory, and a test\n  asserts each package was actually scanned.\n\nAlso honest now: the dev app's / route no longer serves a page whose only\nscript 404s after a build. @flue/vite builds the server environment\nalone, so there is no client bundle to serve; the built server says so\nand vite build earns its CI place by compiling the agent module.\n\nSmaller: REPO_ROOT resolves through fileURLToPath rather than a\npercent-encoded URL.pathname; a workspace directory missing a manifest\nreports that rather than crashing the suite with ENOENT; bunfig.toml pins\nthe isolated linker that makes the dependency direction physical; and the\nfour per-package tsconfigs were referenced by nothing, so they are gone\nrather than left to drift.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>",
+      "sourceInnerSha256": "a64a1d8ff07ec6eb8ddff05773cfae355166251c53888725f2272d729eccd4ab",
+      "innerRecord": "FE-1388: Scaffold the Bun workspace and prove the CI smoke\n\nThe repo held planning documents and no code. This lands the package\ntopology of spec §12.2 with its dependency direction enforced from the\nfirst commit rather than retrofitted later, so every later slice arrives\ninto a structure that already refuses the wrong import.\n\nPackages: core (plugin SDK as its export surface, with a core/testing\nsubpath), binding-flue, plugin-gherkin, and a dev app owning the agent\nmodule, the mount, and the conversation store.\n\nThe direction is enforced twice over. Bun's isolated linker gives each\npackage only what it declares, so plugin-gherkin cannot resolve Flue or\nthe binding even if someone writes the import; test/boundaries.test.ts\nasserts that property still holds, alongside the declared-dependency and\nsource-import checks, so a hoisted node_modules could not quietly restore\nevery forbidden path.\n\nTwo recorded Flue constraints needed opposite treatment. A computed\nagentName already fails the build loudly. A 'use agent' directive that is\nnot the file's first statement does NOT: the build stays green and the\nmodule simply stops being an agent, which nothing would notice until a\nconversation failed to start. That one is the load-bearing check in the\nboundary suite.\n\nNothing here ratifies the SDK export surface. Spec §13's two-targets rule\nkeeps the plugin contract unfrozen until the hard target has stressed it,\nso the plugin descriptor carries identity only and the ask tool fixes its\nname and schema seam while its behaviour waits for FE-1389.\n\nThe product name stays provisional in one constant, and the tool prefix\nderives from it — the name-fog costs one edit rather than a rename.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\nFE-1388: Close the review findings — make the gates able to fail\n\nReview found that three of the guards this ticket added could not\nactually go red, which is the same failure mode as a green build that\ncompiled nothing.\n\n- The CI lint step was decorative. oxlint reports its default rules at\n  warning severity and exits 0 for them, so `oxlint .` passed whatever\n  landed; it now runs with --deny-warnings, and a test asserts that.\n- The boundary suite was never typechecked: the root tsconfig included\n  every package's src and test but not the repo-root test/ directory, so\n  a type error in the file that enforces the architecture shipped green.\n- sourceFiles() scanned src/ only and returned [] for anything else, so a\n  package laid out differently would pass every file-level invariant\n  vacuously. The scan now covers the whole package directory, and a test\n  asserts each package was actually scanned.\n\nAlso honest now: the dev app's / route no longer serves a page whose only\nscript 404s after a build. @flue/vite builds the server environment\nalone, so there is no client bundle to serve; the built server says so\nand vite build earns its CI place by compiling the agent module.\n\nSmaller: REPO_ROOT resolves through fileURLToPath rather than a\npercent-encoded URL.pathname; a workspace directory missing a manifest\nreports that rather than crashing the suite with ENOENT; bunfig.toml pins\nthe isolated linker that makes the dependency direction physical; and the\nfour per-package tsconfigs were referenced by nothing, so they are gone\nrather than left to drift.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>",
+      "innerSha256": "a64a1d8ff07ec6eb8ddff05773cfae355166251c53888725f2272d729eccd4ab",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1388: Scaffold the Bun workspace and prove the CI smoke\n\nThe repo held planning documents and no code. This lands the package\ntopology of spec §12.2 with its dependency direction enforced from the\nfirst commit rather than retrofitted later, so every later slice arrives\ninto a structure that already refuses the wrong import.\n\nPackages: core (plugin SDK as its export surface, with a core/testing\nsubpath), binding-flue, plugin-gherkin, and a dev app owning the agent\nmodule, the mount, and the conversation store.\n\nThe direction is enforced twice over. Bun's isolated linker gives each\npackage only what it declares, so plugin-gherkin cannot resolve Flue or\nthe binding even if someone writes the import; test/boundaries.test.ts\nasserts that property still holds, alongside the declared-dependency and\nsource-import checks, so a hoisted node_modules could not quietly restore\nevery forbidden path.\n\nTwo recorded Flue constraints needed opposite treatment. A computed\nagentName already fails the build loudly. A 'use agent' directive that is\nnot the file's first statement does NOT: the build stays green and the\nmodule simply stops being an agent, which nothing would notice until a\nconversation failed to start. That one is the load-bearing check in the\nboundary suite.\n\nNothing here ratifies the SDK export surface. Spec §13's two-targets rule\nkeeps the plugin contract unfrozen until the hard target has stressed it,\nso the plugin descriptor carries identity only and the ask tool fixes its\nname and schema seam while its behaviour waits for FE-1389.\n\nThe product name stays provisional in one constant, and the tool prefix\nderives from it — the name-fog costs one edit rather than a rename.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\nFE-1388: Close the review findings — make the gates able to fail\n\nReview found that three of the guards this ticket added could not\nactually go red, which is the same failure mode as a green build that\ncompiled nothing.\n\n- The CI lint step was decorative. oxlint reports its default rules at\n  warning severity and exits 0 for them, so `oxlint .` passed whatever\n  landed; it now runs with --deny-warnings, and a test asserts that.\n- The boundary suite was never typechecked: the root tsconfig included\n  every package's src and test but not the repo-root test/ directory, so\n  a type error in the file that enforces the architecture shipped green.\n- sourceFiles() scanned src/ only and returned [] for anything else, so a\n  package laid out differently would pass every file-level invariant\n  vacuously. The scan now covers the whole package directory, and a test\n  asserts each package was actually scanned.\n\nAlso honest now: the dev app's / route no longer serves a page whose only\nscript 404s after a build. @flue/vite builds the server environment\nalone, so there is no client bundle to serve; the built server says so\nand vite build earns its CI place by compiling the agent module.\n\nSmaller: REPO_ROOT resolves through fileURLToPath rather than a\npercent-encoded URL.pathname; a workspace directory missing a manifest\nreports that rather than crashing the suite with ENOENT; bunfig.toml pins\nthe isolated linker that makes the dependency direction physical; and the\nfour per-package tsconfigs were referenced by nothing, so they are gone\nrather than left to drift.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\n</details>\n",
+      "proposedBodySha256": "b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 3,
+      "url": "https://github.com/hashintel/brunch-lite/pull/3",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1363-reference-use-case",
+      "linkedIssue": "FE-1363",
+      "sourceUpdatedAt": "2026-08-19T14:00:02Z",
+      "sourceTitle": "FE-1363: Choose the reference use case; settle the SDCPN-showcase criterion",
+      "sourceTitleSha256": "479fc988f738df20272d535d4cdec59affba9e2c782f716ba8b2c1077966ece0",
+      "sourceBodySha256": "c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00",
+      "proposedTitle": "FE-1363: Choose the demo use case and modelling criteria",
+      "oldOuter": "This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.",
+      "proposedOuter": "This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Glossary: revision story, situation pack, answer key — including the\npack/IR information-wall invariant.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "sourceInnerSha256": "61d4a1544d743147646d62c9ae8c4bfb0d70cfa15585c6348c8025e2ef892f27",
+      "innerRecord": "Glossary: revision story, situation pack, answer key — including the\npack/IR information-wall invariant.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "innerSha256": "61d4a1544d743147646d62c9ae8c4bfb0d70cfa15585c6348c8025e2ef892f27",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.\n\n<details><summary>🏗️ Agent notes</summary>\n\nGlossary: revision story, situation pack, answer key — including the\npack/IR information-wall invariant.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+      "proposedBodySha256": "c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 2,
+      "url": "https://github.com/hashintel/brunch-lite/pull/2",
+      "state": "OPEN",
+      "headRefName": "ln/fe-1362-demo-vehicle",
+      "linkedIssue": "FE-1362",
+      "sourceUpdatedAt": "2026-08-19T14:00:01Z",
+      "sourceTitle": "FE-1362: Decide the September demo vehicle",
+      "sourceTitleSha256": "213035e657b4ee4135ccdf4f4781e3b7a94d4a42d404ced75c5f821df9c4b371",
+      "sourceBodySha256": "def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce",
+      "proposedTitle": "FE-1362: Decide the September demo architecture",
+      "oldOuter": "This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.",
+      "proposedOuter": "This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.",
+      "extractionMethod": "single canonical wrapper extracted",
+      "sourceInnerRecord": "Recommendation doc (demo shell + artifact boundary) with evidence for the\n18 Aug integration discussion; planning tree migrated .scratch/ -> docs/planning/\nwith INDEX; agent docs gained issue-writing (contract/execution-record, voice\nand authority) and git-workflow (Graphite stacks, branch per Linear issue);\ndocumentation protocol gained the untracked drafts/ convention; CONTEXT.md\ngained Demo shell and Artifact boundary; inbox ingest of SDCPN/SAILS/voice/\ntranscript arrivals.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "sourceInnerSha256": "9ea766c6ed1b481260e6cdfa69d077f14aa6f9044c104f1625f69be708cf525d",
+      "innerRecord": "Recommendation doc (demo shell + artifact boundary) with evidence for the\n18 Aug integration discussion; planning tree migrated .scratch/ -> docs/planning/\nwith INDEX; agent docs gained issue-writing (contract/execution-record, voice\nand authority) and git-workflow (Graphite stacks, branch per Linear issue);\ndocumentation protocol gained the untracked drafts/ convention; CONTEXT.md\ngained Demo shell and Artifact boundary; inbox ingest of SDCPN/SAILS/voice/\ntranscript arrivals.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>",
+      "innerSha256": "9ea766c6ed1b481260e6cdfa69d077f14aa6f9044c104f1625f69be708cf525d",
+      "normalizationNotes": "None; the canonical body and inner record are preserved byte-for-byte.",
+      "proposedBody": "This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.\n\n<details><summary>🏗️ Agent notes</summary>\n\nRecommendation doc (demo shell + artifact boundary) with evidence for the\n18 Aug integration discussion; planning tree migrated .scratch/ -> docs/planning/\nwith INDEX; agent docs gained issue-writing (contract/execution-record, voice\nand authority) and git-workflow (Graphite stacks, branch per Linear issue);\ndocumentation protocol gained the untracked drafts/ convention; CONTEXT.md\ngained Demo shell and Artifact boundary; inbox ingest of SDCPN/SAILS/voice/\ntranscript arrivals.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+      "proposedBodySha256": "def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce",
+      "bodyChanged": false,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The existing outer meets the house style; only the title changes."
+    },
+    {
+      "number": 1,
+      "url": "https://github.com/hashintel/brunch-lite/pull/1",
+      "state": "MERGED",
+      "headRefName": "docs/product-description",
+      "linkedIssue": "FE-1374",
+      "sourceUpdatedAt": "2026-08-19T13:59:58Z",
+      "sourceTitle": "FE-1374: Assemble the spec",
+      "sourceTitleSha256": "2349400d04eb80fe6d4f1253ea64eecc37cc01df5cc71141a92dbc1839396dbc",
+      "sourceBodySha256": "b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51",
+      "proposedTitle": "FE-1374: Assemble the elicitation harness specification",
+      "oldOuter": "",
+      "proposedOuter": "This branch assembles the elicitation harness specification and its companion product descriptions. It also records the second review round and the resulting changes to conversation history, absence states, evidence navigation, and reusable strategies.",
+      "extractionMethod": "whole source body treated as authoritative inner record and wrapped once",
+      "sourceInnerRecord": "Follow-through on the assembled elicitation-kernel spec (FE-1374; branch predates the one-branch-per-issue convention, so the range holds the spec's companion artifacts and its second review round):\n\n- **STE product description** (`product-description.md`) — what the product does in ASD-STE100 Simplified Technical English, twelve sections, with a technical-name table mapping product words back to spec vocabulary.\n- **Plain-prose product description** (`product-description-plain.md`) — the same ground in Google/GOV.UK plain-language style.\n- **Spec review round 2** folded into `spec.md` (+ glossary touch-ups in `CONTEXT.md`): session-log archive (archive-on-read, §9.6), `declined`/`deferred` absence states, pointer navigation for evidence spans, and the harness-shipped generic strategy quiver (§11.5).\n\nPaths are `.scratch/elicitation-kernel/…` as of this range; the stack above migrates `.scratch/` → `docs/planning/`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n",
+      "sourceInnerSha256": "b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51",
+      "innerRecord": "Follow-through on the assembled elicitation-kernel spec (FE-1374; branch predates the one-branch-per-issue convention, so the range holds the spec's companion artifacts and its second review round):\n\n- **STE product description** (`product-description.md`) — what the product does in ASD-STE100 Simplified Technical English, twelve sections, with a technical-name table mapping product words back to spec vocabulary.\n- **Plain-prose product description** (`product-description-plain.md`) — the same ground in Google/GOV.UK plain-language style.\n- **Spec review round 2** folded into `spec.md` (+ glossary touch-ups in `CONTEXT.md`): session-log archive (archive-on-read, §9.6), `declined`/`deferred` absence states, pointer navigation for evidence spans, and the harness-shipped generic strategy quiver (§11.5).\n\nPaths are `.scratch/elicitation-kernel/…` as of this range; the stack above migrates `.scratch/` → `docs/planning/`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n",
+      "innerSha256": "b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51",
+      "normalizationNotes": "Added one canonical Agent-notes wrapper around the unchanged source body.",
+      "proposedBody": "This branch assembles the elicitation harness specification and its companion product descriptions. It also records the second review round and the resulting changes to conversation history, absence states, evidence navigation, and reusable strategies.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFollow-through on the assembled elicitation-kernel spec (FE-1374; branch predates the one-branch-per-issue convention, so the range holds the spec's companion artifacts and its second review round):\n\n- **STE product description** (`product-description.md`) — what the product does in ASD-STE100 Simplified Technical English, twelve sections, with a technical-name table mapping product words back to spec vocabulary.\n- **Plain-prose product description** (`product-description-plain.md`) — the same ground in Google/GOV.UK plain-language style.\n- **Spec review round 2** folded into `spec.md` (+ glossary touch-ups in `CONTEXT.md`): session-log archive (archive-on-read, §9.6), `declined`/`deferred` absence states, pointer navigation for evidence spans, and the harness-shipped generic strategy quiver (§11.5).\n\nPaths are `.scratch/elicitation-kernel/…` as of this range; the stack above migrates `.scratch/` → `docs/planning/`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n\n</details>",
+      "proposedBodySha256": "0979c93127052da2249f61275c1bdc3d9b77744bb39473f37b45268c9ba56e27",
+      "bodyChanged": true,
+      "titleChanged": true,
+      "ambiguity": null,
+      "notes": "The source had no Agent-notes wrapper, as specified for this migration."
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-source.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-source.json
new file mode 100644
index 00000000000..4eef66bf14a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/github-source.json
@@ -0,0 +1,477 @@
+[
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1451-fold-protocol",
+    "body": "## Stack Context\n\nFE-1433 sequences the Petrinaut integration from the proven Flue suspension and AI SDK seams. This branch is the ask suspend/return slice, stacked on FE-1436's durable transport; its panel-side counterpart is the FE-1448 host interactive-tool API in hashintel/hash (PR hashintel/hash#9249).\n\n## What?\n\n- `transport-aisdk` holds a `brunch_ask` open on the wire: awaiting client tool with a stable `toolCallId`, the harness's minted affordance output withheld\n- the tool-result follow-up POST — previously refused wholesale — is admitted exactly when it carries the pending ask's correlated `{ answer }` submission\n- `@brunch/core` gains the pure protocol: `pendingAskAffordanceId`, `decideAskReplyAdmission`, and the `AskSubmission` submitted-output contract\n- the application's new `askReply` seam admits against durable Flue history before any dispatch, then resumes the conversation as a fresh user dispatch that the binding binds as the user-affordance reply\n- opt-in inspection gains `ask-await`, `ask-reply-admitted`, `ask-reply-refused`\n\n## Why?\n\nFE-1449 requires provenance to settle at the wire boundary: a human answer travels tool-output-shaped but is not a machine tool result. Only the currently pending ask's correlated submission may become user evidence — stale/duplicate submissions get `409 ask_not_pending`, forged ids `409 ask_mismatch`, malformed submissions `400 invalid_ask_submission`, and machine-only follow-ups (mutation outputs, diagnostics) keep FE-1436's `422`. Concurrent duplicates collapse at the substrate via the `{conversationId}:ask:{toolCallId}` idempotency key.\n\nRemaining for full FE-1449 acceptance: petrinaut-website registers the ask component through the FE-1448 `aiAssistant` API (hash-side branch); the implementation record names it.\n\n## Verification\n\n- `bun run smoke` — lint, fmt, typecheck, 163 tests\n- `bun run build`\n- wire contract tests for the translated ask part and each refusal class\n- end-to-end run over the committed application route: the actual elicitor asks, the correlated answer resumes the same Flue conversation, a replayed duplicate is refused before dispatch\n",
+    "closedAt": null,
+    "createdAt": "2026-08-19T13:59:43Z",
+    "headRefName": "ln/fe-1449-structured-ask",
+    "mergedAt": null,
+    "number": 25,
+    "state": "OPEN",
+    "title": "FE-1449: A structured brunch question suspends and resumes visibly in Petrinaut",
+    "updatedAt": "2026-08-20T08:46:31Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/25"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1435-aisdk-panel-spike",
+    "body": "The spikes proved the required seams separately, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Stack Context\n\nFE-1433 sequences a durable Petrinaut integration from the proven Flue suspension and AI SDK panel seams. This branch is the first production-intent transport slice, stacked on FE-1435.\n\n## What?\n\n- adds a substrate-neutral harness reply protocol and `transport-aisdk` encoder\n- mounts the actual elicitor behind Petrinaut's `/api/chat` contract\n- commits the local Petrinaut launcher, opt-in JSONL inspector, and wire fixtures\n- validates external chat requests with Valibot and keeps transport diagnostics outside user evidence\n- records one truthful terminal sequence for completed, failed, and aborted turns\n\n## Why?\n\nLater structured-ask and editor-tool slices need a durable, inspectable server path rather than the spike's disposable replay harness. The committed application-route golden now crosses the real application, Flue projector, and transport while normalizing only dynamic identifiers and delta segmentation.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` — 152 passed, 0 failed\n- `bun run build`\n- independent standards/spec review plus focused remediation closure review\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-19T12:43:42Z",
+    "headRefName": "ln/fe-1436-transport-aisdk",
+    "mergedAt": null,
+    "number": 24,
+    "state": "OPEN",
+    "title": "FE-1436: The elicitor answers conversation turns in Petrinaut's real chat panel",
+    "updatedAt": "2026-08-19T14:00:38Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/24"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1436-transport-aisdk",
+    "body": "Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.\n\n<details><summary>🏗️ Agent notes</summary>\n\nAgent-written issues, comments, and PR descriptions had become hard to scan. This PR gives issues compact, active-verb task titles and a human-owned plain-language summary, with agent working detail in a collapsed `🏗️ Agent notes` section. It applies the same rules to [FE-1451](https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan), which serves as a live example.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## What changed\n\n- `docs/agents/issue-writing.md` defines compact task-shaped titles, the collapsed section, visible comments limited to one decision or change, and vocabulary rules by audience.\n- The human driving the work owns the visible summary. An agent fetches and preserves that text before writing on the person's behalf; `🏗️ Agent notes` remains agent-maintained.\n- Issues quote and link user, stakeholder, or teammate feedback when the issue's audience can read the source.\n- The org technical-writing rules apply to all prose. The earlier draft applied the word list only to visible summaries.\n- The coined name \"the fold\" was removed rather than added to the glossary. The house word list asks writers to use \"collapsed section,\" and formalizing the coined term would have preserved the conflict.\n- `docs/agents/issue-tracker.md` records the safe raw-description edit process and the shorter project-update format.\n- `AGENTS.md`, `docs/INDEX.md`, and `docs/planning/_shared/CONVERGENCE.md` point to the current rules and state.\n\n## Verification\n\n- `bun run smoke`: 138 tests passed.\n- `bun run build`: passed.\n- Focused document-index and formatting checks passed after the final wording changes.\n- Linear round-trip: FE-1451 retains its human-owned summary and collapsed `🏗️ Agent notes` after update and read-back.\n\n## Arc close\n\n- Inbox sweep: clean.\n- INDEX pass: the CONVERGENCE digest matches the seventh evaluation.\n- CONVERGENCE re-evaluation: FE-1451 changes reporting and does not change the delivery order.\n- Registry audit: FE-1451 is a child of FE-1401; this branch introduces no orphan.\n- Tense repair: the living record says the rules are implemented on this branch.\n- Plain-language review: the required forked reviewer could not start because the subagent service failed twice. A manual strain read found and repaired the coined term, the partial application of the house word list, and the unsupported claim that an audit already checks the label bytes.\n\n</details>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-19T12:19:45Z",
+    "headRefName": "ln/fe-1451-fold-protocol",
+    "mergedAt": null,
+    "number": 23,
+    "state": "OPEN",
+    "title": "FE-1451: Keep issues, comments, and PRs easy to scan",
+    "updatedAt": "2026-08-19T14:00:37Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/23"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1434-suspension-spike",
+    "body": "The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production slice builds on it.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Outcome\n\nProves that harness-level parts translated to AI SDK v6 UI-message-stream frames can drive Petrinaut's real, unmodified chat panel at the pinned dependency versions.\n\nThe live panel rendered reasoning, text, and a provider-executed server tool; executed two client tools against the editor; posted both outputs together in one automatic follow-up; and added diagnostics context through its existing transport decorator. The complete two POST bodies and two SSE streams are frozen as fixtures with semantic golden tests.\n\nThe external `hashintel/hash` checkout remained clean at `1046b5c881cd00cf205b4895348b022934d66b4a`; no prototype source was retained.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (142 tests)\n- `bun run build`\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-19T09:55:29Z",
+    "headRefName": "ln/fe-1435-aisdk-panel-spike",
+    "mergedAt": null,
+    "number": 22,
+    "state": "OPEN",
+    "title": "FE-1435: Spike: does a harness-driven stream drive Petrinaut's real chat panel?",
+    "updatedAt": "2026-08-19T14:00:35Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/22"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1433-petrinaut-integration-spec",
+    "body": "The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## Outcome\n\nProves that Flue 2.0.3 can terminate with a batched client-tool interaction pending and resume through one later non-user `signal` dispatch with per-session state and every tool-call ID intact.\n\nThe durable verdict selects a batch-as-pending-slot variant. It records 3-result and 100-result evidence, two dispatches and two model turns in both cases, rejection of native `tool-result` admission, non-user capture-store refusal, and the remaining retry/mismatch obligations for FE-1438.\n\nThe disposable probe was removed after capture; the verdict and normalized JSON evidence retain its source commit and exact command.\n\n## Verification\n\n- `bun run lint`\n- `bun run fmt`\n- `bun run typecheck`\n- `bun test` (138 tests)\n- `bun run build`\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-19T09:55:16Z",
+    "headRefName": "ln/fe-1434-suspension-spike",
+    "mergedAt": null,
+    "number": 21,
+    "state": "OPEN",
+    "title": "FE-1434: Spike: does Flue turn suspension carry batched client-tool round-trips?",
+    "updatedAt": "2026-08-19T14:00:32Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/21"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1432-review-remediation",
+    "body": "The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1433: Record the in-Petrinaut staging decision and its integration spec\n\nThe 2026-08-18 integration meeting overturned the demo-shell recommendation:\nthe September demo stages inside demo.petrinaut.org, with the elicitor as a\nremote server behind the chat panel's host-pluggable aiAssistant transport.\nADR-0004 records the decision (staging, the @hashintel/brunch-agent rename and\nmonorepo import, the apps-are-the-only-meeting-point boundary discipline, the\nui-shell principal, the N3 amendment retiring the demo shell) and supersedes\nrecommendation-demo-vehicle.md.\n\nThe integration spec (FE-1433) specifies the build: one primary test seam (the\nAI SDK UI-message-stream wire contract), the external-tool round-trip protocol\nsharing the ask protocol's suspension floor while differing in cardinality,\nbinding, and provenance (tool outputs are machine entries, never anchorable\nevidence), the transport-aisdk package, the opaque owner key on the storage\nport, and the two gating spikes (Flue suspension carrying batched client-tool\nround-trips; the Pi-to-AI-SDK stream adapter, whose transcript becomes the\nwire seam's golden fixtures).\n\nINDEX updated: recommendation-demo-vehicle marked superseded; both new\ndocuments indexed; docs gate green.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nFE-1433: File the integration delivery graph — sixth cross-map evaluation\n\nThe ds-write-tickets pass over the integration spec published nine execution\ntickets under FE-1433 (FE-1434–FE-1442) with native blocking relations, and\nthis change deposits the coordination record: the sixth evaluation paragraph\n(the sub-graph joins the strategy without displacing the spine; the spikes\njoin the now-band beside FE-1393/FE-1422), the delivery graph itself (mirrored\nin FE-1433's execution record), the FE-1423 re-scope (gates survive the demo\nshell's retirement and now guard the remote elicitor server; auth → FE-1439,\ndeployment → FE-1441), and the N3 watch-item repair (ADR-0004 amended N3, so\nthe living-prototype charter would shape apps/dev or the deployed server, not\nan apps/demo).\n\nThe one fog-sensitive edge is recorded as such: FE-1438 and FE-1395 share the\npending-slot batching ground, held apart by a coordination edge rather than a\nblocker — whichever lands first writes the §7.3/§7.4 amendment.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T16:36:43Z",
+    "headRefName": "ln/fe-1433-petrinaut-integration-spec",
+    "mergedAt": null,
+    "number": 20,
+    "state": "OPEN",
+    "title": "FE-1433: The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server",
+    "updatedAt": "2026-08-19T14:00:30Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/20"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1392-settlement-sweep",
+    "body": "The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1432 executes the 2026-08-18 cross-stack review-remediation queue and closes its capture channel.\n\nWhat this establishes:\n\n- Capture-store command admission and persisted parsing share the same closure rules: one terminal event per issue, pairwise-disjoint open conflicts, and active references for every open conflict.\n- Baseline interviewer and expert truncation survives in checkpoint metadata; partial output stops before downstream model consumption, and expert resume regenerates the incomplete reply.\n- Valibot declarations and imports agree in both directions, while the walking-skeleton oracle reports absent context as `false` instead of throwing.\n- New dependency resolutions observe a seven-day release-age quarantine.\n- All 15 residual review threads were replied to and resolved: 7 fixes, 2 findings owned by FE-1385/FE-1393, and 6 evidence-backed refusals.\n- The three tooling-side graduation proposals remain owned by FE-1401's `ds-induct`/lens-registry lane.\n\nCommits:\n\n- `380411f` — preserve capture-store closure and prove local-store setup\n- `f71aa9e` — retain baseline completion metadata\n- `bb46941` — make capability and walking-skeleton gates honest\n- `2814090` — quarantine fresh dependency releases\n- `74b535c` — settle the remediation ledger\n\nVerification: OxLint, Oxfmt, TypeScript, 138 tests, workspace build, and an independent adversarial review of the capture lifecycle. A live review-thread refresh found zero unresolved FE-1432 threads; the sole repository-wide unresolved thread is on child PR #20 and belongs to FE-1433.\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T16:36:42Z",
+    "headRefName": "ln/fe-1432-review-remediation",
+    "mergedAt": null,
+    "number": 19,
+    "state": "OPEN",
+    "title": "FE-1432: The stack's open review threads are adjudicated: fixed, owned, or refused on the record",
+    "updatedAt": "2026-08-19T14:00:29Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/19"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1391-entry-projection",
+    "body": "This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.\n\n<details><summary>🏗️ Agent notes</summary>\n\nTrigger settlement from the finish hook, extract against the plugin-declared grade floor, refresh archived history adjacent to atomic application, and reopen refused ranges without weakening session-qualified provenance.\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T16:36:40Z",
+    "headRefName": "ln/fe-1392-settlement-sweep",
+    "mergedAt": null,
+    "number": 18,
+    "state": "OPEN",
+    "title": "FE-1392: Settlement trigger and sweep — the first captured statement",
+    "updatedAt": "2026-08-19T14:00:27Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/18"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1422-ask-protocol",
+    "body": "Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.\n\n<details><summary>🏗️ Agent notes</summary>\n\ndocs: settle Flue projection and compaction\n\nRecord the installed @flue/runtime and @flue/sdk 2.0.3 contract and implementation evidence for FE-1391 B1/B2. Correct the archive premise to the materialized history surface with host-owned routing and evolving-message merge semantics. Trace append-only compaction and state ownership, then reshape FE-1386 to one behavioral upgrade pin and reconcile the living ledgers.\n\nfeat: anchor captures to archived Flue history\n\nRead the public materialized history through a host-supplied URL resolver and transport, and co-locate a versioned session log with capture state behind a binding-private archive capability. Archive ordinals preserve the session-plus-range pointer while Flue identities remain provenance and evolving messages retain distinct versions.\n\nReplace caller-supplied spans with quote-only evidence commands resolved atomically against the archive. Pin mounted in-process routing, affordance classification, non-user refusal, legacy provisioning, parse-on-read, and independent pointer retrieval. Keep the real-compaction compatibility pin with FE-1386 and move refresh-before-sweep orchestration to FE-1392.\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T16:36:38Z",
+    "headRefName": "ln/fe-1391-entry-projection",
+    "mergedAt": null,
+    "number": 17,
+    "state": "OPEN",
+    "title": "FE-1391: Durable entry projection, harness-resolved anchoring, and the session-log archive",
+    "updatedAt": "2026-08-19T14:00:26Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/17"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1405-payload-interiors",
+    "body": "The question-and-reply behavior was tied too closely to one runtime binding. This branch moves the portable part into the core so other application surfaces can use the same protocol.\n\n<details><summary>🏗️ Agent notes</summary>\n\nMove affordance minting, the one-live-affordance decision and refusal, reply-binding signal construction, and render-invariant instruction fragments into a pure core module. The Flue binding now translates hooks, state updates, data writes, and turn termination through that protocol instead of owning its decisions.\n\nCharacterization tests pin every extracted value and branch, while the unchanged walking-skeleton integration test continues to prove the real substrate path, duplicate-ask rejection, durable output, reply binding, and absence of instruction wakes.\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T16:36:35Z",
+    "headRefName": "ln/fe-1422-ask-protocol",
+    "mergedAt": null,
+    "number": 16,
+    "state": "OPEN",
+    "title": "FE-1422: The ask protocol is substrate-portable: mechanism moves from the Flue binding into core",
+    "updatedAt": "2026-08-19T14:00:24Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/16"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1424-docs-housekeeping",
+    "body": "The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.\n\n<details><summary>🏗️ Agent notes</summary>\n\nThis branch settles the FE-1405 payload-interiors arc and closes it.\n\n**What it establishes.** The session found that Layer A's definition sentence (\"active captures read through the payload type system\") describes an evidence ledger, not a model of the domain. Two artifacts fix that:\n\n- **ADR-0003 (three-register IR)**: typed assertions (active captures) are folded by a pure, plugin-declared fold into the elicited model — the IR proper — which projections consume without rereading the transcript. All interpretation happens at write time as contestable captures; promotion never refusal; an acceptance oracle (a second projection consumes the model alone) keeps the read path semantics-free. \"No second store\" survives: the model is a derivation, never a persistence surface.\n- **Provisional plugin-contract spec** (`docs/planning/process-model-elicitation/plugin-contract-spec.md`, published as FE-1431): a plugin is two schemas and two small tables — model schema, proposal catalog (typed proposals with interiors from a standard library), fold table (overrides only; rules mostly derive), demand table. Harness machinery is pure functions classified by which declaration each reads. The provisional marker comes off after a full worked pass across three plugin targets (the FE-1397 precedent); the open strains (grade sources, support closure, temporal patterns, sweep-time concentration, the absence-locator envelope pressure) are first-class sections with owning tickets, not folded into the design.\n\nThe capture envelope is untouched — the one confirmed pressure (absence captures carry no locator) is recorded at the FE-1383/FE-1357 seam in CONVERGENCE, not forked around.\n\n**Arc close** (second commit): SDCPN inbox arrival settled to `docs/reference/` with a skeptical digest; INDEX trued; CONVERGENCE re-evaluated with a dated third sequencing pass (the convergence collision now waits only on the build spine reaching FE-1392); registry audit re-parented two orphans (FE-1399/FE-1400 → FE-1383); CONTEXT.md's IR entry rewritten per ADR-0003 and a Grade entry added.\n\nGates: oxlint clean, oxfmt clean, typecheck clean, 100/100 tests, build green.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-18T11:41:51Z",
+    "headRefName": "ln/fe-1405-payload-interiors",
+    "mergedAt": null,
+    "number": 15,
+    "state": "OPEN",
+    "title": "FE-1405: Draft the CPS payload interiors: annotated shapes for the ten kinds, worked from baseline utterances",
+    "updatedAt": "2026-08-19T14:00:22Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/15"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1419-contract-closure",
+    "body": "The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.\n\n<details><summary>🏗️ Agent notes</summary>\n\n## What this establishes\n\nCloses FE-1424. The documentation protocol (`docs/agents/documentation.md`) specified zones and a settle sweep that were never executed; this branch runs it, amends it where practice had outgrown it, and makes the parts that can be mechanical, mechanical. Ratified by Lu 2026-08-17.\n\n**Commit 1 — settle + reshape.** The seven inbox documents settle into `docs/reference/` (the protocol's specified-but-never-created destination). `docs/planning/` splits by kind: cross-effort living documents (`CONVERGENCE`, `topology`, the Flue cheatsheet) into `_shared/`; dated arc records into `legibility-sweep/`. The planning top level now holds only directories, so living-vs-record is structural, not judged. All links re-pathed in both directions (14 files, verified by walking every relative link); Linear descriptions carrying old paths repaired (FE-1357/59/66/70, FE-1419, FE-1422/23).\n\n**Commit 2 — arc-close.** Three protocols each carried an arc-close step in prose with nothing firing them together; `docs/agents/arc-close.md` is now the single triggerable checklist (inbox sweep → INDEX pass → CONVERGENCE re-evaluation → registry audit → tense repair), with a content-free `/arc-close` skill wrapper. `documentation.md` gains the `_shared/` zone, the living-vs-record rule, the flattened drafts convention (`docs/planning/<effort>/drafts/`), and the ephemera-reference convention (issue IDs glossed at first mention; load-bearing only in the tracking layer; tense repair at arc close).\n\n**Commit 3 — the gate.** `test/docs-index.test.ts`: every file under `docs/` covered by an INDEX row, every row resolves, planning top level directories-only, every `docs/agents/` protocol named in `AGENTS.md`. Enumerated live, vacuous-pass guarded, red-proved in both directions per rule. Freshness deliberately stays procedural — mechanizing it would build a dead gate.\n\n## Not done here\n\nOld Linear *comments* citing pre-move paths are left as historical record (descriptions were repaired); git log resolves the moves. Two pre-existing broken links found and left: the never-committed prototype HTML in `elicitation-kernel/issues/11`, and links inside the Amp transcript's embedded skill text (verbatim record, unfixable without corrupting it).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-17T13:12:17Z",
+    "headRefName": "ln/fe-1424-docs-housekeeping",
+    "mergedAt": null,
+    "number": 14,
+    "state": "OPEN",
+    "title": "FE-1424: The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable",
+    "updatedAt": "2026-08-19T14:00:20Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/14"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1401-legibility-sweep",
+    "body": "This branch closes places where the capture store and verification checks promised stronger guarantees than they actually enforced. It aligns the implementation and the checks with the properties the stack relies on.\n\n<details><summary>🏗️ Agent notes</summary>\n\nExecutes the FE-1419 refactor queue (`docs/planning/refactor-queue-2026-08-14.md`) — nine commits that give each contract one owner and make negative results precise, so green gates and successful commands stop claiming more than their implementations support.\n\nVerification layer: known-gap closure becomes an explicit ledger whose entries the proof commit deletes (no more citation-token inference); CI gates match exact declared commands; substrate access in tests is a reviewed inventory asserted as set equality; resolver probes classify only module-not-found as \"no\" and carry positive controls; asset serving accepts the producer's real name space behind property checks and per-segment encoding (closing a latent backslash-traversal path a probe found), translating exactly four absence errnos and propagating everything else.\n\nCapture store: evidence-range ordering, the issue contract, and set-equality resolution accounting each live in one definition enforced at command time and parse time alike; all event write paths deep-copy (the aliasing hole is closed); conflicts open only over two-plus distinct active captures and pin them until a user-cited resolution frees them — jointly, every open conflict is resolvable and stays resolvable, closing the invariant-2 bypass. Commit 9 locks the closure property totally: every command any test accepts round-trips through the persisted parser (an injected fault fails 19 of 21 tests), and refused commands leave the store file byte-identical.\n\nEvery commit was red-proved in both directions and independently reviewed before landing. Known residue, deliberately out of scope for a test-only commit: a `-0` capture value survives the command surface but returns as `0` through JSON — recorded on FE-1419. Fixes four refusal messages to state what was checked rather than what a reader might hope was verified.\n\nAlso carries the FE-1401 remediation-sweep docs that landed during execution: the two-map CONVERGENCE record with seam section, issue glosses, and ordering strategies; the registry rule in issue-tracker.md; the Flue canonical-patterns audit; and the deep-read records.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-17T11:36:20Z",
+    "headRefName": "ln/fe-1419-contract-closure",
+    "mergedAt": null,
+    "number": 13,
+    "state": "OPEN",
+    "title": "FE-1419: Close the seams where the capture store and verification gates claim more than they enforce",
+    "updatedAt": "2026-08-19T14:00:18Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/13"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1390-capture-store",
+    "body": "The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1401: Land the legibility session's renderings, audit, and penciled directions\n\nThree documents promoted from drafts/ by Lu, with their post-move repairs\n(self-descriptions, relative links) and editorial additions:\n\n- ir-design-plain.md — plain-prose rendering of the IR design (same content\n  commitments; original authoritative). The rendering pass doubled as review:\n  seven strain findings on FE-1401, the load-bearing one being the loss\n  report's unresolved unit of loss (capture vs. capture-facet).\n- notes/research-patterns-audit.md — ~30 research imports in 7 families,\n  each with plain explanation, provenance, evidence grade, and where it\n  landed; strain appendix (8 findings, incl. the betting-questions\n  misattribution and the v0-vs-IDEA quantile divergence).\n- notes/penciled-directions-2026-08-14.md — 8 penciled directions with\n  firming actions and marked editorial reflections (schema as forcing\n  function, plugin manifest sketch, mode oscillation, activation probes,\n  incorporation rubric, super-map question, write-time check tiers,\n  per-domain machinery inventory).\n\nINDEX.md gains rows for all three plus two pre-existing gaps: ir-design.md\nand ir-worked-examples.md were never indexed.\n\nSession record: FE-1401 and its accrual comments; new tickets FE-1402–1407.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nprep refactor queue, and flue analysis\n\nSigned-off-by: Lu Nelson <ln@hash.ai>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-14T14:14:56Z",
+    "headRefName": "ln/fe-1401-legibility-sweep",
+    "mergedAt": null,
+    "number": 12,
+    "state": "OPEN",
+    "title": "FE-1401: Resolve the follow-ups from the stack legibility session",
+    "updatedAt": "2026-08-19T14:00:17Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/12"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1389-walking-skeleton",
+    "body": "This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.\n\n<details><summary>🏗️ Agent notes</summary>\n\nAdds the capture store — the durable, session-independent truth of a target-document — as an append-only snapshot of captures, issues, and events, with every status derived at read time instead of stored. Writes go through one pure command function that returns either a whole new snapshot or a typed refusal, so a sweep applies completely or not at all, and the Flue binding implements the storage port over it with a JSON file, tmp-and-rename, and per-path serialized writes. Capture identity is content-keyed with epistemic status excluded, which makes re-sweeps idempotent and forces revised readings through explicit supersession. The session-log-archive half of the storage port (spec §9.6) and write-time verification of evidence pointers are not in this branch, and nothing consumes the store yet.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md` (FE-1401 remediation sweep); the plain rendering with strain report is `docs/planning/process-model-elicitation/capture-store-plain.md`; contract-closure work is queued as FE-1419.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T16:01:17Z",
+    "headRefName": "ln/fe-1390-capture-store",
+    "mergedAt": null,
+    "number": 11,
+    "state": "OPEN",
+    "title": "FE-1390: Capture envelope, storage port, and the local capture store",
+    "updatedAt": "2026-08-19T14:00:15Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/11"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1400-close-silent-gaps",
+    "body": "This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.\n\n<details><summary>🏗️ Agent notes</summary>\n\nThis turns the ask seam into a working turn-suspension protocol: the tool mints a free-text affordance, parks it in the pending-affordance slot, returns it on the tool output part where its identity is durable, and terminates the turn — then the next user dispatch clears the slot and gets bound to that affordance by the harness itself, announced to the model as a signal rather than left to the model's memory. Because the pending question is never interpolated into the instructions, the instruction string cannot change between turns, which is what removes the wasted \"instructions updated\" wake turn the ticket-10 prototype hit once per question. The dev app is the proof: a chat UI plus an integration test that boots the real Flue runtime and the real Hono app in one process, drives them over a fetch shim with a scripted faux provider, and asserts in one shot that the reply binding reached the model, the affordance survived durably, no advisory wake appeared, and a second ask in the same batch was refused.\n\nDeep-read record: `docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md` (FE-1401 remediation sweep); hardening follow-ups filed as FE-1420.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T16:01:14Z",
+    "headRefName": "ln/fe-1389-walking-skeleton",
+    "mergedAt": null,
+    "number": 10,
+    "state": "OPEN",
+    "title": "FE-1389: Walking skeleton — the harness asks a free-text question and binds the reply",
+    "updatedAt": "2026-08-19T14:00:14Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/10"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1397-worked-examples",
+    "body": "This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.\n\n<details><summary>🏗️ Agent notes</summary>\n\nExecutes the FE-1400 bundle: the ten verified findings from the FE-1397 tie-off review, plus the cleanup tail, as small always-green commits. Each strengthened gate was red-proved — the violation it guards against was temporarily introduced and the gate watched go red — before restoring green.\n\n**Docs truth:** the AGENTS.md triage one-liner now matches the triage doc's state/label mapping.\n\n**Test integrity:** build-artifact witnesses are now strings unique to the guarded modules (`createAgentRouter`/`sqlite` both matched bootstrap code regardless of what bundled); the first-statement check reuses the shared directive pattern instead of a literal compare; the workspace walker's source/test partition is total (nested `src/test/` files no longer escape every invariant); the CI-gate check parses the workflow so commented-out or `if: false` gates read as absent; known-gaps predicates require an explicit `closes-gap: <id>` citation in a real test instead of `existsSync` on a guessed path — a stub can't close a gap, a differently-named real closure can. FWIW the citation-token design earned its keep immediately: the first draft accepted any prose mention of the gap id, and a doc comment in this branch's own new test closed a gap.\n\n**Dev app:** the conversation store's default path anchors to the module (`db-path.ts`) instead of the launch directory, with tests for cwd-independence and the set-but-empty env override (which would have opened an anonymous temp database).\n\n**Baseline runner:** the hand-rolled HTTP client is gone in favor of `@anthropic-ai/sdk` (network-error retries, retry-after, cache-token usage in the totals); truncation survives continuation stitching and is reported with the `--continue-final` escape hatch; fence matching tolerates the info-string forms real runs produce, and a delivered run that yields no extractable artifact — or an ambiguous multi-block one — says so loudly. The post-review pass also added an explicit SDK timeout (the doubled retry budget tripped the SDK's 10-minute non-streaming guard), no-clobber guards for fresh/`--resume` runs, and seam-exact stitching.\n\n**Cleanup tail:** assets serve via a `/assets/*` wildcard and hono's MIME table (nested paths now work); CI builds once (root build inside `bun test`'s artifact suite, exercising every package's build script) and caches bun installs; the root build filter is `@brunch/*`; the runner's parallel `expertMessages` array and dead checkpoint field are gone; the boundary suite derives its topology pin from the spec's §12.2 block and its physical-resolution probes from the tree.\n\nTwo review findings deliberately not taken: swapping the hand-rolled asset handler for hono's `serveStatic` middleware (the strict dotfile/extension refusal semantics are pinned by tests and the ticket asked for framework routing + MIME table, both done), and de-obfuscating the composed `MODEL_KEY_NAME` pattern (an exclusion list for pattern-defining files has its own silent-failure mode; the composition predates this branch and is documented in place).\n\nCloses FE-1400.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T13:49:12Z",
+    "headRefName": "ln/fe-1400-close-silent-gaps",
+    "mergedAt": null,
+    "number": 9,
+    "state": "OPEN",
+    "title": "FE-1400: Close the review-found gaps where the gates, dev app, and baseline runner still fail silently",
+    "updatedAt": "2026-08-19T14:00:12Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/9"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1399-fail-loudly",
+    "body": "The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.\n\n<details><summary>🏗️ Agent notes</summary>\n\nDischarges the ratification condition on the generic IR definition (`ir-design.md`, Layer A): speculative payload type systems drafted for Gherkin (thin) and BPMN/process-mining (mid, the kernel spec's named third target), checked property-by-property alongside CPS (Layer B) and the assurance plugin from spec canon.\n\n**New:** `docs/planning/process-model-elicitation/ir-worked-examples.md` — the two drafted payload designs, per-property verdict table, sublimation findings, and the handoff list for plugin-spec authoring.\n\n**Amended:** `ir-design.md` —\n- All five MUST properties survive; property 2 generalized from statement granularity to **evidence granularity** (log-derived `external-lookup` captures have no user statement), property 3 restated operatively (its bite is proportional to domain–format distance; the enforceable content is IR-legitimacy of unconsumed kinds + the honest loss report).\n- Symbolic name references promoted MAY → SHOULD (all four designs use them); the objective-kind pattern generalized to completion-anchor kinds; motif annotations demoted to a named escape hatch (zero uptake); **source-regime** promoted from Layer B to a Layer-A MAY pattern for process-shaped domains.\n- Status: conditionally ratified → **ratified on worked examples**, still provisional until the September harness run.\n\nStacked on `ln/fe-1399-fail-loudly` because `ir-design.md` is not on main yet.\n\nCloses FE-1397.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T12:50:28Z",
+    "headRefName": "ln/fe-1397-worked-examples",
+    "mergedAt": null,
+    "number": 8,
+    "state": "OPEN",
+    "title": "FE-1397: Validate the generic IR definition against worked payload designs (Gherkin, CPS, +1)",
+    "updatedAt": "2026-08-19T14:00:10Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/8"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1361-baseline-control",
+    "body": "Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1399: Make the CI gates and dev app fail loudly where review found they fail silently\n\nThe five verified findings from the FE-1361 review sweep:\n\n- Agent-module detection is statement-anchored (shared in test/workspace.ts,\n  unit-tested), so a comment mentioning 'use agent' no longer turns a file\n  into an agent module — while a misplaced or comment-trailed directive is\n  still detected and failed loudly.\n- workspacePackages() derives its groups from the root manifest's workspaces\n  globs; an unknown group, unreadable glob shape, or missing directory now\n  throws instead of passing every boundary invariant vacuously.\n- toolName() takes the Operation union instead of string, so a misspelled\n  operation is a compile error; a @ts-expect-error test pins the narrowing.\n- The dev app's mount path derives from GherkinElicitor.agentName, and a new\n  boundary test forbids a pinned identity being duplicated as a string\n  literal outside its agent module.\n- The production /assets/:file route serves everything the client build can\n  emit — bytes, not UTF-8; case-folded extensions; content-type map failing\n  open to octet-stream — with the handler extracted to assets.ts and driven\n  as a real Hono route over binary fixtures.\n\nReview fixes folded in: trailing-comment directives still detected,\nidentity scan matches quoted literals only (no comment cry-wolf),\nuppercase extensions serve.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\nsymlink CLAUDE.md from AGENTS.md\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T12:50:26Z",
+    "headRefName": "ln/fe-1399-fail-loudly",
+    "mergedAt": null,
+    "number": 7,
+    "state": "OPEN",
+    "title": "FE-1399: Make the CI gates and dev app fail loudly where review found they fail silently",
+    "updatedAt": "2026-08-19T14:00:08Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/7"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1364-intermediate-representation",
+    "body": "This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is actually needed.\n\n<details><summary>🏗️ Agent notes</summary>\n\nResolves [FE-1361](https://linear.app/hash/issue/FE-1361): the baseline-control experiment — what does one-shot / lightly-prompted AI elicitation already achieve?\n\nTwo conditions ran against the same simulated master scheduler (Production Scheduling testbed case): bare `claude-opus-5`, and the same model armed with the seven-category v0 prompt. Everything lives under `docs/planning/process-model-elicitation/baseline/` — protocol, situation pack, v0 prompt, runner, both full transcripts, and the scored read-out (`readout.md`).\n\nHeadline findings (details and scores in the read-out, gist on the ticket):\n\n- The bare baseline interviews far better than the positioning assumed — objectives-first, unwritten-rules probing, refusal to invent values, and an unprompted assumptions register. The differentiation story must rest on machinery, and now has evidence to rest on.\n- Neither condition can end the engagement: one novel deliverable-deferral failure, one sophisticated budget-exhaustion. Completion has to be an adjudicated contract.\n- The v0 prompt buys interaction shape, quantile elicitation, live category accounting, conflict-point depth, and penalty-weight co-construction; its residual gaps are the evidence-derived plugin requirements.\n\nAlso on this branch, from the review pass: the typecheck gate now covers `docs/planning/**` scripts (which surfaced and fixed a real narrowing error in the runner), and five off-by-one relative links left by the docs migration are repaired. The review's remaining repo-wide findings are filed as [FE-1399](https://linear.app/hash/issue/FE-1399).\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T11:43:51Z",
+    "headRefName": "ln/fe-1361-baseline-control",
+    "mergedAt": null,
+    "number": 6,
+    "state": "OPEN",
+    "title": "FE-1361: Baseline control — what does one-shot AI elicitation already achieve?",
+    "updatedAt": "2026-08-19T14:00:06Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/6"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1388-scaffold-workspace",
+    "body": "This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.\n\n<details><summary>🏗️ Agent notes</summary>\n\nResolution of the wayfinder ticket: the IR is the set of active captures\nread through the plugin's declared payload type system — no second store;\nthe net is one projection. Layer A (architecture-level definition) is\nconditionally ratified pending worked-examples validation (FE-1397);\nLayer B is the CPS plugin's ten-kind payload design for the truck-fleet\nSeptember case. Adds the IR glossary entry to CONTEXT.md.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T09:15:35Z",
+    "headRefName": "ln/fe-1364-intermediate-representation",
+    "mergedAt": null,
+    "number": 5,
+    "state": "OPEN",
+    "title": "FE-1364: Define the intermediate representation for process-model elicitation",
+    "updatedAt": "2026-08-19T14:00:05Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/5"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1363-reference-use-case",
+    "body": "The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.\n\n<details><summary>🏗️ Agent notes</summary>\n\nFE-1388: Scaffold the Bun workspace and prove the CI smoke\n\nThe repo held planning documents and no code. This lands the package\ntopology of spec §12.2 with its dependency direction enforced from the\nfirst commit rather than retrofitted later, so every later slice arrives\ninto a structure that already refuses the wrong import.\n\nPackages: core (plugin SDK as its export surface, with a core/testing\nsubpath), binding-flue, plugin-gherkin, and a dev app owning the agent\nmodule, the mount, and the conversation store.\n\nThe direction is enforced twice over. Bun's isolated linker gives each\npackage only what it declares, so plugin-gherkin cannot resolve Flue or\nthe binding even if someone writes the import; test/boundaries.test.ts\nasserts that property still holds, alongside the declared-dependency and\nsource-import checks, so a hoisted node_modules could not quietly restore\nevery forbidden path.\n\nTwo recorded Flue constraints needed opposite treatment. A computed\nagentName already fails the build loudly. A 'use agent' directive that is\nnot the file's first statement does NOT: the build stays green and the\nmodule simply stops being an agent, which nothing would notice until a\nconversation failed to start. That one is the load-bearing check in the\nboundary suite.\n\nNothing here ratifies the SDK export surface. Spec §13's two-targets rule\nkeeps the plugin contract unfrozen until the hard target has stressed it,\nso the plugin descriptor carries identity only and the ask tool fixes its\nname and schema seam while its behaviour waits for FE-1389.\n\nThe product name stays provisional in one constant, and the tool prefix\nderives from it — the name-fog costs one edit rather than a rename.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\nFE-1388: Close the review findings — make the gates able to fail\n\nReview found that three of the guards this ticket added could not\nactually go red, which is the same failure mode as a green build that\ncompiled nothing.\n\n- The CI lint step was decorative. oxlint reports its default rules at\n  warning severity and exits 0 for them, so `oxlint .` passed whatever\n  landed; it now runs with --deny-warnings, and a test asserts that.\n- The boundary suite was never typechecked: the root tsconfig included\n  every package's src and test but not the repo-root test/ directory, so\n  a type error in the file that enforces the architecture shipped green.\n- sourceFiles() scanned src/ only and returned [] for anything else, so a\n  package laid out differently would pass every file-level invariant\n  vacuously. The scan now covers the whole package directory, and a test\n  asserts each package was actually scanned.\n\nAlso honest now: the dev app's / route no longer serves a page whose only\nscript 404s after a build. @flue/vite builds the server environment\nalone, so there is no client bundle to serve; the built server says so\nand vite build earns its CI place by compiling the agent module.\n\nSmaller: REPO_ROOT resolves through fileURLToPath rather than a\npercent-encoded URL.pathname; a workspace directory missing a manifest\nreports that rather than crashing the suite with ENOENT; bunfig.toml pins\nthe isolated linker that makes the dependency direction physical; and the\nfour per-package tsconfigs were referenced by nothing, so they are gone\nrather than left to drift.\n\nCo-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-13T09:15:33Z",
+    "headRefName": "ln/fe-1388-scaffold-workspace",
+    "mergedAt": null,
+    "number": 4,
+    "state": "OPEN",
+    "title": "FE-1388: Scaffold the Bun workspace and prove the CI smoke",
+    "updatedAt": "2026-08-19T14:00:04Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/4"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "ln/fe-1362-demo-vehicle",
+    "body": "This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.\n\n<details><summary>🏗️ Agent notes</summary>\n\nGlossary: revision story, situation pack, answer key — including the\npack/IR information-wall invariant.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-12T17:09:26Z",
+    "headRefName": "ln/fe-1363-reference-use-case",
+    "mergedAt": null,
+    "number": 3,
+    "state": "OPEN",
+    "title": "FE-1363: Choose the reference use case; settle the SDCPN-showcase criterion",
+    "updatedAt": "2026-08-19T14:00:02Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/3"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "main",
+    "body": "This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.\n\n<details><summary>🏗️ Agent notes</summary>\n\nRecommendation doc (demo shell + artifact boundary) with evidence for the\n18 Aug integration discussion; planning tree migrated .scratch/ -> docs/planning/\nwith INDEX; agent docs gained issue-writing (contract/execution-record, voice\nand authority) and git-workflow (Graphite stacks, branch per Linear issue);\ndocumentation protocol gained the untracked drafts/ convention; CONTEXT.md\ngained Demo shell and Artifact boundary; inbox ingest of SDCPN/SAILS/voice/\ntranscript arrivals.\n\nCo-Authored-By: Claude Fable 5 <noreply@anthropic.com>\n\n</details>\n",
+    "closedAt": null,
+    "createdAt": "2026-08-12T17:09:24Z",
+    "headRefName": "ln/fe-1362-demo-vehicle",
+    "mergedAt": null,
+    "number": 2,
+    "state": "OPEN",
+    "title": "FE-1362: Decide the September demo vehicle",
+    "updatedAt": "2026-08-19T14:00:01Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/2"
+  },
+  {
+    "author": {
+      "id": "MDQ6VXNlcjEyNDI4NjQ=",
+      "is_bot": false,
+      "login": "lunelson",
+      "name": "Lu Nelson"
+    },
+    "baseRefName": "main",
+    "body": "Follow-through on the assembled elicitation-kernel spec (FE-1374; branch predates the one-branch-per-issue convention, so the range holds the spec's companion artifacts and its second review round):\n\n- **STE product description** (`product-description.md`) — what the product does in ASD-STE100 Simplified Technical English, twelve sections, with a technical-name table mapping product words back to spec vocabulary.\n- **Plain-prose product description** (`product-description-plain.md`) — the same ground in Google/GOV.UK plain-language style.\n- **Spec review round 2** folded into `spec.md` (+ glossary touch-ups in `CONTEXT.md`): session-log archive (archive-on-read, §9.6), `declined`/`deferred` absence states, pointer navigation for evidence spans, and the harness-shipped generic strategy quiver (§11.5).\n\nPaths are `.scratch/elicitation-kernel/…` as of this range; the stack above migrates `.scratch/` → `docs/planning/`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n",
+    "closedAt": "2026-08-19T08:52:18Z",
+    "createdAt": "2026-08-10T15:52:03Z",
+    "headRefName": "docs/product-description",
+    "mergedAt": "2026-08-19T08:52:18Z",
+    "number": 1,
+    "state": "MERGED",
+    "title": "FE-1374: Assemble the spec",
+    "updatedAt": "2026-08-19T13:59:58Z",
+    "url": "https://github.com/hashintel/brunch-lite/pull/1"
+  }
+]
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-canonical-target-hashes.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-canonical-target-hashes.json
new file mode 100644
index 00000000000..0d8f3bed57b
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-canonical-target-hashes.json
@@ -0,0 +1,281 @@
+{
+  "format": "linear-canonical-fold-v1",
+  "issues": [
+    {
+      "identifier": "FE-1357",
+      "bodySha256": "af21a19b276419b7f351b3edb6c48bf3f598dd25934f835e971cc7a908d60f98"
+    },
+    {
+      "identifier": "FE-1358",
+      "bodySha256": "08c91e46efd7697eb722cc04373be6680de6591dc6ad4ed9c35f971f6ca55899"
+    },
+    {
+      "identifier": "FE-1359",
+      "bodySha256": "5229603b3d41374e36d31d761c83528f7ba5291963ac84c843d60a138d56652b"
+    },
+    {
+      "identifier": "FE-1360",
+      "bodySha256": "a6d7709d6fad560785f2c4d8d5d4d93731ff5d6c8e2b16dcf2bc384ac5daae19"
+    },
+    {
+      "identifier": "FE-1361",
+      "bodySha256": "5bd4de3670bdb15872c5826c6d053fcf0e4bbc17542313a21640b6732ae941e8"
+    },
+    {
+      "identifier": "FE-1362",
+      "bodySha256": "9576d5d00ff1e5cc3e8d8ee8d61c762e297bb63889aaea2469a7a778418d9993"
+    },
+    {
+      "identifier": "FE-1363",
+      "bodySha256": "4cc749b9cfdeeec3960bba78110fe36874827ca888085991a97f232009e89d97"
+    },
+    {
+      "identifier": "FE-1364",
+      "bodySha256": "454e2287159c78a31d09cbdea9402be4594916e53106026ec42944445d768a24"
+    },
+    {
+      "identifier": "FE-1366",
+      "bodySha256": "d07ec0b6e6bfdb01e9dbcc57de35dbfeeae65c80d5c688a0fb4b0f855c05739d"
+    },
+    {
+      "identifier": "FE-1367",
+      "bodySha256": "0d564e0427b73c79440b31b09c85a11d83bdada98759c0c0571531e1b7eacdc2"
+    },
+    {
+      "identifier": "FE-1368",
+      "bodySha256": "58eac8c7f4da2110cff73432764c20d71576fbedbed167d88a7c0ccaacfe8b70"
+    },
+    {
+      "identifier": "FE-1369",
+      "bodySha256": "f9acc9c49a910e07ea12eee26f5156578029354e5b695d3b6f679744a4d30d3d"
+    },
+    {
+      "identifier": "FE-1370",
+      "bodySha256": "586900fec359fdea19b40355ce70ada6f4dc6cc1a4b318a5266fd04925e9330b"
+    },
+    {
+      "identifier": "FE-1371",
+      "bodySha256": "8e34e41697c46c46a81ea4c5ab48edcb49de55973b2b11732bcf451b8191a17f"
+    },
+    {
+      "identifier": "FE-1372",
+      "bodySha256": "4ceed9ff828af36baeb0d9fe3be38f70f48b89310c8f6eb86afb98ba9ea34d1e"
+    },
+    {
+      "identifier": "FE-1373",
+      "bodySha256": "3427cd321d38c72b7abb00985cdc8eb1d4de70b2b1cf4be1bad6537edf468d03"
+    },
+    {
+      "identifier": "FE-1374",
+      "bodySha256": "cb0436794a3e2c782938939475a1fa2a0b68e3969b1e1ff03eb8fa4306d4abc0"
+    },
+    {
+      "identifier": "FE-1375",
+      "bodySha256": "f1e803bca9e75caf52ea4346c7d8fe2c859523a1de616367c56b1dc58da2d82c"
+    },
+    {
+      "identifier": "FE-1376",
+      "bodySha256": "3a752cf0d3362718f9364083a2469b501e3d5037dbfd8fde747216b4e53e36ec"
+    },
+    {
+      "identifier": "FE-1377",
+      "bodySha256": "fac78c76da54522de3bfa0777b4f048279581c51300c3fc74bcf80548c0d8cba"
+    },
+    {
+      "identifier": "FE-1378",
+      "bodySha256": "77648b3f761ba84c2837ad23b418104e13c2182772006d3e175f63b0066cf065"
+    },
+    {
+      "identifier": "FE-1379",
+      "bodySha256": "3b61f9e6a64f171a18eb0482da780e41dab67f44bfd7c7568acca05f5b39c85c"
+    },
+    {
+      "identifier": "FE-1382",
+      "bodySha256": "dcbee28f52b04684d16de429518666c033f3d5dc2ace992d55b5fe49f5180e7f"
+    },
+    {
+      "identifier": "FE-1383",
+      "bodySha256": "3e7b2d47ea437880f995a53d223fb9380873e02ae5adac83ceafd9d38a6f55cb"
+    },
+    {
+      "identifier": "FE-1384",
+      "bodySha256": "bf5b66bf1a18287a64f583e0f7df1761c1d3e13278ff349998410d5aa425156c"
+    },
+    {
+      "identifier": "FE-1385",
+      "bodySha256": "9a9849fe884a4047d00b0d673f085c3ca401643df2647eb3a9da07e1530991c6"
+    },
+    {
+      "identifier": "FE-1386",
+      "bodySha256": "6714044cb3c8c5e5f5a511ec8339ec15f8d639b78814cd2f430d068265c4443f"
+    },
+    {
+      "identifier": "FE-1387",
+      "bodySha256": "e02aff72a2640dbe03ff1027ec7ec203c67be06796834148e5ff7b577cbfd66a"
+    },
+    {
+      "identifier": "FE-1388",
+      "bodySha256": "09f30e8f38b786bb7d9645dec9b45137931774e2dbe8d033acabf410fac84a7b"
+    },
+    {
+      "identifier": "FE-1389",
+      "bodySha256": "61d11a095b9ca88dfcd274a2d50e1d1e337713abfce81dc75cf29cbd1dad3c80"
+    },
+    {
+      "identifier": "FE-1390",
+      "bodySha256": "6cf8d9572068580ce883faeed54d1ef0ac20d8c60666d32d810c1ff45b56a0ad"
+    },
+    {
+      "identifier": "FE-1391",
+      "bodySha256": "a10cd59d9b58e0903965106cfc42cace3aa01a8366c414a76196c867c46c5683"
+    },
+    {
+      "identifier": "FE-1392",
+      "bodySha256": "71902c740537f89d9251bcdab39d0569d59e2445e9198305e578100b9eafe77d"
+    },
+    {
+      "identifier": "FE-1393",
+      "bodySha256": "9cc7f0cedf11c039e9e6c55f9904fd35340c2cb329d275cdefa77e022695fffe"
+    },
+    {
+      "identifier": "FE-1394",
+      "bodySha256": "3a738a9370e3a1698e0c0d0fd6c966d15e7635f9be498470ac8c8ef37e8297b1"
+    },
+    {
+      "identifier": "FE-1395",
+      "bodySha256": "325fb0866d84fc3386d7dadd18e1fc5140e0f02bc64508826dada5a514c79318"
+    },
+    {
+      "identifier": "FE-1396",
+      "bodySha256": "60a1aa6eb6aacbb63940637435b2ecd8dcbc8d38ab4e8057976301ba89665b59"
+    },
+    {
+      "identifier": "FE-1397",
+      "bodySha256": "728d19cef7d300fa63be05be9ba870290863be42072f08e865cee254f2ec9cbf"
+    },
+    {
+      "identifier": "FE-1399",
+      "bodySha256": "93f520f9c2e08c999d5105fdd07a770dbe8a20b6f8bea6c1995067bcd44cf221"
+    },
+    {
+      "identifier": "FE-1400",
+      "bodySha256": "096ccde21fd800d9c0cbb751b580ad160b998666313b43702030a78056471204"
+    },
+    {
+      "identifier": "FE-1401",
+      "bodySha256": "9e51a20089190e2e34e70e0a4b6faa35b73c8818a11eb8dce1fcd5402c652a20"
+    },
+    {
+      "identifier": "FE-1402",
+      "bodySha256": "b2abd827fdba53895fdccc6d227d8981e7615a103564a8b5955108faf44a49fa"
+    },
+    {
+      "identifier": "FE-1403",
+      "bodySha256": "d4f1804674241c2b523f122d3a510d4730eabaa564dc2a589e63886e48b94240"
+    },
+    {
+      "identifier": "FE-1404",
+      "bodySha256": "0f61b1baed5eb374bd7366fc51344fd21a65f900ce7a4fc273241ef919819b9d"
+    },
+    {
+      "identifier": "FE-1405",
+      "bodySha256": "cf4bbd9f6c5f81cac7a38ae614a1a87011efdf7ca19020c95e7e14f177fc6517"
+    },
+    {
+      "identifier": "FE-1406",
+      "bodySha256": "25af8c35ff021b508612a58d96316c4ec10415e9abed4f2e32e0ccb1fe4100c4"
+    },
+    {
+      "identifier": "FE-1407",
+      "bodySha256": "58bff2297ba46cb4a223217bb178784550174cb0d72b951d0a4b631e97bffe9f"
+    },
+    {
+      "identifier": "FE-1419",
+      "bodySha256": "cb43c18d19933fb4d41b43b6ba6ebf2a0bbb2ee0bf57a1837ea7cb6045bccc8e"
+    },
+    {
+      "identifier": "FE-1420",
+      "bodySha256": "316d82c70192905999f13c7cb3a972faeca36f024e8e87de11ddd7ed3822536f"
+    },
+    {
+      "identifier": "FE-1422",
+      "bodySha256": "e12e25753221ac1b0052d013d53da4cdb98ed42d2b4d2bfbbc0cc3c7725c4029"
+    },
+    {
+      "identifier": "FE-1423",
+      "bodySha256": "7007aa7a3cf88c13c6d8712425b5ef60a16e648f0339551fcafc3cc79ce6cd68"
+    },
+    {
+      "identifier": "FE-1424",
+      "bodySha256": "de8465621d99b972d89f6685ad71a166b68dec925cea24bf093a1b22938feec3"
+    },
+    {
+      "identifier": "FE-1431",
+      "bodySha256": "99871599b344a53e1a214bc3c1079e074d02cca22299fd8af4a6b19c0cb4cfef"
+    },
+    {
+      "identifier": "FE-1432",
+      "bodySha256": "f482b84dd957b5b765c4890f0414c8026a1d973c2dd1fbd0736cf905394057fb"
+    },
+    {
+      "identifier": "FE-1433",
+      "bodySha256": "7ae7b7bace6b2c93833b7c71c5dbf7625d409543b73f451cbeaf52d995e727f0",
+      "outerReplacement": {
+        "from": "demo.petrinaut.org",
+        "to": "[demo.petrinaut.org](<http://demo.petrinaut.org>)"
+      }
+    },
+    {
+      "identifier": "FE-1434",
+      "bodySha256": "f997a348580b20b35f3c843b022988b459306c159d91a012fce1170a2ae80a6f"
+    },
+    {
+      "identifier": "FE-1435",
+      "bodySha256": "14076be75535ff5dbf12d8f68bb41a8292fed3a98bb41f1eb65eea02de3cf524"
+    },
+    {
+      "identifier": "FE-1436",
+      "bodySha256": "8f8e69c34fc30483f729716e87f695f62bfcf63cb383250b0635a809ef478103"
+    },
+    {
+      "identifier": "FE-1437",
+      "bodySha256": "ca9ca144d3aa18223c7141542955d1c39b805323030bce4a25b948a854de5bbf"
+    },
+    {
+      "identifier": "FE-1438",
+      "bodySha256": "47857e1be8bc182f3954b31aac4e7cd10265e00458549bf0bcc47484cf2d6410"
+    },
+    {
+      "identifier": "FE-1439",
+      "bodySha256": "98c4a00fd0ed5d31948361198b25bdc575fd637e9f2553049511f9b5c7ddcc9a"
+    },
+    {
+      "identifier": "FE-1440",
+      "bodySha256": "1770a1db71c34b2e7f1de875342f58b3212cdcd7d8c386653675f87b80f34622",
+      "outerReplacement": {
+        "from": "demo.petrinaut.org",
+        "to": "[demo.petrinaut.org](<http://demo.petrinaut.org>)"
+      }
+    },
+    {
+      "identifier": "FE-1441",
+      "bodySha256": "56da85ce45688f08c3c9bcc75a1feb6c66c33c364d7d956ab864b4dc6ac7e09c"
+    },
+    {
+      "identifier": "FE-1442",
+      "bodySha256": "e9c8f5050856192989f953358829fce6ace7b563471ee3e2661d9f2fd80b050e"
+    },
+    {
+      "identifier": "FE-1448",
+      "bodySha256": "95b45fea18fcca04ab562f60798aed01189c4b3010184d8eb011bd026c701d37"
+    },
+    {
+      "identifier": "FE-1449",
+      "bodySha256": "1981c5120550d60e77ee6d16355b06cf7eeaacaeee9e7e16432422dfcb4606e3"
+    },
+    {
+      "identifier": "FE-1451",
+      "bodySha256": "91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb"
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1366.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1366.json
new file mode 100644
index 00000000000..dd98f2121f1
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1366.json
@@ -0,0 +1,398 @@
+{
+  "root": {
+    "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+    "identifier": "FE-1366"
+  },
+  "generatedAt": "2026-08-20T09:03:27.215678Z",
+  "issueCount": 14,
+  "issues": [
+    {
+      "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+      "identifier": "FE-1366",
+      "url": "https://linear.app/hash/issue/FE-1366/spec-the-elicitation-harness-architecture-archived-wayfinder-map",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": null,
+      "sourceUpdatedAt": "2026-08-19T16:26:24.440Z",
+      "sourceTitle": "Spec the elicitation harness architecture (archived wayfinder map)",
+      "sourceDescriptionSha256": "991af4e8570535aa208f829fd81107ebcf5163186d25837f78746cee7ed77015",
+      "sourceTitleSha256": "3cd9b3e42040c5bd4f19c7ccb505e838266683b4098bb7d02934b03c8df8f6b5",
+      "oldOuter": "This is the completed planning map for the **elicitation harness**: the architecture that generalizes brunch's AI interviewer into a reusable library, able to interview people about different kinds of subject matter through pluggable target definitions — so the same interviewing machinery can produce, say, software specs in one setting and process models in another. Planning finished on 2026-08-10; the outcome is a reviewable specification, in the brunch-lite repo at `docs/planning/elicitation-kernel/spec.md`, alongside a plain-language product description. The build, and the September demo that motivates it, are planned on the successor map FE-1357.\n\nEverything below the divider is a verbatim mirror of the map as it was worked in repo markdown, kept for team visibility.",
+      "proposedTitle": "Document the elicitation harness architecture",
+      "proposedOuter": "This completed planning map defines an elicitation harness that turns the existing AI interviewer into a reusable library for different subject areas. Planning finished on 2026-08-10 and produced `docs/planning/elicitation-kernel/spec.md` plus a plain-language product description. FE-1357 plans the build and the September demo that depends on it.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** This wayfinder map was worked and completed in local markdown (repo `brunch-lite`, `docs/planning/elicitation-kernel/`) before this repo's tracker moved to Linear; it is mirrored here retroactively for team visibility. **Destination reached 2026-08-10** — the assembled spec lives at `docs/planning/elicitation-kernel/spec.md`. Repo-relative links below refer to files in `brunch-lite`. Successor effort: FE-1357 (process-model elicitation).\n\n---\n\n# Map: Elicitation Kernel — carve-out spec\n\nLabel: wayfinder:map\nStatus: closed — destination reached 2026-08-10 (the spec is assembled: [spec.md](<spec.md>))\nCreated: 2026-08-06\n\n## Destination\n\nA reviewable **spec** for a standalone architecture (working name **elicitation kernel**) that generalizes brunch's elicitor into agentic interviewing against pluggable elicitation targets, on the Pi-family substrate, deployable local and remote (Flue-shaped). The spec fixes: the shipping shape (kernel library vs. Flue agent); the kernel / host / plugin contract decomposition (leading hypothesis: the four-contract + pack model from the agentic-elicitation-challenges doc, with persistence plugin-owned in accord with deploy target); the questioning-UX contract (successor to brunch's structured exchanges, critiqued not copied); and a first milestone against two live dev targets (elicit-gherkin + elicit-lean/formal, BPMN named third).\n\n## Notes\n\n* Tracker: local markdown (`docs/agents/issue-tracker.md`); this map and `issues/` are canonical. Ticket `Status:` values: `open` / `claimed` / `resolved`.\n* HITL tickets consult `/grilling` + `/domain-modeling`; research tickets resolve via `/research` subagents, AFK.\n* Plan, don't do: tickets resolve decisions. The spec (ticket 08) is the map's only deliverable.\n* Lexicon (hardened via `/domain-modeling` 2026-08-06, during the Questioning-UX grilling; canonical home: repo `CONTEXT.md`): **substrate** (the agent framework beneath: Pi family, Flue — the charter's \"harness-agnostic core\" non-goal reads \"substrate-agnostic\"), **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI; replaces \"host\"/\"host-interface\"), **harness** (the generic capability layer: mechanism + orchestration — the effort's essence is harness-engineering; replaces \"kernel\" as shell name), **plugin** (target-defining policy; composes packs, receives harness capabilities via a narrow injected context), **pack** (unchanged: ElicitationPack = concept/observation/completion contracts; ProjectionPack = projection contract; \"kernel card\" survives only as the pack-content unit), **target** (split 2026-08-10 by the multi-session resolution: **target-domain** = the artifact family a plugin defines; **target-document** = the durable unit sessions attach to; bare \"target\" legal where context disambiguates), **issue** (typed backpressure to the elicitation controller; two producers since the capture-sweep resolution — plugin ops at the payload level, the harness itself at the envelope level).\n* **Built artifacts as proofs** (ratified 2026-08-06, from the Questioning-UX grilling): prototypes, walking skeletons, and logic-prototypes are the proof path — grilling tickets resolve decisions *provisionally* and name the proof obligations they delegate to prototype tickets, rather than pinning everything through precedent + conversation alone.\n* Primary references: [docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md](<../../docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md>) (turn 1: four contracts, packs, IR) and [docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>) (turn 2: hourglass, proof obligations, invariants, smells, test matrix)\n* Reference codebase (read-only): `../brunch` — esp. `src/agents/runtime/elicitor/`, `src/exchanges/`, `src/agents/skills/`\n* External: [Flue docs](<https://flueframework.com/docs/guide/why-flue/>), [zil-lean](<https://github.com/jagg-ix/zil-lean>)\n\n### Charter decisions (pre-map grilling, 2026-08-06)\n\n* Destination artifact = a spec (not a decision-set alone, not a build)\n* Elicitor-first: the elicitor is this map's spine\n* Greenfield reimplementation; brunch is reference architecture, not shared code\n* Fully decoupled from brunch's September MVP\n* Pi-family substrate committed; harness-agnostic core is a named non-goal\n* Brunch's exchange vocabulary is prior art to critique, not an incumbent to preserve\n* Persistence plugin-owned (in accord with deploy target) is a hypothesis to test, not a decision — **resolved 2026-08-10, flipped** by [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>): storage port harness-defined, binding-implemented, plugin-blind\n* Two live dev targets from day one (forces generalization on both pack axes); BPMN/process-mining named third\n* \"brunch-lite\" is a temporary label; real name is fog\n* **Principle v2** (ratified 2026-08-06, replaces \"behavioral over procedural\" after an evidence pass over `~/Clones/mattpocock/skills` and `../brunch/docs/design/BEHAVIORAL_KERNELS.md`): *procedure for mechanism, anchors for judgment, shapes for output*. Short step sequences with checkable completion criteria where order matters; leading words wherever judgment is required; annotated shapes for everything produced; reference disclosed progressively. Design against sprawl, negation-steering, no-ops, judgment-as-procedure — not against procedure itself. `writing-for-agents` is the pack-authoring standard; kernel cards (BEHAVIORAL_KERNELS.md) are the unit of elicitation guidance.\n\n## Decisions so far\n\n<!-- one line per closed ticket: gist + link -->\n\n* [Assemble the spec](<issues/08-assemble-the-spec.md>) — **the destination: [spec.md](<spec.md>) assembled** (fourteen sections + adjudications appendix) from the full working set in amendment order; all seven pre-pass contradictions adjudicated (storage port binding-implemented with the `db.ts` reconciliation; ops stay pure; status derived never stored, retraction specified; tap-ness as a transport fact via a reserved reply encoding; invariant 1 reconciled with the provenance rule; per-message current-affordance surface with identity on tool output parts; no instruction interpolation + harness-mechanical reply binding, no echo token); ten harness invariants restated in envelope vocabulary; `CONTEXT.md` gained the envelope vocabulary and the kernel-compound ruling (kernel card kept, \"kernel invariants\" → harness invariants); rename propagated over tickets 02/07. **The frontier is empty — this map is complete.** Remaining fog is post-spec and graduates with the build effort.\n* [Walking skeleton: sweep seam on Flue](<issues/13-walking-skeleton-sweep-seam.md>) — **all four capabilities hold on Flue** (two native, two binding-absorbed, none forbidden), closing pre-pass L1–L3: settlement trigger = `useAgentFinish` would-stop seam with same-response signal steering (fires on `terminate:true` suspensions too — the pending guard is load-bearing; needs a re-nudge loop guard); session-entry read = binding-absorbed via the public durable-history projection (no in-process API; `purpose` discriminates provenance) with the load-bearing HITL amendment that **evidence anchoring is harness-resolved — the model cites verbatim user quotes, never entry numbers** (sharpens issue 12's span shape: excerpt primary, pointer derived); on-behalf injection = `kind:'signal'` append/dispatch, projecting structurally non-user so the citable-evidence rule is mechanically enforced (live: unscripted conversational conflict-surfacing off the re-entry briefing; a fact recovered from a *superseded* capture, honestly marked inferred); transactional store = binding-owned entirely (content-keyed idempotence is load-bearing under Flue's at-least-once re-execution). **Amends Shipping shape's capability list to ten entries** (adds would-stop seam, entry-projection read, signal injection, transactional store). New payload-stratum spec examples: absence smuggled as payload; compound payloads make supersession lossy. Prototype on branch `prototype/13-sweep-seam`.\n* [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>) — **durable target-document, transient sessions, sweep as the only bridge**: \"target\" splits into **target-domain** (family a plugin defines) / **target-document** (durable unit sessions attach to — capture store **plus all session logs** as truth, renders strictly derived); session = one substrate conversation (per-session state: log + swept high-water mark + pending-affordance slot), never formally closes; **interleaved-only** concurrency — serialized store, whole-sweep-atomic refusals, the single-hop refusal doubling as the stale-session guard (true concurrency + per-item application → fog); re-entry briefing = injected on-behalf-of-user state messages (Pi convention), advisory-only, with the sharpened provenance rule that **only true user entries are citable evidence**; completion = derived status, never a write gate; **persistence hypothesis flipped** — storage port harness-defined, binding-implemented, plugin-blind (plugin-addressable only via PluginContext-passed methods); evidence spans = pointer + quoted excerpt.\n* [Shipping shape: kernel library vs. Flue agent](<issues/06-shipping-shape.md>) — **harness library in a thin host-authored agent, ratified with the second-binding test**: the spec enumerates a six-item substrate-capability list as the core/binding seam (portability = pressure test, not build target; **binding** entered the glossary); topology = Bun-workspace monorepo in this repo — `packages/core` (plugin SDK is its export surface; `core/testing` subpath), `packages/flue` (binding), `packages/plugin-gherkin` + `packages/plugin-assurance` (renamed from `plugin-proof-obligations` 2026-08-10, per the Formal-verification canon survey's category-error verdict; plugins depend on core *only* — stated spec invariant), `apps/dev`; Valibot throughout; tool prefix from product name (provisionally `bl_*`, never `elicit_*` — strings name identity, not function); workspace-internal, no publishing; testing = **generation-first fixtures over a deterministic replay driver** (kernel invariants as properties, `arbitraryFromSchema`, `fc.commands` conversation fuzzing from the envelope vocabulary, model as offline generator never CI oracle, regenerate-on-declaration-change); dev app chartered with three roles (dev loop / target-gallery demo / diagnostic probe views); one agent per target; milestone one local-only with remote-parity constraints pinned in spec; CI smoke = build + simulation suite.\n* [Walking skeleton: Flue question round-trip](<issues/10-walking-skeleton-flue-roundtrip.md>) — **transport proven, one amendment**: the one-channel multiplex works end-to-end (three forms, markdown floor, string-only replies, absence strip, redirect), but the fixed data channel is a *one-live-affordance slot per message* (update-in-place at every layer — stream, history, reply read-back), so per-ask identity/payload must ride the ask tool's **output part** and the kernel must **reject a second ask per batch** as mechanism; echo token not needed (adjacency + persistent pending state bound every bare-string reply); turn suspension (`terminate: true` + persistent state + fresh dispatch) sufficient, with a wake wart — instruction-interpolated pending state triggers an extra \"instructions updated\" model turn per ask; cancelled/redirected questions read back cleanly via `record_interpretation` evidence. Flue facts: `@flue/vite` needs vite ^8; dev server gives `app.ts` the whole request space (ui is app-served). Prototype on branch `prototype/10-flue-roundtrip`.\n* [Logic-prototype: capture sweep & settlement](<issues/11-logic-prototype-capture-sweep.md>) — **all five capture hypotheses hold** in a working prototype (branch `prototype/11-capture-sweep`; double-clickable demo + headless driver), each sharpened: settlement splits into **trigger vs judgment** (lifecycle-event wiring *not* proven in ticket 10 — misattribution caught by the 2026-08-10 consistency pre-pass; delegated to the sweep-seam walking skeleton, ticket 13); idempotence splits into **mechanical (harness, evidence-anchored capture identity) vs semantic (plugin reconcile)** and is content-based, so re-sweeps repair omissions; absences are **evidence, not agenda** (re-ask runs through plugin validate → issues); single-hop supersession over active heads = the lost-update guard; **two supersession channels** (sweep-time link / issue-time resolution record) with read-time *derived* status suggested (cf. issue 09). Amendments: **two validation strata** (envelope-level harness-owned refusals + advisories / payload-level plugin ops — strengthens smallest-honest-plugin), op cadence = pure orchestration policy (snapshot-purity), **resume-time sweep reconciliation** (unswept tail as computed re-entry fact). Graduated the multi-session fog → ticket 12.\n* [Questioning-UX contract](<issues/05-questioning-ux-contract.md>) — the reframe: **no exchange-pair ontology** — conversation is primary, structured questions are **affordance emissions** committed to session as evidence, capture via idempotent **range-sweeps** on agent-judged, range-level **settlement**; shells renamed **substrate / ui / harness / plugin** (the effort's essence is *harness-engineering*; IoC via narrow injected PluginContext — the ask API is part of it); harness fixes: three baseline shapes + questionnaire chaining, absence interpret-by-default/afford-when-structured, **one multiplexed data channel** with markdown floor (Flue: outbound rich / inbound string-only), interpretation render harness-owned with plugin-optional typed renderer (JSON default), conflicts close only via explicit **resolution records**, no question-budget machinery (economical interviewing = judgment guidance); all shape-level commitments are working hypotheses with proof obligations delegated to the two prototype tickets created here (10, 11); **built-artifacts-as-proofs** ratified into Notes.\n* [Contract decomposition](<issues/04-contract-decomposition.md>) — the load-bearing resolution: **agent-forward hybrid** (agent judgment owns the loop; deterministic mechanism as tools; typed-issue backpressure); **no universal IR** — the kernel owns only a domain-free **capture envelope** (evidence spans, epistemic-status enum, absence states, alternatives, one `supersedes` link) around opaque plugin payloads, no kernel edges or graph (conflicts/equivalence are typed issues, resolved only explicitly); operations tiered `project`+`validate` required / `reconcile` optional / `observe` agent-native, all snapshot-in/deltas-out with typed loss reports; **facts computed, weights judged** dialogue policy (no scoring engine); packs = kernel cards + shapes + validators + shallow schemas + completion contract; smallest-honest-plugin test; five proof obligations + ten kernel invariants + gating tests (reprojection, minimal pairs, black-box authoring) adopted as spec acceptance material; multi-plugin composition, removal, replay, capability negotiation, versioning deferred to fog. Full ownership table in the ticket.\n* [Flue architecture deep-read](<issues/01-flue-architecture-deep-read.md>) — embedding is Flue's grain: ship the kernel as a custom hook (`useElicitation(plugin)` — final name per Shipping shape) + exportable `defineTool`s over a thin host-authored `'use agent'` module; Pi is exposed only at the provider layer (no path to Pi's loop/extensions — brunch-style Pi assumptions don't transfer); durability contract identical local/remote but storage/ownership differ; **no first-class ask-the-user primitive — the kernel must own its turn-suspension protocol** (`terminate: true` tool + persistent state + data part, answer arrives as fresh dispatch); constraints: Valibot at every schema boundary, stable-tool-set cache economics, subagents conversationally sterile, non-React hosts must build on `@flue/sdk`.\n* [Formal-verification canon survey](<issues/09-formal-verification-canon-survey.md>) — align the second target to a **GSN skeleton** (Goal/Strategy/Solution/Assumption/Justification; the one canon built for argued claims about a system) with **Dafny nouns** (`requires`/`ensures`/`invariant`/`lemma`/`assume` transfer; `modifies`/ghost don't) and **Lean sorry-taint semantics**; the headline artifact is a `dafny audit`-style **assumption ledger** (per-claim status becomes a derived label); acyclicity kept as a deliberate restriction with `decreases` as future escape hatch; sell the Datalog closure as taint-propagation, never as an assurance verdict; **\"proof obligations\" is a category error to verification readers — rename the target** (resolved 2026-08-10: the second target is the **assurance argument**, package `plugin-assurance`); Geolog is *not* an ARIA artifact (negative result) but coherent-logic saturation is the validator's genuinely canonical lineage; concrete milestone-one contract sketch (one `Statement` record, four edge kinds, five-stratum status rules) is in the ticket.\n* [Dev-target portfolio confirmation](<issues/07-dev-target-portfolio.md>) — confirmed `elicit-gherkin` + `elicit-proof-obligations` live (BPMN third, full elicit-lean deferred); **hybrid order**: both packs authored before the pack interface freezes, gherkin wires end-to-end first; proof-obligations format = zil-lean's ideas in our own claim-DAG serialization, hewing to existing canon (Dafny leading candidate — grounded by new ticket 09); gherkin milestone-one validation = parse validity + pack-declared step lexicon; surfaced the **behavioral-over-procedural** design principle (routed to Contract decomposition).\n* [Brunch exchange-schema audit](<issues/03-brunch-exchange-schema-audit.md>) — full catalog + three-way classification: **generic** (the `ask` one-terminal-four-shapes primitive, declared continuations that make offer→answer non-forgeable, answered/cancelled/unavailable property-presence union, self-contained terminals, boundary-teaching schemas, no-storage asking agenda + private scratchpad, hash-pinned prompt directives); **generalize-with-changes** (present-then-ask two-step → one `present(form, payload)` with pluggable validators, parent-link instead of enumerated prev/curr/next unions, opaque target-supplied receipts, rubrics declared by the target); **brunch-specific** (review-set node/edge schema, plane vocabulary, `graph_refs`, `map`/`tutorial` skills). Strain marks confirm the \"just a guess\" caution: wire vocabulary outlived tool names, a digest-into-review merge was retracted, doc/code drift on edge categories. 15 inherit/avoid lessons feed tickets 04 and 05.\n* [zil-lean survey](<issues/02-zil-lean-survey.md>) — zil-lean contains **no elicitation** (agent-authored 2-day snapshot; Datalog/Zanzibar-style claim graph in Lean 4 + Clojure) but is a strong existence proof of the kernel's claim-graph layer: evidence-graded assurance lattice with prohibited promotions, full derivation provenance, assumption/lemma/theorem/guarantee vocabulary with derived PROVED/CONDITIONAL/WEAK/BROKEN statuses. **Verdict: full elicit-lean is not dev-sized; the \"elicit-proof-obligations\" slice is** (claim DAG + criticality + evidence refs, validated by acyclicity + Datalog closure — no Lean statements) and beats BPMN as second target on both pack axes; BPMN stays third.\n\n## Not yet specified\n\n* Diagnostic \"exploded view\" harness for HITL prototype sessions — an instrumented walking-skeleton UI with parallel state readout and labeled moving parts (persistent state, pending affordance slot, tool traffic, terminate boundaries, advisory wakes, activation timing) so the human can react to internals, not just the chat surface; surfaced by the user after the ticket-10 walking skeleton, wanted \"at some point\" — **host identified** by the Shipping-shape resolution: the dev app's probe view (role 3 of its charter); graduates with the dev app, post-spec\n* Remote deploy target choice & provisioning — pending an infra-colleagues conversation (2026-08-07); blocks nothing on this map (the spec pins remote-parity constraints without naming the target)\n* Unstructured-ingest crossover at scale — the IR inside the contract-decomposition ticket absorbs the parsing/mapping core; what remains foggy is bulk/brownfield ingest as a first-class mode\n* elicit-to-petri-net as a future plugin — abstract questions (what fits a net; what IR precedes a net) wait until the pack model exists\n* JSONL-vs-YAML storage-format comparison — persistence resolved harness-defined / binding-implemented (multi-session resolution, 2026-08-10), so the format is a binding-internal choice; graduates with the local binding implementation, post-spec\n* Concurrent-session coordination beyond interleaving — simultaneous sweeps against one target-document, per-item partial sweep application, merge machinery; the spec's stance (serialized store + single-hop refusal + re-entry advisory) covers interleaving, and this graduates only if a real concurrent consumer appears\n* The real product name\n* Deferred plugin-ecosystem machinery (from Contract decomposition): simultaneous multi-plugin composition, plugin removal, full replay, capability negotiation, version/migration (spec names the five version axes only)\n\n## Out of scope\n\n* **Executor-standalone** — a different kind of project; the spec only names the elicitor→executor handoff seam\n* **Harness-agnostic core** — every named consumer is Pi-family; revisit only if a non-Pi consumer materializes (would be a fresh effort under a redrawn destination)",
+      "innerSha256": "5dc0886da2a1b3b2373a1e3f0e172b2adb805003a15aa782200015be298fbd56",
+      "proposedBody": "This completed planning map defines an elicitation harness that turns the existing AI interviewer into a reusable library for different subject areas. Planning finished on 2026-08-10 and produced `docs/planning/elicitation-kernel/spec.md` plus a plain-language product description. FE-1357 plans the build and the September demo that depends on it.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** This wayfinder map was worked and completed in local markdown (repo `brunch-lite`, `docs/planning/elicitation-kernel/`) before this repo's tracker moved to Linear; it is mirrored here retroactively for team visibility. **Destination reached 2026-08-10** — the assembled spec lives at `docs/planning/elicitation-kernel/spec.md`. Repo-relative links below refer to files in `brunch-lite`. Successor effort: FE-1357 (process-model elicitation).\n\n---\n\n# Map: Elicitation Kernel — carve-out spec\n\nLabel: wayfinder:map\nStatus: closed — destination reached 2026-08-10 (the spec is assembled: [spec.md](<spec.md>))\nCreated: 2026-08-06\n\n## Destination\n\nA reviewable **spec** for a standalone architecture (working name **elicitation kernel**) that generalizes brunch's elicitor into agentic interviewing against pluggable elicitation targets, on the Pi-family substrate, deployable local and remote (Flue-shaped). The spec fixes: the shipping shape (kernel library vs. Flue agent); the kernel / host / plugin contract decomposition (leading hypothesis: the four-contract + pack model from the agentic-elicitation-challenges doc, with persistence plugin-owned in accord with deploy target); the questioning-UX contract (successor to brunch's structured exchanges, critiqued not copied); and a first milestone against two live dev targets (elicit-gherkin + elicit-lean/formal, BPMN named third).\n\n## Notes\n\n* Tracker: local markdown (`docs/agents/issue-tracker.md`); this map and `issues/` are canonical. Ticket `Status:` values: `open` / `claimed` / `resolved`.\n* HITL tickets consult `/grilling` + `/domain-modeling`; research tickets resolve via `/research` subagents, AFK.\n* Plan, don't do: tickets resolve decisions. The spec (ticket 08) is the map's only deliverable.\n* Lexicon (hardened via `/domain-modeling` 2026-08-06, during the Questioning-UX grilling; canonical home: repo `CONTEXT.md`): **substrate** (the agent framework beneath: Pi family, Flue — the charter's \"harness-agnostic core\" non-goal reads \"substrate-agnostic\"), **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI; replaces \"host\"/\"host-interface\"), **harness** (the generic capability layer: mechanism + orchestration — the effort's essence is harness-engineering; replaces \"kernel\" as shell name), **plugin** (target-defining policy; composes packs, receives harness capabilities via a narrow injected context), **pack** (unchanged: ElicitationPack = concept/observation/completion contracts; ProjectionPack = projection contract; \"kernel card\" survives only as the pack-content unit), **target** (split 2026-08-10 by the multi-session resolution: **target-domain** = the artifact family a plugin defines; **target-document** = the durable unit sessions attach to; bare \"target\" legal where context disambiguates), **issue** (typed backpressure to the elicitation controller; two producers since the capture-sweep resolution — plugin ops at the payload level, the harness itself at the envelope level).\n* **Built artifacts as proofs** (ratified 2026-08-06, from the Questioning-UX grilling): prototypes, walking skeletons, and logic-prototypes are the proof path — grilling tickets resolve decisions *provisionally* and name the proof obligations they delegate to prototype tickets, rather than pinning everything through precedent + conversation alone.\n* Primary references: [docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md](<../../docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md>) (turn 1: four contracts, packs, IR) and [docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>) (turn 2: hourglass, proof obligations, invariants, smells, test matrix)\n* Reference codebase (read-only): `../brunch` — esp. `src/agents/runtime/elicitor/`, `src/exchanges/`, `src/agents/skills/`\n* External: [Flue docs](<https://flueframework.com/docs/guide/why-flue/>), [zil-lean](<https://github.com/jagg-ix/zil-lean>)\n\n### Charter decisions (pre-map grilling, 2026-08-06)\n\n* Destination artifact = a spec (not a decision-set alone, not a build)\n* Elicitor-first: the elicitor is this map's spine\n* Greenfield reimplementation; brunch is reference architecture, not shared code\n* Fully decoupled from brunch's September MVP\n* Pi-family substrate committed; harness-agnostic core is a named non-goal\n* Brunch's exchange vocabulary is prior art to critique, not an incumbent to preserve\n* Persistence plugin-owned (in accord with deploy target) is a hypothesis to test, not a decision — **resolved 2026-08-10, flipped** by [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>): storage port harness-defined, binding-implemented, plugin-blind\n* Two live dev targets from day one (forces generalization on both pack axes); BPMN/process-mining named third\n* \"brunch-lite\" is a temporary label; real name is fog\n* **Principle v2** (ratified 2026-08-06, replaces \"behavioral over procedural\" after an evidence pass over `~/Clones/mattpocock/skills` and `../brunch/docs/design/BEHAVIORAL_KERNELS.md`): *procedure for mechanism, anchors for judgment, shapes for output*. Short step sequences with checkable completion criteria where order matters; leading words wherever judgment is required; annotated shapes for everything produced; reference disclosed progressively. Design against sprawl, negation-steering, no-ops, judgment-as-procedure — not against procedure itself. `writing-for-agents` is the pack-authoring standard; kernel cards (BEHAVIORAL_KERNELS.md) are the unit of elicitation guidance.\n\n## Decisions so far\n\n<!-- one line per closed ticket: gist + link -->\n\n* [Assemble the spec](<issues/08-assemble-the-spec.md>) — **the destination: [spec.md](<spec.md>) assembled** (fourteen sections + adjudications appendix) from the full working set in amendment order; all seven pre-pass contradictions adjudicated (storage port binding-implemented with the `db.ts` reconciliation; ops stay pure; status derived never stored, retraction specified; tap-ness as a transport fact via a reserved reply encoding; invariant 1 reconciled with the provenance rule; per-message current-affordance surface with identity on tool output parts; no instruction interpolation + harness-mechanical reply binding, no echo token); ten harness invariants restated in envelope vocabulary; `CONTEXT.md` gained the envelope vocabulary and the kernel-compound ruling (kernel card kept, \"kernel invariants\" → harness invariants); rename propagated over tickets 02/07. **The frontier is empty — this map is complete.** Remaining fog is post-spec and graduates with the build effort.\n* [Walking skeleton: sweep seam on Flue](<issues/13-walking-skeleton-sweep-seam.md>) — **all four capabilities hold on Flue** (two native, two binding-absorbed, none forbidden), closing pre-pass L1–L3: settlement trigger = `useAgentFinish` would-stop seam with same-response signal steering (fires on `terminate:true` suspensions too — the pending guard is load-bearing; needs a re-nudge loop guard); session-entry read = binding-absorbed via the public durable-history projection (no in-process API; `purpose` discriminates provenance) with the load-bearing HITL amendment that **evidence anchoring is harness-resolved — the model cites verbatim user quotes, never entry numbers** (sharpens issue 12's span shape: excerpt primary, pointer derived); on-behalf injection = `kind:'signal'` append/dispatch, projecting structurally non-user so the citable-evidence rule is mechanically enforced (live: unscripted conversational conflict-surfacing off the re-entry briefing; a fact recovered from a *superseded* capture, honestly marked inferred); transactional store = binding-owned entirely (content-keyed idempotence is load-bearing under Flue's at-least-once re-execution). **Amends Shipping shape's capability list to ten entries** (adds would-stop seam, entry-projection read, signal injection, transactional store). New payload-stratum spec examples: absence smuggled as payload; compound payloads make supersession lossy. Prototype on branch `prototype/13-sweep-seam`.\n* [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>) — **durable target-document, transient sessions, sweep as the only bridge**: \"target\" splits into **target-domain** (family a plugin defines) / **target-document** (durable unit sessions attach to — capture store **plus all session logs** as truth, renders strictly derived); session = one substrate conversation (per-session state: log + swept high-water mark + pending-affordance slot), never formally closes; **interleaved-only** concurrency — serialized store, whole-sweep-atomic refusals, the single-hop refusal doubling as the stale-session guard (true concurrency + per-item application → fog); re-entry briefing = injected on-behalf-of-user state messages (Pi convention), advisory-only, with the sharpened provenance rule that **only true user entries are citable evidence**; completion = derived status, never a write gate; **persistence hypothesis flipped** — storage port harness-defined, binding-implemented, plugin-blind (plugin-addressable only via PluginContext-passed methods); evidence spans = pointer + quoted excerpt.\n* [Shipping shape: kernel library vs. Flue agent](<issues/06-shipping-shape.md>) — **harness library in a thin host-authored agent, ratified with the second-binding test**: the spec enumerates a six-item substrate-capability list as the core/binding seam (portability = pressure test, not build target; **binding** entered the glossary); topology = Bun-workspace monorepo in this repo — `packages/core` (plugin SDK is its export surface; `core/testing` subpath), `packages/flue` (binding), `packages/plugin-gherkin` + `packages/plugin-assurance` (renamed from `plugin-proof-obligations` 2026-08-10, per the Formal-verification canon survey's category-error verdict; plugins depend on core *only* — stated spec invariant), `apps/dev`; Valibot throughout; tool prefix from product name (provisionally `bl_*`, never `elicit_*` — strings name identity, not function); workspace-internal, no publishing; testing = **generation-first fixtures over a deterministic replay driver** (kernel invariants as properties, `arbitraryFromSchema`, `fc.commands` conversation fuzzing from the envelope vocabulary, model as offline generator never CI oracle, regenerate-on-declaration-change); dev app chartered with three roles (dev loop / target-gallery demo / diagnostic probe views); one agent per target; milestone one local-only with remote-parity constraints pinned in spec; CI smoke = build + simulation suite.\n* [Walking skeleton: Flue question round-trip](<issues/10-walking-skeleton-flue-roundtrip.md>) — **transport proven, one amendment**: the one-channel multiplex works end-to-end (three forms, markdown floor, string-only replies, absence strip, redirect), but the fixed data channel is a *one-live-affordance slot per message* (update-in-place at every layer — stream, history, reply read-back), so per-ask identity/payload must ride the ask tool's **output part** and the kernel must **reject a second ask per batch** as mechanism; echo token not needed (adjacency + persistent pending state bound every bare-string reply); turn suspension (`terminate: true` + persistent state + fresh dispatch) sufficient, with a wake wart — instruction-interpolated pending state triggers an extra \"instructions updated\" model turn per ask; cancelled/redirected questions read back cleanly via `record_interpretation` evidence. Flue facts: `@flue/vite` needs vite ^8; dev server gives `app.ts` the whole request space (ui is app-served). Prototype on branch `prototype/10-flue-roundtrip`.\n* [Logic-prototype: capture sweep & settlement](<issues/11-logic-prototype-capture-sweep.md>) — **all five capture hypotheses hold** in a working prototype (branch `prototype/11-capture-sweep`; double-clickable demo + headless driver), each sharpened: settlement splits into **trigger vs judgment** (lifecycle-event wiring *not* proven in ticket 10 — misattribution caught by the 2026-08-10 consistency pre-pass; delegated to the sweep-seam walking skeleton, ticket 13); idempotence splits into **mechanical (harness, evidence-anchored capture identity) vs semantic (plugin reconcile)** and is content-based, so re-sweeps repair omissions; absences are **evidence, not agenda** (re-ask runs through plugin validate → issues); single-hop supersession over active heads = the lost-update guard; **two supersession channels** (sweep-time link / issue-time resolution record) with read-time *derived* status suggested (cf. issue 09). Amendments: **two validation strata** (envelope-level harness-owned refusals + advisories / payload-level plugin ops — strengthens smallest-honest-plugin), op cadence = pure orchestration policy (snapshot-purity), **resume-time sweep reconciliation** (unswept tail as computed re-entry fact). Graduated the multi-session fog → ticket 12.\n* [Questioning-UX contract](<issues/05-questioning-ux-contract.md>) — the reframe: **no exchange-pair ontology** — conversation is primary, structured questions are **affordance emissions** committed to session as evidence, capture via idempotent **range-sweeps** on agent-judged, range-level **settlement**; shells renamed **substrate / ui / harness / plugin** (the effort's essence is *harness-engineering*; IoC via narrow injected PluginContext — the ask API is part of it); harness fixes: three baseline shapes + questionnaire chaining, absence interpret-by-default/afford-when-structured, **one multiplexed data channel** with markdown floor (Flue: outbound rich / inbound string-only), interpretation render harness-owned with plugin-optional typed renderer (JSON default), conflicts close only via explicit **resolution records**, no question-budget machinery (economical interviewing = judgment guidance); all shape-level commitments are working hypotheses with proof obligations delegated to the two prototype tickets created here (10, 11); **built-artifacts-as-proofs** ratified into Notes.\n* [Contract decomposition](<issues/04-contract-decomposition.md>) — the load-bearing resolution: **agent-forward hybrid** (agent judgment owns the loop; deterministic mechanism as tools; typed-issue backpressure); **no universal IR** — the kernel owns only a domain-free **capture envelope** (evidence spans, epistemic-status enum, absence states, alternatives, one `supersedes` link) around opaque plugin payloads, no kernel edges or graph (conflicts/equivalence are typed issues, resolved only explicitly); operations tiered `project`+`validate` required / `reconcile` optional / `observe` agent-native, all snapshot-in/deltas-out with typed loss reports; **facts computed, weights judged** dialogue policy (no scoring engine); packs = kernel cards + shapes + validators + shallow schemas + completion contract; smallest-honest-plugin test; five proof obligations + ten kernel invariants + gating tests (reprojection, minimal pairs, black-box authoring) adopted as spec acceptance material; multi-plugin composition, removal, replay, capability negotiation, versioning deferred to fog. Full ownership table in the ticket.\n* [Flue architecture deep-read](<issues/01-flue-architecture-deep-read.md>) — embedding is Flue's grain: ship the kernel as a custom hook (`useElicitation(plugin)` — final name per Shipping shape) + exportable `defineTool`s over a thin host-authored `'use agent'` module; Pi is exposed only at the provider layer (no path to Pi's loop/extensions — brunch-style Pi assumptions don't transfer); durability contract identical local/remote but storage/ownership differ; **no first-class ask-the-user primitive — the kernel must own its turn-suspension protocol** (`terminate: true` tool + persistent state + data part, answer arrives as fresh dispatch); constraints: Valibot at every schema boundary, stable-tool-set cache economics, subagents conversationally sterile, non-React hosts must build on `@flue/sdk`.\n* [Formal-verification canon survey](<issues/09-formal-verification-canon-survey.md>) — align the second target to a **GSN skeleton** (Goal/Strategy/Solution/Assumption/Justification; the one canon built for argued claims about a system) with **Dafny nouns** (`requires`/`ensures`/`invariant`/`lemma`/`assume` transfer; `modifies`/ghost don't) and **Lean sorry-taint semantics**; the headline artifact is a `dafny audit`-style **assumption ledger** (per-claim status becomes a derived label); acyclicity kept as a deliberate restriction with `decreases` as future escape hatch; sell the Datalog closure as taint-propagation, never as an assurance verdict; **\"proof obligations\" is a category error to verification readers — rename the target** (resolved 2026-08-10: the second target is the **assurance argument**, package `plugin-assurance`); Geolog is *not* an ARIA artifact (negative result) but coherent-logic saturation is the validator's genuinely canonical lineage; concrete milestone-one contract sketch (one `Statement` record, four edge kinds, five-stratum status rules) is in the ticket.\n* [Dev-target portfolio confirmation](<issues/07-dev-target-portfolio.md>) — confirmed `elicit-gherkin` + `elicit-proof-obligations` live (BPMN third, full elicit-lean deferred); **hybrid order**: both packs authored before the pack interface freezes, gherkin wires end-to-end first; proof-obligations format = zil-lean's ideas in our own claim-DAG serialization, hewing to existing canon (Dafny leading candidate — grounded by new ticket 09); gherkin milestone-one validation = parse validity + pack-declared step lexicon; surfaced the **behavioral-over-procedural** design principle (routed to Contract decomposition).\n* [Brunch exchange-schema audit](<issues/03-brunch-exchange-schema-audit.md>) — full catalog + three-way classification: **generic** (the `ask` one-terminal-four-shapes primitive, declared continuations that make offer→answer non-forgeable, answered/cancelled/unavailable property-presence union, self-contained terminals, boundary-teaching schemas, no-storage asking agenda + private scratchpad, hash-pinned prompt directives); **generalize-with-changes** (present-then-ask two-step → one `present(form, payload)` with pluggable validators, parent-link instead of enumerated prev/curr/next unions, opaque target-supplied receipts, rubrics declared by the target); **brunch-specific** (review-set node/edge schema, plane vocabulary, `graph_refs`, `map`/`tutorial` skills). Strain marks confirm the \"just a guess\" caution: wire vocabulary outlived tool names, a digest-into-review merge was retracted, doc/code drift on edge categories. 15 inherit/avoid lessons feed tickets 04 and 05.\n* [zil-lean survey](<issues/02-zil-lean-survey.md>) — zil-lean contains **no elicitation** (agent-authored 2-day snapshot; Datalog/Zanzibar-style claim graph in Lean 4 + Clojure) but is a strong existence proof of the kernel's claim-graph layer: evidence-graded assurance lattice with prohibited promotions, full derivation provenance, assumption/lemma/theorem/guarantee vocabulary with derived PROVED/CONDITIONAL/WEAK/BROKEN statuses. **Verdict: full elicit-lean is not dev-sized; the \"elicit-proof-obligations\" slice is** (claim DAG + criticality + evidence refs, validated by acyclicity + Datalog closure — no Lean statements) and beats BPMN as second target on both pack axes; BPMN stays third.\n\n## Not yet specified\n\n* Diagnostic \"exploded view\" harness for HITL prototype sessions — an instrumented walking-skeleton UI with parallel state readout and labeled moving parts (persistent state, pending affordance slot, tool traffic, terminate boundaries, advisory wakes, activation timing) so the human can react to internals, not just the chat surface; surfaced by the user after the ticket-10 walking skeleton, wanted \"at some point\" — **host identified** by the Shipping-shape resolution: the dev app's probe view (role 3 of its charter); graduates with the dev app, post-spec\n* Remote deploy target choice & provisioning — pending an infra-colleagues conversation (2026-08-07); blocks nothing on this map (the spec pins remote-parity constraints without naming the target)\n* Unstructured-ingest crossover at scale — the IR inside the contract-decomposition ticket absorbs the parsing/mapping core; what remains foggy is bulk/brownfield ingest as a first-class mode\n* elicit-to-petri-net as a future plugin — abstract questions (what fits a net; what IR precedes a net) wait until the pack model exists\n* JSONL-vs-YAML storage-format comparison — persistence resolved harness-defined / binding-implemented (multi-session resolution, 2026-08-10), so the format is a binding-internal choice; graduates with the local binding implementation, post-spec\n* Concurrent-session coordination beyond interleaving — simultaneous sweeps against one target-document, per-item partial sweep application, merge machinery; the spec's stance (serialized store + single-hop refusal + re-entry advisory) covers interleaving, and this graduates only if a real concurrent consumer appears\n* The real product name\n* Deferred plugin-ecosystem machinery (from Contract decomposition): simultaneous multi-plugin composition, plugin removal, full replay, capability negotiation, version/migration (spec names the five version axes only)\n\n## Out of scope\n\n* **Executor-standalone** — a different kind of project; the spec only names the elicitor→executor handoff seam\n* **Harness-agnostic core** — every named consumer is Pi-family; revisit only if a non-Pi consumer materializes (would be a fresh effort under a redrawn destination)\n+++",
+      "proposedBodySha256": "8ae07f2f4e89c51313aa1147df800dd286672bb5323c70a5034de3222b406314",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "4f506cd8-070b-41ad-b208-0b625f987418",
+      "identifier": "FE-1367",
+      "url": "https://linear.app/hash/issue/FE-1367/flue-architecture-deep-read-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.414Z",
+      "sourceTitle": "Flue architecture deep-read [archive]",
+      "sourceDescriptionSha256": "5f6506ff45d1964c8545e824d2c5b8f989410ac176bfa5fef6b9cfe150109239",
+      "sourceTitleSha256": "d56adb14bff1dbfe03cac1c1c2a312d5fc3ac3693b36a8324c59c080ef5aea2a",
+      "oldOuter": "Read Flue — the web/agent framework the interviewing library runs on — closely enough to know how the library should ship on it. Conclusion: embed as a library inside a host-authored app, which is Flue's natural grain; Flue has no built-in \"pause and ask the user\" facility, so the library owns its own turn-taking mechanism. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Define how the elicitation harness uses Flue",
+      "proposedOuter": "This research determined how the interviewing library should run on Flue. The library belongs inside a host-authored app, and it must manage conversational turn-taking because Flue does not provide a built-in way to pause and ask the user. The research was resolved on 2026-08-06 as part of the completed elicitation-harness plan.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/01-flue-architecture-deep-read.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Flue architecture deep-read\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nWhat does Flue's architecture offer — and constrain — for embedding an elicitation kernel, such that the shipping-shape and contract-decomposition tickets can decide on facts rather than the marketing page?\n\nSpecifically:\n\n* The agent programming model (React-like hooks API): what is \"an agent\" as a unit of code, state, and deployment?\n* How skills, tools, subagents, persistent state, sandboxes, and channels are defined and composed\n* How Pi is exposed through Flue — can an embedded library reach Pi primitives directly, or only through Flue's abstractions?\n* Local vs. remote parity: what changes between a Node local run and a Cloudflare/CI deploy? What state survives where?\n* Is a \"kernel library embedded in a thin Flue agent\" a natural pattern, or does Flue push toward the agent *being* the program?\n* Channels (Slack/Teams/Discord/GitHub) as host input pathways — what does a host surface look like in Flue terms?\n\nSources: [https://flueframework.com/docs/guide/](<https://flueframework.com/docs/guide/>) (pages are fetchable as markdown at `/docs/guide/<topic>/index.md`).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Flue Architecture — Findings for an Embedded \"Elicitation Kernel\"\n\nVersion context: `@flue/runtime` **2.0.3** (npm, published 2026-08-05; package created 2026-05-14, 48 versions). Siblings `@flue/cli`, `@flue/sdk`, `@flue/react`, `@flue/vite` all at 2.0.3. Docs pages carry \"Last updated Jul 21–23, 2026\". Repo: `github.com/withastro/flue`.\n\n## 1. Agent as a unit\n\n**Code.** An agent is a plain exported, capitalized JS function that returns its system-prompt string. Capabilities come from `use*` hooks called in its body. A module marked `'use agent'` is scanned at build time by the Vite plugin (`flue()` from `@flue/vite`); every exported capitalized function in it becomes a registered agent. One file may export several.\n\n**Lifecycle.** The function **re-renders before every model call** and rebuilds instructions and its declared resource set from scratch. Unlike React, resource hooks *may* be called conditionally — this is the framework's central design bet (\"an agent is a program to write, not an object to configure\"). Between renders the runtime diffs the declared set against a \"last-narrated snapshot\" and appends a framework-authored `resources` signal at the next turn boundary (\"New tool available: …\"). Skill/subagent catalogs are frozen on a durable baseline so flips don't bust the prompt cache; custom-tool changes rewrite the native tools array and *do* invalidate cache (documented exception: a tool unlocked by a completed tool call, on non-Haiku Anthropic models).\n\n**State.** Durable identity is the function name (or the `Fn.agentName` static) — it keys conversation storage, so renaming without pinning `agentName` is a DB migration. Each conversation is addressed by a caller-chosen `id`. `Fn.initialData` (a Valibot schema static) validates creation-time data exactly once.\n\n**Deployment.** Registration ≠ mounting. `createAgentRouter(agent)` returns a Hono sub-app you mount yourself in `src/app.ts`; agents reached only via `dispatch(...)` need no mount at all. Entry points: `flue run <module>` (CLI, no server), HTTP `POST /:id` (202 fire-and-forget), `dispatch(agent, {id, message, initialData, uid})`, and `start()` + `init()` for standalone Node processes.\n\n## 2. Primitive inventory (what a library could register/own)\n\n* **Tools.** `defineTool({name, description, input?, output?, harness?, durable?, run})` — Valibot schemas, frozen at module load, importable from a light `@flue/runtime/tool` entry \"for tool-only modules\". Mounted per render via `useTool(def)`. `run` receives `{data, signal, log, toolCallId}`; `harness: true` adds `harness`, `durable: true` adds `step`. Reserved names: `task`, `activate_skill`, `read_skill_resource`, plus sandbox built-ins (`read/write/edit/bash/grep/glob`). **This is the primary registration surface an embedded kernel would own.**\n* **Harness tools** (worth calling out separately). `harness.sandbox` (direct file/exec verbs, *never recorded in the conversation*) and `harness.prompt(text, {result: Schema, tools, model, thinkingLevel, images})` — runs a model operation in a private scratch conversation invisible to clients, with Valibot-validated structured output enforced via a framework-injected `finish` tool. Repeated calls continue that scratch conversation. **This is the closest thing Flue has to a sub-LLM call primitive, and it is a strong fit for a kernel's internal extraction/normalization steps.** Also `harness.compact()`.\n* **Skills.** Open Agent Skills format (`SKILL.md` + supporting files), or `defineSkill({name, description, instructions, files})` for generated/assembled content. Progressive disclosure: one catalog line always present; full instructions arrive as an `activate_skill` tool *result*, so activation never mutates the system prompt and the cached prefix survives. Supporting files are served read-only from the app bundle at virtual paths — **not** copied into the sandbox. Also auto-discovered from `<cwd>/.agents/skills/` when a sandbox exists.\n* **Subagents.** `defineSubagent({name, description, agent})` + `useSubagent()`. Model-driven via the always-present `task` tool. Child inherits *environment* (sandbox, workspace context, parent model) but **nothing conversational** — no history, instructions, tools, skills, persistent state, or initialData. Only the final message returns. Explicitly *not* a second addressable agent: \"no conversation id, no persistent state, and no address.\" `GeneralSubagent` ships as a blank delegate under `flue-general`.\n* **Persistent state.** `usePersistentState(name, initial)` — React-shaped, JSON-serializable, keyed by name, durable for the life of the conversation. Writes commit **atomically with the unit of work that made them** (tool batch, or event-hook seam checkpoint), which is what makes it the correct guard for at-least-once callbacks. Prefer updater functions; the render value is a snapshot.\n* **Sandboxes.** `useSandbox(factory, {cwd})`. `local()` from `@flue/runtime/node`, or adapters (Daytona, E2B, Modal, Cloudflare Sandbox/Computer) built against the Sandbox Adapter API. Attaching one adds the six built-in file/shell tools; an adapter may replace that set entirely. Sandbox filesystems are **ephemeral by default** and independent of conversation durability.\n* **Channels.** Inbound-only verified HTTP ingress (Slack, Discord, Teams, GitHub, Stripe, …), shipped as **blueprints** (`flue add channel slack`) that generate project source rather than as opaque packages. A channel is \"an object with declarative routes\"; `createChannelRouter(routes)` builds one by hand. Handlers call `dispatch(...)` themselves. **Outbound is explicitly not Flue's job** — no send-message abstraction; you use the provider SDK and expose narrow tools with the destination bound in trusted code.\n* **Event hooks / data writers.** `useAgentStart` (async — the load-data seam), `useAgentFinish`, `useResponseStart/Finish` (return values merge onto response *metadata*). `useDataWriter(name, {schema})` streams typed structured data parts to clients (`{type: 'data-orderCard', data}`), strictly one-way out of the agent — **the model never sees data parts**, and a write never re-renders the agent.\n* **Custom hooks.** Plain `use*` functions composing the built-ins, returning instruction fragments to the caller. Docs explicitly frame this as the reuse/packaging unit.\n\n## 3. Pi exposure\n\nPartial and deliberate, concentrated at the **model-provider layer**. Documented facts:\n\n* `@flue/runtime`'s npm dependencies include `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` directly.\n* Models guide: \"Providers are Pi's own objects, and Flue accepts them directly: build one with Pi's `createProvider()` … and hand it to `setProvider()` at module top level in `app.ts`.\" Examples import from `@earendil-works/pi-ai`, `.../api/anthropic-messages.lazy`, `.../providers/anthropic`, `.../api/openai-completions.lazy`.\n* `start({providers})` registers \"the Pi providers this runtime registers, replacing the default set.\"\n* `PromptImage` \"re-exports pi-ai's `ImageContent`.\"\n* Why-Flue: \"Flue builds on Pi, the open agent harness behind OpenClaw, and integrates it deeply into every agent you build.\"\n\nEverything else — conversation loop, tool dispatch, skills, subagents, durability — sits behind Flue's own abstractions. **Inference:** there is no documented path to Pi's agent loop, message list, or Pi extension/package system from inside a Flue agent. A kernel that currently assumes Pi-level tool registration, transcript control, or `renderResult`-style TUI hooks would have to be re-expressed entirely in Flue's `defineTool` + render model. Flue also uses Durable Streams (`@durable-streams/client`) as its client transport protocol.\n\n## 4. Local vs. remote parity\n\nDurable *records and recovery decisions are identical* across targets; ownership and wake mechanics differ.\n\n|  | Node | Cloudflare |\n| -- | -- | -- |\n| Unit | one server process, coordinator with **lease-based** ownership | one **Durable Object per agent conversation**, own SQLite; ownership structural |\n| Recovery | startup reconciliation + periodic lease scans | wake-on-start + self-renewing durable wake schedule, bounded supervision pass |\n| Storage | `db.ts` adapter required (sqlite, Postgres, MySQL, Mongo, Redis, libSQL, Turso, Supabase, Valkey); **without one, conversations are process-local memory and a restart loses them** | built in |\n| Constraint | must route each conversation to exactly one owner; active-active / round-robin for the same conversation is unsafe | every deployed agent needs an append-only DO migration tag in your hand-authored `wrangler.jsonc`; renames/deletes are storage migrations (`renamed_classes` / `deleted_classes`) |\n\nCore contract: \"Every accepted submission reaches exactly one durable terminal outcome — completed, failed, or aborted — no matter how many crashes happen in between.\" Submissions are recorded durably *before* any model work; that is what the 202 and the `DispatchReceipt` attest to. There is a retry budget plus a wall-clock timeout, enforced preemptively via the attempt's abort signal.\n\n**Deliberately not durable:** sandbox files (rebuilt fresh on each initialization unless the adapter keys a provider workspace on the instance id — \"a durable database does not make a sandbox durable\"); in-flight local promises (persist the `DispatchReceipt` and `read(receipt)` re-attaches from any process); and **code outside the agent** — Flue explicitly does not checkpoint arbitrary TypeScript. For that, docs point to Cloudflare Workflows / Inngest / Temporal calling Flue \"like any other service.\" External side effects are never recorded, only that a tool ran and what it returned.\n\nAlso: there is **no GitHub Actions or GitLab *target***. CI is just `flue run` in a shell step (`--new` + deterministic `--id` gives exactly-once conversation creation). GHA/GitLab appear only in the ecosystem catalog. Builds are Vite (`vite build` → `dist/server.mjs` + `dist/app.mjs`, or the Cloudflare plugin's output). Node deps are externalized, not bundled; the built server does not load `.env`.\n\n## 5. Library-in-agent vs. agent-as-product\n\n**Embedding is a natural pattern, and the docs endorse it explicitly.** Evidence:\n\n* `defineTool` / `defineSkill` / `defineSubagent` all exist specifically as *exportable, frozen, module-load-validated* units — described as \"the natural shape for tools shared across agents\" and \"the exportable unit — define a delegate once, mount it from any agent.\"\n* **Custom hooks are the documented composition unit:** \"a `useGitHub()` hook that bundles the right tools, skills, and instructions can be written once and dropped into every agent that works with GitHub.\" That is precisely a kernel-in-a-hook.\n* `@flue/runtime/tool` is a lighter entry point for tool-only modules — a library can depend on Flue without pulling in the server runtime.\n* Source-dir resolution order puts `.flue/` **first**, described as \"a self-contained Flue source area inside a larger application,\" with authored modules free to \"import ordinary supporting code from elsewhere in the project.\"\n* Per-mount overrides \"spread cleanly\": `useSubagent({ ...issueClassifier, model: 'anthropic/claude-haiku-4-5' })`.\n\nCounter-pressure: Flue insists the *agent itself* be a program, not config, and the `'use agent'` build-time scan means a library **cannot ship a pre-registered agent** — the agent module must be authored in the consuming project.\n\n**Recommendation (inference):** ship the kernel as a published custom hook — `useElicitationKernel(targetPlugin)` — that internally calls `useTool` / `useSkill` / `usePersistentState` / `useDataWriter` and returns instruction fragments, plus raw `defineTool` exports for hosts that want selective mounting. The host owns a ~10-line `'use agent'` module, the `app.ts` mount, and `db.ts`. This is library-in-a-thin-agent, and Flue's grain supports it. One real constraint: tool names are globally unique per render and collide with reserved names, so the kernel needs a namespacing convention.\n\n## 6. Channels as host surfaces\n\nA \"host input pathway\" in Flue is: verified ingress → `dispatch(agent, {id, message, initialData})`. Three distinct payload lanes:\n\n* `initialData` — recorded once at conversation creation, validated against the agent's schema static, read with `useInitialData()`, immutable thereafter. This is where an elicitation *target descriptor* belongs.\n* `kind: 'signal'` **messages** — `{type, body, attributes}` where `attributes` is a string→string map of facts *trusted code* attached. Read with `useDelivery()`. Docs push this hard as the authorization pattern: \"the model may choose an order ID to look up, but it cannot choose the customer.\" For a kernel, this is the channel for host-verified respondent identity. Channel deliveries are signals rather than `user` messages precisely because a Slack thread is multi-participant.\n* `kind: 'user'` — direct human turns.\n\n**Interviewing-UX rendering surfaces, ranked by fit:**\n\n1. `useDataWriter` **+** `@flue/react`**.** Named, schema-validated structured data parts arriving alongside text on the same message; a tool can write several times mid-run to drive live progress. `useFlueAgent({url})` gives `messages`, `parts`, `status`, `historyReady`, `sendMessage()`, `refresh()`. Message parts are `text | reasoning | dynamic-tool | file`, and **validated structured tool output is preserved on the** `dynamic-tool` **part's** `output` — the React docs say this exists \"so applications can render custom tool interfaces without a separate data-event channel.\" Direct fit for question cards, choice sets, and review panes.\n2. **Chat channels** (Slack/Teams/Discord/GitHub) for text-shaped interviewing only. There is **no outbound abstraction** — every reply is a tool you write against the provider SDK with the destination bound in trusted code (the `replyInThread(data)` pattern). Rich Slack Block Kit interviewing is entirely your code.\n\n**Gap worth flagging loudly: Flue documents no first-class human-in-the-loop / elicitation / interrupt primitive.** There is no \"ask the user and suspend\" hook. `terminate: true` on a tool result ends the turn once the current batch settles; the documented pattern for waiting on a human is state-gated tools (`record_approval` unlocks `publish_release`) plus a new inbound submission. **Inference:** the kernel must implement its own turn-suspension protocol — a `terminate: true` tool that writes the pending question into `usePersistentState` and emits a data part, with the host's answer arriving as a fresh `dispatch`. That is exactly the kind of thing a kernel *should* own, but Flue provides no scaffolding for it, so it is net-new work either way.\n\n## 7. Constraints & risks\n\n* **Maturity.** 2.0.3, with 2.0 a full API rewrite around hooks announced this cycle; a Migration Guide exists. `@flue/vite` first published 2026-07-10 (19 versions). Fast-moving — expect churn.\n* **Build-time magic is load-bearing.** `'use agent'` scanning, `SKILL.md` module imports, and agent-identity stamping all happen in the Vite plugin. **This effectively requires Vite.** A kernel published as a library must not depend on that transform internally — keep to `defineTool`/`defineSkill` (plain runtime calls) and let the host own the scanned module.\n* **Durable-identity coupling.** Conversation storage is keyed by agent function name. Always pin `agentName`.\n* **Cloudflare migration ceremony.** Adding an agent is always agent + mount + new DO migration tag. If the design ever wants *dynamic* agent creation per elicitation target, Cloudflare forbids it — agents are a build-time set. Use one agent + many conversation ids instead.\n* **Prompt-cache economics constrain dynamism.** \"Gate tools on state that changes rarely.\" An interviewing kernel that swaps tools per question would thrash the cache. Prefer one stable tool set + state-driven instructions, or skill activation (cache-safe by design).\n* **Valibot lock-in** at every schema boundary (`input`, `output`, `initialData`, `useDataWriter`, `harness.prompt({result})`). A kernel with Zod-based plugin contracts needs a conversion layer or a dual-schema strategy.\n* **Node multi-replica.** No active-active per conversation; you must own routing.\n* **Subagents are conversationally sterile** — no id, no state, no address. If elicitation-target plugins need their own durable memory, they cannot be subagents; they must be state + tools inside the parent, or separately registered agents.\n* **Petrinaut / non-React web-UI host risk:** the rich path (`useFlueAgent`) is React-specific. `@flue/sdk` (`createFlueClient` → `send/read/wait/observe/history`, built on `@durable-streams/client`) is framework-neutral and is what `@flue/react` sits on, so a non-React host is viable — but it must reimplement the materialized-snapshot / reconnect / canonical-reset layer that `useFlueAgent` provides. **Inference:** budget for that, or wrap `createFlueClient` directly and accept a thinner UI contract.\n* `skills` **frontmatter** `allowed-tools` **is accepted but not enforced** — Flue does not restrict the session toolset from a skill. Any kernel-level tool gating must be done with conditional `useTool`.\n\n## 8. Unreached sources\n\n**HTTP 404 (do not exist at those paths):** `/docs/guide/deployment/`, `/docs/guide/state/`, `/docs/guide/cloudflare/`, `/docs/guide/cli/`, `/docs/guide/github-actions-target/`, `/docs/reference/index.md`, `/llms.txt`. (Real equivalents: `/docs/guide/deploy/`, state is a section of `agent-hooks`, `/docs/guide/cloudflare-target/`.)\n\n**Exist but not fetched** (nav-confirmed; would sharpen specific answers): `/docs/guide/database/`, `/docs/guide/schedules/`, `/docs/guide/evals/`, `/docs/guide/observability/`, `/docs/guide/configuration/`, `/docs/guide/migration/`, `/docs/guide/agent-behavior/`, `/docs/reference/sandbox-api/`, `/docs/reference/provider-api/`, the full `/docs/reference/agent-hooks-api/` (indexed, read only via search), the CLI and Agent SDK reference sections, all `/docs/ecosystem/*` sub-pages, the `@flue/react` package README, and `examples/react-chat`. The GitHub repo (`withastro/flue`) source and Pi's own docs (`pi.dev/docs/latest`) were not read.",
+      "innerSha256": "6d565c7365ebc78f76a053a624703acd07ac03cb40a6c8cb3c127bc0de30a087",
+      "proposedBody": "This research determined how the interviewing library should run on Flue. The library belongs inside a host-authored app, and it must manage conversational turn-taking because Flue does not provide a built-in way to pause and ask the user. The research was resolved on 2026-08-06 as part of the completed elicitation-harness plan.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/01-flue-architecture-deep-read.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Flue architecture deep-read\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nWhat does Flue's architecture offer — and constrain — for embedding an elicitation kernel, such that the shipping-shape and contract-decomposition tickets can decide on facts rather than the marketing page?\n\nSpecifically:\n\n* The agent programming model (React-like hooks API): what is \"an agent\" as a unit of code, state, and deployment?\n* How skills, tools, subagents, persistent state, sandboxes, and channels are defined and composed\n* How Pi is exposed through Flue — can an embedded library reach Pi primitives directly, or only through Flue's abstractions?\n* Local vs. remote parity: what changes between a Node local run and a Cloudflare/CI deploy? What state survives where?\n* Is a \"kernel library embedded in a thin Flue agent\" a natural pattern, or does Flue push toward the agent *being* the program?\n* Channels (Slack/Teams/Discord/GitHub) as host input pathways — what does a host surface look like in Flue terms?\n\nSources: [https://flueframework.com/docs/guide/](<https://flueframework.com/docs/guide/>) (pages are fetchable as markdown at `/docs/guide/<topic>/index.md`).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Flue Architecture — Findings for an Embedded \"Elicitation Kernel\"\n\nVersion context: `@flue/runtime` **2.0.3** (npm, published 2026-08-05; package created 2026-05-14, 48 versions). Siblings `@flue/cli`, `@flue/sdk`, `@flue/react`, `@flue/vite` all at 2.0.3. Docs pages carry \"Last updated Jul 21–23, 2026\". Repo: `github.com/withastro/flue`.\n\n## 1. Agent as a unit\n\n**Code.** An agent is a plain exported, capitalized JS function that returns its system-prompt string. Capabilities come from `use*` hooks called in its body. A module marked `'use agent'` is scanned at build time by the Vite plugin (`flue()` from `@flue/vite`); every exported capitalized function in it becomes a registered agent. One file may export several.\n\n**Lifecycle.** The function **re-renders before every model call** and rebuilds instructions and its declared resource set from scratch. Unlike React, resource hooks *may* be called conditionally — this is the framework's central design bet (\"an agent is a program to write, not an object to configure\"). Between renders the runtime diffs the declared set against a \"last-narrated snapshot\" and appends a framework-authored `resources` signal at the next turn boundary (\"New tool available: …\"). Skill/subagent catalogs are frozen on a durable baseline so flips don't bust the prompt cache; custom-tool changes rewrite the native tools array and *do* invalidate cache (documented exception: a tool unlocked by a completed tool call, on non-Haiku Anthropic models).\n\n**State.** Durable identity is the function name (or the `Fn.agentName` static) — it keys conversation storage, so renaming without pinning `agentName` is a DB migration. Each conversation is addressed by a caller-chosen `id`. `Fn.initialData` (a Valibot schema static) validates creation-time data exactly once.\n\n**Deployment.** Registration ≠ mounting. `createAgentRouter(agent)` returns a Hono sub-app you mount yourself in `src/app.ts`; agents reached only via `dispatch(...)` need no mount at all. Entry points: `flue run <module>` (CLI, no server), HTTP `POST /:id` (202 fire-and-forget), `dispatch(agent, {id, message, initialData, uid})`, and `start()` + `init()` for standalone Node processes.\n\n## 2. Primitive inventory (what a library could register/own)\n\n* **Tools.** `defineTool({name, description, input?, output?, harness?, durable?, run})` — Valibot schemas, frozen at module load, importable from a light `@flue/runtime/tool` entry \"for tool-only modules\". Mounted per render via `useTool(def)`. `run` receives `{data, signal, log, toolCallId}`; `harness: true` adds `harness`, `durable: true` adds `step`. Reserved names: `task`, `activate_skill`, `read_skill_resource`, plus sandbox built-ins (`read/write/edit/bash/grep/glob`). **This is the primary registration surface an embedded kernel would own.**\n* **Harness tools** (worth calling out separately). `harness.sandbox` (direct file/exec verbs, *never recorded in the conversation*) and `harness.prompt(text, {result: Schema, tools, model, thinkingLevel, images})` — runs a model operation in a private scratch conversation invisible to clients, with Valibot-validated structured output enforced via a framework-injected `finish` tool. Repeated calls continue that scratch conversation. **This is the closest thing Flue has to a sub-LLM call primitive, and it is a strong fit for a kernel's internal extraction/normalization steps.** Also `harness.compact()`.\n* **Skills.** Open Agent Skills format (`SKILL.md` + supporting files), or `defineSkill({name, description, instructions, files})` for generated/assembled content. Progressive disclosure: one catalog line always present; full instructions arrive as an `activate_skill` tool *result*, so activation never mutates the system prompt and the cached prefix survives. Supporting files are served read-only from the app bundle at virtual paths — **not** copied into the sandbox. Also auto-discovered from `<cwd>/.agents/skills/` when a sandbox exists.\n* **Subagents.** `defineSubagent({name, description, agent})` + `useSubagent()`. Model-driven via the always-present `task` tool. Child inherits *environment* (sandbox, workspace context, parent model) but **nothing conversational** — no history, instructions, tools, skills, persistent state, or initialData. Only the final message returns. Explicitly *not* a second addressable agent: \"no conversation id, no persistent state, and no address.\" `GeneralSubagent` ships as a blank delegate under `flue-general`.\n* **Persistent state.** `usePersistentState(name, initial)` — React-shaped, JSON-serializable, keyed by name, durable for the life of the conversation. Writes commit **atomically with the unit of work that made them** (tool batch, or event-hook seam checkpoint), which is what makes it the correct guard for at-least-once callbacks. Prefer updater functions; the render value is a snapshot.\n* **Sandboxes.** `useSandbox(factory, {cwd})`. `local()` from `@flue/runtime/node`, or adapters (Daytona, E2B, Modal, Cloudflare Sandbox/Computer) built against the Sandbox Adapter API. Attaching one adds the six built-in file/shell tools; an adapter may replace that set entirely. Sandbox filesystems are **ephemeral by default** and independent of conversation durability.\n* **Channels.** Inbound-only verified HTTP ingress (Slack, Discord, Teams, GitHub, Stripe, …), shipped as **blueprints** (`flue add channel slack`) that generate project source rather than as opaque packages. A channel is \"an object with declarative routes\"; `createChannelRouter(routes)` builds one by hand. Handlers call `dispatch(...)` themselves. **Outbound is explicitly not Flue's job** — no send-message abstraction; you use the provider SDK and expose narrow tools with the destination bound in trusted code.\n* **Event hooks / data writers.** `useAgentStart` (async — the load-data seam), `useAgentFinish`, `useResponseStart/Finish` (return values merge onto response *metadata*). `useDataWriter(name, {schema})` streams typed structured data parts to clients (`{type: 'data-orderCard', data}`), strictly one-way out of the agent — **the model never sees data parts**, and a write never re-renders the agent.\n* **Custom hooks.** Plain `use*` functions composing the built-ins, returning instruction fragments to the caller. Docs explicitly frame this as the reuse/packaging unit.\n\n## 3. Pi exposure\n\nPartial and deliberate, concentrated at the **model-provider layer**. Documented facts:\n\n* `@flue/runtime`'s npm dependencies include `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` directly.\n* Models guide: \"Providers are Pi's own objects, and Flue accepts them directly: build one with Pi's `createProvider()` … and hand it to `setProvider()` at module top level in `app.ts`.\" Examples import from `@earendil-works/pi-ai`, `.../api/anthropic-messages.lazy`, `.../providers/anthropic`, `.../api/openai-completions.lazy`.\n* `start({providers})` registers \"the Pi providers this runtime registers, replacing the default set.\"\n* `PromptImage` \"re-exports pi-ai's `ImageContent`.\"\n* Why-Flue: \"Flue builds on Pi, the open agent harness behind OpenClaw, and integrates it deeply into every agent you build.\"\n\nEverything else — conversation loop, tool dispatch, skills, subagents, durability — sits behind Flue's own abstractions. **Inference:** there is no documented path to Pi's agent loop, message list, or Pi extension/package system from inside a Flue agent. A kernel that currently assumes Pi-level tool registration, transcript control, or `renderResult`-style TUI hooks would have to be re-expressed entirely in Flue's `defineTool` + render model. Flue also uses Durable Streams (`@durable-streams/client`) as its client transport protocol.\n\n## 4. Local vs. remote parity\n\nDurable *records and recovery decisions are identical* across targets; ownership and wake mechanics differ.\n\n|  | Node | Cloudflare |\n| -- | -- | -- |\n| Unit | one server process, coordinator with **lease-based** ownership | one **Durable Object per agent conversation**, own SQLite; ownership structural |\n| Recovery | startup reconciliation + periodic lease scans | wake-on-start + self-renewing durable wake schedule, bounded supervision pass |\n| Storage | `db.ts` adapter required (sqlite, Postgres, MySQL, Mongo, Redis, libSQL, Turso, Supabase, Valkey); **without one, conversations are process-local memory and a restart loses them** | built in |\n| Constraint | must route each conversation to exactly one owner; active-active / round-robin for the same conversation is unsafe | every deployed agent needs an append-only DO migration tag in your hand-authored `wrangler.jsonc`; renames/deletes are storage migrations (`renamed_classes` / `deleted_classes`) |\n\nCore contract: \"Every accepted submission reaches exactly one durable terminal outcome — completed, failed, or aborted — no matter how many crashes happen in between.\" Submissions are recorded durably *before* any model work; that is what the 202 and the `DispatchReceipt` attest to. There is a retry budget plus a wall-clock timeout, enforced preemptively via the attempt's abort signal.\n\n**Deliberately not durable:** sandbox files (rebuilt fresh on each initialization unless the adapter keys a provider workspace on the instance id — \"a durable database does not make a sandbox durable\"); in-flight local promises (persist the `DispatchReceipt` and `read(receipt)` re-attaches from any process); and **code outside the agent** — Flue explicitly does not checkpoint arbitrary TypeScript. For that, docs point to Cloudflare Workflows / Inngest / Temporal calling Flue \"like any other service.\" External side effects are never recorded, only that a tool ran and what it returned.\n\nAlso: there is **no GitHub Actions or GitLab *target***. CI is just `flue run` in a shell step (`--new` + deterministic `--id` gives exactly-once conversation creation). GHA/GitLab appear only in the ecosystem catalog. Builds are Vite (`vite build` → `dist/server.mjs` + `dist/app.mjs`, or the Cloudflare plugin's output). Node deps are externalized, not bundled; the built server does not load `.env`.\n\n## 5. Library-in-agent vs. agent-as-product\n\n**Embedding is a natural pattern, and the docs endorse it explicitly.** Evidence:\n\n* `defineTool` / `defineSkill` / `defineSubagent` all exist specifically as *exportable, frozen, module-load-validated* units — described as \"the natural shape for tools shared across agents\" and \"the exportable unit — define a delegate once, mount it from any agent.\"\n* **Custom hooks are the documented composition unit:** \"a `useGitHub()` hook that bundles the right tools, skills, and instructions can be written once and dropped into every agent that works with GitHub.\" That is precisely a kernel-in-a-hook.\n* `@flue/runtime/tool` is a lighter entry point for tool-only modules — a library can depend on Flue without pulling in the server runtime.\n* Source-dir resolution order puts `.flue/` **first**, described as \"a self-contained Flue source area inside a larger application,\" with authored modules free to \"import ordinary supporting code from elsewhere in the project.\"\n* Per-mount overrides \"spread cleanly\": `useSubagent({ ...issueClassifier, model: 'anthropic/claude-haiku-4-5' })`.\n\nCounter-pressure: Flue insists the *agent itself* be a program, not config, and the `'use agent'` build-time scan means a library **cannot ship a pre-registered agent** — the agent module must be authored in the consuming project.\n\n**Recommendation (inference):** ship the kernel as a published custom hook — `useElicitationKernel(targetPlugin)` — that internally calls `useTool` / `useSkill` / `usePersistentState` / `useDataWriter` and returns instruction fragments, plus raw `defineTool` exports for hosts that want selective mounting. The host owns a ~10-line `'use agent'` module, the `app.ts` mount, and `db.ts`. This is library-in-a-thin-agent, and Flue's grain supports it. One real constraint: tool names are globally unique per render and collide with reserved names, so the kernel needs a namespacing convention.\n\n## 6. Channels as host surfaces\n\nA \"host input pathway\" in Flue is: verified ingress → `dispatch(agent, {id, message, initialData})`. Three distinct payload lanes:\n\n* `initialData` — recorded once at conversation creation, validated against the agent's schema static, read with `useInitialData()`, immutable thereafter. This is where an elicitation *target descriptor* belongs.\n* `kind: 'signal'` **messages** — `{type, body, attributes}` where `attributes` is a string→string map of facts *trusted code* attached. Read with `useDelivery()`. Docs push this hard as the authorization pattern: \"the model may choose an order ID to look up, but it cannot choose the customer.\" For a kernel, this is the channel for host-verified respondent identity. Channel deliveries are signals rather than `user` messages precisely because a Slack thread is multi-participant.\n* `kind: 'user'` — direct human turns.\n\n**Interviewing-UX rendering surfaces, ranked by fit:**\n\n1. `useDataWriter` **+** `@flue/react`**.** Named, schema-validated structured data parts arriving alongside text on the same message; a tool can write several times mid-run to drive live progress. `useFlueAgent({url})` gives `messages`, `parts`, `status`, `historyReady`, `sendMessage()`, `refresh()`. Message parts are `text | reasoning | dynamic-tool | file`, and **validated structured tool output is preserved on the** `dynamic-tool` **part's** `output` — the React docs say this exists \"so applications can render custom tool interfaces without a separate data-event channel.\" Direct fit for question cards, choice sets, and review panes.\n2. **Chat channels** (Slack/Teams/Discord/GitHub) for text-shaped interviewing only. There is **no outbound abstraction** — every reply is a tool you write against the provider SDK with the destination bound in trusted code (the `replyInThread(data)` pattern). Rich Slack Block Kit interviewing is entirely your code.\n\n**Gap worth flagging loudly: Flue documents no first-class human-in-the-loop / elicitation / interrupt primitive.** There is no \"ask the user and suspend\" hook. `terminate: true` on a tool result ends the turn once the current batch settles; the documented pattern for waiting on a human is state-gated tools (`record_approval` unlocks `publish_release`) plus a new inbound submission. **Inference:** the kernel must implement its own turn-suspension protocol — a `terminate: true` tool that writes the pending question into `usePersistentState` and emits a data part, with the host's answer arriving as a fresh `dispatch`. That is exactly the kind of thing a kernel *should* own, but Flue provides no scaffolding for it, so it is net-new work either way.\n\n## 7. Constraints & risks\n\n* **Maturity.** 2.0.3, with 2.0 a full API rewrite around hooks announced this cycle; a Migration Guide exists. `@flue/vite` first published 2026-07-10 (19 versions). Fast-moving — expect churn.\n* **Build-time magic is load-bearing.** `'use agent'` scanning, `SKILL.md` module imports, and agent-identity stamping all happen in the Vite plugin. **This effectively requires Vite.** A kernel published as a library must not depend on that transform internally — keep to `defineTool`/`defineSkill` (plain runtime calls) and let the host own the scanned module.\n* **Durable-identity coupling.** Conversation storage is keyed by agent function name. Always pin `agentName`.\n* **Cloudflare migration ceremony.** Adding an agent is always agent + mount + new DO migration tag. If the design ever wants *dynamic* agent creation per elicitation target, Cloudflare forbids it — agents are a build-time set. Use one agent + many conversation ids instead.\n* **Prompt-cache economics constrain dynamism.** \"Gate tools on state that changes rarely.\" An interviewing kernel that swaps tools per question would thrash the cache. Prefer one stable tool set + state-driven instructions, or skill activation (cache-safe by design).\n* **Valibot lock-in** at every schema boundary (`input`, `output`, `initialData`, `useDataWriter`, `harness.prompt({result})`). A kernel with Zod-based plugin contracts needs a conversion layer or a dual-schema strategy.\n* **Node multi-replica.** No active-active per conversation; you must own routing.\n* **Subagents are conversationally sterile** — no id, no state, no address. If elicitation-target plugins need their own durable memory, they cannot be subagents; they must be state + tools inside the parent, or separately registered agents.\n* **Petrinaut / non-React web-UI host risk:** the rich path (`useFlueAgent`) is React-specific. `@flue/sdk` (`createFlueClient` → `send/read/wait/observe/history`, built on `@durable-streams/client`) is framework-neutral and is what `@flue/react` sits on, so a non-React host is viable — but it must reimplement the materialized-snapshot / reconnect / canonical-reset layer that `useFlueAgent` provides. **Inference:** budget for that, or wrap `createFlueClient` directly and accept a thinner UI contract.\n* `skills` **frontmatter** `allowed-tools` **is accepted but not enforced** — Flue does not restrict the session toolset from a skill. Any kernel-level tool gating must be done with conditional `useTool`.\n\n## 8. Unreached sources\n\n**HTTP 404 (do not exist at those paths):** `/docs/guide/deployment/`, `/docs/guide/state/`, `/docs/guide/cloudflare/`, `/docs/guide/cli/`, `/docs/guide/github-actions-target/`, `/docs/reference/index.md`, `/llms.txt`. (Real equivalents: `/docs/guide/deploy/`, state is a section of `agent-hooks`, `/docs/guide/cloudflare-target/`.)\n\n**Exist but not fetched** (nav-confirmed; would sharpen specific answers): `/docs/guide/database/`, `/docs/guide/schedules/`, `/docs/guide/evals/`, `/docs/guide/observability/`, `/docs/guide/configuration/`, `/docs/guide/migration/`, `/docs/guide/agent-behavior/`, `/docs/reference/sandbox-api/`, `/docs/reference/provider-api/`, the full `/docs/reference/agent-hooks-api/` (indexed, read only via search), the CLI and Agent SDK reference sections, all `/docs/ecosystem/*` sub-pages, the `@flue/react` package README, and `examples/react-chat`. The GitHub repo (`withastro/flue`) source and Pi's own docs (`pi.dev/docs/latest`) were not read.\n+++",
+      "proposedBodySha256": "7c869076eb14b8d3bef3a1e446c269ec8bd8f616eb682b19598888a22546f300",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "d3e3d8b2-170a-4fa9-8ea8-26d396caa0b6",
+      "identifier": "FE-1368",
+      "url": "https://linear.app/hash/issue/FE-1368/zil-lean-survey-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.450Z",
+      "sourceTitle": "zil-lean survey [archive]",
+      "sourceDescriptionSha256": "a34174377a2da0548781191d7cbb33e606fb329065a5f14afe4d22454917596f",
+      "sourceTitleSha256": "aa2bdea3725452e09651b2a77e90deef72ab518995b82968d256935035bf1dad",
+      "oldOuter": "Examined zil-lean, a prototype claim-graph system, as a candidate second practice subject for the interviewing architecture. Conclusion: it contains no interviewing itself, but it is a working proof of the claim-graph idea; a smaller \"assurance argument\" slice was chosen as the second subject instead of the full system. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Assess zil-lean as an elicitation subject",
+      "proposedOuter": "This research assessed zil-lean, a prototype claim-graph system, as the second subject for testing the interviewing architecture. zil-lean does not include interviewing, but it demonstrates the claim-graph model. The plan therefore chose a smaller assurance-argument subject instead of the full system and resolved the research on 2026-08-06.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/02-zil-lean-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# zil-lean survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). This ticket's ElicitationPack sketch is superseded by ticket 09's `Statement` contract (pre-pass S10); the surviving contributions are the existence proof, the assurance lattice with prohibited promotions, derivation provenance, and the derived-status idea.\n\n## Question\n\nWhat elicitation-for-formal-verification insights does [https://github.com/jagg-ix/zil-lean](<https://github.com/jagg-ix/zil-lean>) hold, and is a lean/formal-flavored elicitation target *dev-sized* — small enough to develop the kernel against without wading into a massively complex target?\n\nSpecifically:\n\n* What is the repo: purpose, structure, how it relates natural-language intent to Lean formalization\n* What would an **ElicitationPack** for a lean-flavored target need: concept contract (what counts as a proposition/invariant/assumption), observation lenses, completion criteria\n* What would its **ProjectionPack** need: output contract/shape, validators (does Lean itself act as the deterministic validator?), lossiness\n* Verdict: dev-sized or too heavy? If too heavy, what is the smallest formal-flavored slice that still exercises both pack axes differently from elicit-gherkin? (Fallback second target is BPMN/process-mining.)\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Local clone for follow-up: scratchpad `zil-lean/` (session-temporary).\n\n# zil-lean survey\n\n## 1. What it is\n\n**Documented facts.**\n\n* `jagg-ix/zil-lean` — \"ZIL: a relational knowledge language implemented in Lean 4 with a Clojure runtime and toolchain.\" Primary language Clojure; no license file; 31 stars, 1 fork, 0 subscribers, 1 open issue, no topics.\n* **Provenance/activity**: repo created 2026-07-27T06:10, last push 2026-07-29T02:26. Entire history is **27 commits over \\~2 days**. First commit is \"Initial public snapshot\" by `github-actions[bot]`; all six PRs are branches named `agent/modularize-*`, `agent/complete-engine-governance-modules`. There is also a `PUBLIC-CONTENT-POLICY.md` and commits titled \"Isolate validated source publication.\" **Inference (high confidence)**: this is an agent-authored code dump published from a private working repo — ~140k tracked lines landed in one snapshot, then mechanically split into modules. Not an organically evolved project, and not battle-tested.\n* **Size/structure**: 532 files. `Zil/` (106 files, 14.2k lines Lean 4 — the native library), `src/zil/` (75 files, 17.5k lines Clojure — runtime/CLI/bridges), `spec/` (44 markdown specs, 5.3k lines), `examples/` (133 files, 85k lines — dominated by generated data), `lib/` + `libsets/` (`.zc` macro libraries), `test/` (57 files, 6.1k). Lean pinned to `leanprover/lean4:v4.31.0`.\n* **What \"ZIL\" is**: a **relation-tuple + Horn-rule (Datalog) knowledge language**, explicitly modeled on Google's Zanzibar `object#relation@user` tuple syntax, extended from authorization into general project knowledge: `declaration ─implements→ requirement`, `theorem ─validates→ component`, `claim ─supportedBy→ document`. Four primitives: nodes, relations, rules, queries. Two surface syntaxes (`.zc` tuple text; native Lean macros `zil_fact` / `zil_theorem_rule`) plus a canonical IR, snapshot format `ZILX/1`, delta format `ZILD/1`, revision log `ZILR/1`, and exporters to Soufflé and Prolog.\n* **Relation to Lean**: Lean is (a) the implementation host of the engine and (b) a **certification backend for a narrow slice**. `Zil.Trust` has three levels — `asserted` (registered fact), `graphDerived` (rule-inferred), `certified` (a rule paired with a Lean proposition + proof term, kernel-checked). Everything else about proofs is *bookkeeping*: `spec/proof-obligation-governance-v1.md` governs declared obligations across `z3 | tlaps | lean4 | acl2 | manual` and validates *presence of evidence references*, not their content (\"Lean kernel validation remain[s] the responsibility of [its] producing system\").\n\n**It is not**: a benchmark, a proof-automation system, an autoformalization pipeline, or anything with an LLM in it. `grep -ril 'openai|anthropic|llm|prompt|natural.language|gpt-'` across the repo hits **two files, both false positives** (a Terraform API schema, a config macro lib). \"assistant\" appears only as node names in examples (`assistant.formalization`, `assistant.codegen`) — agents are *modeled as nodes in the graph*, never as interviewers. **There is no elicitation, no question-asking, and no natural-language front-end anywhere in this repo.**\n\n## 2. Elicitation-relevant insights\n\nThe bookmark intuition is wrong about the surface but partly right about the substrate. zil-lean contains **no informal→formal capture**, but it is an unusually well-worked-out example of **the layer the kernel calls the claim graph** — and it is worth reading precisely for that.\n\nTransferable, documented:\n\n* **Evidence-graded claim graph as a first-class artifact.** `spec/assurance-levels-v1.md` defines five orthogonal labels — `exploratory`, `validated`, `kernel-backed`, `externally-attested`, `byte-attested` — with an explicit **prohibited-promotion lattice** (`validated ↛ kernel-backed`, `externally-attested ↛ kernel-backed`, `byte-attested ↛ validated`). Crucially: \"Assurance labels state what checked a result… must not be inferred from a successful exit code alone.\" Directly reusable as the kernel's IR annotation on captured claims, and the sharpest thing in the repo.\n* **Full derivation provenance.** `spec/derivation-provenance-v1.md`: every fact node carries `id / fact / origin / stratum`, where origin is `base` or `rule(ruleName, premiseFactIds, negativeChecks, binding)`. Query answers emit witnesses with premise fact IDs and bindings. Reports are deterministic and **timestamp-free** so they hash stably. This is the evidence-preserving IR the kernel wants, worked out concretely — including the honest caveat: \"The trace is graph-derived evidence. It is not a Lean kernel proof term.\"\n* **A concept vocabulary for formal-flavored capture that already distinguishes the kernel's hard cases.** `examples/formalization-arc-demo.zc` + `lib/theorem-dsl-macros.zc` separate **assumption** (with class + `ASSUME_HOLDS(source)` / `ASSUME_BROKEN(source, reason)`), **lemma**, **theorem**, **guarantee** (`THEOREM_ENSURES`), **evidence** (engine + token), **component**, **signal**, and **incident** (which can *break* an assumption and propagate). Derived statuses: `PROVED` (deps satisfied + witness), `CONDITIONAL` (witness but assumption under review), `WEAK` (no witness), `BROKEN` (required assumption broken). That is a completion-criteria ladder, expressed as Datalog, that the kernel could adopt nearly verbatim.\n* **Two forms of \"enough.\"** `spec/formalization-plan-v1.md` schedules `FORMALIZATION_TARGET` declarations (`module, file, declaration, status, priority, dependencies?`) over a validated acyclic dependency graph, defining *readiness* as `status ∈ {ready, in_progress} ∧ ∀dep. dep.status ∈ {verified, reviewed, proved}`, with structured blocking reasons (`status:<s>`, `missing:<t>`, `dependency:<t>:<s>`). `spec/agent-context-v1.md` defines a **context bundle** for handing a task to an agent — changed nodes → reverse impact → relevant facts → originating rules → auto-selected queries and targets — with explicit incompleteness issues (`unknown-changed-node`, `missing-query`, `missing-formalization-target`) and `context_bundle_id = sha256(report bytes)`.\n* **Drift detection on formal statements.** `spec/theorem-statement-locks-v1.md` locks `(token_id, declaration, module, kind, type_fingerprint)` and reports ordered check states (`fingerprint_changed`, `declaration_changed`, `missing_token`, `current_unresolved`, `unexpected_token`…). Answers \"did the formalization silently stop meaning what the user said?\" — a re-elicitation trigger.\n* **A request-elicitation schema that already exists.** `spec/request-form-core-v0.1.md` (draft) formalizes \"a requester asks for `<something>`\" as `Data | Action | Compound | Recursive`, with `mode ∈ {dry_run, apply}`, explicit `Effect` entities, and `Criterion` acceptance predicates, lowered to canonical tuples with derived judgments (`has_side_effect`, `is_recursive`, `execution_contract plan_only`). **Inference**: this is the closest thing in the repo to an elicitation target schema, and it is *not* Lean-flavored at all — it is intent-flavored. It may be more useful to the kernel than the theorem DSL.\n\nWhat zil-lean does **not** show, and the kernel must supply: how anyone *arrives* at these declarations. Every `.zc` file is hand-authored. There is no question generation, no ambiguity detection, no candidate extraction from prose, no clarification loop. The Lean checker is used as an oracle over *already-formal* artifacts, never as a feedback signal into a conversation.\n\n## 3. ElicitationPack sketch (elicit-lean/formal)\n\nGrounded in the vocabulary zil-lean shows is actually load-bearing.\n\n**Concept contract** — five kinds, distinguished by their *evidential obligations*, not their grammar:\n\n| Kind | Test | Obligation on capture |\n| -- | -- | -- |\n| `assumption` | Taken as given; not to be discharged here | must name a holder/source and a review status |\n| `invariant` | Must hold at all times over a named state/scope | must name scope + the state it constrains |\n| `proposition/theorem` | A claim asserted to follow from others | must name required assumptions + lemmas |\n| `guarantee` (ensures) | An outcome promised to a consumer | must attach to a producing component |\n| `constraint` | A restriction on inputs/config, not a claim about behavior | must name what it restricts |\n\nNon-negotiable per-item fields (from `THM_*` + proof-obligation governance): `id`, `criticality`, `depends_on: [assumption|lemma]`, `evidence?: (engine, token)`, `status`, and — added by the kernel, absent in zil-lean — `source_span` (the utterance it came from) and `paraphrase_confirmed: bool`.\n\n**Observation lenses** (what to notice in conversation):\n\n1. **Modal/quantifier lens** — \"always\", \"never\", \"must\", \"for every\", \"at most one\" → invariant candidate.\n2. **Hedge lens** — \"assuming\", \"as long as\", \"we can take for granted\", \"in practice X is well-formed\" → assumption candidate, and a *required* follow-up on who guarantees it. `a_input_well_formed` in the demo is exactly this shape.\n3. **Consequence lens** — \"so then\", \"which means\", \"that guarantees\" → proposition with an implicit dependency edge to name.\n4. **Break lens** — \"except when\", \"unless\", \"this fell over once when…\" → either a missing precondition on an existing item, or an incident that breaks an assumption (`INCIDENT_BREAK_ASSUMPTION`).\n5. **Undefined-term lens** — a noun used in a claim that has no node yet → must be introduced before the claim can be normalized.\n\n**Completion criteria** (ladder taken from the demo's status computation, plus dependency-closure from the plan spec):\n\n* *Structurally complete*: every claim's `depends_on` targets exist; dependency graph acyclic; every term referenced has a node. (Directly = the plan spec's set-validation rules.)\n* *Epistemically complete*: no claim is `WEAK` without the user having explicitly deferred it; every `CONDITIONAL` names the assumption under review and its owner; every `critical` item has either evidence or an explicit, reasoned waiver (governance spec forbids waiving critical items).\n* *Faithfulness*: every captured item has a user-confirmed paraphrase. This is the one criterion zil-lean cannot inform — there is no user in it.\n\n## 4. ProjectionPack sketch\n\n**Output contract**: the claim graph projects to a `.zc`-shaped tuple set plus derived-status queries — the `formalization-arc-demo.zc` shape is a working, concrete target. Textual, diffable, deterministic, machine-checkable *without Lean*.\n\n**Deterministic validators, in ascending cost** — and this is the important structural finding: **zil-lean demonstrates that Lean is the wrong first validator.** Three cheaper tiers exist and catch most errors:\n\n1. **Schema/graph validation** (free): unique IDs, nonnegative priorities, existing dependency targets, acyclicity, stratification safety, relation declared in some base fact or rule head (`unknown-relation` verdict).\n2. **Datalog closure** (cheap, deterministic, bounded — default fuel 64/stratum): derives `PROVED / CONDITIONAL / WEAK / BROKEN`, impact sets, break roots. The real workhorse oracle, and it runs on the *informal* graph.\n3. **Obligation governance** (cheap): checks that declared statuses are supported by evidence references — `proved-status-requires-evidence`, `obligation-not-discharged`, `waiver-reason-missing`, `critical-obligation-cannot-be-waived`.\n4. **Lean elaboration** (expensive, narrow): only for items actually written as Lean declarations. `spec/lean-verification-report-v1.md` runs `lake env lean <file>` per module + SHA-256 manifest match; `Zil.Trust.CertifiedRule` kernel-checks a proposition/proof pair.\n\nSo: **Lean serves as the deterministic validator only for the** `kernel-backed` **tier, and zil-lean's own architecture says you must not let success at tiers 1–3 masquerade as tier 4.** The prohibited-promotion table is the lossiness policy, pre-written.\n\n**What's lossy**: the natural-language statement itself (`statement` is a free-text field in the obligation schema, unvalidated); the *reason* an assumption is believed (only `source` is kept); alternative derivations (v1 provenance retains only the first witness); and — the deep one — the gap between \"Lean accepted this declaration\" and \"this declaration means what the user said.\" `theorem-statement-locks` spells it out: \"The lock does not claim that unchanged type fingerprints imply unchanged proof terms, source text, or external scientific meaning.\" The kernel must keep the utterance→claim→declaration chain because nothing downstream can reconstruct it.\n\n## 5. VERDICT — dev-sized?\n\n**A full elicit-lean/formal target is not dev-sized. A slice of it is, and it's a good one — but it is not the slice with Lean in it.**\n\nReasoning:\n\n* **The heavy part is real.** Getting from a user's claim to a Lean *statement* (not proof) requires committing to a type-theoretic encoding of the domain — the step autoformalization research finds hardest. That is deep-Lean-expertise work, and the contract is not definable without it. zil-lean quietly concedes this: it never writes theorem statements from intent. It stores `proof:Normalize.idempotent` as an opaque **token naming a declaration a human already wrote**. The demo file says so outright: \"Proof status here is bookkeeping only. The proof assistant remains the sole proof authority; proof tokens name checked declarations but do not assert them.\"\n* **The light part is genuinely there, and zil-lean is a working existence proof of it.** Eliciting an **assumption/lemma/theorem dependency graph with criticality and evidence pointers** — no Lean statements, no proofs — is weeks-scale. Every validator you need is graph-level and already specified in this repo.\n\n**Smallest formal-flavored slice: \"elicit-proof-obligations\" / the verification arc.** Interview a user about a system they believe is correct; capture assumptions (with owners and review status), lemmas, theorems, guarantees, and the dependency edges among them; attach evidence references where they exist; project to a `.zc`-style graph; validate by acyclicity + stratified Datalog closure yielding `PROVED/CONDITIONAL/WEAK/BROKEN` + break-root and impact queries.\n\n**Does it differ from elicit-gherkin on both pack axes? Yes, cleanly:**\n\n* *ElicitationPack*: Gherkin's concept contract is **scenario-shaped and example-driven** (Given/When/Then, concrete instances, no cross-item structure); completion is per-scenario coverage. This target's contract is **claim-shaped and dependency-structured** — the unit is a proposition with edges to other propositions, the hedge lens is central (Gherkin has no notion of an assumption), and completion is *graph closure plus evidence adequacy*, not enumeration. Different lenses, genuinely different \"enough.\"\n* *ProjectionPack*: Gherkin projects to a flat, independently-executable list; validation is parse + step-binding. This projects to a **DAG with derived statuses**, validated by fixpoint computation and an evidence-promotion lattice. The lossiness policy is substantive (assurance levels, first-witness-only) rather than near-absent.\n\n**Fallback comparison.** Take this slice **over** elicit-BPMN/process-mining as second target. Both differ from Gherkin, but the proof-obligation slice stresses the kernel harder on the axes the design cares about: it forces the claim-graph IR to carry *evidence grades and derivation provenance* (BPMN mostly forces sequencing and gateway structure, which Gherkin partly covers), and it gives you a deterministic non-trivial validator — a Datalog fixpoint — without any external tooling or domain SME. Keep BPMN as third; it's the better *breadth* target once the IR is stable, and it has an easier user-recruitment story. **Inference**, based on pack-axis distance, not on any BPMN sources reviewed here.\n\nOne caveat worth carrying: nothing in this repo has been validated by use. Treat the specs as well-reasoned design documents by an agent-assisted author, not as field-tested contracts — the `assurance-levels` lattice and the `THM_*` status ladder are worth stealing on their merits, not on their track record.\n\n## 6. Unreached sources\n\n* Did not build or run anything (`lake build`, `lake exe zilLeanTests`, `clojure -M:test`) — no Lean toolchain here; **all correctness claims are from specs and source, not execution.**\n* Did not read: the 129 Lean files in `Zil/` beyond filenames; `spec/zil-formal-core-v0.1.md` (427 lines, the core semantics); `spec/canonical-relational-ir-v0.1.md`; `spec/evidence-envelope-v1.md`; `spec/query-governance-v1.md`; `spec/recovery-audit-v1.md`; `spec/dmetavm-core-v0.1.md`; `formal/` (TLA+/SMT); the 17 `libsets/` domain packs; the 133 example files beyond three.\n* Repo wiki is enabled (`has_wiki: true`) — not checked. 1 open issue — not read. No discussions, no releases checked.\n* Author `jagg-ix` (Jorge A. Garcia) — no external profile or publication search performed, so no independent read on provenance beyond commit metadata.",
+      "innerSha256": "ae5914e467433c3a0002f56350c81322249cc6eb04ab971cf4371f994ab35d26",
+      "proposedBody": "This research assessed zil-lean, a prototype claim-graph system, as the second subject for testing the interviewing architecture. zil-lean does not include interviewing, but it demonstrates the claim-graph model. The plan therefore chose a smaller assurance-argument subject instead of the full system and resolved the research on 2026-08-06.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/02-zil-lean-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# zil-lean survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). This ticket's ElicitationPack sketch is superseded by ticket 09's `Statement` contract (pre-pass S10); the surviving contributions are the existence proof, the assurance lattice with prohibited promotions, derivation provenance, and the derived-status idea.\n\n## Question\n\nWhat elicitation-for-formal-verification insights does [https://github.com/jagg-ix/zil-lean](<https://github.com/jagg-ix/zil-lean>) hold, and is a lean/formal-flavored elicitation target *dev-sized* — small enough to develop the kernel against without wading into a massively complex target?\n\nSpecifically:\n\n* What is the repo: purpose, structure, how it relates natural-language intent to Lean formalization\n* What would an **ElicitationPack** for a lean-flavored target need: concept contract (what counts as a proposition/invariant/assumption), observation lenses, completion criteria\n* What would its **ProjectionPack** need: output contract/shape, validators (does Lean itself act as the deterministic validator?), lossiness\n* Verdict: dev-sized or too heavy? If too heavy, what is the smallest formal-flavored slice that still exercises both pack axes differently from elicit-gherkin? (Fallback second target is BPMN/process-mining.)\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Local clone for follow-up: scratchpad `zil-lean/` (session-temporary).\n\n# zil-lean survey\n\n## 1. What it is\n\n**Documented facts.**\n\n* `jagg-ix/zil-lean` — \"ZIL: a relational knowledge language implemented in Lean 4 with a Clojure runtime and toolchain.\" Primary language Clojure; no license file; 31 stars, 1 fork, 0 subscribers, 1 open issue, no topics.\n* **Provenance/activity**: repo created 2026-07-27T06:10, last push 2026-07-29T02:26. Entire history is **27 commits over \\~2 days**. First commit is \"Initial public snapshot\" by `github-actions[bot]`; all six PRs are branches named `agent/modularize-*`, `agent/complete-engine-governance-modules`. There is also a `PUBLIC-CONTENT-POLICY.md` and commits titled \"Isolate validated source publication.\" **Inference (high confidence)**: this is an agent-authored code dump published from a private working repo — ~140k tracked lines landed in one snapshot, then mechanically split into modules. Not an organically evolved project, and not battle-tested.\n* **Size/structure**: 532 files. `Zil/` (106 files, 14.2k lines Lean 4 — the native library), `src/zil/` (75 files, 17.5k lines Clojure — runtime/CLI/bridges), `spec/` (44 markdown specs, 5.3k lines), `examples/` (133 files, 85k lines — dominated by generated data), `lib/` + `libsets/` (`.zc` macro libraries), `test/` (57 files, 6.1k). Lean pinned to `leanprover/lean4:v4.31.0`.\n* **What \"ZIL\" is**: a **relation-tuple + Horn-rule (Datalog) knowledge language**, explicitly modeled on Google's Zanzibar `object#relation@user` tuple syntax, extended from authorization into general project knowledge: `declaration ─implements→ requirement`, `theorem ─validates→ component`, `claim ─supportedBy→ document`. Four primitives: nodes, relations, rules, queries. Two surface syntaxes (`.zc` tuple text; native Lean macros `zil_fact` / `zil_theorem_rule`) plus a canonical IR, snapshot format `ZILX/1`, delta format `ZILD/1`, revision log `ZILR/1`, and exporters to Soufflé and Prolog.\n* **Relation to Lean**: Lean is (a) the implementation host of the engine and (b) a **certification backend for a narrow slice**. `Zil.Trust` has three levels — `asserted` (registered fact), `graphDerived` (rule-inferred), `certified` (a rule paired with a Lean proposition + proof term, kernel-checked). Everything else about proofs is *bookkeeping*: `spec/proof-obligation-governance-v1.md` governs declared obligations across `z3 | tlaps | lean4 | acl2 | manual` and validates *presence of evidence references*, not their content (\"Lean kernel validation remain[s] the responsibility of [its] producing system\").\n\n**It is not**: a benchmark, a proof-automation system, an autoformalization pipeline, or anything with an LLM in it. `grep -ril 'openai|anthropic|llm|prompt|natural.language|gpt-'` across the repo hits **two files, both false positives** (a Terraform API schema, a config macro lib). \"assistant\" appears only as node names in examples (`assistant.formalization`, `assistant.codegen`) — agents are *modeled as nodes in the graph*, never as interviewers. **There is no elicitation, no question-asking, and no natural-language front-end anywhere in this repo.**\n\n## 2. Elicitation-relevant insights\n\nThe bookmark intuition is wrong about the surface but partly right about the substrate. zil-lean contains **no informal→formal capture**, but it is an unusually well-worked-out example of **the layer the kernel calls the claim graph** — and it is worth reading precisely for that.\n\nTransferable, documented:\n\n* **Evidence-graded claim graph as a first-class artifact.** `spec/assurance-levels-v1.md` defines five orthogonal labels — `exploratory`, `validated`, `kernel-backed`, `externally-attested`, `byte-attested` — with an explicit **prohibited-promotion lattice** (`validated ↛ kernel-backed`, `externally-attested ↛ kernel-backed`, `byte-attested ↛ validated`). Crucially: \"Assurance labels state what checked a result… must not be inferred from a successful exit code alone.\" Directly reusable as the kernel's IR annotation on captured claims, and the sharpest thing in the repo.\n* **Full derivation provenance.** `spec/derivation-provenance-v1.md`: every fact node carries `id / fact / origin / stratum`, where origin is `base` or `rule(ruleName, premiseFactIds, negativeChecks, binding)`. Query answers emit witnesses with premise fact IDs and bindings. Reports are deterministic and **timestamp-free** so they hash stably. This is the evidence-preserving IR the kernel wants, worked out concretely — including the honest caveat: \"The trace is graph-derived evidence. It is not a Lean kernel proof term.\"\n* **A concept vocabulary for formal-flavored capture that already distinguishes the kernel's hard cases.** `examples/formalization-arc-demo.zc` + `lib/theorem-dsl-macros.zc` separate **assumption** (with class + `ASSUME_HOLDS(source)` / `ASSUME_BROKEN(source, reason)`), **lemma**, **theorem**, **guarantee** (`THEOREM_ENSURES`), **evidence** (engine + token), **component**, **signal**, and **incident** (which can *break* an assumption and propagate). Derived statuses: `PROVED` (deps satisfied + witness), `CONDITIONAL` (witness but assumption under review), `WEAK` (no witness), `BROKEN` (required assumption broken). That is a completion-criteria ladder, expressed as Datalog, that the kernel could adopt nearly verbatim.\n* **Two forms of \"enough.\"** `spec/formalization-plan-v1.md` schedules `FORMALIZATION_TARGET` declarations (`module, file, declaration, status, priority, dependencies?`) over a validated acyclic dependency graph, defining *readiness* as `status ∈ {ready, in_progress} ∧ ∀dep. dep.status ∈ {verified, reviewed, proved}`, with structured blocking reasons (`status:<s>`, `missing:<t>`, `dependency:<t>:<s>`). `spec/agent-context-v1.md` defines a **context bundle** for handing a task to an agent — changed nodes → reverse impact → relevant facts → originating rules → auto-selected queries and targets — with explicit incompleteness issues (`unknown-changed-node`, `missing-query`, `missing-formalization-target`) and `context_bundle_id = sha256(report bytes)`.\n* **Drift detection on formal statements.** `spec/theorem-statement-locks-v1.md` locks `(token_id, declaration, module, kind, type_fingerprint)` and reports ordered check states (`fingerprint_changed`, `declaration_changed`, `missing_token`, `current_unresolved`, `unexpected_token`…). Answers \"did the formalization silently stop meaning what the user said?\" — a re-elicitation trigger.\n* **A request-elicitation schema that already exists.** `spec/request-form-core-v0.1.md` (draft) formalizes \"a requester asks for `<something>`\" as `Data | Action | Compound | Recursive`, with `mode ∈ {dry_run, apply}`, explicit `Effect` entities, and `Criterion` acceptance predicates, lowered to canonical tuples with derived judgments (`has_side_effect`, `is_recursive`, `execution_contract plan_only`). **Inference**: this is the closest thing in the repo to an elicitation target schema, and it is *not* Lean-flavored at all — it is intent-flavored. It may be more useful to the kernel than the theorem DSL.\n\nWhat zil-lean does **not** show, and the kernel must supply: how anyone *arrives* at these declarations. Every `.zc` file is hand-authored. There is no question generation, no ambiguity detection, no candidate extraction from prose, no clarification loop. The Lean checker is used as an oracle over *already-formal* artifacts, never as a feedback signal into a conversation.\n\n## 3. ElicitationPack sketch (elicit-lean/formal)\n\nGrounded in the vocabulary zil-lean shows is actually load-bearing.\n\n**Concept contract** — five kinds, distinguished by their *evidential obligations*, not their grammar:\n\n| Kind | Test | Obligation on capture |\n| -- | -- | -- |\n| `assumption` | Taken as given; not to be discharged here | must name a holder/source and a review status |\n| `invariant` | Must hold at all times over a named state/scope | must name scope + the state it constrains |\n| `proposition/theorem` | A claim asserted to follow from others | must name required assumptions + lemmas |\n| `guarantee` (ensures) | An outcome promised to a consumer | must attach to a producing component |\n| `constraint` | A restriction on inputs/config, not a claim about behavior | must name what it restricts |\n\nNon-negotiable per-item fields (from `THM_*` + proof-obligation governance): `id`, `criticality`, `depends_on: [assumption|lemma]`, `evidence?: (engine, token)`, `status`, and — added by the kernel, absent in zil-lean — `source_span` (the utterance it came from) and `paraphrase_confirmed: bool`.\n\n**Observation lenses** (what to notice in conversation):\n\n1. **Modal/quantifier lens** — \"always\", \"never\", \"must\", \"for every\", \"at most one\" → invariant candidate.\n2. **Hedge lens** — \"assuming\", \"as long as\", \"we can take for granted\", \"in practice X is well-formed\" → assumption candidate, and a *required* follow-up on who guarantees it. `a_input_well_formed` in the demo is exactly this shape.\n3. **Consequence lens** — \"so then\", \"which means\", \"that guarantees\" → proposition with an implicit dependency edge to name.\n4. **Break lens** — \"except when\", \"unless\", \"this fell over once when…\" → either a missing precondition on an existing item, or an incident that breaks an assumption (`INCIDENT_BREAK_ASSUMPTION`).\n5. **Undefined-term lens** — a noun used in a claim that has no node yet → must be introduced before the claim can be normalized.\n\n**Completion criteria** (ladder taken from the demo's status computation, plus dependency-closure from the plan spec):\n\n* *Structurally complete*: every claim's `depends_on` targets exist; dependency graph acyclic; every term referenced has a node. (Directly = the plan spec's set-validation rules.)\n* *Epistemically complete*: no claim is `WEAK` without the user having explicitly deferred it; every `CONDITIONAL` names the assumption under review and its owner; every `critical` item has either evidence or an explicit, reasoned waiver (governance spec forbids waiving critical items).\n* *Faithfulness*: every captured item has a user-confirmed paraphrase. This is the one criterion zil-lean cannot inform — there is no user in it.\n\n## 4. ProjectionPack sketch\n\n**Output contract**: the claim graph projects to a `.zc`-shaped tuple set plus derived-status queries — the `formalization-arc-demo.zc` shape is a working, concrete target. Textual, diffable, deterministic, machine-checkable *without Lean*.\n\n**Deterministic validators, in ascending cost** — and this is the important structural finding: **zil-lean demonstrates that Lean is the wrong first validator.** Three cheaper tiers exist and catch most errors:\n\n1. **Schema/graph validation** (free): unique IDs, nonnegative priorities, existing dependency targets, acyclicity, stratification safety, relation declared in some base fact or rule head (`unknown-relation` verdict).\n2. **Datalog closure** (cheap, deterministic, bounded — default fuel 64/stratum): derives `PROVED / CONDITIONAL / WEAK / BROKEN`, impact sets, break roots. The real workhorse oracle, and it runs on the *informal* graph.\n3. **Obligation governance** (cheap): checks that declared statuses are supported by evidence references — `proved-status-requires-evidence`, `obligation-not-discharged`, `waiver-reason-missing`, `critical-obligation-cannot-be-waived`.\n4. **Lean elaboration** (expensive, narrow): only for items actually written as Lean declarations. `spec/lean-verification-report-v1.md` runs `lake env lean <file>` per module + SHA-256 manifest match; `Zil.Trust.CertifiedRule` kernel-checks a proposition/proof pair.\n\nSo: **Lean serves as the deterministic validator only for the** `kernel-backed` **tier, and zil-lean's own architecture says you must not let success at tiers 1–3 masquerade as tier 4.** The prohibited-promotion table is the lossiness policy, pre-written.\n\n**What's lossy**: the natural-language statement itself (`statement` is a free-text field in the obligation schema, unvalidated); the *reason* an assumption is believed (only `source` is kept); alternative derivations (v1 provenance retains only the first witness); and — the deep one — the gap between \"Lean accepted this declaration\" and \"this declaration means what the user said.\" `theorem-statement-locks` spells it out: \"The lock does not claim that unchanged type fingerprints imply unchanged proof terms, source text, or external scientific meaning.\" The kernel must keep the utterance→claim→declaration chain because nothing downstream can reconstruct it.\n\n## 5. VERDICT — dev-sized?\n\n**A full elicit-lean/formal target is not dev-sized. A slice of it is, and it's a good one — but it is not the slice with Lean in it.**\n\nReasoning:\n\n* **The heavy part is real.** Getting from a user's claim to a Lean *statement* (not proof) requires committing to a type-theoretic encoding of the domain — the step autoformalization research finds hardest. That is deep-Lean-expertise work, and the contract is not definable without it. zil-lean quietly concedes this: it never writes theorem statements from intent. It stores `proof:Normalize.idempotent` as an opaque **token naming a declaration a human already wrote**. The demo file says so outright: \"Proof status here is bookkeeping only. The proof assistant remains the sole proof authority; proof tokens name checked declarations but do not assert them.\"\n* **The light part is genuinely there, and zil-lean is a working existence proof of it.** Eliciting an **assumption/lemma/theorem dependency graph with criticality and evidence pointers** — no Lean statements, no proofs — is weeks-scale. Every validator you need is graph-level and already specified in this repo.\n\n**Smallest formal-flavored slice: \"elicit-proof-obligations\" / the verification arc.** Interview a user about a system they believe is correct; capture assumptions (with owners and review status), lemmas, theorems, guarantees, and the dependency edges among them; attach evidence references where they exist; project to a `.zc`-style graph; validate by acyclicity + stratified Datalog closure yielding `PROVED/CONDITIONAL/WEAK/BROKEN` + break-root and impact queries.\n\n**Does it differ from elicit-gherkin on both pack axes? Yes, cleanly:**\n\n* *ElicitationPack*: Gherkin's concept contract is **scenario-shaped and example-driven** (Given/When/Then, concrete instances, no cross-item structure); completion is per-scenario coverage. This target's contract is **claim-shaped and dependency-structured** — the unit is a proposition with edges to other propositions, the hedge lens is central (Gherkin has no notion of an assumption), and completion is *graph closure plus evidence adequacy*, not enumeration. Different lenses, genuinely different \"enough.\"\n* *ProjectionPack*: Gherkin projects to a flat, independently-executable list; validation is parse + step-binding. This projects to a **DAG with derived statuses**, validated by fixpoint computation and an evidence-promotion lattice. The lossiness policy is substantive (assurance levels, first-witness-only) rather than near-absent.\n\n**Fallback comparison.** Take this slice **over** elicit-BPMN/process-mining as second target. Both differ from Gherkin, but the proof-obligation slice stresses the kernel harder on the axes the design cares about: it forces the claim-graph IR to carry *evidence grades and derivation provenance* (BPMN mostly forces sequencing and gateway structure, which Gherkin partly covers), and it gives you a deterministic non-trivial validator — a Datalog fixpoint — without any external tooling or domain SME. Keep BPMN as third; it's the better *breadth* target once the IR is stable, and it has an easier user-recruitment story. **Inference**, based on pack-axis distance, not on any BPMN sources reviewed here.\n\nOne caveat worth carrying: nothing in this repo has been validated by use. Treat the specs as well-reasoned design documents by an agent-assisted author, not as field-tested contracts — the `assurance-levels` lattice and the `THM_*` status ladder are worth stealing on their merits, not on their track record.\n\n## 6. Unreached sources\n\n* Did not build or run anything (`lake build`, `lake exe zilLeanTests`, `clojure -M:test`) — no Lean toolchain here; **all correctness claims are from specs and source, not execution.**\n* Did not read: the 129 Lean files in `Zil/` beyond filenames; `spec/zil-formal-core-v0.1.md` (427 lines, the core semantics); `spec/canonical-relational-ir-v0.1.md`; `spec/evidence-envelope-v1.md`; `spec/query-governance-v1.md`; `spec/recovery-audit-v1.md`; `spec/dmetavm-core-v0.1.md`; `formal/` (TLA+/SMT); the 17 `libsets/` domain packs; the 133 example files beyond three.\n* Repo wiki is enabled (`has_wiki: true`) — not checked. 1 open issue — not read. No discussions, no releases checked.\n* Author `jagg-ix` (Jorge A. Garcia) — no external profile or publication search performed, so no independent read on provenance beyond commit metadata.\n+++",
+      "proposedBodySha256": "acdf4e736f42e9c2600955c0daea658a8f66ca3788a89654f4ef5c23a6477df9",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "75228d43-47c4-4197-858c-433334016a59",
+      "identifier": "FE-1369",
+      "url": "https://linear.app/hash/issue/FE-1369/brunch-exchange-schema-audit-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.340Z",
+      "sourceTitle": "Brunch exchange-schema audit [archive]",
+      "sourceDescriptionSha256": "1fd94e7b433040097a806d169e9cd702bb67db2dcbf906a5e197e678ed4249c2",
+      "sourceTitleSha256": "dfdef0d5ba4e9548fd25e728e40fb8685c0bd6e0daa4432d3793d8d5d6cb85e6",
+      "oldOuter": "Catalogued how the existing brunch app structures its question-and-answer exchanges, sorting every part into keep / adapt / leave behind for the new library. The generic asking machinery survives; brunch-specific vocabulary and review structures do not. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Classify Brunch exchange structures for reuse",
+      "proposedOuter": "This audit classified each part of the existing Brunch question-and-answer exchanges by whether the new library should keep, adapt, or leave it behind. The generic asking machinery remains useful, while Brunch-specific vocabulary and review structures do not carry forward. The audit was resolved on 2026-08-06.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Brunch exchange-schema audit\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nCatalog brunch's structured-exchange vocabulary and classify each element as **generic to any elicitation** vs. **brunch-specific** (coupled to the spec-graph/product), so the questioning-UX and contract-decomposition tickets inherit a map of what to keep, generalize, or drop.\n\nSpecifically, in `../brunch` (read-only):\n\n* `src/exchanges/` — schemas (`ask`, `present_candidates`, `present_digest`, `present_review_set`, `request_choice`/`request_review`, capture/editor envelopes), projections, recovery\n* `src/agents/runtime/elicitor/` — prompt/context assembly, active-tool policy, the control-ownership table (spec posture / elicitation style / asking agenda)\n* `src/agents/skills/` — the activity-move routing table (analyze/elicit/ingest/propose/project/map/review) as candidate generic elicitation routines\n* Relevant `TOPOLOGY.md` files for boundary intent\n\nFor each element: what interaction problem it solves, where it hard-codes brunch's graph/spec shape, and any right-sizedness doubts visible in the code or docs (the abstractions \"were also just a guess\" — look for strain marks: legacy kept-for-reads projections, migration notes, loud failure modes).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Facts cited to file:line-range in `../brunch`; judgments marked **\\[J\\]**.\n\n# Brunch Structured-Exchange & Elicitor Audit\n\n## 1. Exchange catalog\n\n`ask` **(the only registered interactive terminal).** Solves: getting exactly one typed response from a human, in one of four shapes, without a separate collect tool per shape. Params (`src/exchanges/schemas/params.ts:~180-215`) carry markdown `body`, optional `options[]`, `multiple`, `allowOther`, `allowNone`, `commentPrompt`, `topLabel`/`bottomLabel`; no options ⇒ free text, options ⇒ single choice, options + `multiple` ⇒ multi-choice (`src/.pi/extensions/exchanges/TOPOLOGY.md`, \"Answer sources\"). Details (`src/exchanges/schemas/request.ts:~390-460`) echo the question *and* the answer in one result: `question` echo (body, options, `commentPrompt`, `otherPrompt`) plus exactly one of `answered | cancelled | unavailable` — a **property-presence union** rather than a status enum (`src/exchanges/schemas/TOPOLOGY.md:293-300`). Continuation: `ask({ continues: exchange_id })` reads the declared continuation off a prior present; model-authored payload fields on a continuing ask are rejected at the params boundary (`params.ts` `zAskParams.superRefine`, message `\"continuing ask payload is declared by the referenced offer\"`).\n\n`present_candidates`**.** Solves: fan-out comparison — let the user *recognize* a direction among alternatives instead of authoring one. Details (`src/exchanges/schemas/present.ts:185-235`): `display{heading, body?}` plus `candidates[]` of `{id, title, user_rubric, meta_rubric, graph_refs[]}`. `user_rubric` is six required nonblank markdown fields — `core_bet, best_fit, cost_complexity, covers_well, main_risks, lock_in_constraints` (+ optional `recommendation`); `meta_rubric` is four optional fields — `legibility_cost_of_knowing, failure_modes, coverage_range, commitment` (the D31-L four-axis meta-rubric, `memory/SPEC.md:262`). Continuation: `continuation: zOptionRequiredAskContinuationDeclaration` → `{tool: \"ask\", params: {body, options, ...}}`; the answer emits a `request_choice` detail discriminant with `tool_meta.prev = present_candidates`, and may lead to `capture_candidate`.\n\n`present_digest`**.** Solves: putting a large ingested source in front of the user as prose. Details (`present.ts:237-262`): `digest{abstract (required, nonblank), analysis?, recommendation?}`. Explicitly *not* a graph carrier — graph payload fields are rejected (`schemas/TOPOLOGY.md:289`). Continuation is the **free-text** variant (`zFreeTextAskContinuationDeclaration`, which `z.never()`s options/multiple/allowOther/allowNone/commentPrompt/labels — `shared.ts`), collecting conversational feedback only. Acceptance is deliberately *not* a review decision: a later standalone `ask({acceptsDigest, questions})` questionnaire or a `confirm|revise` single-select mints the accepted carrier, copying `accepted_abstract` from the runtime-resolved digest — caller-authored abstracts are rejected (`src/exchanges/TOPOLOGY.md:27`; `projections/ask.ts` `projectDigestQuestionnaire` / `projectDigestConfirmation`).\n\n`present_review_set`**.** Solves: batch approval of a structurally valid graph-mutation proposal. Details (`present.ts:60-180`): `review_set{nodes[], edges[]}` where each node is `{draft_id, proposed_code, settlement: advisory|settled, plane: intent|oracle|design|plan, kind, title, body?, detail?}` and each edge is a role-named discriminated union over nine categories (`dependency, witness, rationale, realization, refinement, exclusion, composition, cross_reference, supersession`) with `{draft_id}|{existing_code}` endpoint refs. Continuation is option-required. Approval is the commit: an approved continuation invokes shared settlement *before* `ask.execute` returns, so only a committed, `receipt`-bearing result is appended (`.pi/extensions/exchanges/TOPOLOGY.md`; `ask/continuation.ts:527` throws `'Review-set approval must route through shared settlement'`). `request_changes` requires a comment; `request_changes`/`reject` are terminal-only, no graph effect.\n\n**Legacy** `present_question`**.** A merged question/offer anchor (`response_kind: answer|choice|choices` + options inline). Unregistered; its Pi adapter is deleted; the projection survives only for old persisted reads (`schemas/TOPOLOGY.md:132-134`; `projections/present-question.ts`).\n\n`request_choice` **/** `request_review` **/** `request_answer` **/** `request_choices`**.** No longer registered tools — they are the *preserved wire vocabulary* for terminal details, so capture/sweep readers keep reading what they always read (`.pi/extensions/exchanges/TOPOLOGY.md:81-84`). `request_review` projection callers must pass a present-tool discriminator because review-set and digest close through the same detail kind but capture reads them differently (`projections/request-response/review.ts` `ReviewPresentTool`).\n\n**Capture envelopes.** `capture_answer|choice|choices|review|candidate` (`schemas/capture.ts`), each a `zCaptureDetailsHeader` + `tool_meta{prev, curr}`. Graph payloads intentionally undesigned in this pass (`schemas/TOPOLOGY.md:386-390`); `capture_candidate` consumes only the selected id.\n\n**Editor envelope.** `editor.ts` is a *wire* envelope, not transcript detail: a JSON blob prefilled into `ctx.ui.editor` for the one payload Pi built-ins can't carry over RPC (multi-choice). Its `status: 'answered'|'cancelled'` string never enters details, which carry outcome as key presence (`schemas/TOPOLOGY.md:36-38`).\n\n**Questionnaires.** `schemas/questionnaire.ts`: `{id, kind: free-text|single-select|multi-select, prompt, options[]}` questions and kind-matched answers, replayed on persisted completion so IDs/kinds/option-membership/completeness can't diverge.\n\n## 2. Classification\n\n| Element | Class | Change needed / coupling |\n| -- | -- | -- |\n| `ask` single-tool-four-shapes | **Generic** | The strongest abstraction here. **\\[J\\]** One terminal covering free-text/single/multi + a declared-continuation mode is the right primitive. |\n| Property-presence terminal union (`answered`/`cancelled`/`unavailable`) | **Generic** | Distinguishes \"user declined\" from \"no UI available\" — both are non-answers, and conflating them is the classic bug. |\n| `comment` (user-authored) vs `message` (system-authored) split | **Generic** | `schemas/TOPOLOGY.md:108-112`. Cheap, high-value provenance discipline. |\n| Question-echo-in-result (self-contained terminal) | **Generic** | Makes the transcript replayable without joining back to the present. |\n| Declared continuation (`present` names its own terminal; collector rejects model re-authoring) | **Generic** | **\\[J\\]** The single most transferable idea: the offer owns the answer vocabulary, so the model cannot drift the options between showing and collecting. |\n| `exchange_id` + `tool_meta{prev,curr,next}` chain | **Generalize-with-changes** | Currently a hand-maintained discriminated union of ~15 literal prev/curr/next triples (`shared.ts`). Replace with a generic `{exchangeId, parentId?}` link + one `form` tag; the pairwise enumeration is combinatorial and buys little. |\n| Recovery scan / pending-present resumption | **Generic** | `recovery.ts:78-81`: only an *answered* terminal closes an exchange; cancelled/unavailable stay resumable. Any interviewer needs this. |\n| Present-then-ask two-step (offer ≠ collection) | **Generalize-with-changes** | Generic as \"render surface separate from input surface\", but brunch pins the offer set at three named tools. A kernel wants one `present(form, payload)` with pluggable payload validators. |\n| `present_candidates` as an *interaction* | **Generic** | Fan-out/compare/recognize is plane-invariant (A31-L, `memory/SPEC.md:111`). |\n| Candidate `user_rubric` (six required fields) | **Brunch-specific** | Hard-codes brunch's product judgment about what makes specs comparable (`core_bet`, `lock_in_constraints`). A kernel should take a caller-declared rubric schema. |\n| Candidate `meta_rubric` (D31-L four axes) | **Generalize-with-changes** | SPEC calls it \"a soft heuristic… not architecturally enforced\" (`memory/SPEC.md:262`) yet it is a required schema key. Demote to optional caller-supplied axes. |\n| `graph_refs[]` on candidates | **Brunch-specific** | Node-id coupling to the spec graph. |\n| `present_digest` as an interaction | **Generic** | \"Here is my reading of your source; react to it\" is universal to ingestion-shaped interviewing. |\n| Digest accept-via-later-carrier (feedback ≠ acceptance) | **Generalize-with-changes** | **\\[J\\]** The *separation* is a real lesson; the specific `acceptsDigest`/`accepted_abstract` field names and the \"runtime resolves the final eligible digest\" recognizer (`recovery.ts:18`) are brunch plumbing. |\n| `present_review_set` as an interaction | **Generalize-with-changes** | \"Approve/request-changes/reject a proposed batch of writes, atomically\" is generic. Brunch's version hardwires the target. |\n| Review-set node/edge draft schema | **Brunch-specific** | `plane: intent\\|oracle\\|design\\|plan`, nine graph edge categories, `settlement: advisory\\|settled` (D27-L), `proposed_code`. Params import `zReviewSetProposalPayloadForBoundary` from `graph/review-set.ts` — the only inbound coupling `exchanges/` allows (`exchanges/TOPOLOGY.md`, dependency direction). |\n| \"Boundary-teaching\" schema (advertise nested shape so the model sees it before the deep validator runs) | **Generic** | `schemas/TOPOLOGY.md:47-52`. **\\[J\\]** A genuinely good pattern: shallow schema for model legibility, deep validator for correctness. |\n| Approval-commits-atomically + receipt | **Generalize-with-changes** | Generic as \"the approve branch runs the target's commit and the terminal carries the target's receipt\"; `MutateGraphSuccess` (`request.ts:1`) is the coupling. Kernel needs an opaque target-supplied receipt type. |\n| Capture layer | **Brunch-specific** | Exists as envelope only, graph payloads undesigned; `capture_candidate` semantics are graph-shaped. |\n| Editor envelope (`editor.ts`) | **Generalize-with-changes** | Real problem (host UI can't carry a payload over RPC), brunch-shaped solution. Kernel: name it a \"degraded-transport fallback\", don't bind it to multi-choice. |\n| Option-id regex `^[^>\\r\\n]+$` | **Generalize-with-changes** | The comment says ids round-trip through an HTML-comment marker recovered by a regex stopping at `>` (`params.ts`). **\\[J\\]** A rendering leak in a validation schema — a kernel should encode ids opaquely instead. |\n| `active-tools.ts` allowlist | **Generalize-with-changes** | Generic pattern (fixed tool policy per role), brunch-specific contents (`read_graph`, `mutate_graph`, `read_elicitation_scratchpad`). |\n| Elicitation scratchpad (private, non-authoritative obligations) | **Generic** | D101-L: session-local, last-snapshot-wins, \"durable truth stays in the graph; low-confidence noticings land here.\" Every interviewer needs a place for \"noticed, not yet asked.\" |\n| `elicitation_style: interrogate\\|disambiguate\\|propose` | **Generic** | `session/elicitation-style.ts`. Style ≠ authority ≠ capability. |\n| `warrant-before-commit` directive (hash-pinned, ablatable) | **Generic** | `compose-live-prompt.ts` validates exactly one directive block, hashes it, exposes it as `providerVisibleText`, and supports dev-only ablation. **\\[J\\]** Treating one prompt paragraph as a versioned, A/B-testable artifact is a pattern worth stealing outright. |\n| Skill moves `analyze / elicit / ingest / propose / project / review` | **Generic** | These six are the actual elicitation routine vocabulary. |\n| Skill move `map` | **Brunch-specific** | Graph vocabulary/routing/persistence. |\n| Skill move `tutorial` | **Brunch-specific** | Product walkthrough of Brunch itself. |\n| `elicit` topology-driven question ranking table | **Generalize-with-changes** | The *shape* — structural signal in the target ⇒ question shape — is generic; every row names graph kinds (`assumption`, `witness` path, `criterion`, `exclusion`). Kernel: targets supply their own signal→question-shape table. |\n| Readiness bands as \"concentric concern envelopes, not workflow stages\" | **Generalize-with-changes** | **\\[J\\]** Excellent dialogue policy (\"absence matters *later*, capture is never illegal earlier\"); the band vocabulary is brunch's. |\n| Prompt-injected skill manifest (`<brunch-skills>` with absolute paths, \"do not infer additional skills\") | **Generic** | `skills/registry.ts` `renderBrunchSkills`. |\n| `intent -> design -> verification -> scope -> build` handoff sequence, frontier/scope edge directions, `PROJECT_EXECUTION_HARNESS_TITLE` verify-recipe block | **Brunch-specific** | `prompts/elicitor.md`; `compose-live-prompt.ts` `renderProjectExecutionHarnessGuidance`. |\n\n## 3. Strain marks\n\n**Legacy-kept-for-reads.** `present-question.ts` and `request-response.ts` survive as projections with no registered tool (`exchanges/TOPOLOGY.md:22`; `.pi/.../TOPOLOGY.md:81-84`). `shared.ts` literally names the residue: `STRUCTURED_EXCHANGE_TERMINAL_NAMES = { current: 'ask', legacyRequestPrefix: 'request_' }`. The tool topology collapsed from `present_question → request_response` to `ask`, but the *detail* vocabulary could not follow because capture/sweep readers were written against it.\n\n**Same detail kind, two meanings.** `request_review` closes both review-set and digest, so `projectRequestReview` demands a `ReviewPresentTool` discriminator from callers (`projections/request-response/review.ts`). Receipts are required for review-set approval and *strictly rejected* on every digest branch (`schemas/TOPOLOGY.md:~325`). **\\[J\\]** Two different transactions wearing one name — a merge that shouldn't have happened.\n\n**A retracted merge.** Digest acceptance *was* a review decision and was pulled back out: \"digest acceptance is no longer a review decision\" (`exchanges/TOPOLOGY.md:27`), with `recovery.ts:31-36` retaining a `legacyReview` parse path for digests approved under the old model.\n\n**Doc/code drift on edge categories.** `schemas/TOPOLOGY.md:194` documents `dependency | proof | support | realization | boundary | composition | association | supersession`; the Zod in `present.ts:89-160` implements `dependency | witness | rationale | realization | refinement | exclusion | composition | cross_reference | supersession`. Four categories were renamed and the schema doc was not updated.\n\n**Retired axes.** D98-L retired strategy/lens/method as runtime or manifest state; A35-L records the retreat: the axis model \"may still be useful as prompt-resource organization, but it is no longer trusted as user-changeable or transcript-backed runtime state\" (`memory/SPEC.md:115`). The migration note in `skills/TOPOLOGY.md` maps seven old constructs onto activity homes and ends with a hard rule: *\"if a skill is live, it appears in the first-level registry; if guidance is not there, it is not switchable product state.\"* Retired axes also left dead vocabulary behind — `lens` is still advertised in the review-set boundary schema (`schemas/TOPOLOGY.md:50`) and the elicitor prompt still says \"plan-lens review set\".\n\n**Loud failure modes.** Only two `throw`s in the whole exchange surface, both about authority: `'Review-set approval must route through shared settlement'` (`ask/continuation.ts:527`) and `'parsed ask parameters do not describe a runtime variant'` (`ask.ts:748`). Everything user-facing degrades to an `unavailable` terminal with a message instead (`continuation.ts:222` — a missing continuation declaration is an error string, not a crash). Params failures return bounded `TOOL_INPUT_INVALID` tool results with no human-visible transcript line.\n\n**Where validation lives (revised once).** D105-L: validate at trust boundaries — LLM params, RPC input, editor replies, transcript read-back — *not* inside constructors, which \"do not parse objects [they] just built.\" D108-L consolidated the whole contract out of two prior homes (`src/.pi/extensions/exchanges/schemas/` and `src/projections/exchanges/`) into `src/exchanges/`.\n\n**Lessons \\[J\\].** (a) Wire vocabulary outlives tool names — version the *detail* schema independently of the tool registry from day one, or every tool rename leaves a fossil. (b) Do not merge two interaction forms because their outcomes look alike; brunch merged digest into review and had to un-merge it while keeping a legacy read path. (c) An enumerated `prev/curr/next` chain across N forms is O(N²) maintenance for a link that could be one parent pointer. (d) The `settlement: advisory|settled` retrofit (D27-L, FE-1187) shows that *strength of assertion* is a first-class field, not a later annotation.\n\n## 4. Elicitor control model\n\nThree controls, three owners, three lifetimes (`runtime/elicitor/TOPOLOGY.md`, \"Control ownership\"):\n\n* **Spec posture** (`kind`/`origin`/`relatesToSpecId`) — owned by the persisted product row, spec lifetime. Session establishment decides *whether to ask*, not what the fact is; the live context renderer \"cannot establish or overwrite it.\" Enforced in code: `context.ts:14-19` comments that `workspace.posture` is a *workspace* stub, \"not D118-L spec posture.\"\n* **Elicitation style** (`interrogate|disambiguate|propose`) — last valid `brunch.elicitation_style` entry on the active branch, session lifetime across kicks. The prompt adapter \"projects it into the live elicitor control block without changing capability or authority.\"\n* **Asking agenda** — *has no state field at all*. Turn lifetime, \"reconsidered from current conversation and on-demand reads.\" Origination supplies neutral graph facts once; the prompt directs `establish orientation` then `focus a vein`.\n\nThe closing rule is the sharp part: **\"Formatting is not authority: shared text helpers may render facts, but spec posture cannot satisfy style, style cannot persist or gate an agenda, and the prompt cannot establish product posture.\"**\n\nThe conduct itself lives in `prompts/elicitor.md`: a new session \"starts from graph facts and an empty or inherited elicitation scratchpad, **never a scored or ranked agenda**\"; establish orientation, then \"pick one concrete thread worth pursuing this session and let the scratchpad track obligations you notice along the way, rather than trying to cover every absence at once.\" Scratchpad obligations are private working state — \"do not disclose even a summary… unless the user explicitly asks.\"\n\n**Judgment \\[J\\].** *Generic dialogue policy:* the three-way separation of persisted-fact / session-style / turn-agenda; the refusal to persist an agenda (D101-L retired the persisted spec-scoped register in favour of a session scratchpad — `memory/SPEC.md:180`); \"one vein, not full coverage\"; private-by-default working state; the three style values; \"formatting is not authority.\" *Product policy:* that spec posture is the persisted axis at all; the specific graph facts constituting orientation; the `intent→design→verification→scope→build` sequence and execution-harness verify-recipe block; the `mutate_graph`/`read_graph` tool allowlist. **\\[J\\]** The most under-appreciated design move is the *negative* one — an agenda deliberately has no storage, so it cannot go stale, cannot be gamed, and cannot become a scoring engine the prompt defers to instead of reading the conversation.\n\n## 5. Design lessons for a greenfield questioning-UX contract\n\n**Inherit**\n\n 1. **Declared continuations.** The offer names its own terminal in its result; the collector fills body/options from that declaration and rejects model-authored payload on a continuing call. This is the mechanism that makes offer→answer non-forgeable.\n 2. **Property-presence outcome union with three arms** — answered / cancelled / unavailable — plus the recovery rule that *only answered closes an exchange* (`recovery.ts:78-81`). Cancel must leave the offer resumable, and the user-facing hint must stay honest after a cancel.\n 3. **One terminal tool, several shapes.** Not one collect-tool per question type. Params-level cross-field refinement decides the shape; the runtime asserts the parsed params \"describe a runtime variant\" and throws if not.\n 4. **Self-contained terminals.** Echo the question, the options, and the sub-prompts into the answer detail so a transcript reader never needs the present.\n 5. `comment` **vs** `message` — never let user text and system text share a field.\n 6. **Boundary-teaching schemas.** Advertise the nested shape shallowly for model legibility; keep the deep requiredness contract in one validator the target owns.\n 7. **Agenda as derived state, not stored state**, with a private, non-authoritative scratchpad for \"noticed but not asked.\"\n 8. **Version and hash load-bearing prompt paragraphs.** `LIVE_ELICITOR_DIRECTIVES` pins one directive by sha256, validates its stable opening sentence, and supports dev-only ablation — prompt text as a testable artifact.\n 9. **Separate \"react to this\" from \"accept this.\"** Digest feedback and digest acceptance are different exchanges for a reason brunch learned by reverting the merge.\n10. **Approval-commits, with the target's receipt in the terminal.** Never leave \"approved\" and \"committed\" as two states the model can straddle — the settlement runs before the terminal is appended.\n\n**Avoid**\n\n11. **Enumerated** `prev/curr/next` **tool-meta unions.** Use one parent link and one form tag.\n12. **Product judgment baked into required schema fields** — the six-field `user_rubric` and the four-axis `meta_rubric` (documented as \"a soft heuristic… not architecturally enforced\" yet schema-required). Rubrics belong to the target, declared per call.\n13. **Rendering constraints leaking into validation** — the option-id regex exists because ids round-trip through an HTML comment. Encode ids opaquely.\n14. **One detail kind for two transactions.** `request_review` forces every caller to hand-carry a discriminator and forks receipt rules downstream.\n15. **Tool names as the versioning unit.** Brunch's wire vocabulary froze independently of its tool registry; plan for that from the start rather than maintaining `legacyRequestPrefix` and a parallel unregistered projection tree.\n\n**Key paths:** `../brunch/src/exchanges/{TOPOLOGY.md,recovery.ts,editor-envelope.ts,text.ts}`, `../brunch/src/exchanges/schemas/{TOPOLOGY.md,shared.ts,present.ts,request.ts,params.ts,questionnaire.ts,capture.ts,editor.ts}`, `../brunch/src/exchanges/projections/`, `../brunch/src/.pi/extensions/exchanges/{TOPOLOGY.md,ask.ts,ask/continuation.ts,index.ts}`, `../brunch/src/agents/runtime/elicitor/{TOPOLOGY.md,active-tools.ts,compose-live-prompt.ts,context.ts}`, `../brunch/src/agents/prompts/elicitor.md`, `../brunch/src/agents/skills/{TOPOLOGY.md,registry.ts,elicit/SKILL.md,propose/SKILL.md}`, `../brunch/src/session/elicitation-style.ts`, `../brunch/memory/SPEC.md`.",
+      "innerSha256": "09086b43d756206ba140c9019b0a1b0d89cb74d9783bfede2317e047e884e130",
+      "proposedBody": "This audit classified each part of the existing Brunch question-and-answer exchanges by whether the new library should keep, adapt, or leave it behind. The generic asking machinery remains useful, while Brunch-specific vocabulary and review structures do not carry forward. The audit was resolved on 2026-08-06.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Brunch exchange-schema audit\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nCatalog brunch's structured-exchange vocabulary and classify each element as **generic to any elicitation** vs. **brunch-specific** (coupled to the spec-graph/product), so the questioning-UX and contract-decomposition tickets inherit a map of what to keep, generalize, or drop.\n\nSpecifically, in `../brunch` (read-only):\n\n* `src/exchanges/` — schemas (`ask`, `present_candidates`, `present_digest`, `present_review_set`, `request_choice`/`request_review`, capture/editor envelopes), projections, recovery\n* `src/agents/runtime/elicitor/` — prompt/context assembly, active-tool policy, the control-ownership table (spec posture / elicitation style / asking agenda)\n* `src/agents/skills/` — the activity-move routing table (analyze/elicit/ingest/propose/project/map/review) as candidate generic elicitation routines\n* Relevant `TOPOLOGY.md` files for boundary intent\n\nFor each element: what interaction problem it solves, where it hard-codes brunch's graph/spec shape, and any right-sizedness doubts visible in the code or docs (the abstractions \"were also just a guess\" — look for strain marks: legacy kept-for-reads projections, migration notes, loud failure modes).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Facts cited to file:line-range in `../brunch`; judgments marked **\\[J\\]**.\n\n# Brunch Structured-Exchange & Elicitor Audit\n\n## 1. Exchange catalog\n\n`ask` **(the only registered interactive terminal).** Solves: getting exactly one typed response from a human, in one of four shapes, without a separate collect tool per shape. Params (`src/exchanges/schemas/params.ts:~180-215`) carry markdown `body`, optional `options[]`, `multiple`, `allowOther`, `allowNone`, `commentPrompt`, `topLabel`/`bottomLabel`; no options ⇒ free text, options ⇒ single choice, options + `multiple` ⇒ multi-choice (`src/.pi/extensions/exchanges/TOPOLOGY.md`, \"Answer sources\"). Details (`src/exchanges/schemas/request.ts:~390-460`) echo the question *and* the answer in one result: `question` echo (body, options, `commentPrompt`, `otherPrompt`) plus exactly one of `answered | cancelled | unavailable` — a **property-presence union** rather than a status enum (`src/exchanges/schemas/TOPOLOGY.md:293-300`). Continuation: `ask({ continues: exchange_id })` reads the declared continuation off a prior present; model-authored payload fields on a continuing ask are rejected at the params boundary (`params.ts` `zAskParams.superRefine`, message `\"continuing ask payload is declared by the referenced offer\"`).\n\n`present_candidates`**.** Solves: fan-out comparison — let the user *recognize* a direction among alternatives instead of authoring one. Details (`src/exchanges/schemas/present.ts:185-235`): `display{heading, body?}` plus `candidates[]` of `{id, title, user_rubric, meta_rubric, graph_refs[]}`. `user_rubric` is six required nonblank markdown fields — `core_bet, best_fit, cost_complexity, covers_well, main_risks, lock_in_constraints` (+ optional `recommendation`); `meta_rubric` is four optional fields — `legibility_cost_of_knowing, failure_modes, coverage_range, commitment` (the D31-L four-axis meta-rubric, `memory/SPEC.md:262`). Continuation: `continuation: zOptionRequiredAskContinuationDeclaration` → `{tool: \"ask\", params: {body, options, ...}}`; the answer emits a `request_choice` detail discriminant with `tool_meta.prev = present_candidates`, and may lead to `capture_candidate`.\n\n`present_digest`**.** Solves: putting a large ingested source in front of the user as prose. Details (`present.ts:237-262`): `digest{abstract (required, nonblank), analysis?, recommendation?}`. Explicitly *not* a graph carrier — graph payload fields are rejected (`schemas/TOPOLOGY.md:289`). Continuation is the **free-text** variant (`zFreeTextAskContinuationDeclaration`, which `z.never()`s options/multiple/allowOther/allowNone/commentPrompt/labels — `shared.ts`), collecting conversational feedback only. Acceptance is deliberately *not* a review decision: a later standalone `ask({acceptsDigest, questions})` questionnaire or a `confirm|revise` single-select mints the accepted carrier, copying `accepted_abstract` from the runtime-resolved digest — caller-authored abstracts are rejected (`src/exchanges/TOPOLOGY.md:27`; `projections/ask.ts` `projectDigestQuestionnaire` / `projectDigestConfirmation`).\n\n`present_review_set`**.** Solves: batch approval of a structurally valid graph-mutation proposal. Details (`present.ts:60-180`): `review_set{nodes[], edges[]}` where each node is `{draft_id, proposed_code, settlement: advisory|settled, plane: intent|oracle|design|plan, kind, title, body?, detail?}` and each edge is a role-named discriminated union over nine categories (`dependency, witness, rationale, realization, refinement, exclusion, composition, cross_reference, supersession`) with `{draft_id}|{existing_code}` endpoint refs. Continuation is option-required. Approval is the commit: an approved continuation invokes shared settlement *before* `ask.execute` returns, so only a committed, `receipt`-bearing result is appended (`.pi/extensions/exchanges/TOPOLOGY.md`; `ask/continuation.ts:527` throws `'Review-set approval must route through shared settlement'`). `request_changes` requires a comment; `request_changes`/`reject` are terminal-only, no graph effect.\n\n**Legacy** `present_question`**.** A merged question/offer anchor (`response_kind: answer|choice|choices` + options inline). Unregistered; its Pi adapter is deleted; the projection survives only for old persisted reads (`schemas/TOPOLOGY.md:132-134`; `projections/present-question.ts`).\n\n`request_choice` **/** `request_review` **/** `request_answer` **/** `request_choices`**.** No longer registered tools — they are the *preserved wire vocabulary* for terminal details, so capture/sweep readers keep reading what they always read (`.pi/extensions/exchanges/TOPOLOGY.md:81-84`). `request_review` projection callers must pass a present-tool discriminator because review-set and digest close through the same detail kind but capture reads them differently (`projections/request-response/review.ts` `ReviewPresentTool`).\n\n**Capture envelopes.** `capture_answer|choice|choices|review|candidate` (`schemas/capture.ts`), each a `zCaptureDetailsHeader` + `tool_meta{prev, curr}`. Graph payloads intentionally undesigned in this pass (`schemas/TOPOLOGY.md:386-390`); `capture_candidate` consumes only the selected id.\n\n**Editor envelope.** `editor.ts` is a *wire* envelope, not transcript detail: a JSON blob prefilled into `ctx.ui.editor` for the one payload Pi built-ins can't carry over RPC (multi-choice). Its `status: 'answered'|'cancelled'` string never enters details, which carry outcome as key presence (`schemas/TOPOLOGY.md:36-38`).\n\n**Questionnaires.** `schemas/questionnaire.ts`: `{id, kind: free-text|single-select|multi-select, prompt, options[]}` questions and kind-matched answers, replayed on persisted completion so IDs/kinds/option-membership/completeness can't diverge.\n\n## 2. Classification\n\n| Element | Class | Change needed / coupling |\n| -- | -- | -- |\n| `ask` single-tool-four-shapes | **Generic** | The strongest abstraction here. **\\[J\\]** One terminal covering free-text/single/multi + a declared-continuation mode is the right primitive. |\n| Property-presence terminal union (`answered`/`cancelled`/`unavailable`) | **Generic** | Distinguishes \"user declined\" from \"no UI available\" — both are non-answers, and conflating them is the classic bug. |\n| `comment` (user-authored) vs `message` (system-authored) split | **Generic** | `schemas/TOPOLOGY.md:108-112`. Cheap, high-value provenance discipline. |\n| Question-echo-in-result (self-contained terminal) | **Generic** | Makes the transcript replayable without joining back to the present. |\n| Declared continuation (`present` names its own terminal; collector rejects model re-authoring) | **Generic** | **\\[J\\]** The single most transferable idea: the offer owns the answer vocabulary, so the model cannot drift the options between showing and collecting. |\n| `exchange_id` + `tool_meta{prev,curr,next}` chain | **Generalize-with-changes** | Currently a hand-maintained discriminated union of ~15 literal prev/curr/next triples (`shared.ts`). Replace with a generic `{exchangeId, parentId?}` link + one `form` tag; the pairwise enumeration is combinatorial and buys little. |\n| Recovery scan / pending-present resumption | **Generic** | `recovery.ts:78-81`: only an *answered* terminal closes an exchange; cancelled/unavailable stay resumable. Any interviewer needs this. |\n| Present-then-ask two-step (offer ≠ collection) | **Generalize-with-changes** | Generic as \"render surface separate from input surface\", but brunch pins the offer set at three named tools. A kernel wants one `present(form, payload)` with pluggable payload validators. |\n| `present_candidates` as an *interaction* | **Generic** | Fan-out/compare/recognize is plane-invariant (A31-L, `memory/SPEC.md:111`). |\n| Candidate `user_rubric` (six required fields) | **Brunch-specific** | Hard-codes brunch's product judgment about what makes specs comparable (`core_bet`, `lock_in_constraints`). A kernel should take a caller-declared rubric schema. |\n| Candidate `meta_rubric` (D31-L four axes) | **Generalize-with-changes** | SPEC calls it \"a soft heuristic… not architecturally enforced\" (`memory/SPEC.md:262`) yet it is a required schema key. Demote to optional caller-supplied axes. |\n| `graph_refs[]` on candidates | **Brunch-specific** | Node-id coupling to the spec graph. |\n| `present_digest` as an interaction | **Generic** | \"Here is my reading of your source; react to it\" is universal to ingestion-shaped interviewing. |\n| Digest accept-via-later-carrier (feedback ≠ acceptance) | **Generalize-with-changes** | **\\[J\\]** The *separation* is a real lesson; the specific `acceptsDigest`/`accepted_abstract` field names and the \"runtime resolves the final eligible digest\" recognizer (`recovery.ts:18`) are brunch plumbing. |\n| `present_review_set` as an interaction | **Generalize-with-changes** | \"Approve/request-changes/reject a proposed batch of writes, atomically\" is generic. Brunch's version hardwires the target. |\n| Review-set node/edge draft schema | **Brunch-specific** | `plane: intent\\|oracle\\|design\\|plan`, nine graph edge categories, `settlement: advisory\\|settled` (D27-L), `proposed_code`. Params import `zReviewSetProposalPayloadForBoundary` from `graph/review-set.ts` — the only inbound coupling `exchanges/` allows (`exchanges/TOPOLOGY.md`, dependency direction). |\n| \"Boundary-teaching\" schema (advertise nested shape so the model sees it before the deep validator runs) | **Generic** | `schemas/TOPOLOGY.md:47-52`. **\\[J\\]** A genuinely good pattern: shallow schema for model legibility, deep validator for correctness. |\n| Approval-commits-atomically + receipt | **Generalize-with-changes** | Generic as \"the approve branch runs the target's commit and the terminal carries the target's receipt\"; `MutateGraphSuccess` (`request.ts:1`) is the coupling. Kernel needs an opaque target-supplied receipt type. |\n| Capture layer | **Brunch-specific** | Exists as envelope only, graph payloads undesigned; `capture_candidate` semantics are graph-shaped. |\n| Editor envelope (`editor.ts`) | **Generalize-with-changes** | Real problem (host UI can't carry a payload over RPC), brunch-shaped solution. Kernel: name it a \"degraded-transport fallback\", don't bind it to multi-choice. |\n| Option-id regex `^[^>\\r\\n]+$` | **Generalize-with-changes** | The comment says ids round-trip through an HTML-comment marker recovered by a regex stopping at `>` (`params.ts`). **\\[J\\]** A rendering leak in a validation schema — a kernel should encode ids opaquely instead. |\n| `active-tools.ts` allowlist | **Generalize-with-changes** | Generic pattern (fixed tool policy per role), brunch-specific contents (`read_graph`, `mutate_graph`, `read_elicitation_scratchpad`). |\n| Elicitation scratchpad (private, non-authoritative obligations) | **Generic** | D101-L: session-local, last-snapshot-wins, \"durable truth stays in the graph; low-confidence noticings land here.\" Every interviewer needs a place for \"noticed, not yet asked.\" |\n| `elicitation_style: interrogate\\|disambiguate\\|propose` | **Generic** | `session/elicitation-style.ts`. Style ≠ authority ≠ capability. |\n| `warrant-before-commit` directive (hash-pinned, ablatable) | **Generic** | `compose-live-prompt.ts` validates exactly one directive block, hashes it, exposes it as `providerVisibleText`, and supports dev-only ablation. **\\[J\\]** Treating one prompt paragraph as a versioned, A/B-testable artifact is a pattern worth stealing outright. |\n| Skill moves `analyze / elicit / ingest / propose / project / review` | **Generic** | These six are the actual elicitation routine vocabulary. |\n| Skill move `map` | **Brunch-specific** | Graph vocabulary/routing/persistence. |\n| Skill move `tutorial` | **Brunch-specific** | Product walkthrough of Brunch itself. |\n| `elicit` topology-driven question ranking table | **Generalize-with-changes** | The *shape* — structural signal in the target ⇒ question shape — is generic; every row names graph kinds (`assumption`, `witness` path, `criterion`, `exclusion`). Kernel: targets supply their own signal→question-shape table. |\n| Readiness bands as \"concentric concern envelopes, not workflow stages\" | **Generalize-with-changes** | **\\[J\\]** Excellent dialogue policy (\"absence matters *later*, capture is never illegal earlier\"); the band vocabulary is brunch's. |\n| Prompt-injected skill manifest (`<brunch-skills>` with absolute paths, \"do not infer additional skills\") | **Generic** | `skills/registry.ts` `renderBrunchSkills`. |\n| `intent -> design -> verification -> scope -> build` handoff sequence, frontier/scope edge directions, `PROJECT_EXECUTION_HARNESS_TITLE` verify-recipe block | **Brunch-specific** | `prompts/elicitor.md`; `compose-live-prompt.ts` `renderProjectExecutionHarnessGuidance`. |\n\n## 3. Strain marks\n\n**Legacy-kept-for-reads.** `present-question.ts` and `request-response.ts` survive as projections with no registered tool (`exchanges/TOPOLOGY.md:22`; `.pi/.../TOPOLOGY.md:81-84`). `shared.ts` literally names the residue: `STRUCTURED_EXCHANGE_TERMINAL_NAMES = { current: 'ask', legacyRequestPrefix: 'request_' }`. The tool topology collapsed from `present_question → request_response` to `ask`, but the *detail* vocabulary could not follow because capture/sweep readers were written against it.\n\n**Same detail kind, two meanings.** `request_review` closes both review-set and digest, so `projectRequestReview` demands a `ReviewPresentTool` discriminator from callers (`projections/request-response/review.ts`). Receipts are required for review-set approval and *strictly rejected* on every digest branch (`schemas/TOPOLOGY.md:~325`). **\\[J\\]** Two different transactions wearing one name — a merge that shouldn't have happened.\n\n**A retracted merge.** Digest acceptance *was* a review decision and was pulled back out: \"digest acceptance is no longer a review decision\" (`exchanges/TOPOLOGY.md:27`), with `recovery.ts:31-36` retaining a `legacyReview` parse path for digests approved under the old model.\n\n**Doc/code drift on edge categories.** `schemas/TOPOLOGY.md:194` documents `dependency | proof | support | realization | boundary | composition | association | supersession`; the Zod in `present.ts:89-160` implements `dependency | witness | rationale | realization | refinement | exclusion | composition | cross_reference | supersession`. Four categories were renamed and the schema doc was not updated.\n\n**Retired axes.** D98-L retired strategy/lens/method as runtime or manifest state; A35-L records the retreat: the axis model \"may still be useful as prompt-resource organization, but it is no longer trusted as user-changeable or transcript-backed runtime state\" (`memory/SPEC.md:115`). The migration note in `skills/TOPOLOGY.md` maps seven old constructs onto activity homes and ends with a hard rule: *\"if a skill is live, it appears in the first-level registry; if guidance is not there, it is not switchable product state.\"* Retired axes also left dead vocabulary behind — `lens` is still advertised in the review-set boundary schema (`schemas/TOPOLOGY.md:50`) and the elicitor prompt still says \"plan-lens review set\".\n\n**Loud failure modes.** Only two `throw`s in the whole exchange surface, both about authority: `'Review-set approval must route through shared settlement'` (`ask/continuation.ts:527`) and `'parsed ask parameters do not describe a runtime variant'` (`ask.ts:748`). Everything user-facing degrades to an `unavailable` terminal with a message instead (`continuation.ts:222` — a missing continuation declaration is an error string, not a crash). Params failures return bounded `TOOL_INPUT_INVALID` tool results with no human-visible transcript line.\n\n**Where validation lives (revised once).** D105-L: validate at trust boundaries — LLM params, RPC input, editor replies, transcript read-back — *not* inside constructors, which \"do not parse objects [they] just built.\" D108-L consolidated the whole contract out of two prior homes (`src/.pi/extensions/exchanges/schemas/` and `src/projections/exchanges/`) into `src/exchanges/`.\n\n**Lessons \\[J\\].** (a) Wire vocabulary outlives tool names — version the *detail* schema independently of the tool registry from day one, or every tool rename leaves a fossil. (b) Do not merge two interaction forms because their outcomes look alike; brunch merged digest into review and had to un-merge it while keeping a legacy read path. (c) An enumerated `prev/curr/next` chain across N forms is O(N²) maintenance for a link that could be one parent pointer. (d) The `settlement: advisory|settled` retrofit (D27-L, FE-1187) shows that *strength of assertion* is a first-class field, not a later annotation.\n\n## 4. Elicitor control model\n\nThree controls, three owners, three lifetimes (`runtime/elicitor/TOPOLOGY.md`, \"Control ownership\"):\n\n* **Spec posture** (`kind`/`origin`/`relatesToSpecId`) — owned by the persisted product row, spec lifetime. Session establishment decides *whether to ask*, not what the fact is; the live context renderer \"cannot establish or overwrite it.\" Enforced in code: `context.ts:14-19` comments that `workspace.posture` is a *workspace* stub, \"not D118-L spec posture.\"\n* **Elicitation style** (`interrogate|disambiguate|propose`) — last valid `brunch.elicitation_style` entry on the active branch, session lifetime across kicks. The prompt adapter \"projects it into the live elicitor control block without changing capability or authority.\"\n* **Asking agenda** — *has no state field at all*. Turn lifetime, \"reconsidered from current conversation and on-demand reads.\" Origination supplies neutral graph facts once; the prompt directs `establish orientation` then `focus a vein`.\n\nThe closing rule is the sharp part: **\"Formatting is not authority: shared text helpers may render facts, but spec posture cannot satisfy style, style cannot persist or gate an agenda, and the prompt cannot establish product posture.\"**\n\nThe conduct itself lives in `prompts/elicitor.md`: a new session \"starts from graph facts and an empty or inherited elicitation scratchpad, **never a scored or ranked agenda**\"; establish orientation, then \"pick one concrete thread worth pursuing this session and let the scratchpad track obligations you notice along the way, rather than trying to cover every absence at once.\" Scratchpad obligations are private working state — \"do not disclose even a summary… unless the user explicitly asks.\"\n\n**Judgment \\[J\\].** *Generic dialogue policy:* the three-way separation of persisted-fact / session-style / turn-agenda; the refusal to persist an agenda (D101-L retired the persisted spec-scoped register in favour of a session scratchpad — `memory/SPEC.md:180`); \"one vein, not full coverage\"; private-by-default working state; the three style values; \"formatting is not authority.\" *Product policy:* that spec posture is the persisted axis at all; the specific graph facts constituting orientation; the `intent→design→verification→scope→build` sequence and execution-harness verify-recipe block; the `mutate_graph`/`read_graph` tool allowlist. **\\[J\\]** The most under-appreciated design move is the *negative* one — an agenda deliberately has no storage, so it cannot go stale, cannot be gamed, and cannot become a scoring engine the prompt defers to instead of reading the conversation.\n\n## 5. Design lessons for a greenfield questioning-UX contract\n\n**Inherit**\n\n 1. **Declared continuations.** The offer names its own terminal in its result; the collector fills body/options from that declaration and rejects model-authored payload on a continuing call. This is the mechanism that makes offer→answer non-forgeable.\n 2. **Property-presence outcome union with three arms** — answered / cancelled / unavailable — plus the recovery rule that *only answered closes an exchange* (`recovery.ts:78-81`). Cancel must leave the offer resumable, and the user-facing hint must stay honest after a cancel.\n 3. **One terminal tool, several shapes.** Not one collect-tool per question type. Params-level cross-field refinement decides the shape; the runtime asserts the parsed params \"describe a runtime variant\" and throws if not.\n 4. **Self-contained terminals.** Echo the question, the options, and the sub-prompts into the answer detail so a transcript reader never needs the present.\n 5. `comment` **vs** `message` — never let user text and system text share a field.\n 6. **Boundary-teaching schemas.** Advertise the nested shape shallowly for model legibility; keep the deep requiredness contract in one validator the target owns.\n 7. **Agenda as derived state, not stored state**, with a private, non-authoritative scratchpad for \"noticed but not asked.\"\n 8. **Version and hash load-bearing prompt paragraphs.** `LIVE_ELICITOR_DIRECTIVES` pins one directive by sha256, validates its stable opening sentence, and supports dev-only ablation — prompt text as a testable artifact.\n 9. **Separate \"react to this\" from \"accept this.\"** Digest feedback and digest acceptance are different exchanges for a reason brunch learned by reverting the merge.\n10. **Approval-commits, with the target's receipt in the terminal.** Never leave \"approved\" and \"committed\" as two states the model can straddle — the settlement runs before the terminal is appended.\n\n**Avoid**\n\n11. **Enumerated** `prev/curr/next` **tool-meta unions.** Use one parent link and one form tag.\n12. **Product judgment baked into required schema fields** — the six-field `user_rubric` and the four-axis `meta_rubric` (documented as \"a soft heuristic… not architecturally enforced\" yet schema-required). Rubrics belong to the target, declared per call.\n13. **Rendering constraints leaking into validation** — the option-id regex exists because ids round-trip through an HTML comment. Encode ids opaquely.\n14. **One detail kind for two transactions.** `request_review` forces every caller to hand-carry a discriminator and forks receipt rules downstream.\n15. **Tool names as the versioning unit.** Brunch's wire vocabulary froze independently of its tool registry; plan for that from the start rather than maintaining `legacyRequestPrefix` and a parallel unregistered projection tree.\n\n**Key paths:** `../brunch/src/exchanges/{TOPOLOGY.md,recovery.ts,editor-envelope.ts,text.ts}`, `../brunch/src/exchanges/schemas/{TOPOLOGY.md,shared.ts,present.ts,request.ts,params.ts,questionnaire.ts,capture.ts,editor.ts}`, `../brunch/src/exchanges/projections/`, `../brunch/src/.pi/extensions/exchanges/{TOPOLOGY.md,ask.ts,ask/continuation.ts,index.ts}`, `../brunch/src/agents/runtime/elicitor/{TOPOLOGY.md,active-tools.ts,compose-live-prompt.ts,context.ts}`, `../brunch/src/agents/prompts/elicitor.md`, `../brunch/src/agents/skills/{TOPOLOGY.md,registry.ts,elicit/SKILL.md,propose/SKILL.md}`, `../brunch/src/session/elicitation-style.ts`, `../brunch/memory/SPEC.md`.\n+++",
+      "proposedBodySha256": "bf35cca443ec1319a47374634cfca1234dbb65939b2f8a9c12dac9b9ba773d3a",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "9d7da48f-bd0d-4320-ab00-08e9060625f0",
+      "identifier": "FE-1370",
+      "url": "https://linear.app/hash/issue/FE-1370/contract-decomposition-kernel-host-plugin-pack-boundary-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.501Z",
+      "sourceTitle": "Contract decomposition: kernel / host / plugin / pack boundary [archive]",
+      "sourceDescriptionSha256": "2234383db65ad51aafd0ef50877851b0449988ebd0e1c57173120549a6f95c11",
+      "sourceTitleSha256": "e26e5d7d5c992fae3d3148ce48e892d0f0246c65aace5cb2f76f686181b778a8",
+      "oldOuter": "Decided how responsibility splits between the generic interviewing engine and the pluggable subject-matter definitions. The engine owns a domain-free envelope around whatever a plugin stores — with evidence links, confidence, and explicit \"no answer\" states — and typed issues as its feedback channel; there is deliberately no universal data model. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Define the harness and plugin responsibilities",
+      "proposedOuter": "This decision assigns responsibilities between the generic interviewing engine and the subject-matter plugins. The engine owns a domain-free envelope for plugin data, including evidence links, confidence, explicit absence states, and typed issues for feedback. The design does not impose one universal data model and was resolved on 2026-08-07.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/04-contract-decomposition.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Contract decomposition: kernel / host / plugin / pack boundary\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 01, 03 (both resolved)\n\n## Question\n\nWhat exactly does the kernel own (mechanism + orchestration), what does the host supply (input shapes and pathways, deploy target), and what do plugins define (target policy) — and does the four-contract + pack decomposition (ElicitationPack: concept/observation/completion; ProjectionPack: projection) survive contact with the Flue facts and the brunch audit?\n\nSub-questions this grilling must close:\n\n* Are the A-axis (semantic target) and B-axis (representation target) genuinely separately swappable in our first milestone, or bundled per plugin?\n* Where does the evidence-preserving IR / claim graph live, and how thin is its common core?\n* Persistence: does the plugin-owned-persistence hypothesis hold, or does the host (deploy target) own it with plugins declaring shape? What state must the kernel externalize (session, transcript refs, artifact-in-progress, episteme ledger)?\n* Where is control inverted: typed issues as backpressure (projector → elicitation controller) — is that the only inversion, or do observation lenses invert too?\n* The policy-vs-mechanism rule: enumerate what would otherwise become the central `switch` and check each is on the plugin side.\n\nPrimary input: docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md\n\nNamed input from the portfolio decision (issue 07): **behavioral over procedural** — agents do better with behavioral guidance than procedural scripts, and with clear shapes/patterns to fill rather than schemas that require extensive parsing to build a model of the output shape. Brunch's unsolved problem — specifying how an elicitation process should work plus skill material to guide an agent through it, without over-proceduralizing — is a core stress test for the pack contract. The decomposition must say what a pack *feels like* to the agent consuming it, not only what it validates.\n\nConcrete test cases for every boundary claim (from issue 07): how would `elicit-gherkin` do this vs. `elicit-proof-obligations`? The spec mandates both packs are authored before the pack interface freezes.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (four rounds, including an evidence pass over `~/Clones/mattpocock/skills` + `../brunch/docs/design/BEHAVIORAL_KERNELS.md`, and integration of [agentic-elicitation-criteria](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>), the second inbox doc).\n\n### Ownership table\n\n|  | Owns |\n| -- | -- |\n| **Kernel** *(mechanism + orchestration)* | The conversation loop, agent-forward (agent judgment at the helm) · the questioning-UX contract (issue 05's subject) · the **capture envelope** (below) around opaque plugin payloads · the **typed issue queue** (vocabulary, storage, factual attributes; the only stored agenda-like state; also where conflict/equivalence live) · the private scratchpad · the **turn-suspension protocol** (Flue has no ask-primitive; the kernel owns one) · operation *signatures* (`observe/reconcile/project/validate`) with snapshot-in/deltas-out calling convention, validation, and application of returned deltas · completion evaluation (running plugin-declared criteria) · pack loading, progressive disclosure, kernel-card activation · capture-id minting · the **storage port** definition |\n| **Host** *(embedding + affordances)* | Input surfaces and pathways (TUI / web / chat channel / Petrinaut later) · verified respondent identity · deploy target · **storage port implementation** · artifact delivery (repo write, API, post) · model/provider via the Pi family |\n| **Plugin** *(target policy)* | Its **own IR payload structure** — graph, flat list, whatever fits; shared between its packs, never universal; namespaced concepts · **ElicitationPack**: kernel cards (Detects / Goal / contrastive Questions / Artifacts), completion contract, clarification hints · **ProjectionPack(s)**: `project` + `validate` (required), `reconcile` (optional), output contract, annotated shapes, **typed loss reports**, lossiness policy · artifact persistence *shape* · domain vocabulary |\n\n### The capture envelope (the hourglass waist)\n\nKernel-defined, domain-free — semantically rich, structurally minimal:\n\n* `id` (kernel-minted), evidence spans (utterance provenance, phrase-level where possible)\n* **Epistemic status** enum, distinct from confidence: `explicit | inferred | tentative | defaulted | external-lookup`\n* Confidence (qualitative), status: `active | superseded | retracted`, one `supersedes` link\n* **Absence states** as first-class capture values: `not-mentioned | unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred`\n* **Alternatives** grouping: >1 live interpretation of the same evidence may coexist until resolved\n* Opaque, plugin-typed payload. **No kernel edges, no graph, no kind taxonomy** — structure is payload business. Conflict (`conflicting`) and equivalence (`possibly-equivalent`) are **typed issues referencing capture ids**, not edges; resolution must be an explicit event (supersession or recorded decision) — \"no silent conflict resolution.\"\n\n### Operations\n\n* **Required**: `project` (captures → draft artifact **+ typed loss report**: `mapped-exactly / normalized / approximate / collapsed / omitted / defaulted / unrepresentable`) and `validate` (→ typed issues).\n* **Optional**: `reconcile` (dedup/merge over the plugin's own structure); kernel calls it when present.\n* **Agent-native**: `observe` — noticing is the agent's work guided by pack kernel cards; code-level extractors are an optimization, never the required path.\n* **Calling convention**: plugin ops receive an **immutable state snapshot**, return observations/issues/deltas; the kernel validates and applies. Buys atomic plugin failure, semantically idempotent retries (a retry never counts as a second user assertion), and tracing.\n* **Backpressure**: validators and projectors never address the user; they return typed issues the agent consumes.\n\n### Dialogue policy\n\nBehavioral guidance + factual issue queue. **Facts computed, weights judged**: the kernel computes issue facts (blocks-required-criterion, origin semantic|representational, can_default); the agent weighs them qualitatively. The inbox doc's priority formula is adopted as *prose the agent thinks with*, never as a computed score — computed-priority dimensions are judgments wearing metric costumes, and a stored ranking becomes an authority the agent defers to instead of reading the conversation (brunch's no-stored-agenda lesson).\n\n### Cross-cutting decisions\n\n1. **No universal IR** — the kernel's slice is the envelope; structure is plugin-unique. Typed-entity-graph maximalism explicitly not adopted; a graph remains any plugin's private choice (including a future brunch-target plugin).\n2. **Smallest-honest-plugin test** — a flat record list + one validator must suffice; every kernel-contract addition is checked against the bar it raises. Empirical form: the black-box authoring test.\n3. **Axes separated in contract, bundled in shipping** — one ElicitationPack + N ProjectionPacks per plugin sharing the plugin's IR; swappability proven by reprojection.\n4. **Principle v2 (ratified, replaces \"behavioral over procedural\")**: *procedure for mechanism, anchors for judgment, shapes for output*. Evidence: the mattpocock skills are full of procedure that works because it is short, carried by leading words (pretrained concepts recruited deliberately), ends on checkable completion criteria, and rides on shapes/templates with progressive disclosure. Failure modes to design against: sprawl, negation-steering, no-ops, judgment-encoded-as-procedure — not procedure itself. `writing-for-agents` is the cited pack-authoring standard.\n5. **Kernel cards** (from BEHAVIORAL_KERNELS.md) are the unit of ElicitationPack content: Detects (signal-phrase activation) / Goal / contrastive Question patterns / Artifacts (typed claims emitted) / validator hooks. The fifteen-kernel ontology itself stays brunch prior art; packs declare their own kernels. Contrastive classification over open-ended essays.\n6. **Pack physical form**: kernel cards + annotated shapes + deterministic validators + small wire schemas (boundary-teaching: shallow for model legibility, deep requiredness in validators) + completion contract as checkable bounds.\n\n### Acceptance material adopted into the spec (from the criteria doc)\n\n* The **five proof obligations** as contract acceptance criteria: independent variability, semantic conservation, explicit transformation, controlled elicitation, local implementation.\n* The **ten kernel invariants** (§9) as kernel-enforced test properties (no unsupported value without provenance; no silent conflict resolution; no silent projection loss; corrections don't erase history; retries idempotent; target issues namespaced; plugin failures atomic; equivalent state → equivalent projection; unknown ≠ false; explicit ≠ inferred/defaulted).\n* Gating tests: **reprojection/projector substitution**, **minimal pairs** (\"the budget is / might be €20,000\"), **black-box authoring test** (count concepts, boilerplate, escape hatches).\n* Named smells as review vocabulary: opaque payload waist, giant context bag, schema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden target leakage.\n\n### Deferred to fog (post-milestone)\n\nSimultaneous multi-plugin composition · plugin removal · full replay · capability negotiation · version/migration machinery (the spec names the five version axes — API contract / plugin impl / concept-schema / target-schema / persisted state — implements nothing).\n\n### Routed onward\n\n* §4 SDK-machinery list (evidence anchoring, issue construction, fixtures, **local simulation harness** — \"debugging should not require reading an entire agent transcript\") → issue 06 (Shipping shape).\n* Envelope + absence states + turn-suspension → issue 05 (Questioning-UX contract).\n\n## Comments\n\n**2026-08-07 (vocabulary clarification from issue 05's resolution).** The ownership table's \"Host (embedding + affordances)\" bundled two concerns that later split: the **ui** shell (interface: rendering, input, reply transport, identity) and the **substrate** (the embedding environment: deploy target, storage-port implementation, artifact delivery, model/provider). Under the hardened lexicon (`CONTEXT.md`), this table's \"Host\" row reads as substrate concerns plus ui concerns; \"kernel\" reads as **harness**. No substantive change to the decomposition.",
+      "innerSha256": "a8617883eff469f2b9a5dce712067f072907d7ca666141998a19d46323477384",
+      "proposedBody": "This decision assigns responsibilities between the generic interviewing engine and the subject-matter plugins. The engine owns a domain-free envelope for plugin data, including evidence links, confidence, explicit absence states, and typed issues for feedback. The design does not impose one universal data model and was resolved on 2026-08-07.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/04-contract-decomposition.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Contract decomposition: kernel / host / plugin / pack boundary\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 01, 03 (both resolved)\n\n## Question\n\nWhat exactly does the kernel own (mechanism + orchestration), what does the host supply (input shapes and pathways, deploy target), and what do plugins define (target policy) — and does the four-contract + pack decomposition (ElicitationPack: concept/observation/completion; ProjectionPack: projection) survive contact with the Flue facts and the brunch audit?\n\nSub-questions this grilling must close:\n\n* Are the A-axis (semantic target) and B-axis (representation target) genuinely separately swappable in our first milestone, or bundled per plugin?\n* Where does the evidence-preserving IR / claim graph live, and how thin is its common core?\n* Persistence: does the plugin-owned-persistence hypothesis hold, or does the host (deploy target) own it with plugins declaring shape? What state must the kernel externalize (session, transcript refs, artifact-in-progress, episteme ledger)?\n* Where is control inverted: typed issues as backpressure (projector → elicitation controller) — is that the only inversion, or do observation lenses invert too?\n* The policy-vs-mechanism rule: enumerate what would otherwise become the central `switch` and check each is on the plugin side.\n\nPrimary input: docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md\n\nNamed input from the portfolio decision (issue 07): **behavioral over procedural** — agents do better with behavioral guidance than procedural scripts, and with clear shapes/patterns to fill rather than schemas that require extensive parsing to build a model of the output shape. Brunch's unsolved problem — specifying how an elicitation process should work plus skill material to guide an agent through it, without over-proceduralizing — is a core stress test for the pack contract. The decomposition must say what a pack *feels like* to the agent consuming it, not only what it validates.\n\nConcrete test cases for every boundary claim (from issue 07): how would `elicit-gherkin` do this vs. `elicit-proof-obligations`? The spec mandates both packs are authored before the pack interface freezes.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (four rounds, including an evidence pass over `~/Clones/mattpocock/skills` + `../brunch/docs/design/BEHAVIORAL_KERNELS.md`, and integration of [agentic-elicitation-criteria](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>), the second inbox doc).\n\n### Ownership table\n\n|  | Owns |\n| -- | -- |\n| **Kernel** *(mechanism + orchestration)* | The conversation loop, agent-forward (agent judgment at the helm) · the questioning-UX contract (issue 05's subject) · the **capture envelope** (below) around opaque plugin payloads · the **typed issue queue** (vocabulary, storage, factual attributes; the only stored agenda-like state; also where conflict/equivalence live) · the private scratchpad · the **turn-suspension protocol** (Flue has no ask-primitive; the kernel owns one) · operation *signatures* (`observe/reconcile/project/validate`) with snapshot-in/deltas-out calling convention, validation, and application of returned deltas · completion evaluation (running plugin-declared criteria) · pack loading, progressive disclosure, kernel-card activation · capture-id minting · the **storage port** definition |\n| **Host** *(embedding + affordances)* | Input surfaces and pathways (TUI / web / chat channel / Petrinaut later) · verified respondent identity · deploy target · **storage port implementation** · artifact delivery (repo write, API, post) · model/provider via the Pi family |\n| **Plugin** *(target policy)* | Its **own IR payload structure** — graph, flat list, whatever fits; shared between its packs, never universal; namespaced concepts · **ElicitationPack**: kernel cards (Detects / Goal / contrastive Questions / Artifacts), completion contract, clarification hints · **ProjectionPack(s)**: `project` + `validate` (required), `reconcile` (optional), output contract, annotated shapes, **typed loss reports**, lossiness policy · artifact persistence *shape* · domain vocabulary |\n\n### The capture envelope (the hourglass waist)\n\nKernel-defined, domain-free — semantically rich, structurally minimal:\n\n* `id` (kernel-minted), evidence spans (utterance provenance, phrase-level where possible)\n* **Epistemic status** enum, distinct from confidence: `explicit | inferred | tentative | defaulted | external-lookup`\n* Confidence (qualitative), status: `active | superseded | retracted`, one `supersedes` link\n* **Absence states** as first-class capture values: `not-mentioned | unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred`\n* **Alternatives** grouping: >1 live interpretation of the same evidence may coexist until resolved\n* Opaque, plugin-typed payload. **No kernel edges, no graph, no kind taxonomy** — structure is payload business. Conflict (`conflicting`) and equivalence (`possibly-equivalent`) are **typed issues referencing capture ids**, not edges; resolution must be an explicit event (supersession or recorded decision) — \"no silent conflict resolution.\"\n\n### Operations\n\n* **Required**: `project` (captures → draft artifact **+ typed loss report**: `mapped-exactly / normalized / approximate / collapsed / omitted / defaulted / unrepresentable`) and `validate` (→ typed issues).\n* **Optional**: `reconcile` (dedup/merge over the plugin's own structure); kernel calls it when present.\n* **Agent-native**: `observe` — noticing is the agent's work guided by pack kernel cards; code-level extractors are an optimization, never the required path.\n* **Calling convention**: plugin ops receive an **immutable state snapshot**, return observations/issues/deltas; the kernel validates and applies. Buys atomic plugin failure, semantically idempotent retries (a retry never counts as a second user assertion), and tracing.\n* **Backpressure**: validators and projectors never address the user; they return typed issues the agent consumes.\n\n### Dialogue policy\n\nBehavioral guidance + factual issue queue. **Facts computed, weights judged**: the kernel computes issue facts (blocks-required-criterion, origin semantic|representational, can_default); the agent weighs them qualitatively. The inbox doc's priority formula is adopted as *prose the agent thinks with*, never as a computed score — computed-priority dimensions are judgments wearing metric costumes, and a stored ranking becomes an authority the agent defers to instead of reading the conversation (brunch's no-stored-agenda lesson).\n\n### Cross-cutting decisions\n\n1. **No universal IR** — the kernel's slice is the envelope; structure is plugin-unique. Typed-entity-graph maximalism explicitly not adopted; a graph remains any plugin's private choice (including a future brunch-target plugin).\n2. **Smallest-honest-plugin test** — a flat record list + one validator must suffice; every kernel-contract addition is checked against the bar it raises. Empirical form: the black-box authoring test.\n3. **Axes separated in contract, bundled in shipping** — one ElicitationPack + N ProjectionPacks per plugin sharing the plugin's IR; swappability proven by reprojection.\n4. **Principle v2 (ratified, replaces \"behavioral over procedural\")**: *procedure for mechanism, anchors for judgment, shapes for output*. Evidence: the mattpocock skills are full of procedure that works because it is short, carried by leading words (pretrained concepts recruited deliberately), ends on checkable completion criteria, and rides on shapes/templates with progressive disclosure. Failure modes to design against: sprawl, negation-steering, no-ops, judgment-encoded-as-procedure — not procedure itself. `writing-for-agents` is the cited pack-authoring standard.\n5. **Kernel cards** (from BEHAVIORAL_KERNELS.md) are the unit of ElicitationPack content: Detects (signal-phrase activation) / Goal / contrastive Question patterns / Artifacts (typed claims emitted) / validator hooks. The fifteen-kernel ontology itself stays brunch prior art; packs declare their own kernels. Contrastive classification over open-ended essays.\n6. **Pack physical form**: kernel cards + annotated shapes + deterministic validators + small wire schemas (boundary-teaching: shallow for model legibility, deep requiredness in validators) + completion contract as checkable bounds.\n\n### Acceptance material adopted into the spec (from the criteria doc)\n\n* The **five proof obligations** as contract acceptance criteria: independent variability, semantic conservation, explicit transformation, controlled elicitation, local implementation.\n* The **ten kernel invariants** (§9) as kernel-enforced test properties (no unsupported value without provenance; no silent conflict resolution; no silent projection loss; corrections don't erase history; retries idempotent; target issues namespaced; plugin failures atomic; equivalent state → equivalent projection; unknown ≠ false; explicit ≠ inferred/defaulted).\n* Gating tests: **reprojection/projector substitution**, **minimal pairs** (\"the budget is / might be €20,000\"), **black-box authoring test** (count concepts, boilerplate, escape hatches).\n* Named smells as review vocabulary: opaque payload waist, giant context bag, schema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden target leakage.\n\n### Deferred to fog (post-milestone)\n\nSimultaneous multi-plugin composition · plugin removal · full replay · capability negotiation · version/migration machinery (the spec names the five version axes — API contract / plugin impl / concept-schema / target-schema / persisted state — implements nothing).\n\n### Routed onward\n\n* §4 SDK-machinery list (evidence anchoring, issue construction, fixtures, **local simulation harness** — \"debugging should not require reading an entire agent transcript\") → issue 06 (Shipping shape).\n* Envelope + absence states + turn-suspension → issue 05 (Questioning-UX contract).\n\n## Comments\n\n**2026-08-07 (vocabulary clarification from issue 05's resolution).** The ownership table's \"Host (embedding + affordances)\" bundled two concerns that later split: the **ui** shell (interface: rendering, input, reply transport, identity) and the **substrate** (the embedding environment: deploy target, storage-port implementation, artifact delivery, model/provider). Under the hardened lexicon (`CONTEXT.md`), this table's \"Host\" row reads as substrate concerns plus ui concerns; \"kernel\" reads as **harness**. No substantive change to the decomposition.\n+++",
+      "proposedBodySha256": "db79ebd21fa13286a626889b0a58932527104dc8c4413769fe313a4b5e681a8f",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "4302b30b-db51-41f6-ab3c-8fbfa97fa1fb",
+      "identifier": "FE-1371",
+      "url": "https://linear.app/hash/issue/FE-1371/questioning-ux-contract-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.539Z",
+      "sourceTitle": "Questioning-UX contract [archive]",
+      "sourceDescriptionSha256": "7ec025083f39f180878790e096ec19c369a7d4120c839730dacc7fe7980cc9fb",
+      "sourceTitleSha256": "9c5bb4c0020f39dc129390162dbb882bf463fa6e089c5000047f64924d49f497",
+      "oldOuter": "Decided how structured questions live inside a free-flowing conversation: the conversation stays primary, forms and choice strips are dropped into it as interactive elements, and captured knowledge is extracted afterwards in repeatable sweeps rather than question-by-question. Also fixed the system's four-layer naming (substrate / ui / harness / plugin). Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Define structured questions within conversation",
+      "proposedOuter": "This decision keeps free-flowing conversation primary while placing forms and choices within it as interactive elements. The system extracts captured knowledge through repeatable range sweeps after the conversation rather than after each question. It also establishes the four component names: platform, UI, harness, and plugin. The decision was resolved on 2026-08-06.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/05-questioning-ux-contract.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Questioning-UX contract\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 03\n\n## Question\n\nWhat is the kernel's generic questioning-UX contract — the successor to brunch's `ask` / `present_*` / `request_*` exchange family — critiqued rather than copied?\n\nSub-questions:\n\n* Which of brunch's exchange forms earn a place in the generic contract, which generalize with changes, which are brunch-specific and stay behind?\n* What does the \"one high-value question over several low-value questions\" dialogue policy need from the UX contract (question budgets, visible current interpretation, distinguish not-mentioned/no/unknown/N-A)?\n* How do typed issues (missing/ambiguous/conflicting/invalid/unsupported/unmapped/low-confidence) render as user-facing exchanges?\n* What must the contract leave to the host surface (TUI vs. web vs. chat channel) vs. fix in the kernel?\n\nInput from Contract decomposition (issue 04): the exchange contract must carry the envelope's conversation-level semantics — **absence states** (`unknown-to-user | declined | deferred | not-applicable`… as answer outcomes, not null), **alternatives** (letting more than one interpretation stay live through an exchange), and conflict-resolution exchanges (an explicit resolution event for a `conflicting` issue). Dialogue policy is behavioral guidance + factual issue queue — the UX contract renders issues to the agent, never scores them.\n\nNote from the Flue deep-read (issue 01): Flue has **no first-class ask-the-user primitive** — the kernel must own a turn-suspension protocol (`terminate: true` tool + pending question in persistent state + structured data part; the answer arrives as a fresh dispatch). The UX contract should be designed with that as the remote rendering path (`useDataWriter` / `dynamic-tool` output parts), alongside richer local surfaces.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (five rounds), with a live fact-finding pass over Flue's docs mid-session. All shape-level commitments are **working hypotheses** per the built-artifacts-as-proofs preference (ratified into the map's Notes during this session); delegated proof obligations live in tickets 10 (walking skeleton) and 11 (logic-prototype). Vocabulary hardened via `/domain-modeling` into repo `CONTEXT.md`.\n\n### The load-bearing reframe: no exchange-pair ontology\n\nBrunch's exchange machinery (offer→terminal pairs, pending-exchange state, recovery scans) was baggage from its older agent-initiated turn-by-turn model and is **not inherited**. The free-flowing conversation is primary. When the agent poses a structured question it emits an **affordance** — a rendered enhancement in the stream, not a state machine the harness maintains. There is no \"pending exchange\" concept, hence no cardinality rule, no recovery scan, no terminal union.\n\n* Ask invocations **do commit** structured question payloads to the session (design clue: Claude Code's `AskUserQuestion` — question set as `tool_use`, selections/interruption as adjacent `tool_result`; self-contained, replayable, no separate exchange store). The answer may follow as a structured response, or the ask may be cancelled/redirected — all of it is **session evidence**.\n* **Capture is decoupled from asking**: a **range-sweep** over session entries, run on **settlement** (agent-judged, range-level — a vein closing — never per-question, which would resurrect exchange-pairs through the back door). Harness owns sweep bookkeeping (high-water mark, idempotence); agent owns settlement judgment. → ticket 11.\n* Audit lessons demoted by the reframe: *declared continuations / non-forgeability* (the failure mode shifts from forgery to misinterpretation, which the envelope's `epistemic_status: inferred` already covers; whether a widget reply needs an echo token is empirical → ticket 10); *only-answered-closes recovery* and *self-contained terminals* (patterns at most, not structure).\n\n### Shells, vocabulary, and control (hardened)\n\n**substrate** (Pi family, Flue) → **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI) → **harness** (the generic capability layer — mechanism + orchestration; the effort's essence is *harness-engineering*; replaces \"kernel\" as shell name) → **plugin** (target policy). Control is IoC per the Hollywood principle: the plugin declares and registers; the harness discovers, orders, invokes; harness capabilities (the ask API, capture envelope, issue queue, sweep bookkeeping) reach the plugin as a **narrow injected context** — the questioning-UX contract is literally part of the PluginContext surface. Composition is the plugin's at authoring time; control flow is the harness's at runtime. Schema ownership follows capability ownership: *the shell that defines a capability owns its affordance schemas.*\n\n### What the harness fixes (the generic contract)\n\n1. **Baseline question forms**: free-text / single-choice / multi-choice, plus **questionnaire chaining** as first-class baseline (beyond brunch's `ask`). The harness owns the standard ask API and payload shapes; plugins add custom presentation/collection forms through the plugin API.\n2. **Absence**: interpret by default, afford when structured. Agent-interpreted absence from free conversation carries `epistemic_status: inferred`; structured affordances carry a one-tap absence strip (don't-know / not-applicable / decide-later — generalizing `allowNone`), keeping `unknown-to-user` vs `declined` vs `not-applicable` explicit. Transport outcome and epistemic absence never conflate.\n3. **One harness data channel** multiplexing all affordance forms (`form` tag + plugin-typed body + markdown baseline), because Flue channel names are static structural identity in a flat collision-prone namespace. Plugin widgets are progressive enhancement keyed on the form tag; hosts that know only the envelope render everything via markdown. → ticket 10.\n4. **Interpretation render** (\"visible current interpretation\"): the one affordance form that must be harness-owned, since it renders the harness's own envelope vocabulary — captures with epistemic status, absence states, live alternatives. The **plugin may supply a renderer/projector definition with typed arguments** (typed against its own payload shapes), which the harness uses to produce the ui-level view; **when it doesn't, the harness falls back to a default renderer (plain JSON view of payloads)** — keeping the renderer optional, consistent with the smallest-honest-plugin test. React vs. accept are two *capture semantics*, not exchange steps. Renderer-seam exercised once real packs exist (ticket 07's portfolio).\n5. **Issues → exchanges**: only `conflicting` / `possibly-equivalent` get forced treatment — a `conflicting` issue closes **only via an explicit resolution record** (capture-layer event citing the user's utterance as evidence); the guarantee moved from wire to store. Every other issue type renders however the agent judges best, guided by kernel cards — prescribing seven mappings would be judgment-as-procedure. → ticket 11.\n6. **No question-budget machinery**: economical interviewing is implemented through strategy and judgment guidance in pack kernel cards; with asks committed to session, anything countable is derivable — no stored counters, no ask-to-issue attribution model, no stored number for the agent to defer to.\n\n### What the ui owns\n\nRendering (zero built-in widgets in Flue — the embedding app branches on part types), reply transport, identity. Flue facts recorded for the spec: outbound is rich (Valibot-validated `data-*` parts, dynamic-tool outputs), **inbound is string-only** (`sendMessage(text, images)`; SDK signals are string-body too) — so answer typing/validation happens entirely harness-side on read-back; unknown part types are silently dropped (hence the markdown-baseline floor); one documented contradiction (data-part update-in-place vs append) needs the ticket-10 runtime check; turn suspension confirmed (`terminate: true`, answer as fresh dispatch; multi-tool batches terminate only when every result terminates).\n\n### Brunch disposition (sub-question 1)\n\n**Earns a place**: the three answer shapes as interaction vocabulary; questionnaire (promoted); absence affordances (generalized from `allowNone`); react≠accept (as capture semantics); no-stored-agenda (extended: no stored counters either). **Generalizes with changes**: named present tools → plugin-declared forms over one channel; approval-commits-atomically → the resolution-record store guarantee. **Stays behind**: the exchange-pair ontology and everything predicated on it (terminal unions, recovery scans, prev/curr/next chains, declared continuations as wire mechanism), plus everything the audit already classed brunch-specific (rubric schemas, review-set node/edge machinery, graph_refs). Audit lessons not touched by the reframe (comment-vs-message provenance, boundary-teaching schemas, hash-pinned prompt directives, private scratchpad) stand as pattern guidance for the spec.\n\n### Process decision (map-level)\n\n**Built artifacts as proofs** ratified into the map Notes: grilling tickets resolve decisions provisionally and name the proof obligations they delegate. Two prototype tickets created from this session: [Walking skeleton: Flue question round-trip](<10-walking-skeleton-flue-roundtrip.md>) and [Logic-prototype: capture sweep & settlement](<11-logic-prototype-capture-sweep.md>). Plugin lifecycle, fault containment, and contract versioning routed to [Shipping shape](<06-shipping-shape.md>).",
+      "innerSha256": "6abd613018b32d1ce53af2ef93b056e10c3c89ad68f43950a792f102edfb5db3",
+      "proposedBody": "This decision keeps free-flowing conversation primary while placing forms and choices within it as interactive elements. The system extracts captured knowledge through repeatable range sweeps after the conversation rather than after each question. It also establishes the four component names: platform, UI, harness, and plugin. The decision was resolved on 2026-08-06.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/05-questioning-ux-contract.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Questioning-UX contract\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 03\n\n## Question\n\nWhat is the kernel's generic questioning-UX contract — the successor to brunch's `ask` / `present_*` / `request_*` exchange family — critiqued rather than copied?\n\nSub-questions:\n\n* Which of brunch's exchange forms earn a place in the generic contract, which generalize with changes, which are brunch-specific and stay behind?\n* What does the \"one high-value question over several low-value questions\" dialogue policy need from the UX contract (question budgets, visible current interpretation, distinguish not-mentioned/no/unknown/N-A)?\n* How do typed issues (missing/ambiguous/conflicting/invalid/unsupported/unmapped/low-confidence) render as user-facing exchanges?\n* What must the contract leave to the host surface (TUI vs. web vs. chat channel) vs. fix in the kernel?\n\nInput from Contract decomposition (issue 04): the exchange contract must carry the envelope's conversation-level semantics — **absence states** (`unknown-to-user | declined | deferred | not-applicable`… as answer outcomes, not null), **alternatives** (letting more than one interpretation stay live through an exchange), and conflict-resolution exchanges (an explicit resolution event for a `conflicting` issue). Dialogue policy is behavioral guidance + factual issue queue — the UX contract renders issues to the agent, never scores them.\n\nNote from the Flue deep-read (issue 01): Flue has **no first-class ask-the-user primitive** — the kernel must own a turn-suspension protocol (`terminate: true` tool + pending question in persistent state + structured data part; the answer arrives as a fresh dispatch). The UX contract should be designed with that as the remote rendering path (`useDataWriter` / `dynamic-tool` output parts), alongside richer local surfaces.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (five rounds), with a live fact-finding pass over Flue's docs mid-session. All shape-level commitments are **working hypotheses** per the built-artifacts-as-proofs preference (ratified into the map's Notes during this session); delegated proof obligations live in tickets 10 (walking skeleton) and 11 (logic-prototype). Vocabulary hardened via `/domain-modeling` into repo `CONTEXT.md`.\n\n### The load-bearing reframe: no exchange-pair ontology\n\nBrunch's exchange machinery (offer→terminal pairs, pending-exchange state, recovery scans) was baggage from its older agent-initiated turn-by-turn model and is **not inherited**. The free-flowing conversation is primary. When the agent poses a structured question it emits an **affordance** — a rendered enhancement in the stream, not a state machine the harness maintains. There is no \"pending exchange\" concept, hence no cardinality rule, no recovery scan, no terminal union.\n\n* Ask invocations **do commit** structured question payloads to the session (design clue: Claude Code's `AskUserQuestion` — question set as `tool_use`, selections/interruption as adjacent `tool_result`; self-contained, replayable, no separate exchange store). The answer may follow as a structured response, or the ask may be cancelled/redirected — all of it is **session evidence**.\n* **Capture is decoupled from asking**: a **range-sweep** over session entries, run on **settlement** (agent-judged, range-level — a vein closing — never per-question, which would resurrect exchange-pairs through the back door). Harness owns sweep bookkeeping (high-water mark, idempotence); agent owns settlement judgment. → ticket 11.\n* Audit lessons demoted by the reframe: *declared continuations / non-forgeability* (the failure mode shifts from forgery to misinterpretation, which the envelope's `epistemic_status: inferred` already covers; whether a widget reply needs an echo token is empirical → ticket 10); *only-answered-closes recovery* and *self-contained terminals* (patterns at most, not structure).\n\n### Shells, vocabulary, and control (hardened)\n\n**substrate** (Pi family, Flue) → **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI) → **harness** (the generic capability layer — mechanism + orchestration; the effort's essence is *harness-engineering*; replaces \"kernel\" as shell name) → **plugin** (target policy). Control is IoC per the Hollywood principle: the plugin declares and registers; the harness discovers, orders, invokes; harness capabilities (the ask API, capture envelope, issue queue, sweep bookkeeping) reach the plugin as a **narrow injected context** — the questioning-UX contract is literally part of the PluginContext surface. Composition is the plugin's at authoring time; control flow is the harness's at runtime. Schema ownership follows capability ownership: *the shell that defines a capability owns its affordance schemas.*\n\n### What the harness fixes (the generic contract)\n\n1. **Baseline question forms**: free-text / single-choice / multi-choice, plus **questionnaire chaining** as first-class baseline (beyond brunch's `ask`). The harness owns the standard ask API and payload shapes; plugins add custom presentation/collection forms through the plugin API.\n2. **Absence**: interpret by default, afford when structured. Agent-interpreted absence from free conversation carries `epistemic_status: inferred`; structured affordances carry a one-tap absence strip (don't-know / not-applicable / decide-later — generalizing `allowNone`), keeping `unknown-to-user` vs `declined` vs `not-applicable` explicit. Transport outcome and epistemic absence never conflate.\n3. **One harness data channel** multiplexing all affordance forms (`form` tag + plugin-typed body + markdown baseline), because Flue channel names are static structural identity in a flat collision-prone namespace. Plugin widgets are progressive enhancement keyed on the form tag; hosts that know only the envelope render everything via markdown. → ticket 10.\n4. **Interpretation render** (\"visible current interpretation\"): the one affordance form that must be harness-owned, since it renders the harness's own envelope vocabulary — captures with epistemic status, absence states, live alternatives. The **plugin may supply a renderer/projector definition with typed arguments** (typed against its own payload shapes), which the harness uses to produce the ui-level view; **when it doesn't, the harness falls back to a default renderer (plain JSON view of payloads)** — keeping the renderer optional, consistent with the smallest-honest-plugin test. React vs. accept are two *capture semantics*, not exchange steps. Renderer-seam exercised once real packs exist (ticket 07's portfolio).\n5. **Issues → exchanges**: only `conflicting` / `possibly-equivalent` get forced treatment — a `conflicting` issue closes **only via an explicit resolution record** (capture-layer event citing the user's utterance as evidence); the guarantee moved from wire to store. Every other issue type renders however the agent judges best, guided by kernel cards — prescribing seven mappings would be judgment-as-procedure. → ticket 11.\n6. **No question-budget machinery**: economical interviewing is implemented through strategy and judgment guidance in pack kernel cards; with asks committed to session, anything countable is derivable — no stored counters, no ask-to-issue attribution model, no stored number for the agent to defer to.\n\n### What the ui owns\n\nRendering (zero built-in widgets in Flue — the embedding app branches on part types), reply transport, identity. Flue facts recorded for the spec: outbound is rich (Valibot-validated `data-*` parts, dynamic-tool outputs), **inbound is string-only** (`sendMessage(text, images)`; SDK signals are string-body too) — so answer typing/validation happens entirely harness-side on read-back; unknown part types are silently dropped (hence the markdown-baseline floor); one documented contradiction (data-part update-in-place vs append) needs the ticket-10 runtime check; turn suspension confirmed (`terminate: true`, answer as fresh dispatch; multi-tool batches terminate only when every result terminates).\n\n### Brunch disposition (sub-question 1)\n\n**Earns a place**: the three answer shapes as interaction vocabulary; questionnaire (promoted); absence affordances (generalized from `allowNone`); react≠accept (as capture semantics); no-stored-agenda (extended: no stored counters either). **Generalizes with changes**: named present tools → plugin-declared forms over one channel; approval-commits-atomically → the resolution-record store guarantee. **Stays behind**: the exchange-pair ontology and everything predicated on it (terminal unions, recovery scans, prev/curr/next chains, declared continuations as wire mechanism), plus everything the audit already classed brunch-specific (rubric schemas, review-set node/edge machinery, graph_refs). Audit lessons not touched by the reframe (comment-vs-message provenance, boundary-teaching schemas, hash-pinned prompt directives, private scratchpad) stand as pattern guidance for the spec.\n\n### Process decision (map-level)\n\n**Built artifacts as proofs** ratified into the map Notes: grilling tickets resolve decisions provisionally and name the proof obligations they delegate. Two prototype tickets created from this session: [Walking skeleton: Flue question round-trip](<10-walking-skeleton-flue-roundtrip.md>) and [Logic-prototype: capture sweep & settlement](<11-logic-prototype-capture-sweep.md>). Plugin lifecycle, fault containment, and contract versioning routed to [Shipping shape](<06-shipping-shape.md>).\n+++",
+      "proposedBodySha256": "cbe10c07bcba59bfe3982e316635a10ad1c18893cf1df8b56ecb04f4bb589580",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "dc49b036-3e7f-4663-85c9-64fa741c64f8",
+      "identifier": "FE-1372",
+      "url": "https://linear.app/hash/issue/FE-1372/shipping-shape-kernel-library-vs-flue-agent-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.583Z",
+      "sourceTitle": "Shipping shape: kernel library vs. Flue agent [archive]",
+      "sourceDescriptionSha256": "b0f7c959583b663416d505a36c08f6db34f037d1bf8842b950cddce5797462c5",
+      "sourceTitleSha256": "1dab9baee26c9752955fa86d601f08aed2a362b5cf4c721084b6f2259ab68b68",
+      "oldOuter": "Decided what actually ships: a harness library inside a thin host-authored agent — not a standalone product — organized as a workspace monorepo with the plugin SDK as its public surface, and tested by generated, replayable interview fixtures rather than live model calls. Resolved 2026-08-08; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Choose how the elicitation harness ships",
+      "proposedOuter": "This decision makes the deliverable a harness library inside a thin host-authored agent rather than a standalone product. A workspace monorepo exposes the plugin SDK, and generated replayable interview fixtures test the system without live model calls. The decision was resolved on 2026-08-08.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/06-shipping-shape.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Shipping shape: kernel library vs. Flue agent\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 01, 04\n\n## Question\n\nWhat does the carve-out physically ship as — a kernel library that a thin Flue agent (and later Petrinaut/web/brunch hosts) embeds, or a Flue agent as the product itself — and what is the viable/ideal package structure?\n\nSub-questions:\n\n* Given the Flue deep-read: is library-embedded-in-agent natural in Flue, or fighting the framework?\n* What does each option cost the Petrinaut-UI and web-UI futures?\n* Package topology: one package or kernel + packs as separate packages? Where do dev targets (elicit-gherkin, elicit-lean) live?\n* What is the local dev loop (run against both targets) vs. the remote deploy story?\n\nInput from Contract decomposition (issue 04): the plugin **SDK surface** is part of the shipping shape — standard machinery for evidence anchoring, claim identity, issue construction, schema validation, retries, idempotency, state-delta application, tracing, test fixtures, and a **local simulation harness** (fixture-driven pack testing: conversation in → expected claims/issues/projections out; \"debugging should not require reading an entire agent transcript\"). The black-box authoring test and change-surface metric are the acceptance bar.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-07 (two rounds + a testing-strategy revision pass grounded in `expert-property-based-testing`).\n\n### Root: harness library in a thin host-authored agent — ratified, with the second-binding test\n\nThe product is the **harness library** (core + packs/plugins); every host authors its own thin `'use agent'` module, `app.ts` mount, and storage adapter, and calls a hook shaped like `useElicitation(plugin)`. The Flue facts make the alternative structurally unavailable anyway (build-time `'use agent'` scan lives in the consuming project; a library cannot ship a pre-registered agent). A runnable reference app ships alongside as a dev/demo vehicle, not as the product.\n\n**Amendment — portability as a named pressure test, not a build target.** The deliverable decomposes into (1) pure runtime mechanism, (2) a tool surface, (3) prompt/skill material — and (3) is already portable for free (Open Agent Skills format is shared by Flue, Claude Code, and Pi-family harnesses). The substrate-agnostic-core non-goal stands as written (no ports for hypothetical consumers, no second maintained binding), but the decomposition must keep a second binding *demonstrably small*:\n\n* The spec **enumerates the substrate-facing surface as a short named capability list** the binding must supply: register a tool · contribute instructions · persist state · emit an affordance payload · suspend-for-reply · private model call. Porting = reimplementing that list; if it grows exotic Flue-shaped entries, that is an early smell signal.\n* **Second-binding test** (sibling to smallest-honest-plugin, adopted into spec acceptance material): every time mechanism wants to land in the binding rather than the core, ask \"is this genuinely substrate-specific, or is mechanism leaking into Flue's dialect?\"\n* Binding-size asymmetry is expected, not a failure: Flue's binding carries the turn-suspension compensation (ticket 10); a terminal binding gets ask-the-user nearly free but may only afford the questioning-UX markdown floor (which issue 05 already fixed as universal). Claude Code/Codex would be the awkward cousins (out-of-process: MCP server + skills dir). The core stays identical; each binding absorbs what its substrate lacks or forbids.\n* **Binding** entered the glossary (`CONTEXT.md`): the harness defines the capability list; a binding imports both harness and substrate; the harness imports no substrate.\n\n### Package topology\n\n* **Core and Flue binding as two workspace packages from day one.** The package boundary is the enforcement mechanism for the portability property; extracting a subpath later is visible churn. Acknowledged as mild ceremony now — accepted because the cost is low if kept clean.\n* **Monorepo in this repo** (brunch-lite becomes the workspace; rename is cheap once the real name resolves). Bun workspaces: `packages/core`, `packages/flue` (binding), `packages/plugin-gherkin`, `packages/plugin-proof-obligations`, `apps/dev`. The dev app owns the `'use agent'` module, `app.ts`, `db.ts`, and the Vite build Flue requires. Spec records the layout as intended structure; nothing is scaffolded during this map.\n* **Plugin packages are** `plugin-*`**, not** `elicit-*` — the prefix names what they are architecturally; \"elicit\" is the function, not the identity.\n* **Plugin SDK is core's public export surface** (authoring types + machinery; test/fixture machinery on a `core/testing` subpath so prod bundles stay clean). A separate SDK package would re-export core with no seam-value.\n* **Dependency rule, stated as a spec invariant: plugins depend on** `core` **only** — never on the binding, never on Flue. Every plugin is substrate-portable by construction, and the black-box authoring test stays honest (a plugin author's world is one package's exports).\n* **Envisioned horizon** (named, not built): per-substrate binding packages (`flue-<name>`, `pi-<name>`, `codex-<name>`), same harness inside each. The payoff *if the second-binding test keeps passing*, not a commitment.\n\n### Cross-cutting choices\n\n* **Valibot throughout** — Flue locks it at every boundary; Standard-Schema-at-the-waist would buy plugin-author comfort at the cost of a conversion seam that can silently drop constraints (named smell: silent coercion/loss).\n* **Tool namespacing: prefix derived from the product name**, provisionally `bl_*` — never `elicit_*` (function vs. identity again). Core names ops abstractly; the binding renders them as substrate tool names. All model-facing tools are harness-owned (plugins expose ops, not tools).\n* **Naming principle** (recurring, carried forward): architectural strings name *identity* (product, role), not *function*; the name-fog eventually resolves every one of these strings, so nothing bakes \"elicit\" or \"brunch\" into structure.\n* **Publishing posture: workspace-internal** — no npm publishing until the real name resolves and an external consumer exists. The spec describes the publishable shape; publishing waits.\n\n### Testing strategy: generation-first fixtures, deterministic replay\n\nThe scripted deterministic driver (ticket 11's headless-driver pattern) is the **execution/replay layer**: fixtures are data, replay is pure, everything runs in plain `bun test` — no model, no substrate. But hand-written fixtures demote to **seeds**; the corpus is generated, answering the two untruthfulness modes:\n\n1. **Circularity** (fixtures tailored to the plugin-as-written): properties come from the **kernel contract** — the ten kernel invariants (ticket 04) are literally properties (re-sweep idempotence, equivalent-state → equivalent-projection, corrections don't erase history, retries idempotent, …) — and generators come from the **plugin's declarations**, never its implementation. The SDK ships `arbitraryFromSchema` (Valibot → fast-check arbitraries) for generated capture populations, plus negative-space properties for plugin code (validators total: never throw, always typed issues; `project` never emits an undeclared loss category).\n2. **Unrealistic conversational dynamics**: (i) most invariants hold over capture/state space directly — no conversation needed; (ii) where dynamics are the subject (sweep/settlement, supersession, absences), **model-based command-sequence testing** (`fc.commands`) over a small command alphabet — utter · settle-range · sweep · correct · contradict · reply-with-absence · redirect — derived from the envelope vocabulary; the fuzzer explores interleavings no hand-scripted conversation contains; (iii) language realism via a **model as offline generator, never CI oracle**: a model plays the respondent against the plugin's own kernel cards (Detects/Questions = targeting spec), varied by persona/curveball, plus a **mutation library** generalizing the minimal-pairs test (epistemic-status flips, absence injections, supersession injections). Outputs freeze as replayable fixture files; **regenerate when declarations change** (the anti-drift mechanism).\n\nBonus adopted: shrunk counterexamples from broken invariants *are* minimal pathological conversations — pinned as regressions and read first as type-design feedback on envelope/payload types. SDK surface therefore includes: schema-driven arbitraries, the command alphabet, mutation operators, fixture freeze/replay format — alongside ticket 04's list (evidence anchoring, capture identity, issue construction, retries, tracing).\n\n### Dev loop, demo, deploy\n\n* **One agent per target** in one dev app (`ElicitGherkin`, `ElicitProofObligations`): static per-agent tool sets (Flue cache economics), and the shape Cloudflare forces later anyway (build-time agent set; plugin choice is conversation-lifetime-immutable via `initialData` regardless).\n* **The dev app is chartered with three roles, spec'd as roles not features**: (1) local dev loop against both plugins; (2) the colleague-facing **target-gallery demo** — parallel tabbed sessions: start a BDD-spec elicitation, open another tab for a proof obligation, another for a process model; (3) the diagnostic/probe surface — provisional affordance renderers now (the deferred UI package's exploratory material), exploded-view instrumented readout when it graduates. Demo-polish and probe-internals pull opposite ways, so they are different views/routes of one app.\n* **UI affordance package deferred**: spec names it as intended (React renderers + reply transport over `@flue/react`; non-React hosts build on `@flue/sdk`), milestone one keeps renderers in the dev app.\n* **Remote deploy: milestone one is local-only; the spec pins the remote-parity constraints** (one-agent-many-conversations, pinned `agentName`, host-owned storage port, no dynamic agent creation) so nothing local-only creeps in. CI smoke = `vite build` + the simulation suite (no model key, no flake); an optional secret-gated real-model `flue run` smoke once a provider key exists. Actual deploy-target choice waits on an infra conversation (user, 2026-08-07) and blocks nothing on this map.\n\n## Comments\n\n**2026-08-07 (context pointer, from issue 11's cleanup).** The prototype branches are the implementation seeds for this topology, kept as primary sources out of main: `prototype/11-capture-sweep` holds the pure capture-layer reducer (no DOM, envelope semantics only) whose behavior `packages/core`'s capture module lifts *as semantics, not code-by-copy*, plus a headless driver whose 32 checks seed the invariant-property suite described under Testing strategy (several are already kernel-invariant instances: re-sweep idempotence, atomic sweep application, corrections-don't-erase-history, single-hop supersession). Likewise `prototype/10-flue-roundtrip` is the sketch `packages/flue` starts from. Working-tree copies were deleted after HITL review; retrieve any file with e.g. `git show prototype/11-capture-sweep:.scratch/elicitation-kernel/prototypes/11-capture-sweep.html`.\n\n**2026-08-10 (amendment, from [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>)).** The charter's persistence hypothesis resolved: **flipped** — the storage port is harness-defined and binding-implemented, plugin-blind; plugin-addressable storage exists only as harness-defined methods passed through the injected PluginContext. This sharpens two things already in this ticket: the capability-list entry \"persist state\" and the remote-parity constraint \"host-owned storage port\". Additionally, evidence spans carry pointer + quoted excerpt, so capture provenance is self-contained regardless of how a deploy target exposes substrate session logs.\n\n**2026-08-10 (amendment, second-target rename).** Per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict, the second target is now the **assurance argument**; the topology's `packages/plugin-proof-obligations` reads `packages/plugin-assurance`.",
+      "innerSha256": "92eed4355aa2a82a0ba5d4e65d53ac27de767087bbce2f98c387b70f0d9e3478",
+      "proposedBody": "This decision makes the deliverable a harness library inside a thin host-authored agent rather than a standalone product. A workspace monorepo exposes the plugin SDK, and generated replayable interview fixtures test the system without live model calls. The decision was resolved on 2026-08-08.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/06-shipping-shape.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Shipping shape: kernel library vs. Flue agent\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 01, 04\n\n## Question\n\nWhat does the carve-out physically ship as — a kernel library that a thin Flue agent (and later Petrinaut/web/brunch hosts) embeds, or a Flue agent as the product itself — and what is the viable/ideal package structure?\n\nSub-questions:\n\n* Given the Flue deep-read: is library-embedded-in-agent natural in Flue, or fighting the framework?\n* What does each option cost the Petrinaut-UI and web-UI futures?\n* Package topology: one package or kernel + packs as separate packages? Where do dev targets (elicit-gherkin, elicit-lean) live?\n* What is the local dev loop (run against both targets) vs. the remote deploy story?\n\nInput from Contract decomposition (issue 04): the plugin **SDK surface** is part of the shipping shape — standard machinery for evidence anchoring, claim identity, issue construction, schema validation, retries, idempotency, state-delta application, tracing, test fixtures, and a **local simulation harness** (fixture-driven pack testing: conversation in → expected claims/issues/projections out; \"debugging should not require reading an entire agent transcript\"). The black-box authoring test and change-surface metric are the acceptance bar.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-07 (two rounds + a testing-strategy revision pass grounded in `expert-property-based-testing`).\n\n### Root: harness library in a thin host-authored agent — ratified, with the second-binding test\n\nThe product is the **harness library** (core + packs/plugins); every host authors its own thin `'use agent'` module, `app.ts` mount, and storage adapter, and calls a hook shaped like `useElicitation(plugin)`. The Flue facts make the alternative structurally unavailable anyway (build-time `'use agent'` scan lives in the consuming project; a library cannot ship a pre-registered agent). A runnable reference app ships alongside as a dev/demo vehicle, not as the product.\n\n**Amendment — portability as a named pressure test, not a build target.** The deliverable decomposes into (1) pure runtime mechanism, (2) a tool surface, (3) prompt/skill material — and (3) is already portable for free (Open Agent Skills format is shared by Flue, Claude Code, and Pi-family harnesses). The substrate-agnostic-core non-goal stands as written (no ports for hypothetical consumers, no second maintained binding), but the decomposition must keep a second binding *demonstrably small*:\n\n* The spec **enumerates the substrate-facing surface as a short named capability list** the binding must supply: register a tool · contribute instructions · persist state · emit an affordance payload · suspend-for-reply · private model call. Porting = reimplementing that list; if it grows exotic Flue-shaped entries, that is an early smell signal.\n* **Second-binding test** (sibling to smallest-honest-plugin, adopted into spec acceptance material): every time mechanism wants to land in the binding rather than the core, ask \"is this genuinely substrate-specific, or is mechanism leaking into Flue's dialect?\"\n* Binding-size asymmetry is expected, not a failure: Flue's binding carries the turn-suspension compensation (ticket 10); a terminal binding gets ask-the-user nearly free but may only afford the questioning-UX markdown floor (which issue 05 already fixed as universal). Claude Code/Codex would be the awkward cousins (out-of-process: MCP server + skills dir). The core stays identical; each binding absorbs what its substrate lacks or forbids.\n* **Binding** entered the glossary (`CONTEXT.md`): the harness defines the capability list; a binding imports both harness and substrate; the harness imports no substrate.\n\n### Package topology\n\n* **Core and Flue binding as two workspace packages from day one.** The package boundary is the enforcement mechanism for the portability property; extracting a subpath later is visible churn. Acknowledged as mild ceremony now — accepted because the cost is low if kept clean.\n* **Monorepo in this repo** (brunch-lite becomes the workspace; rename is cheap once the real name resolves). Bun workspaces: `packages/core`, `packages/flue` (binding), `packages/plugin-gherkin`, `packages/plugin-proof-obligations`, `apps/dev`. The dev app owns the `'use agent'` module, `app.ts`, `db.ts`, and the Vite build Flue requires. Spec records the layout as intended structure; nothing is scaffolded during this map.\n* **Plugin packages are** `plugin-*`**, not** `elicit-*` — the prefix names what they are architecturally; \"elicit\" is the function, not the identity.\n* **Plugin SDK is core's public export surface** (authoring types + machinery; test/fixture machinery on a `core/testing` subpath so prod bundles stay clean). A separate SDK package would re-export core with no seam-value.\n* **Dependency rule, stated as a spec invariant: plugins depend on** `core` **only** — never on the binding, never on Flue. Every plugin is substrate-portable by construction, and the black-box authoring test stays honest (a plugin author's world is one package's exports).\n* **Envisioned horizon** (named, not built): per-substrate binding packages (`flue-<name>`, `pi-<name>`, `codex-<name>`), same harness inside each. The payoff *if the second-binding test keeps passing*, not a commitment.\n\n### Cross-cutting choices\n\n* **Valibot throughout** — Flue locks it at every boundary; Standard-Schema-at-the-waist would buy plugin-author comfort at the cost of a conversion seam that can silently drop constraints (named smell: silent coercion/loss).\n* **Tool namespacing: prefix derived from the product name**, provisionally `bl_*` — never `elicit_*` (function vs. identity again). Core names ops abstractly; the binding renders them as substrate tool names. All model-facing tools are harness-owned (plugins expose ops, not tools).\n* **Naming principle** (recurring, carried forward): architectural strings name *identity* (product, role), not *function*; the name-fog eventually resolves every one of these strings, so nothing bakes \"elicit\" or \"brunch\" into structure.\n* **Publishing posture: workspace-internal** — no npm publishing until the real name resolves and an external consumer exists. The spec describes the publishable shape; publishing waits.\n\n### Testing strategy: generation-first fixtures, deterministic replay\n\nThe scripted deterministic driver (ticket 11's headless-driver pattern) is the **execution/replay layer**: fixtures are data, replay is pure, everything runs in plain `bun test` — no model, no substrate. But hand-written fixtures demote to **seeds**; the corpus is generated, answering the two untruthfulness modes:\n\n1. **Circularity** (fixtures tailored to the plugin-as-written): properties come from the **kernel contract** — the ten kernel invariants (ticket 04) are literally properties (re-sweep idempotence, equivalent-state → equivalent-projection, corrections don't erase history, retries idempotent, …) — and generators come from the **plugin's declarations**, never its implementation. The SDK ships `arbitraryFromSchema` (Valibot → fast-check arbitraries) for generated capture populations, plus negative-space properties for plugin code (validators total: never throw, always typed issues; `project` never emits an undeclared loss category).\n2. **Unrealistic conversational dynamics**: (i) most invariants hold over capture/state space directly — no conversation needed; (ii) where dynamics are the subject (sweep/settlement, supersession, absences), **model-based command-sequence testing** (`fc.commands`) over a small command alphabet — utter · settle-range · sweep · correct · contradict · reply-with-absence · redirect — derived from the envelope vocabulary; the fuzzer explores interleavings no hand-scripted conversation contains; (iii) language realism via a **model as offline generator, never CI oracle**: a model plays the respondent against the plugin's own kernel cards (Detects/Questions = targeting spec), varied by persona/curveball, plus a **mutation library** generalizing the minimal-pairs test (epistemic-status flips, absence injections, supersession injections). Outputs freeze as replayable fixture files; **regenerate when declarations change** (the anti-drift mechanism).\n\nBonus adopted: shrunk counterexamples from broken invariants *are* minimal pathological conversations — pinned as regressions and read first as type-design feedback on envelope/payload types. SDK surface therefore includes: schema-driven arbitraries, the command alphabet, mutation operators, fixture freeze/replay format — alongside ticket 04's list (evidence anchoring, capture identity, issue construction, retries, tracing).\n\n### Dev loop, demo, deploy\n\n* **One agent per target** in one dev app (`ElicitGherkin`, `ElicitProofObligations`): static per-agent tool sets (Flue cache economics), and the shape Cloudflare forces later anyway (build-time agent set; plugin choice is conversation-lifetime-immutable via `initialData` regardless).\n* **The dev app is chartered with three roles, spec'd as roles not features**: (1) local dev loop against both plugins; (2) the colleague-facing **target-gallery demo** — parallel tabbed sessions: start a BDD-spec elicitation, open another tab for a proof obligation, another for a process model; (3) the diagnostic/probe surface — provisional affordance renderers now (the deferred UI package's exploratory material), exploded-view instrumented readout when it graduates. Demo-polish and probe-internals pull opposite ways, so they are different views/routes of one app.\n* **UI affordance package deferred**: spec names it as intended (React renderers + reply transport over `@flue/react`; non-React hosts build on `@flue/sdk`), milestone one keeps renderers in the dev app.\n* **Remote deploy: milestone one is local-only; the spec pins the remote-parity constraints** (one-agent-many-conversations, pinned `agentName`, host-owned storage port, no dynamic agent creation) so nothing local-only creeps in. CI smoke = `vite build` + the simulation suite (no model key, no flake); an optional secret-gated real-model `flue run` smoke once a provider key exists. Actual deploy-target choice waits on an infra conversation (user, 2026-08-07) and blocks nothing on this map.\n\n## Comments\n\n**2026-08-07 (context pointer, from issue 11's cleanup).** The prototype branches are the implementation seeds for this topology, kept as primary sources out of main: `prototype/11-capture-sweep` holds the pure capture-layer reducer (no DOM, envelope semantics only) whose behavior `packages/core`'s capture module lifts *as semantics, not code-by-copy*, plus a headless driver whose 32 checks seed the invariant-property suite described under Testing strategy (several are already kernel-invariant instances: re-sweep idempotence, atomic sweep application, corrections-don't-erase-history, single-hop supersession). Likewise `prototype/10-flue-roundtrip` is the sketch `packages/flue` starts from. Working-tree copies were deleted after HITL review; retrieve any file with e.g. `git show prototype/11-capture-sweep:.scratch/elicitation-kernel/prototypes/11-capture-sweep.html`.\n\n**2026-08-10 (amendment, from [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>)).** The charter's persistence hypothesis resolved: **flipped** — the storage port is harness-defined and binding-implemented, plugin-blind; plugin-addressable storage exists only as harness-defined methods passed through the injected PluginContext. This sharpens two things already in this ticket: the capability-list entry \"persist state\" and the remote-parity constraint \"host-owned storage port\". Additionally, evidence spans carry pointer + quoted excerpt, so capture provenance is self-contained regardless of how a deploy target exposes substrate session logs.\n\n**2026-08-10 (amendment, second-target rename).** Per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict, the second target is now the **assurance argument**; the topology's `packages/plugin-proof-obligations` reads `packages/plugin-assurance`.\n+++",
+      "proposedBodySha256": "5c432f49fb3ad02e7c3e3a20df7fb171ea71204b1176c89ebafdcb40459b8688",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "4b48c94d-9bf0-4c40-beeb-7c5192117580",
+      "identifier": "FE-1373",
+      "url": "https://linear.app/hash/issue/FE-1373/dev-target-portfolio-confirmation-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.618Z",
+      "sourceTitle": "Dev-target portfolio confirmation [archive]",
+      "sourceDescriptionSha256": "a1a499c06b23735a1b16cabcc6c787f35c1e3fda3af30f09c87927173b54f426",
+      "sourceTitleSha256": "f716acc84bd7e8b18c26d9f5020804c103bd5a28cd5f957f643d47885903a973",
+      "oldOuter": "Confirmed the two practice subjects the architecture is built against — Gherkin scenarios and assurance arguments (BPMN third) — because building two very different subjects at once forces the plugin model to stay genuinely general. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Choose the initial elicitation subjects",
+      "proposedOuter": "This decision selects Gherkin scenarios and assurance arguments as the two initial subjects, with BPMN third. Developing two different subjects together tests whether the plugin model remains general. The decision was resolved on 2026-08-07.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/07-dev-target-portfolio.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Dev-target portfolio confirmation\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 02\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). Also superseded here: the four-rung status ladder is demoted to a derived UI label with the assumption ledger as headline (pre-pass S8), and the Geolog/ARIA adjacency guess is refuted (pre-pass S9).\n\n## Question\n\nConfirm the first milestone's two live dev targets. The zil-lean survey resolved the shape of the second: full elicit-lean is **not** dev-sized (writing Lean statements from intent is the deep-expertise step), but the **elicit-proof-obligations** slice is — capture an assumption/lemma/theorem/guarantee dependency graph with criticality and evidence refs, validated by acyclicity + Datalog closure (no Lean statements, no proofs), per the ElicitationPack/ProjectionPack sketches in the survey answer. The survey judges it a *better* second target than BPMN on both pack axes; BPMN stays third.\n\nProposed portfolio to confirm: **elicit-gherkin** (tracer) + **elicit-proof-obligations** (second, forces the pack swap and the evidence-graded IR).\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06.\n\n**Portfolio confirmed**: `elicit-gherkin` + `elicit-proof-obligations` are the first milestone's two live dev targets; `elicit-BPMN/process-mining` is named third; full elicit-lean is deferred (writing Lean statements from intent is the deep-expertise step zil-lean itself never attempts).\n\n**Order — hybrid, addressing the real risk at the design layer**: the spec mandates that **both packs are authored before the pack interface freezes** (design against both simultaneously, on paper — the \"two targets on each axis from the beginning\" rule), while **elicit-gherkin wires end-to-end first** as the cheap mechanism proof, with elicit-proof-obligations immediately after. Rationale: the user's identified risk — brunch failed to find a scalable, modular way to specify an elicitation process plus guiding skill material without over-proceduralizing — lives in interface design, not wiring order. The trivial target must not freeze the pack contract before the hard target has stressed it.\n\n**Design principle surfaced (routed to Contract decomposition as a named input)**: agents do better with *behavioral* guidance than procedural, and with *clear shapes/patterns to fill* rather than schemas that require extensive parsing to build a model of the output shape. Packs are shapes-to-fill plus behavioral guidance — not procedural scripts, not parse-heavy schemas.\n\n**Proof-obligations output format**: steal the ideas, own the format. Adopt zil-lean's load-bearing vocabulary (evidence-graded assurance lattice with prohibited promotions; PROVED/CONDITIONAL/WEAK/BROKEN status ladder; acyclicity + Datalog-closure validation) in our own claim-DAG serialization, **hewing to whatever existing canon fits** — Dafny's `requires/ensures/invariant` contract vocabulary is the leading candidate; Geolog (ARIA program, axioms addressed via Datalog-like queries) is plausibly adjacent. Grounding this is the new **Formal-verification canon survey** ticket (09), which blocks Assemble-the-spec so the milestone lands canon-grounded. `.zc` export is someday-maybe; no dependency on the unproven zil-lean repo.\n\n**Gherkin validator depth (milestone one)**: parse validity + optional **pack-declared step-lexicon** binding check. The apparent codebase coupling dissolves: a step lexicon carried as pack policy needs no external project; only live-codebase step binding defers, named as the target's growth path.\n\nSub-questions:\n\n* Do the two chosen targets differ materially on *both* pack axes (semantic + representation)?\n* What is each target's smallest honest output contract for milestone one?\n* Which target is the tracer (built first) and which trails to force the second-pack swap?",
+      "innerSha256": "af4bb40e8c7c41c4f1c03c942e33f45a93b4934d3850af95029ff474e268a702",
+      "proposedBody": "This decision selects Gherkin scenarios and assurance arguments as the two initial subjects, with BPMN third. Developing two different subjects together tests whether the plugin model remains general. The decision was resolved on 2026-08-07.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/07-dev-target-portfolio.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Dev-target portfolio confirmation\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 02\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). Also superseded here: the four-rung status ladder is demoted to a derived UI label with the assumption ledger as headline (pre-pass S8), and the Geolog/ARIA adjacency guess is refuted (pre-pass S9).\n\n## Question\n\nConfirm the first milestone's two live dev targets. The zil-lean survey resolved the shape of the second: full elicit-lean is **not** dev-sized (writing Lean statements from intent is the deep-expertise step), but the **elicit-proof-obligations** slice is — capture an assumption/lemma/theorem/guarantee dependency graph with criticality and evidence refs, validated by acyclicity + Datalog closure (no Lean statements, no proofs), per the ElicitationPack/ProjectionPack sketches in the survey answer. The survey judges it a *better* second target than BPMN on both pack axes; BPMN stays third.\n\nProposed portfolio to confirm: **elicit-gherkin** (tracer) + **elicit-proof-obligations** (second, forces the pack swap and the evidence-graded IR).\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06.\n\n**Portfolio confirmed**: `elicit-gherkin` + `elicit-proof-obligations` are the first milestone's two live dev targets; `elicit-BPMN/process-mining` is named third; full elicit-lean is deferred (writing Lean statements from intent is the deep-expertise step zil-lean itself never attempts).\n\n**Order — hybrid, addressing the real risk at the design layer**: the spec mandates that **both packs are authored before the pack interface freezes** (design against both simultaneously, on paper — the \"two targets on each axis from the beginning\" rule), while **elicit-gherkin wires end-to-end first** as the cheap mechanism proof, with elicit-proof-obligations immediately after. Rationale: the user's identified risk — brunch failed to find a scalable, modular way to specify an elicitation process plus guiding skill material without over-proceduralizing — lives in interface design, not wiring order. The trivial target must not freeze the pack contract before the hard target has stressed it.\n\n**Design principle surfaced (routed to Contract decomposition as a named input)**: agents do better with *behavioral* guidance than procedural, and with *clear shapes/patterns to fill* rather than schemas that require extensive parsing to build a model of the output shape. Packs are shapes-to-fill plus behavioral guidance — not procedural scripts, not parse-heavy schemas.\n\n**Proof-obligations output format**: steal the ideas, own the format. Adopt zil-lean's load-bearing vocabulary (evidence-graded assurance lattice with prohibited promotions; PROVED/CONDITIONAL/WEAK/BROKEN status ladder; acyclicity + Datalog-closure validation) in our own claim-DAG serialization, **hewing to whatever existing canon fits** — Dafny's `requires/ensures/invariant` contract vocabulary is the leading candidate; Geolog (ARIA program, axioms addressed via Datalog-like queries) is plausibly adjacent. Grounding this is the new **Formal-verification canon survey** ticket (09), which blocks Assemble-the-spec so the milestone lands canon-grounded. `.zc` export is someday-maybe; no dependency on the unproven zil-lean repo.\n\n**Gherkin validator depth (milestone one)**: parse validity + optional **pack-declared step-lexicon** binding check. The apparent codebase coupling dissolves: a step lexicon carried as pack policy needs no external project; only live-codebase step binding defers, named as the target's growth path.\n\nSub-questions:\n\n* Do the two chosen targets differ materially on *both* pack axes (semantic + representation)?\n* What is each target's smallest honest output contract for milestone one?\n* Which target is the tracer (built first) and which trails to force the second-pack swap?\n+++",
+      "proposedBodySha256": "396075c231ecc27d168bfbf7eb9aec920ea14eef5fa50f3fbd460c8fd1d5aa6b",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "fa06f304-4d60-457e-ba14-801664e34c49",
+      "identifier": "FE-1374",
+      "url": "https://linear.app/hash/issue/FE-1374/assemble-the-spec-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.406Z",
+      "sourceTitle": "Assemble the spec [archive]",
+      "sourceDescriptionSha256": "a61865e7695eb3e3170612f0101ffd8bf4dd97c8322fc08c4bd129d2ea0828c1",
+      "sourceTitleSha256": "e0ef68909d31cd8e17da3910dd6beb59c3fd02068b82f7a8179a35a498f40f44",
+      "oldOuter": "The destination of the whole planning effort: assembled the full specification from every resolved ticket — fourteen sections plus an appendix of adjudicated contradictions. The spec lives at `docs/planning/elicitation-kernel/spec.md` (brunch-lite repo), with a companion plain-language product description. Resolved 2026-08-10; this closed the parent map.",
+      "proposedTitle": "Assemble the elicitation harness specification",
+      "proposedOuter": "This task assembled the completed planning decisions into a fourteen-section specification with an appendix that resolves prior contradictions. The specification is at `docs/planning/elicitation-kernel/spec.md`, with a companion plain-language product description. It was completed on 2026-08-10 and closed the parent map.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/08-assemble-the-spec.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Assemble the spec\n\nType: task\nStatus: resolved\nResolved: 2026-08-10\nBlocked by: 04, 05, 06, 07, 09, 10, 11, 12, 13\n\n## Question\n\nAssemble the destination spec from the resolved decisions: architecture + contract decomposition + questioning-UX contract + shipping shape + first milestone against the confirmed dev-target portfolio. Non-goals (harness-agnosticism) and the elicitor→executor seam named explicitly. This is the map's terminal deliverable; resolving it ends the effort.\n\n## Answer\n\n> Resolved by spec assembly, 2026-08-10. Full read of the ~54K-token working set (map, glossary, tickets 01–13 in the pre-pass's amendment order, both inbox docs), one session, no digest subagents — as sized.\n\n**The spec is assembled: [spec.md](<../spec.md>)** — the map's terminal deliverable. Fourteen sections + an adjudications appendix: purpose · non-goals & the elicitor→executor seam · vocabulary · four shells + binding · the capture envelope (derived-status principle, three strata) · operations & validation strata · questioning-UX contract · capture mechanics · sessions/durability/storage port · the ten-item substrate-capability list · plugins & packs · shipping shape · dev targets & milestone one (gherkin + assurance argument, `Statement` contract) · acceptance material (five proof obligations, ten harness invariants restated in envelope vocabulary, gating tests, testing strategy, open verification items).\n\n**All seven pre-pass contradictions adjudicated** (spec Appendix A): C1 storage port binding-implemented, with the `db.ts`-vs-capture-store reconciliation stated; C2 the four operations stay pure — ticket 12's PluginContext-storage clause scoped to non-op code, milestone one defines no such methods; C3 status derived, never stored — retraction specified as an explicit user-cited event with no successor; C4 tap-ness made a transport fact via a harness-defined reserved reply encoding (else absences are inferred); C5 invariant 1 reconciled with the provenance rule — user-derived captures cite user entries, `defaulted`/`external-lookup` cite declared defaults/documented transformations; C6 the channel is a per-message current-affordance surface, durable identity on tool output parts, reject-second-interactive-affordance as mechanism; C7 picked together — no instruction interpolation (kills the wake wart's cause), pending question on the ask tool result + pending-affordance slot, reply binding harness-mechanical via the single-pending invariant, no echo token.\n\n**Notable assembler adjudications beyond the seven** (each flagged inline in the spec): retraction semantics; `not-mentioned` demoted to computed fact; absence-strip label mapping and the `not-yet-decided`/`deferred` distinction; advisories as computed-ephemeral vs. stored issues; issue namespacing; domain labels computed via `project` at read time; transport outcomes `answered | redirected | unanswered` (`unavailable` retired); session→target-document binding via `initialData`; milestone-one store format constrained by whole-sweep atomicity; **kernel card** kept as a term of art, **\"kernel invariants\" renamed harness invariants**.\n\n**Fold-ins completed alongside**: `CONTEXT.md` gained the envelope-vocabulary section (capture envelope, evidence span, epistemic status, absence state, supersession, resolution record, issue, advisory, pack, kernel card, PluginContext, storage port — pre-pass L11) and the kernel-compound ruling (L12); the `plugin-assurance` rename propagated as header notes on tickets 02 and 07; the 42-item obligation checklist verified covered (§ mapping held during drafting); the ten kernel invariants restated in current vocabulary (S14) so only one vocabulary exists in the acceptance criteria.\n\nResolving this ticket ends the effort: the map's frontier is empty. Remaining fog (dev-app probe view, remote deploy target, storage format, concurrent-session coordination, plugin-ecosystem machinery, the real name) is post-spec by construction and graduates with the build effort the spec now enables.\n\n## Comments\n\n**2026-08-10 (pre-assembly prep, HITL).** Three prep items completed ahead of this ticket:\n\n* **Second-target rename decided**: the target is the **assurance argument**, package `plugin-assurance` (recorded on the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>); ticket 09's category-error verdict discharged). Propagate over the historical `elicit-proof-obligations` occurrences in tickets 02 and 07.\n* **Cross-ticket consistency pre-pass**: [notes/consistency-prepass-2026-08-10.md](<../notes/consistency-prepass-2026-08-10.md>) — the assembler's working checklist. Contents: **seven contradictions** the spec must adjudicate, each with an authoritative-side recommendation (C1 storage-port implementer; C2 op purity vs PluginContext storage methods; C3 derived capture status changes 04's envelope schema; C4 `deferred (explicit)` lacks a transport mechanism; C5 provenance rule vs kernel invariant 1's declared defaults; C6 one-live-affordance slot vs multiplexed forms; C7 wake-wart remedy and reply binding must be picked together); **fourteen stale statements** (S1–S14) so nobody re-imports superseded material — notably 03's partly-overturned classification table and the requirement to restate the ten kernel invariants in current vocabulary; the **42-item \"the spec must…\" checklist** (§3b) collected from every ticket; and the **amendment-order reading guide** (§4) — read tickets in that order, treating 01/02/03 as lookup sources.\n* **Sizing corrected**: ~54K tokens total — map + glossary + tickets (~42K) **plus the two inbox docs** (`agentic-elicitation-challenges`, `agentic-elicitation-criteria`, ~13K), which ticket 04 adopts by reference and by count, so the spec cannot be assembled without reading them. Fits one session raw; no digest subagents needed.\n\n**New blocker added**: [Walking skeleton: sweep seam on Flue](<13-walking-skeleton-sweep-seam.md>) — the pre-pass found the sweep seam unproven on the committed substrate (no settlement-trigger lifecycle event exercised, no proven harness path to read a session entry range; items L1–L3). Decision (HITL, 2026-08-10): prove it before assembly. Its resolution also completes the substrate-capability list this spec must enumerate.\n\nAlso fold in when drafting: the glossary needs the envelope vocabulary added (pre-pass L11–L12) — capture envelope, evidence span, epistemic status, absence state, resolution record, supersession, pack, issue, kernel card, PluginContext, storage port — and a ruling on the \"kernel card\" / \"kernel invariants\" compounds vs the glossary's \"avoid: kernel\".\n\n**2026-08-10 (HITL review round 1, via tuicr).** Seven comments on the draft; five spec amendments: (1) **executor/handoff language removed entirely** — brunch adoption leakage; the spec now names *no privileged downstream consumer* (partially supersedes obligation 17's \"elicitor→executor seam\" clause); (2) absence-state enum marked a working set with expected extension pressure (the assumption vs. known-unknown lesson; naming-for-behavioral-activation as kernel-card-grade work); (3) structured taps pinned as optional ui capability, not a requirement; (4) `project` kept as canon op name with a stated prose preference for the noun (and the §9.4 \"signals project\" verb collision fixed); (5) **new §9.7 compaction vs. durable log** — compaction may shrink what the model re-reads, never what the store can resolve; durable-projection independence stated as a storage-contract constraint, binding absorbs otherwise; verification item added to §14.5; (6) Principle v2 ratified by acclaim, no change; (7) **binding packages take the role prefix**: `packages/binding-flue`, horizon `binding-*` (product name lives in the npm scope, not the basename).\n\n**2026-08-11 (HITL review round 2, from the plain-prose read-through).** Four observations, all folded in: (1) evidence pointers confirmed already stored — §5 sharpened so quote→entry resolution is stated as write-time-once, every later reader navigates by pointer, never text search; (2) `declined` ≠ `deferred` pinned in §5.1 — a decline is a boundary (closes only via explicit act), a deferral an invitation (completion evaluation chases it); (3) **conversations are documents too** — storage-port scope extended to capture store **plus session-log archive**, archive-on-read mechanism, session logs retained indefinitely with the target-document (§9.1/§9.6/§9.7 amended; the archive also becomes the compaction defense); (4) **generic strategy quiver written in as §11.5**, named-not-designed — guidance ownership follows vocabulary ownership; harness-shipped strategy cards over envelope vocabulary, plugin-composed; reference shapes `ln-grill`/`ln-disambiguate` and brunch's style trichotomy; the assurance technique decomposes into generic strategy + domain cards. `CONTEXT.md` (storage port, kernel card) and both companion docs updated to match. Note: round 2's changes were narrated in-session on 2026-08-10 but committed 2026-08-11 — the earlier narration preceded the actual edits.",
+      "innerSha256": "4f36c5012d06ba284886145fb9fec5c92aa650338986366b9c619ef383874030",
+      "proposedBody": "This task assembled the completed planning decisions into a fourteen-section specification with an appendix that resolves prior contradictions. The specification is at `docs/planning/elicitation-kernel/spec.md`, with a companion plain-language product description. It was completed on 2026-08-10 and closed the parent map.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/08-assemble-the-spec.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Assemble the spec\n\nType: task\nStatus: resolved\nResolved: 2026-08-10\nBlocked by: 04, 05, 06, 07, 09, 10, 11, 12, 13\n\n## Question\n\nAssemble the destination spec from the resolved decisions: architecture + contract decomposition + questioning-UX contract + shipping shape + first milestone against the confirmed dev-target portfolio. Non-goals (harness-agnosticism) and the elicitor→executor seam named explicitly. This is the map's terminal deliverable; resolving it ends the effort.\n\n## Answer\n\n> Resolved by spec assembly, 2026-08-10. Full read of the ~54K-token working set (map, glossary, tickets 01–13 in the pre-pass's amendment order, both inbox docs), one session, no digest subagents — as sized.\n\n**The spec is assembled: [spec.md](<../spec.md>)** — the map's terminal deliverable. Fourteen sections + an adjudications appendix: purpose · non-goals & the elicitor→executor seam · vocabulary · four shells + binding · the capture envelope (derived-status principle, three strata) · operations & validation strata · questioning-UX contract · capture mechanics · sessions/durability/storage port · the ten-item substrate-capability list · plugins & packs · shipping shape · dev targets & milestone one (gherkin + assurance argument, `Statement` contract) · acceptance material (five proof obligations, ten harness invariants restated in envelope vocabulary, gating tests, testing strategy, open verification items).\n\n**All seven pre-pass contradictions adjudicated** (spec Appendix A): C1 storage port binding-implemented, with the `db.ts`-vs-capture-store reconciliation stated; C2 the four operations stay pure — ticket 12's PluginContext-storage clause scoped to non-op code, milestone one defines no such methods; C3 status derived, never stored — retraction specified as an explicit user-cited event with no successor; C4 tap-ness made a transport fact via a harness-defined reserved reply encoding (else absences are inferred); C5 invariant 1 reconciled with the provenance rule — user-derived captures cite user entries, `defaulted`/`external-lookup` cite declared defaults/documented transformations; C6 the channel is a per-message current-affordance surface, durable identity on tool output parts, reject-second-interactive-affordance as mechanism; C7 picked together — no instruction interpolation (kills the wake wart's cause), pending question on the ask tool result + pending-affordance slot, reply binding harness-mechanical via the single-pending invariant, no echo token.\n\n**Notable assembler adjudications beyond the seven** (each flagged inline in the spec): retraction semantics; `not-mentioned` demoted to computed fact; absence-strip label mapping and the `not-yet-decided`/`deferred` distinction; advisories as computed-ephemeral vs. stored issues; issue namespacing; domain labels computed via `project` at read time; transport outcomes `answered | redirected | unanswered` (`unavailable` retired); session→target-document binding via `initialData`; milestone-one store format constrained by whole-sweep atomicity; **kernel card** kept as a term of art, **\"kernel invariants\" renamed harness invariants**.\n\n**Fold-ins completed alongside**: `CONTEXT.md` gained the envelope-vocabulary section (capture envelope, evidence span, epistemic status, absence state, supersession, resolution record, issue, advisory, pack, kernel card, PluginContext, storage port — pre-pass L11) and the kernel-compound ruling (L12); the `plugin-assurance` rename propagated as header notes on tickets 02 and 07; the 42-item obligation checklist verified covered (§ mapping held during drafting); the ten kernel invariants restated in current vocabulary (S14) so only one vocabulary exists in the acceptance criteria.\n\nResolving this ticket ends the effort: the map's frontier is empty. Remaining fog (dev-app probe view, remote deploy target, storage format, concurrent-session coordination, plugin-ecosystem machinery, the real name) is post-spec by construction and graduates with the build effort the spec now enables.\n\n## Comments\n\n**2026-08-10 (pre-assembly prep, HITL).** Three prep items completed ahead of this ticket:\n\n* **Second-target rename decided**: the target is the **assurance argument**, package `plugin-assurance` (recorded on the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>); ticket 09's category-error verdict discharged). Propagate over the historical `elicit-proof-obligations` occurrences in tickets 02 and 07.\n* **Cross-ticket consistency pre-pass**: [notes/consistency-prepass-2026-08-10.md](<../notes/consistency-prepass-2026-08-10.md>) — the assembler's working checklist. Contents: **seven contradictions** the spec must adjudicate, each with an authoritative-side recommendation (C1 storage-port implementer; C2 op purity vs PluginContext storage methods; C3 derived capture status changes 04's envelope schema; C4 `deferred (explicit)` lacks a transport mechanism; C5 provenance rule vs kernel invariant 1's declared defaults; C6 one-live-affordance slot vs multiplexed forms; C7 wake-wart remedy and reply binding must be picked together); **fourteen stale statements** (S1–S14) so nobody re-imports superseded material — notably 03's partly-overturned classification table and the requirement to restate the ten kernel invariants in current vocabulary; the **42-item \"the spec must…\" checklist** (§3b) collected from every ticket; and the **amendment-order reading guide** (§4) — read tickets in that order, treating 01/02/03 as lookup sources.\n* **Sizing corrected**: ~54K tokens total — map + glossary + tickets (~42K) **plus the two inbox docs** (`agentic-elicitation-challenges`, `agentic-elicitation-criteria`, ~13K), which ticket 04 adopts by reference and by count, so the spec cannot be assembled without reading them. Fits one session raw; no digest subagents needed.\n\n**New blocker added**: [Walking skeleton: sweep seam on Flue](<13-walking-skeleton-sweep-seam.md>) — the pre-pass found the sweep seam unproven on the committed substrate (no settlement-trigger lifecycle event exercised, no proven harness path to read a session entry range; items L1–L3). Decision (HITL, 2026-08-10): prove it before assembly. Its resolution also completes the substrate-capability list this spec must enumerate.\n\nAlso fold in when drafting: the glossary needs the envelope vocabulary added (pre-pass L11–L12) — capture envelope, evidence span, epistemic status, absence state, resolution record, supersession, pack, issue, kernel card, PluginContext, storage port — and a ruling on the \"kernel card\" / \"kernel invariants\" compounds vs the glossary's \"avoid: kernel\".\n\n**2026-08-10 (HITL review round 1, via tuicr).** Seven comments on the draft; five spec amendments: (1) **executor/handoff language removed entirely** — brunch adoption leakage; the spec now names *no privileged downstream consumer* (partially supersedes obligation 17's \"elicitor→executor seam\" clause); (2) absence-state enum marked a working set with expected extension pressure (the assumption vs. known-unknown lesson; naming-for-behavioral-activation as kernel-card-grade work); (3) structured taps pinned as optional ui capability, not a requirement; (4) `project` kept as canon op name with a stated prose preference for the noun (and the §9.4 \"signals project\" verb collision fixed); (5) **new §9.7 compaction vs. durable log** — compaction may shrink what the model re-reads, never what the store can resolve; durable-projection independence stated as a storage-contract constraint, binding absorbs otherwise; verification item added to §14.5; (6) Principle v2 ratified by acclaim, no change; (7) **binding packages take the role prefix**: `packages/binding-flue`, horizon `binding-*` (product name lives in the npm scope, not the basename).\n\n**2026-08-11 (HITL review round 2, from the plain-prose read-through).** Four observations, all folded in: (1) evidence pointers confirmed already stored — §5 sharpened so quote→entry resolution is stated as write-time-once, every later reader navigates by pointer, never text search; (2) `declined` ≠ `deferred` pinned in §5.1 — a decline is a boundary (closes only via explicit act), a deferral an invitation (completion evaluation chases it); (3) **conversations are documents too** — storage-port scope extended to capture store **plus session-log archive**, archive-on-read mechanism, session logs retained indefinitely with the target-document (§9.1/§9.6/§9.7 amended; the archive also becomes the compaction defense); (4) **generic strategy quiver written in as §11.5**, named-not-designed — guidance ownership follows vocabulary ownership; harness-shipped strategy cards over envelope vocabulary, plugin-composed; reference shapes `ln-grill`/`ln-disambiguate` and brunch's style trichotomy; the assurance technique decomposes into generic strategy + domain cards. `CONTEXT.md` (storage port, kernel card) and both companion docs updated to match. Note: round 2's changes were narrated in-session on 2026-08-10 but committed 2026-08-11 — the earlier narration preceded the actual edits.\n+++",
+      "proposedBodySha256": "2580962162612f84dd358987a0972a0b8a9deb126451f0b070f4c8306b9b2e22",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "2375aced-d1bc-4e3c-8b00-88ebc8ea2e8c",
+      "identifier": "FE-1375",
+      "url": "https://linear.app/hash/issue/FE-1375/formal-verification-canon-survey-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.379Z",
+      "sourceTitle": "Formal-verification canon survey [archive]",
+      "sourceDescriptionSha256": "da21a9ce028674fd3a68be0b7b6401585fa9af23cd013781a53c1d1a8a1a787c",
+      "sourceTitleSha256": "686845995b96dbb4605c51d32a3db23e65fe13afab1b3d29fb71ac0f3aa751f5",
+      "oldOuter": "Checked the second practice subject against the formal-verification literature. Verdict: \"proof obligations\" was the wrong name — a category error to verification readers — so the subject was renamed to the assurance argument, aligned to the GSN standard with vocabulary borrowed from Dafny. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Align the assurance subject with verification practice",
+      "proposedOuter": "This research compared the second practice subject with formal-verification literature. It found that “proof obligations” named the wrong concept for verification readers, so the plan renamed the subject “assurance argument” and aligned it with GSN and Dafny vocabulary. The research was resolved on 2026-08-10.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/09-formal-verification-canon-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Formal-verification canon survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\n> **Rename decided 2026-08-10** (HITL, during spec-assembly prep): the second target is the **assurance argument** — GSN's own noun, per this ticket's verdict that \"proof obligations\" reads as a category error. Package: `plugin-assurance` (was `plugin-proof-obligations` in the Shipping-shape topology). References to `elicit-proof-obligations` below are the historical name.\n\nWhat existing canon should the `elicit-proof-obligations` output contract hew to, and — written didactically, for a reader new to formal verification — what does a verification workflow *actually do*: what are its artifacts, what is one trying to produce, where does the human effort go?\n\nSpecifically:\n\n* **Dafny's contract vocabulary** (`requires` / `ensures` / `invariant` / `decreases`, pre/postconditions, loop invariants): how practitioners actually express obligations, and how much of that vocabulary transfers to a language-agnostic claim DAG\n* **Proof-obligation workflow 101**: in Dafny/Lean/TLA+-style work, what is the day-to-day loop (state → obligation → discharge/failure → refine)? What does \"an obligation\" look like as an artifact? What roles do assumptions/axioms play?\n* **Geolog / ARIA relevance**: what is Geolog (ARIA program context — axiom sets ostensibly addressed via Datalog-like queries), and does its shape align with our acyclicity + Datalog-closure validator design?\n* **Recommendation**: what our claim-DAG format should align to — which canon's vocabulary, which parts to adopt vs. leave, and what the smallest canonical-feeling output contract for milestone one looks like\n\nContext: the portfolio decision (issue 07) adopted zil-lean's *ideas* (assurance lattice, PROVED/CONDITIONAL/WEAK/BROKEN ladder, Datalog-closure validation) but rejected its format as unproven; the output contract should feel native to people who do this work.\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Formal-Verification Canon Survey — for the `elicit-proof-obligations` target\n\n## 1. Proof-obligation workflow 101\n\n**The daily loop (Dafny-style, most concrete of the three).** You write code *and* annotations in the same file. You hit save. The verifier translates your program into a pile of logical formulas called **verification conditions (VCs)** and asks an automated prover whether each is valid. Dafny specifically \"verif[ies] that the program meets its specifications, by translating the program to verification conditions and checking those with Boogie and an SMT solver, typically Z3\" ([Dafny Reference Manual §13.1](<https://dafny.org/latest/DafnyRef/DafnyRef>)). Green = discharged. Red = an assertion the solver could not prove. You then edit *the annotations, not usually the code*, and re-run. Loop time is seconds-to-minutes; Midspiral reports \"proofs often take more than 10 minutes to run\" on real domains ([midspiral.com](<https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/>)).\n\n**What a proof obligation *is*.** It is machine-generated, not human-authored. The human writes *contracts*; the tool derives obligations from them. Worked micro-example:\n\n```dafny\nmethod Decrement(n: int) returns (m: int)\n  requires n > 0        // precondition — caller must establish\n  ensures m == n - 1    // postcondition — callee must establish\n  ensures m >= 0\n{ m := n - 1; }\n```\n\nFrom those three lines the verifier generates roughly: (a) *assuming* `n > 0` and the body's effect, prove `m == n-1`; (b) same, prove `m >= 0`; (c) at every call site of `Decrement`, prove `n > 0` holds there. Add a loop and you get more: the invariant holds on entry, is preserved by one iteration, and (with the negated guard) implies what follows — \"The `invariant` clause is effectively a precondition and it along with the negation of the loop test condition provides the postcondition. The `decreases` clause is used to prove termination\" (Dafny RM §7.6). Termination needs the `decreases` expression to both *decrease* and be *bounded below* ([Dafny tutorial, Termination](<https://dafny.org/dafny/OnlineTutorial/guide>)).\n\n**\"Discharging\"** = the prover established that VC. Nobody hand-writes it. **On failure there are exactly two diagnoses** and telling them apart is the actual skill: \"there are two main causes for Dafny verification errors: specifications that are inconsistent with the code, and situations where it is not 'clever' enough to prove the required properties\" (Dafny tutorial). Failure gives you an error at a source location, optionally a counterexample — which Dafny explicitly downgrades to a hint: \"Dafny cannot guarantee that the counterexample it reports provably violates the assertion... should be inspected manually and treated as a hint\" (RM §13.7.1).\n\n**Where human effort goes.** Not into proofs — into *specs, invariants, and hints*. Concretely: strengthening a loop invariant; adding a `lemma` (\"a lemma states a logical fact, summarizing an inference that the verifier cannot do on its own,\" RM §6.3.3); hiding irrelevant facts so the solver focuses (\"sometimes less information is better for the solver,\" RM §8.20.2). Midspiral's numbers make the shape vivid: same kernel, \"counter domain (~50 lines of proofs) and the Kanban domain (~1,400 lines of proofs).\"\n\n**Durable vs. ephemeral artifacts.** Durable: the specification (contracts, invariants), the lemma corpus, and — critically — **the ledger of things assumed rather than proved**. Ephemeral: SMT queries, counterexamples, timings, proof-search traces. And the canon is explicit that the durable spec is the weak point: \"Proofs guarantee that the implementation satisfies the specification. They don't guarantee that the specification is what you actually wanted... The human still owns the spec\" (Midspiral, *Methodology Limitations*). That sentence is the entire justification for your product.\n\n## 2. Dafny's contract vocabulary — what transfers\n\n| Keyword | Meaning | Transfers to a claim DAG about an arbitrary system? |\n| -- | -- | -- |\n| `requires` | precondition, obligation on the *caller* | **Yes** — the canonical name for \"this claim's premise / what must hold for my guarantee to mean anything\" |\n| `ensures` | postcondition, obligation on the *callee* | **Yes** — canonical for \"guarantee\" |\n| `invariant` | property preserved across steps | **Yes** — reads naturally as a system-level always-true claim |\n| `decreases` | termination measure | **Partial** — as a *well-foundedness witness* it's the honest canonical way to license a cycle; otherwise program-bound |\n| `modifies` / `reads` | frame conditions | **No** — \"framing only applies to the heap, or memory accessed through references\" (RM §7.1.4). Inherently program text. |\n| `assert` | prove this here | **Yes** — an obligation you accept |\n| `assume` | take this on faith | **Yes** — this *is* your \"assumption with review status\" |\n| ghost state | spec-only variables, erased at compile | **No** — an artifact of having a compiler |\n| `lemma` | named reusable inference step | **Yes** — maps directly to your lemma record |\n\nThe single most transferable thing in the Dafny ecosystem is not a keyword: it is `dafny audit`, which \"reports issues in the Dafny code that might limit the soundness claims of verification\" and flags declarations marked `{:axiom}`, `{:verify false}`, `{:extern}` with contracts, any `assume` in a body, and `decreases *` — because \"the key purpose of the `audit` command is to ensure that all assumptions are intentional and acknowledged\" (RM §13.6.1.8). It emits a **Markdown table**. That is, near-verbatim, the output artifact you are building. Adopt its framing.\n\n## 3. Adjacent canons\n\n**TLA+.** Obligation-like artifact: an *invariant* or *temporal property* checked against a state machine. Two tools, two epistemics. TLC does bounded exhaustive search: it \"builds a finite state model... performs a breadth-first search... If TLC discovers a state which violates a system invariant, it halts and provides a state trace path\" ([Wikipedia](<https://en.wikipedia.org/wiki/TLA%2B>)). TLAPS does real proof: proofs are \"transformed into individual obligations which are sent to back-end provers\" (Isabelle, Zenon, Z3), and are \"hierarchically structured, easing refactoring and enabling non-linear development: work can begin on later steps before all prior steps are verified.\" **Fit: strong on structure** — hierarchical, obligation-per-step, partial completion is normal — but the vocabulary (`Init`, `Next`, `[]`, fairness) presumes a state machine you don't have.\n\n**Lean / Isabelle.** Artifacts: `definition` / `lemma` / `theorem`, organized in namespaces, with `axiom` a first-class declaration kind ([Lean Language Reference §8](<https://lean-lang.org/doc/reference/latest/>)). The culture-critical mechanism is `sorry`**-tracking**: a proof left incomplete still typechecks but taints the result, and `#print axioms` reveals the taint. **Fit: excellent for your lemma/theorem/assumption trichotomy and for the CONDITIONAL rung** — \"proved, but modulo these named holes\" is native theorem-prover thinking.\n\n**Alloy.** Vocabulary: `sig` (signatures define vocabulary), `fact` (always-true constraints), `pred`, `fun`, `assert` — checked by a SAT-based model finder within a bounded scope ([Wikipedia](<https://en.wikipedia.org/wiki/Alloy_(specification_language)>)). \"Lightweight formal methods\": finds counterexamples, never proves. **Fit: weaker on vocabulary, but philosophically closest to milestone one** — you too are doing a cheap, bounded, always-terminating check that surfaces defects rather than certifying correctness. Borrow the *stance*, not the nouns.\n\n**GSN (assurance cases).** Six core element types: **Goal** (a claim), **Strategy** (the nature of the inference from a goal to its sub-goals), **Solution** (a reference to evidence), **Context**, **Assumption**, **Justification** (rationale). Two link types: **SupportedBy** (inferential or evidential) and **InContextOf** (relating Context/Assumption/Justification to Goals and Strategies). Goals and Strategies may be marked **Undeveloped** — \"a line of argument has not been developed yet.\" Large arguments modularize via **away goals** ([GSN Community Standard v1, FAA-hosted PDF](<https://www.faa.gov/about/office_org/headquarters_offices/ang/redac/redac-sas-201503-gsn-community-standard-v1.pdf>); [SCSC GSN](<https://scsc.uk/gsn>); GSN liaises with OMG's [SACM](<https://www.omg.org/spec/SACM/>)). **Fit: best of the four for interviewed claims about an arbitrary system.** It was designed for exactly your situation — a human argues that a system is adequate, with heterogeneous evidence, in a graph, where \"not yet argued\" is a legitimate node state.\n\n## 4. Geolog / ARIA — negative result, stated plainly\n\n**No ARIA / Safeguarded AI / davidad artifact named \"Geolog\" could be found.** Searches across `geolog + davidad`, `geolog + Safeguarded AI`, `geolog + Datalog + verification kernel`, and GitHub returned nothing. The ARIA [Programme Thesis v2](<https://aria.org.uk/media/ikrkutfk/safeguarded-ai-programme-thesis-v2.pdf>) is an image-heavy PDF whose text could not be extracted; the [funded projects page](<https://aria.org.uk/opportunity-spaces/mathematics-for-safe-ai/safeguarded-ai/funded-projects>) and the [TA1.1 Theory call](<https://aria.org.uk/media/tfkjkjxy/aria-safeguarded-ai-ta11-theory-call-for-proposals.pdf>) describe \"computationally practicable mathematical representations and formal semantics\" without naming a logic. **Do not build on a claim that ARIA ships something called Geolog.**\n\n**What \"Geolog\" actually names in the literature** (documented): a logic-programming language for **coherent logic**, the language whose queries Skolem machines compute (Fisher & Bezem, *Skolem Machines*; Bezem & Coquand, *Automating Coherent Logic*). Coherent logic is \"a restriction of first-order logic due to Skolem that is proof-theoretically tractable\"; geometric logic is its infinitary generalisation, with axioms written as sequents built from `⊤, ∧, ⊥, ⋁, ∃, =`, and models \"preserved and reflected by geometric morphisms\" ([Wikipedia: Geometric logic](<https://en.wikipedia.org/wiki/Geometric_logic>); [nLab: geometric theory](<https://ncatlab.org/nlab/show/geometric+logic>)). There is a separate, unrelated *Geolog* for GIS/spatial Prolog ([arXiv:2109.08295](<https://arxiv.org/abs/2109.08295>)).\n\n**Does the shape align with acyclicity + Datalog closure?** Yes, and non-trivially. Coherent-logic provers are **forward-chaining fixpoint engines** — \"the first automated theorem prover based on coherent logic, Euclid, was developed in Prolog and its inference system relied on a forward-chaining mechanism,\" computing \"the fixpoint for a geometric configuration\" ([Automating Coherent Logic, Springer](<https://link.springer.com/chapter/10.1007/11591191_18>); [A Deductive Database Approach to Automated Geometry Theorem Proving](<https://link.springer.com/article/10.1023/A:1006171315513>)). Datalog is precisely the ∃-free, ⋁-free fragment of that. **(Inference):** the validator is a Datalog restriction of a coherent-logic saturation engine, which is a genuinely canonical lineage you can cite — Geolog is the *right ancestor* to name, just not an ARIA one. Honest caveat: coherent logic in general is undecidable; Datalog is not. The restriction is what buys determinism.\n\n*(Adjacent, real, and possibly what was half-remembered: ARIA-adjacent work on **Kolm**, \"an early-stage decentralized proof database designed to interoperate with Lean\" — mentioned in [a davidad interview](<https://www.cognitiverevolution.ai/alignment-with-awakening-davidad-on-moral-realism-ai-wisdom-why-his-p-doom-is-down-to-5/>), with usable tools projected end of 2027. Single-source; treat as unconfirmed.)*\n\n## 5. RECOMMENDATION\n\n**Align to a GSN skeleton with Dafny nouns on the claim fields and Lean/Dafny-audit semantics on the status ladder.** GSN because it is the only canon designed for *argued* claims about a system by humans with mixed evidence; Dafny because `requires`/`ensures`/`invariant`/`lemma` are the words verification people reach for first and cost nothing to adopt; `dafny audit` because it is literally the deliverable.\n\n**Adopt:** GSN's Goal / Strategy / Solution / Assumption / Justification vocabulary and its two link types; Dafny's `requires`/`ensures`/`invariant`/`lemma`/`assumption`; Lean's `sorry`-taint semantics; `dafny audit`'s \"list of intentional, acknowledged assumptions\" as the primary output.\n**Leave:** `modifies`/`reads` (heap-bound), ghost state, TLA+'s temporal operators, Alloy's `sig`/scope machinery.\n\n### Smallest canonical-feeling milestone-one contract\n\n**One record type,** `Statement`**, with a** `kind` **discriminant** (avoids five near-identical schemas):\n\n* `id`, `kind` ∈ {`goal`, `strategy`, `assumption`, `lemma`, `theorem`, `guarantee`, `constraint`, `evidence`, `justification`, `context`}\n* `statement` — one natural-language sentence, indicative mood\n* `owner`, `review_status` ∈ {`unreviewed`, `accepted`, `disputed`, `retired`} *(assumptions only; from* `dafny audit`*)*\n* `criticality` ∈ {`catastrophic`, `major`, `minor`} — **note: this comes from safety engineering (DAL/SIL/ASIL), not from Dafny/Lean, which have no notion of it.** Source it there and say so.\n* `evidence_refs[]`, `provenance` (transcript span), `developed: bool` (GSN Undeveloped)\n\n**Four edge kinds:**\n\n1. `supports` (GSN SupportedBy — inferential; child → parent)\n2. `evidenced_by` (GSN SupportedBy — evidential; claim → evidence)\n3. `requires` (Dafny precondition; claim → premise it needs)\n4. `in_context_of` (GSN InContextOf; claim → assumption/context/justification)\n\nOnly `supports`, `evidenced_by`, `requires` are load-bearing for status. `in_context_of` is scoping.\n\n**Derived status, stratified:**\n\n* **S0** `refuted(X)` if evidence marked contradicting; `open(X)` if `kind=assumption ∧ review_status ∈ {unreviewed, disputed}`\n* **S1** `BROKEN(X)` if `refuted(X)` ∨ ∃ load-bearing child `BROKEN` *(pure positive recursion — closes first)*\n* **S2** `WEAK(X)` if ¬BROKEN ∧ (`¬developed` ∨ (no `evidenced_by` ∧ no `supports`))\n* **S3** `CONDITIONAL(X)` if ¬BROKEN ∧ ¬WEAK ∧ ∃ transitively-reachable `open` assumption\n* **S4** `PROVED(X)` if ¬BROKEN ∧ ¬WEAK ∧ ¬CONDITIONAL\n\nNegation only ever looks at a lower stratum — that is the stratification the validator must enforce, alongside acyclicity of the three load-bearing edge kinds.\n\n### Where canon conflicts with already-made decisions\n\n1. **The four-rung ladder is not canon; the audit list is.** Dafny and Lean are binary (verified / not) *plus an enumerated list of soundness caveats*. **Canon should win on emphasis:** make the per-claim status a derived UI label, and make the **assumption ledger** — every `open` assumption with its owner, review status, and which guarantees it taints — the headline artifact. Ship it as a Markdown table, like `dafny audit`.\n2. **Acyclicity is stricter than canon.** Lean and Dafny permit mutual recursion licensed by a `decreases` measure. **The acyclicity decision should win for milestone one** — it makes validation trivially decidable and the failure message legible — but record it as a deliberate restriction and name `decreases` as the future escape hatch. That framing reads as informed rather than naive to a verification reader.\n3. **GSN is deliberately *not* computed.** A GSN goal structure is a human argument; nobody derives a verdict from it mechanically. The Datalog closure must therefore be sold as a **well-formedness and taint-propagation check, not an assurance verdict.** Never let the UI say a claim is \"proved\" unqualified. Borrow Alloy's honest stance: this finds defects; it does not certify.\n4. **\"Proof obligation\" is a term of art for a machine-generated VC.** We are eliciting *contracts and claims*, from which obligations would later be generated. Calling the output \"proof obligations\" will read as a category error to a Dafny user. **Prefer \"obligation ledger,\" \"claim structure,\" or \"assurance argument.\"**\n\n## 6. Unreached sources\n\n* ARIA **Safeguarded AI Programme Thesis v1.2 / v2** — PDFs are image-based; no text extraction. Likely the single highest-value unread source for Q4.\n* **GSN Community Standard v3 (SCSC-141C)** — download endpoint returns a redirect stub, not the PDF. GSN element definitions come from the FAA-hosted v1 plus secondary literature; v3 may have refined them.\n* **Bezem & Coquand, *Automating Coherent Logic*** (ResearchGate HTTP 403) and **Fisher & Bezem, *Skolem Machines*** (Semantic Scholar, empty body) — the primary Geolog sources. Read via institutional access before citing Geolog's concrete syntax.\n* **LessWrong: *Davidad's Provably Safe AI Architecture*** — HTTP 429 rate-limited. Worth a retry for Q4.\n* **Alloy online tutorial** (HTML parser crash) and **alloytools day-course slides** (PDF) — Alloy detail rests on Wikipedia plus its citation of Jackson's *Software Abstractions*.\n* **TLAPS project site** (`lamport.azurewebsites.net/tla/tlaps.html`, 404); TLAPS facts are from Wikipedia and the INRIA mirror.\n* **Isabelle documentation** (fetch error) — Isabelle is covered only by analogy to Lean here.",
+      "innerSha256": "b3522ac5372aa5e91bac588fead9e7603c59d5fd669f256d1bc627d68a7e4b7a",
+      "proposedBody": "This research compared the second practice subject with formal-verification literature. It found that “proof obligations” named the wrong concept for verification readers, so the plan renamed the subject “assurance argument” and aligned it with GSN and Dafny vocabulary. The research was resolved on 2026-08-10.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/09-formal-verification-canon-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Formal-verification canon survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\n> **Rename decided 2026-08-10** (HITL, during spec-assembly prep): the second target is the **assurance argument** — GSN's own noun, per this ticket's verdict that \"proof obligations\" reads as a category error. Package: `plugin-assurance` (was `plugin-proof-obligations` in the Shipping-shape topology). References to `elicit-proof-obligations` below are the historical name.\n\nWhat existing canon should the `elicit-proof-obligations` output contract hew to, and — written didactically, for a reader new to formal verification — what does a verification workflow *actually do*: what are its artifacts, what is one trying to produce, where does the human effort go?\n\nSpecifically:\n\n* **Dafny's contract vocabulary** (`requires` / `ensures` / `invariant` / `decreases`, pre/postconditions, loop invariants): how practitioners actually express obligations, and how much of that vocabulary transfers to a language-agnostic claim DAG\n* **Proof-obligation workflow 101**: in Dafny/Lean/TLA+-style work, what is the day-to-day loop (state → obligation → discharge/failure → refine)? What does \"an obligation\" look like as an artifact? What roles do assumptions/axioms play?\n* **Geolog / ARIA relevance**: what is Geolog (ARIA program context — axiom sets ostensibly addressed via Datalog-like queries), and does its shape align with our acyclicity + Datalog-closure validator design?\n* **Recommendation**: what our claim-DAG format should align to — which canon's vocabulary, which parts to adopt vs. leave, and what the smallest canonical-feeling output contract for milestone one looks like\n\nContext: the portfolio decision (issue 07) adopted zil-lean's *ideas* (assurance lattice, PROVED/CONDITIONAL/WEAK/BROKEN ladder, Datalog-closure validation) but rejected its format as unproven; the output contract should feel native to people who do this work.\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Formal-Verification Canon Survey — for the `elicit-proof-obligations` target\n\n## 1. Proof-obligation workflow 101\n\n**The daily loop (Dafny-style, most concrete of the three).** You write code *and* annotations in the same file. You hit save. The verifier translates your program into a pile of logical formulas called **verification conditions (VCs)** and asks an automated prover whether each is valid. Dafny specifically \"verif[ies] that the program meets its specifications, by translating the program to verification conditions and checking those with Boogie and an SMT solver, typically Z3\" ([Dafny Reference Manual §13.1](<https://dafny.org/latest/DafnyRef/DafnyRef>)). Green = discharged. Red = an assertion the solver could not prove. You then edit *the annotations, not usually the code*, and re-run. Loop time is seconds-to-minutes; Midspiral reports \"proofs often take more than 10 minutes to run\" on real domains ([midspiral.com](<https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/>)).\n\n**What a proof obligation *is*.** It is machine-generated, not human-authored. The human writes *contracts*; the tool derives obligations from them. Worked micro-example:\n\n```dafny\nmethod Decrement(n: int) returns (m: int)\n  requires n > 0        // precondition — caller must establish\n  ensures m == n - 1    // postcondition — callee must establish\n  ensures m >= 0\n{ m := n - 1; }\n```\n\nFrom those three lines the verifier generates roughly: (a) *assuming* `n > 0` and the body's effect, prove `m == n-1`; (b) same, prove `m >= 0`; (c) at every call site of `Decrement`, prove `n > 0` holds there. Add a loop and you get more: the invariant holds on entry, is preserved by one iteration, and (with the negated guard) implies what follows — \"The `invariant` clause is effectively a precondition and it along with the negation of the loop test condition provides the postcondition. The `decreases` clause is used to prove termination\" (Dafny RM §7.6). Termination needs the `decreases` expression to both *decrease* and be *bounded below* ([Dafny tutorial, Termination](<https://dafny.org/dafny/OnlineTutorial/guide>)).\n\n**\"Discharging\"** = the prover established that VC. Nobody hand-writes it. **On failure there are exactly two diagnoses** and telling them apart is the actual skill: \"there are two main causes for Dafny verification errors: specifications that are inconsistent with the code, and situations where it is not 'clever' enough to prove the required properties\" (Dafny tutorial). Failure gives you an error at a source location, optionally a counterexample — which Dafny explicitly downgrades to a hint: \"Dafny cannot guarantee that the counterexample it reports provably violates the assertion... should be inspected manually and treated as a hint\" (RM §13.7.1).\n\n**Where human effort goes.** Not into proofs — into *specs, invariants, and hints*. Concretely: strengthening a loop invariant; adding a `lemma` (\"a lemma states a logical fact, summarizing an inference that the verifier cannot do on its own,\" RM §6.3.3); hiding irrelevant facts so the solver focuses (\"sometimes less information is better for the solver,\" RM §8.20.2). Midspiral's numbers make the shape vivid: same kernel, \"counter domain (~50 lines of proofs) and the Kanban domain (~1,400 lines of proofs).\"\n\n**Durable vs. ephemeral artifacts.** Durable: the specification (contracts, invariants), the lemma corpus, and — critically — **the ledger of things assumed rather than proved**. Ephemeral: SMT queries, counterexamples, timings, proof-search traces. And the canon is explicit that the durable spec is the weak point: \"Proofs guarantee that the implementation satisfies the specification. They don't guarantee that the specification is what you actually wanted... The human still owns the spec\" (Midspiral, *Methodology Limitations*). That sentence is the entire justification for your product.\n\n## 2. Dafny's contract vocabulary — what transfers\n\n| Keyword | Meaning | Transfers to a claim DAG about an arbitrary system? |\n| -- | -- | -- |\n| `requires` | precondition, obligation on the *caller* | **Yes** — the canonical name for \"this claim's premise / what must hold for my guarantee to mean anything\" |\n| `ensures` | postcondition, obligation on the *callee* | **Yes** — canonical for \"guarantee\" |\n| `invariant` | property preserved across steps | **Yes** — reads naturally as a system-level always-true claim |\n| `decreases` | termination measure | **Partial** — as a *well-foundedness witness* it's the honest canonical way to license a cycle; otherwise program-bound |\n| `modifies` / `reads` | frame conditions | **No** — \"framing only applies to the heap, or memory accessed through references\" (RM §7.1.4). Inherently program text. |\n| `assert` | prove this here | **Yes** — an obligation you accept |\n| `assume` | take this on faith | **Yes** — this *is* your \"assumption with review status\" |\n| ghost state | spec-only variables, erased at compile | **No** — an artifact of having a compiler |\n| `lemma` | named reusable inference step | **Yes** — maps directly to your lemma record |\n\nThe single most transferable thing in the Dafny ecosystem is not a keyword: it is `dafny audit`, which \"reports issues in the Dafny code that might limit the soundness claims of verification\" and flags declarations marked `{:axiom}`, `{:verify false}`, `{:extern}` with contracts, any `assume` in a body, and `decreases *` — because \"the key purpose of the `audit` command is to ensure that all assumptions are intentional and acknowledged\" (RM §13.6.1.8). It emits a **Markdown table**. That is, near-verbatim, the output artifact you are building. Adopt its framing.\n\n## 3. Adjacent canons\n\n**TLA+.** Obligation-like artifact: an *invariant* or *temporal property* checked against a state machine. Two tools, two epistemics. TLC does bounded exhaustive search: it \"builds a finite state model... performs a breadth-first search... If TLC discovers a state which violates a system invariant, it halts and provides a state trace path\" ([Wikipedia](<https://en.wikipedia.org/wiki/TLA%2B>)). TLAPS does real proof: proofs are \"transformed into individual obligations which are sent to back-end provers\" (Isabelle, Zenon, Z3), and are \"hierarchically structured, easing refactoring and enabling non-linear development: work can begin on later steps before all prior steps are verified.\" **Fit: strong on structure** — hierarchical, obligation-per-step, partial completion is normal — but the vocabulary (`Init`, `Next`, `[]`, fairness) presumes a state machine you don't have.\n\n**Lean / Isabelle.** Artifacts: `definition` / `lemma` / `theorem`, organized in namespaces, with `axiom` a first-class declaration kind ([Lean Language Reference §8](<https://lean-lang.org/doc/reference/latest/>)). The culture-critical mechanism is `sorry`**-tracking**: a proof left incomplete still typechecks but taints the result, and `#print axioms` reveals the taint. **Fit: excellent for your lemma/theorem/assumption trichotomy and for the CONDITIONAL rung** — \"proved, but modulo these named holes\" is native theorem-prover thinking.\n\n**Alloy.** Vocabulary: `sig` (signatures define vocabulary), `fact` (always-true constraints), `pred`, `fun`, `assert` — checked by a SAT-based model finder within a bounded scope ([Wikipedia](<https://en.wikipedia.org/wiki/Alloy_(specification_language)>)). \"Lightweight formal methods\": finds counterexamples, never proves. **Fit: weaker on vocabulary, but philosophically closest to milestone one** — you too are doing a cheap, bounded, always-terminating check that surfaces defects rather than certifying correctness. Borrow the *stance*, not the nouns.\n\n**GSN (assurance cases).** Six core element types: **Goal** (a claim), **Strategy** (the nature of the inference from a goal to its sub-goals), **Solution** (a reference to evidence), **Context**, **Assumption**, **Justification** (rationale). Two link types: **SupportedBy** (inferential or evidential) and **InContextOf** (relating Context/Assumption/Justification to Goals and Strategies). Goals and Strategies may be marked **Undeveloped** — \"a line of argument has not been developed yet.\" Large arguments modularize via **away goals** ([GSN Community Standard v1, FAA-hosted PDF](<https://www.faa.gov/about/office_org/headquarters_offices/ang/redac/redac-sas-201503-gsn-community-standard-v1.pdf>); [SCSC GSN](<https://scsc.uk/gsn>); GSN liaises with OMG's [SACM](<https://www.omg.org/spec/SACM/>)). **Fit: best of the four for interviewed claims about an arbitrary system.** It was designed for exactly your situation — a human argues that a system is adequate, with heterogeneous evidence, in a graph, where \"not yet argued\" is a legitimate node state.\n\n## 4. Geolog / ARIA — negative result, stated plainly\n\n**No ARIA / Safeguarded AI / davidad artifact named \"Geolog\" could be found.** Searches across `geolog + davidad`, `geolog + Safeguarded AI`, `geolog + Datalog + verification kernel`, and GitHub returned nothing. The ARIA [Programme Thesis v2](<https://aria.org.uk/media/ikrkutfk/safeguarded-ai-programme-thesis-v2.pdf>) is an image-heavy PDF whose text could not be extracted; the [funded projects page](<https://aria.org.uk/opportunity-spaces/mathematics-for-safe-ai/safeguarded-ai/funded-projects>) and the [TA1.1 Theory call](<https://aria.org.uk/media/tfkjkjxy/aria-safeguarded-ai-ta11-theory-call-for-proposals.pdf>) describe \"computationally practicable mathematical representations and formal semantics\" without naming a logic. **Do not build on a claim that ARIA ships something called Geolog.**\n\n**What \"Geolog\" actually names in the literature** (documented): a logic-programming language for **coherent logic**, the language whose queries Skolem machines compute (Fisher & Bezem, *Skolem Machines*; Bezem & Coquand, *Automating Coherent Logic*). Coherent logic is \"a restriction of first-order logic due to Skolem that is proof-theoretically tractable\"; geometric logic is its infinitary generalisation, with axioms written as sequents built from `⊤, ∧, ⊥, ⋁, ∃, =`, and models \"preserved and reflected by geometric morphisms\" ([Wikipedia: Geometric logic](<https://en.wikipedia.org/wiki/Geometric_logic>); [nLab: geometric theory](<https://ncatlab.org/nlab/show/geometric+logic>)). There is a separate, unrelated *Geolog* for GIS/spatial Prolog ([arXiv:2109.08295](<https://arxiv.org/abs/2109.08295>)).\n\n**Does the shape align with acyclicity + Datalog closure?** Yes, and non-trivially. Coherent-logic provers are **forward-chaining fixpoint engines** — \"the first automated theorem prover based on coherent logic, Euclid, was developed in Prolog and its inference system relied on a forward-chaining mechanism,\" computing \"the fixpoint for a geometric configuration\" ([Automating Coherent Logic, Springer](<https://link.springer.com/chapter/10.1007/11591191_18>); [A Deductive Database Approach to Automated Geometry Theorem Proving](<https://link.springer.com/article/10.1023/A:1006171315513>)). Datalog is precisely the ∃-free, ⋁-free fragment of that. **(Inference):** the validator is a Datalog restriction of a coherent-logic saturation engine, which is a genuinely canonical lineage you can cite — Geolog is the *right ancestor* to name, just not an ARIA one. Honest caveat: coherent logic in general is undecidable; Datalog is not. The restriction is what buys determinism.\n\n*(Adjacent, real, and possibly what was half-remembered: ARIA-adjacent work on **Kolm**, \"an early-stage decentralized proof database designed to interoperate with Lean\" — mentioned in [a davidad interview](<https://www.cognitiverevolution.ai/alignment-with-awakening-davidad-on-moral-realism-ai-wisdom-why-his-p-doom-is-down-to-5/>), with usable tools projected end of 2027. Single-source; treat as unconfirmed.)*\n\n## 5. RECOMMENDATION\n\n**Align to a GSN skeleton with Dafny nouns on the claim fields and Lean/Dafny-audit semantics on the status ladder.** GSN because it is the only canon designed for *argued* claims about a system by humans with mixed evidence; Dafny because `requires`/`ensures`/`invariant`/`lemma` are the words verification people reach for first and cost nothing to adopt; `dafny audit` because it is literally the deliverable.\n\n**Adopt:** GSN's Goal / Strategy / Solution / Assumption / Justification vocabulary and its two link types; Dafny's `requires`/`ensures`/`invariant`/`lemma`/`assumption`; Lean's `sorry`-taint semantics; `dafny audit`'s \"list of intentional, acknowledged assumptions\" as the primary output.\n**Leave:** `modifies`/`reads` (heap-bound), ghost state, TLA+'s temporal operators, Alloy's `sig`/scope machinery.\n\n### Smallest canonical-feeling milestone-one contract\n\n**One record type,** `Statement`**, with a** `kind` **discriminant** (avoids five near-identical schemas):\n\n* `id`, `kind` ∈ {`goal`, `strategy`, `assumption`, `lemma`, `theorem`, `guarantee`, `constraint`, `evidence`, `justification`, `context`}\n* `statement` — one natural-language sentence, indicative mood\n* `owner`, `review_status` ∈ {`unreviewed`, `accepted`, `disputed`, `retired`} *(assumptions only; from* `dafny audit`*)*\n* `criticality` ∈ {`catastrophic`, `major`, `minor`} — **note: this comes from safety engineering (DAL/SIL/ASIL), not from Dafny/Lean, which have no notion of it.** Source it there and say so.\n* `evidence_refs[]`, `provenance` (transcript span), `developed: bool` (GSN Undeveloped)\n\n**Four edge kinds:**\n\n1. `supports` (GSN SupportedBy — inferential; child → parent)\n2. `evidenced_by` (GSN SupportedBy — evidential; claim → evidence)\n3. `requires` (Dafny precondition; claim → premise it needs)\n4. `in_context_of` (GSN InContextOf; claim → assumption/context/justification)\n\nOnly `supports`, `evidenced_by`, `requires` are load-bearing for status. `in_context_of` is scoping.\n\n**Derived status, stratified:**\n\n* **S0** `refuted(X)` if evidence marked contradicting; `open(X)` if `kind=assumption ∧ review_status ∈ {unreviewed, disputed}`\n* **S1** `BROKEN(X)` if `refuted(X)` ∨ ∃ load-bearing child `BROKEN` *(pure positive recursion — closes first)*\n* **S2** `WEAK(X)` if ¬BROKEN ∧ (`¬developed` ∨ (no `evidenced_by` ∧ no `supports`))\n* **S3** `CONDITIONAL(X)` if ¬BROKEN ∧ ¬WEAK ∧ ∃ transitively-reachable `open` assumption\n* **S4** `PROVED(X)` if ¬BROKEN ∧ ¬WEAK ∧ ¬CONDITIONAL\n\nNegation only ever looks at a lower stratum — that is the stratification the validator must enforce, alongside acyclicity of the three load-bearing edge kinds.\n\n### Where canon conflicts with already-made decisions\n\n1. **The four-rung ladder is not canon; the audit list is.** Dafny and Lean are binary (verified / not) *plus an enumerated list of soundness caveats*. **Canon should win on emphasis:** make the per-claim status a derived UI label, and make the **assumption ledger** — every `open` assumption with its owner, review status, and which guarantees it taints — the headline artifact. Ship it as a Markdown table, like `dafny audit`.\n2. **Acyclicity is stricter than canon.** Lean and Dafny permit mutual recursion licensed by a `decreases` measure. **The acyclicity decision should win for milestone one** — it makes validation trivially decidable and the failure message legible — but record it as a deliberate restriction and name `decreases` as the future escape hatch. That framing reads as informed rather than naive to a verification reader.\n3. **GSN is deliberately *not* computed.** A GSN goal structure is a human argument; nobody derives a verdict from it mechanically. The Datalog closure must therefore be sold as a **well-formedness and taint-propagation check, not an assurance verdict.** Never let the UI say a claim is \"proved\" unqualified. Borrow Alloy's honest stance: this finds defects; it does not certify.\n4. **\"Proof obligation\" is a term of art for a machine-generated VC.** We are eliciting *contracts and claims*, from which obligations would later be generated. Calling the output \"proof obligations\" will read as a category error to a Dafny user. **Prefer \"obligation ledger,\" \"claim structure,\" or \"assurance argument.\"**\n\n## 6. Unreached sources\n\n* ARIA **Safeguarded AI Programme Thesis v1.2 / v2** — PDFs are image-based; no text extraction. Likely the single highest-value unread source for Q4.\n* **GSN Community Standard v3 (SCSC-141C)** — download endpoint returns a redirect stub, not the PDF. GSN element definitions come from the FAA-hosted v1 plus secondary literature; v3 may have refined them.\n* **Bezem & Coquand, *Automating Coherent Logic*** (ResearchGate HTTP 403) and **Fisher & Bezem, *Skolem Machines*** (Semantic Scholar, empty body) — the primary Geolog sources. Read via institutional access before citing Geolog's concrete syntax.\n* **LessWrong: *Davidad's Provably Safe AI Architecture*** — HTTP 429 rate-limited. Worth a retry for Q4.\n* **Alloy online tutorial** (HTML parser crash) and **alloytools day-course slides** (PDF) — Alloy detail rests on Wikipedia plus its citation of Jackson's *Software Abstractions*.\n* **TLAPS project site** (`lamport.azurewebsites.net/tla/tlaps.html`, 404); TLAPS facts are from Wikipedia and the INRIA mirror.\n* **Isabelle documentation** (fetch error) — Isabelle is covered only by analogy to Lean here.\n+++",
+      "proposedBodySha256": "b8e8ecc04e49eca99b147e04ee010d0d8b01d563190d52857ded2b760a29f919",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "f1ae0996-3c1f-4dcd-90a3-703b8681a7c3",
+      "identifier": "FE-1376",
+      "url": "https://linear.app/hash/issue/FE-1376/walking-skeleton-flue-question-round-trip-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.447Z",
+      "sourceTitle": "Walking skeleton: Flue question round-trip [archive]",
+      "sourceDescriptionSha256": "ed9a8f3a2277d2bbb6122af8c449793c65672faa235173b5d51d657f8e5dc3c6",
+      "sourceTitleSha256": "b44606046ef4f88db1c99ea98b64ca1c22da4d2dbe757268232851b775131f77",
+      "oldOuter": "Built a working skeleton on real Flue proving a structured question can travel from the agent to the user and the answer back — with the discovered constraint that only one live question can be pending at a time, which became a rule in the spec. Code on branch `prototype/10-flue-roundtrip` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Prove a Flue question round trip",
+      "proposedOuter": "This prototype demonstrated that a structured question can travel from the agent to the user and return with an answer on Flue. It also found that only one live question can remain pending, which became a specification rule. The code is on branch `prototype/10-flue-roundtrip`, and the task was resolved on 2026-08-09.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: Flue question round-trip\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDoes the one-channel questioning transport hold up in a real Flue agent + web UI? Build a walking skeleton — real Flue agent, minimal elicitor stub (no plugin), one question round-trip: structured ask affordance emitted via a single kernel-owned data channel (`form` tag + markdown-baseline payload), answer returned as string dispatch, interpretation recorded to the session.\n\nProves or refutes (proof obligations delegated from the Questioning-UX contract, issue 05):\n\n* The **one-channel multiplex** working hypothesis: one fixed `data-exchange` channel, forms discriminated inside the payload, plugin widgets as progressive enhancement.\n* The **data-part update-in-place vs. append** contradiction in Flue's docs (hooks reference says in-place; streaming protocol + `AgentReply.data` say append) — runtime check.\n* Whether a reply needs an **echo token** binding it to the question asked, or whether transcript adjacency + agent interpretation suffice.\n* What the **turn-suspension protocol** actually needs to persist (`terminate: true` tool + fresh-dispatch answer) — and how a cancelled/redirected question reads back from the session.\n* UI-side **rendering ergonomics**: branching on the form tag, markdown fallback for unknown forms, `purpose`/`display` filtering of non-user-facing traffic.\n\n## Answer\n\n> Resolved by walking skeleton, 2026-08-07. Real Flue agent (`@flue/runtime` 2.0.3, vite 8, Node target, no db) + React UI (`useFlueAgent`), driven live over multiple conversations: full round-trips through single-choice, free-text, an unknown form, absence-strip taps, and a redirect. Prototype captured on branch `prototype/10-flue-roundtrip` (`prototypes/flue-roundtrip/` — README documents the probes; `probe-stream.mjs` is the SSE-level evidence).\n\n**Overall: the transport holds — with one load-bearing amendment.** The one-channel questioning transport survives contact with the real runtime, but the fixed data channel is a *one-live-affordance slot per message*, not an accumulating log, so affordance **identity** must ride the ask tool's output part, not the channel.\n\n### Verdict per proof obligation\n\n1. **One-channel multiplex: PROVEN, amended.** One `data-exchange` channel carried three forms (single-choice, free-text, and the deliberately unknown `rating-stars`); the UI branched on the `form` tag, rendered widgets for known forms and the markdown floor for the unknown one, and reply transport stayed string-only throughout. **The amendment:** writes to one channel name materialize *last-write-wins per assistant message* — forced two `ask_user` calls in one turn, and the first question's affordance was silently clobbered from the durable record (both `dynamic-tool` parts survived, with inputs and validated outputs). So: the channel is a \"current affordance\" surface; per-ask identity and payload belong on the ask tool's `output` (Flue's React docs bless exactly this — tool output parts exist \"so applications can render custom tool interfaces\"). A kernel invariant follows: **the ask tool must reject a second ask in the same batch** (mechanism, not instruction — the stub's instruction-level \"one question at a time\" held until deliberately overridden, but the guarantee belongs in the tool).\n2. **Update-in-place vs append: SETTLED — update-in-place, at every layer.** The hooks reference wins; the streaming protocol's \"append\" describes delta chunks, not part materialization. Evidence: two same-channel writes (`draft` → `open`) produced two SSE deltas but every snapshot held exactly one part; durable history holds one part (final value); even `readSubmissionReply`'s \"emit order\" array returns one entry. Clients DO see intermediate values live (progress rendering works); only the final value persists.\n3. **Echo token: NOT NEEDED for the tested shapes — adjacency + persistent pending state suffice.** All replies were bare strings (typed text, choice-button labels, absence taps, a mid-stream redirect); the agent bound every one to the correct `exchangeId` because the pending question (with its id) is interpolated into the instructions from `usePersistentState`. The binding evidence is the `record_interpretation` tool part citing the exchangeId — session evidence, exactly as issue 05 hypothesized. Untested residual: simultaneous multiple open questions (ruled out by the one-ask invariant above) and long-delay/interleaved answers.\n4. **Turn suspension: WORKS, with a wake wart.** `terminate: true` + pending question in `usePersistentState` + answer-as-fresh-dispatch is sufficient; nothing else needed persisting. A cancelled/redirected question reads back cleanly: the affordance part stays in the transcript, and the `record_interpretation` part (`outcome: redirected`, `epistemicStatus: stated`) is the resolution evidence — the store-level guarantee issue 05 wanted. **The wart:** writing pending-state that's interpolated into instructions triggers a \"System instructions updated\" advisory *after* the terminating batch, which wakes the model for an extra turn that emits redundant \"I'm still waiting…\" text — one wasted model call per ask, plus transcript noise. Spec options: don't interpolate the pending question into instructions (keep it in state only, or narrate it inside the ask tool's result), or accept and UI-filter. Related fact: a mixed batch (non-terminating `record_interpretation` + terminating `ask_user`) still suspended correctly.\n5. **Rendering ergonomics: PROVEN.** Form-tag branching, markdown fallback, and read-back of a whole past conversation from durable history (including resolved-question dimming derived purely from `record_interpretation` parts in the transcript — no side store) all worked first try. Messages carry `purpose` and `display` fields (`display: \"diagnostic\"` on the advisory noise) — the UI must filter on them; the skeleton didn't at first, and the advisories rendered as visible cards.\n\n### Incidental facts worth the spec's attention\n\n* `@flue/vite` **hard-requires vite ^8** (its `parseAstAsync` TS support); on vite 6 the `'use agent'` scan dies with a bare parse error. The directive must also be the file's first statement.\n* **The Flue dev controller gives** `app.ts` **the entire request space** — no fall-through to vite's HTML serving — so a co-located browser UI is served by the Hono app itself (vite still transforms module requests, but react-refresh/HMR is off the table without a second server). A real deployment would face the same: the ui shell is a separate app or app-served static assets.\n* Data-channel writes are Valibot-validated per write; `body: v.any()` works fine as the opaque plugin-payload slot with typed envelope fields around it.\n* Restart durability untested by design (no `db.ts` → process-memory conversations; a restart wipes them — consistent with the deploy-target-owns-persistence hypothesis).\n\n## Comments\n\n**2026-08-07 (user, post-resolution):** Ratified reading of the questionnaire dimension against the clobbering finding — the whole questionnaire is a **single affordance with multiple steps**, not per-question affordances. The **one-ask-per-batch invariant stands** even though one ask may carry multiple questions passed in the same call. **Progression is UI-driven**: the payload carries all N questions, the ui walks them locally, answers return as evidence (individually or batched), and the agent interprets on settlement — zero intermediate model turns, sidestepping the wake-wart. Interpretation-on-settlement hands off to the capture-sweep semantics in ticket 11.",
+      "innerSha256": "c211016d13a5e46835dddd71c1c611027dc47df950221d50117a51e06622b450",
+      "proposedBody": "This prototype demonstrated that a structured question can travel from the agent to the user and return with an answer on Flue. It also found that only one live question can remain pending, which became a specification rule. The code is on branch `prototype/10-flue-roundtrip`, and the task was resolved on 2026-08-09.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: Flue question round-trip\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDoes the one-channel questioning transport hold up in a real Flue agent + web UI? Build a walking skeleton — real Flue agent, minimal elicitor stub (no plugin), one question round-trip: structured ask affordance emitted via a single kernel-owned data channel (`form` tag + markdown-baseline payload), answer returned as string dispatch, interpretation recorded to the session.\n\nProves or refutes (proof obligations delegated from the Questioning-UX contract, issue 05):\n\n* The **one-channel multiplex** working hypothesis: one fixed `data-exchange` channel, forms discriminated inside the payload, plugin widgets as progressive enhancement.\n* The **data-part update-in-place vs. append** contradiction in Flue's docs (hooks reference says in-place; streaming protocol + `AgentReply.data` say append) — runtime check.\n* Whether a reply needs an **echo token** binding it to the question asked, or whether transcript adjacency + agent interpretation suffice.\n* What the **turn-suspension protocol** actually needs to persist (`terminate: true` tool + fresh-dispatch answer) — and how a cancelled/redirected question reads back from the session.\n* UI-side **rendering ergonomics**: branching on the form tag, markdown fallback for unknown forms, `purpose`/`display` filtering of non-user-facing traffic.\n\n## Answer\n\n> Resolved by walking skeleton, 2026-08-07. Real Flue agent (`@flue/runtime` 2.0.3, vite 8, Node target, no db) + React UI (`useFlueAgent`), driven live over multiple conversations: full round-trips through single-choice, free-text, an unknown form, absence-strip taps, and a redirect. Prototype captured on branch `prototype/10-flue-roundtrip` (`prototypes/flue-roundtrip/` — README documents the probes; `probe-stream.mjs` is the SSE-level evidence).\n\n**Overall: the transport holds — with one load-bearing amendment.** The one-channel questioning transport survives contact with the real runtime, but the fixed data channel is a *one-live-affordance slot per message*, not an accumulating log, so affordance **identity** must ride the ask tool's output part, not the channel.\n\n### Verdict per proof obligation\n\n1. **One-channel multiplex: PROVEN, amended.** One `data-exchange` channel carried three forms (single-choice, free-text, and the deliberately unknown `rating-stars`); the UI branched on the `form` tag, rendered widgets for known forms and the markdown floor for the unknown one, and reply transport stayed string-only throughout. **The amendment:** writes to one channel name materialize *last-write-wins per assistant message* — forced two `ask_user` calls in one turn, and the first question's affordance was silently clobbered from the durable record (both `dynamic-tool` parts survived, with inputs and validated outputs). So: the channel is a \"current affordance\" surface; per-ask identity and payload belong on the ask tool's `output` (Flue's React docs bless exactly this — tool output parts exist \"so applications can render custom tool interfaces\"). A kernel invariant follows: **the ask tool must reject a second ask in the same batch** (mechanism, not instruction — the stub's instruction-level \"one question at a time\" held until deliberately overridden, but the guarantee belongs in the tool).\n2. **Update-in-place vs append: SETTLED — update-in-place, at every layer.** The hooks reference wins; the streaming protocol's \"append\" describes delta chunks, not part materialization. Evidence: two same-channel writes (`draft` → `open`) produced two SSE deltas but every snapshot held exactly one part; durable history holds one part (final value); even `readSubmissionReply`'s \"emit order\" array returns one entry. Clients DO see intermediate values live (progress rendering works); only the final value persists.\n3. **Echo token: NOT NEEDED for the tested shapes — adjacency + persistent pending state suffice.** All replies were bare strings (typed text, choice-button labels, absence taps, a mid-stream redirect); the agent bound every one to the correct `exchangeId` because the pending question (with its id) is interpolated into the instructions from `usePersistentState`. The binding evidence is the `record_interpretation` tool part citing the exchangeId — session evidence, exactly as issue 05 hypothesized. Untested residual: simultaneous multiple open questions (ruled out by the one-ask invariant above) and long-delay/interleaved answers.\n4. **Turn suspension: WORKS, with a wake wart.** `terminate: true` + pending question in `usePersistentState` + answer-as-fresh-dispatch is sufficient; nothing else needed persisting. A cancelled/redirected question reads back cleanly: the affordance part stays in the transcript, and the `record_interpretation` part (`outcome: redirected`, `epistemicStatus: stated`) is the resolution evidence — the store-level guarantee issue 05 wanted. **The wart:** writing pending-state that's interpolated into instructions triggers a \"System instructions updated\" advisory *after* the terminating batch, which wakes the model for an extra turn that emits redundant \"I'm still waiting…\" text — one wasted model call per ask, plus transcript noise. Spec options: don't interpolate the pending question into instructions (keep it in state only, or narrate it inside the ask tool's result), or accept and UI-filter. Related fact: a mixed batch (non-terminating `record_interpretation` + terminating `ask_user`) still suspended correctly.\n5. **Rendering ergonomics: PROVEN.** Form-tag branching, markdown fallback, and read-back of a whole past conversation from durable history (including resolved-question dimming derived purely from `record_interpretation` parts in the transcript — no side store) all worked first try. Messages carry `purpose` and `display` fields (`display: \"diagnostic\"` on the advisory noise) — the UI must filter on them; the skeleton didn't at first, and the advisories rendered as visible cards.\n\n### Incidental facts worth the spec's attention\n\n* `@flue/vite` **hard-requires vite ^8** (its `parseAstAsync` TS support); on vite 6 the `'use agent'` scan dies with a bare parse error. The directive must also be the file's first statement.\n* **The Flue dev controller gives** `app.ts` **the entire request space** — no fall-through to vite's HTML serving — so a co-located browser UI is served by the Hono app itself (vite still transforms module requests, but react-refresh/HMR is off the table without a second server). A real deployment would face the same: the ui shell is a separate app or app-served static assets.\n* Data-channel writes are Valibot-validated per write; `body: v.any()` works fine as the opaque plugin-payload slot with typed envelope fields around it.\n* Restart durability untested by design (no `db.ts` → process-memory conversations; a restart wipes them — consistent with the deploy-target-owns-persistence hypothesis).\n\n## Comments\n\n**2026-08-07 (user, post-resolution):** Ratified reading of the questionnaire dimension against the clobbering finding — the whole questionnaire is a **single affordance with multiple steps**, not per-question affordances. The **one-ask-per-batch invariant stands** even though one ask may carry multiple questions passed in the same call. **Progression is UI-driven**: the payload carries all N questions, the ui walks them locally, answers return as evidence (individually or batched), and the agent interprets on settlement — zero intermediate model turns, sidestepping the wake-wart. Interpretation-on-settlement hands off to the capture-sweep semantics in ticket 11.\n+++",
+      "proposedBodySha256": "116b718f55afb36ec9df2f39c1480a428baff7064b2f0724a255a57b4ad47d8c",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "49c26a41-68c6-45a6-9148-14bdfe39a170",
+      "identifier": "FE-1377",
+      "url": "https://linear.app/hash/issue/FE-1377/logic-prototype-capture-sweep-and-settlement-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.491Z",
+      "sourceTitle": "Logic-prototype: capture sweep & settlement [archive]",
+      "sourceDescriptionSha256": "1f7efed2a48a98b6b9ddb02cce3aef6afedb49aeb7ba33415ca5a32dfc38b908",
+      "sourceTitleSha256": "37acb34d281af002054f9c0cecaececb353463f7bd3f37b592c050efcb5076f7",
+      "oldOuter": "Built an isolated prototype proving the knowledge-capture mechanics: deciding when a stretch of conversation is ready to harvest, harvesting it repeatably without double-counting, recording \"no answer\" as real information, and correcting earlier captures without erasing history. Code on branch `prototype/11-capture-sweep` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Prove repeatable conversation capture",
+      "proposedOuter": "This prototype demonstrated the knowledge-capture mechanics: deciding when conversation is ready to collect, collecting it repeatedly without duplicate records, treating an absent answer as information, and correcting prior captures without deleting history. The code is on branch `prototype/11-capture-sweep`, and the task was resolved on 2026-08-09.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Logic-prototype: capture sweep & settlement\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDo the session-as-evidence capture mechanics hold up when implemented in isolation (no substrate — mechanism semantics only)? Build a logic-prototype of the harness's sweep machinery over a synthetic session log.\n\nWorking hypotheses to prove or refute (delegated from the Questioning-UX contract, issue 05):\n\n* **Range-level settlement**: settlement is declared over ranges of conversation (a vein closing), never per-question — the agent judges *when* a range has settled; the harness provides the bookkeeping (swept high-water mark). Per-question \"settled\" events are the rejected alternative (exchange-pair machinery through the back door).\n* **Sweep idempotence**: re-sweeping a range never double-captures (the retries-idempotent kernel invariant, exercised at the sweep level).\n* **Cancelled/redirected questions at sweep time**: an ask affordance committed to session but answered by cancellation, silence, or topic-change must read back honestly — as absence evidence, not as an answer.\n* **Supersession across sweeps**: a later range's captures superseding an earlier range's, via the envelope's one `supersedes` link and explicit events only.\n* **Conflict-resolution record**: a `conflicting` issue closes only via an explicit resolution record — a capture-layer event citing the user's utterance as evidence; the harness refuses to close the issue without it (the \"no silent conflict resolution\" invariant moved from wire to store).\n\n## Answer\n\n> Resolved by logic-prototype + HITL reaction, 2026-08-07. Prototype on throwaway branch `prototype/11-capture-sweep` (commit d235258): single-file demo ([11-capture-sweep.html](<../prototypes/11-capture-sweep.html>), working-tree copy left untracked for double-clicking) + headless driver (32 checks passing) + browser walkthrough smoke (refusals land exactly on the deliberately-illegal steps, no console errors). The pure reducer module — the liftable part — is the demo's first script block.\n\n### Verdict: all five hypotheses hold, each sharpened\n\n1. **Range-level settlement — holds.** Zero per-ask state exists anywhere in the model; the swept high-water mark is the only sweep bookkeeping. Sharpened by the reaction: settlement decomposes into **trigger** (when to invoke the judgment — substrate lifecycle events such as turn-end/agent-settled; wiring proof delegated to ticket 10) and **judgment** (the agent names `upTo`). The race with concurrent user input is benign by construction: a sweep asserts only \"read up to N,\" never \"conversation paused\" — new entries land above the high-water mark, in the next range.\n2. **Sweep idempotence — holds, split in two.** The harness guarantee is **mechanical** idempotence via evidence-anchored capture identity (dedup key = evidence spans + payload/absence) — aligned with where retries actually occur, since a retried tool call re-executes byte-identical proposals. **Semantic** re-interpretation (a fresh judgment re-phrasing the same fact) is deliberately not a harness concern: that is plugin `reconcile` + `possibly-equivalent` issues. Identity is **content-based, not range-based**: a re-sweep never double-captures but *can repair omissions* (exercised in the dodged-question walkthrough). Epistemic status is excluded from identity — revising the epistemic reading of unchanged evidence requires explicit supersession, never a silent update.\n3. **Honest absence — holds.** A dodge reads back as `declined (inferred)`, a strip tap as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Absences are **evidence, not agenda**: the re-ask path runs through plugin `validate` → typed issues, with completion evaluation as the backstop for unresolved deferrals on required concepts. Adopted mechanism: the **unaccounted-ask advisory** — a swept range containing an ask with no reply and no capture citing it makes the harness report the fact and block nothing.\n4. **Explicit supersession — holds.** Supersession is single-hop over **active heads only**: superseding an already-superseded capture is refused, which is the lost-update guard (a corrector must confront the current head, so history stays a chain, never a silently forking tree). Sweeps validate and apply atomically; superseded captures remain visible — corrections don't erase history.\n5. **No silent conflict resolution — holds, with the wrinkle.** A bare close is refused; a resolution citing the *agent's* words is refused; only a record citing the user's utterance closes a `conflicting` issue. Wrinkle: the envelope's one creation-time `supersedes` link cannot adjudicate between two *already-existing* alternatives — there are **two supersession channels**: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status while authority sits in the record, suggesting per-capture status be **derived at read time** (echoes the derived-label approach from the formal-verification canon survey, issue 09).\n\n### Amendments to prior decisions (from the HITL reaction)\n\n* **Two validation strata**, amending the operation tiering in Contract decomposition (04): **envelope-level, harness-owned** — hard invariants enforced as refusals (provenance required, value-xor-absence, single-hop supersession) plus computed facts raised as advisories or generic `possibly-equivalent` issues (same-evidence duplicate actives, near-identical payload text — the harness can compare payloads as strings without understanding them) — versus **payload-level, plugin-owned** (`validate`/`reconcile` as already decided). Strengthens the smallest-honest-plugin test: a flat-record plugin gets generic duplicate detection for free.\n* **Op cadence is orchestration policy, not correctness.** Nothing had pinned when `project`/`validate`/`reconcile` run; snapshot-in/deltas-out purity means the harness may run them at any time without changing outcomes. Sweep-completion is the default trigger; the spec states cadence as explicit harness policy.\n* **Resume-time sweep reconciliation.** A session ending between settlement judgment and sweep leaves an unswept tail — a computable fact (entries above the high-water mark). On resume the harness surfaces it as an advisory and the agent judges whether to sweep before proceeding. Facts computed, weights judged.\n\n### Graduated\n\nThe multi-session question raised in the reaction (target state durable beyond sessions; interleaved sessions against one target; re-entry semantics) graduates the map's \"Spec permanence / sessions-roam-across-specs\" fog → [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>). The prototype's decomposition carries it: durable capture store / per-session evidence logs / sweep as sole bridge, with the single-hop refusal doubling as the stale-session guard.\n\n## Comments\n\n**2026-08-07 (prototype built — awaiting your reaction; HITL).** The logic-prototype is done and the mechanics were exercised end-to-end. **Provisional verdict: all five hypotheses hold**, with two design wrinkles surfaced for the spec.\n\n**Assets** (throwaway branch `prototype/11-capture-sweep`, commit d235258):\n\n* [11-capture-sweep.html](<../prototypes/11-capture-sweep.html>) — single-file shareable demo; double-click to open. Also left untracked in the working tree at the same path. Five guided walkthroughs (one per hypothesis, including every deliberately-illegal move) plus a free-play console with evidence-ticking and a sweep-proposal builder. The pure reducer module (no DOM) is the first `<script>` block — the liftable part.\n* `prototypes/driver/` (branch only) — headless sanity driver; `node driver.js` re-runs all five walkthroughs plus edge probes (32 checks, all passing). Also smoke-driven in headless Chrome: every walkthrough completes, refusals land exactly on the three illegal steps, no console errors.\n\n**Per hypothesis:**\n\n1. **Range-level settlement — holds.** The swept high-water mark is the *only* sweep state; nothing per-ask exists anywhere in the model. An ask is just a session entry. The demo's \"✓ Mark this question settled\" button exists solely to explain why it isn't in the vocabulary.\n2. **Sweep idempotence — holds, and sharpened.** Idempotence falls out of *evidence-anchored capture identity*: a capture's dedup key is (evidence spans + payload/absence). That makes idempotence **content-based, not range-based** — a re-sweep of an already-swept range never double-captures *but can repair omissions* (the dodged-question walkthrough does exactly this). This is stronger and more useful than gating on the high-water mark, and is the semantics the spec should pin.\n3. **Honest absence — holds.** A dodged ask reads back as `declined (inferred)`, a tapped strip as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Bonus mechanism worth speccing: a non-blocking **advisory** — when a swept range contains an ask with no reply and no capture citing it, the harness reports the fact and blocks nothing (\"facts computed, weights judged\" applied to sweep honesty).\n4. **Explicit supersession — holds.** Single-hop enforced (superseding an already-superseded capture is refused), sweeps apply atomically, history is never erased. Also surfaced: epistemic status is deliberately *excluded* from capture identity, so re-reading the same evidence with a different epistemic status dedups as a retry — an actual revision must go through explicit supersession. The alternative (epistemic in the key) silently spawns near-duplicate actives.\n5. **Resolution records — holds, with the interesting wrinkle.** Bare close refused; resolution citing the *agent's* words refused; only a record citing the user's utterance closes the issue. **Wrinkle:** the envelope's one creation-time `supersedes` link cannot express adjudication between two *already-existing* alternatives — the resolution record (an event) has to carry that supersession instead. The spec should name both supersession channels: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status (`tentative` in the walkthrough) while the authority lives in the resolution record — which suggests read-time *derived* status, echoing the derived-label idea from the formal-verification canon survey (issue 09).\n\n**To resolve this ticket:** click through the five walkthroughs (and free-play if inclined), react, and we record the verdict + fold the two wrinkles into the map.",
+      "innerSha256": "98d7b96fd075a96786c314905d3c2fe3bcf5661d0f18ee234b167f21a7c02dbc",
+      "proposedBody": "This prototype demonstrated the knowledge-capture mechanics: deciding when conversation is ready to collect, collecting it repeatedly without duplicate records, treating an absent answer as information, and correcting prior captures without deleting history. The code is on branch `prototype/11-capture-sweep`, and the task was resolved on 2026-08-09.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Logic-prototype: capture sweep & settlement\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDo the session-as-evidence capture mechanics hold up when implemented in isolation (no substrate — mechanism semantics only)? Build a logic-prototype of the harness's sweep machinery over a synthetic session log.\n\nWorking hypotheses to prove or refute (delegated from the Questioning-UX contract, issue 05):\n\n* **Range-level settlement**: settlement is declared over ranges of conversation (a vein closing), never per-question — the agent judges *when* a range has settled; the harness provides the bookkeeping (swept high-water mark). Per-question \"settled\" events are the rejected alternative (exchange-pair machinery through the back door).\n* **Sweep idempotence**: re-sweeping a range never double-captures (the retries-idempotent kernel invariant, exercised at the sweep level).\n* **Cancelled/redirected questions at sweep time**: an ask affordance committed to session but answered by cancellation, silence, or topic-change must read back honestly — as absence evidence, not as an answer.\n* **Supersession across sweeps**: a later range's captures superseding an earlier range's, via the envelope's one `supersedes` link and explicit events only.\n* **Conflict-resolution record**: a `conflicting` issue closes only via an explicit resolution record — a capture-layer event citing the user's utterance as evidence; the harness refuses to close the issue without it (the \"no silent conflict resolution\" invariant moved from wire to store).\n\n## Answer\n\n> Resolved by logic-prototype + HITL reaction, 2026-08-07. Prototype on throwaway branch `prototype/11-capture-sweep` (commit d235258): single-file demo ([11-capture-sweep.html](<../prototypes/11-capture-sweep.html>), working-tree copy left untracked for double-clicking) + headless driver (32 checks passing) + browser walkthrough smoke (refusals land exactly on the deliberately-illegal steps, no console errors). The pure reducer module — the liftable part — is the demo's first script block.\n\n### Verdict: all five hypotheses hold, each sharpened\n\n1. **Range-level settlement — holds.** Zero per-ask state exists anywhere in the model; the swept high-water mark is the only sweep bookkeeping. Sharpened by the reaction: settlement decomposes into **trigger** (when to invoke the judgment — substrate lifecycle events such as turn-end/agent-settled; wiring proof delegated to ticket 10) and **judgment** (the agent names `upTo`). The race with concurrent user input is benign by construction: a sweep asserts only \"read up to N,\" never \"conversation paused\" — new entries land above the high-water mark, in the next range.\n2. **Sweep idempotence — holds, split in two.** The harness guarantee is **mechanical** idempotence via evidence-anchored capture identity (dedup key = evidence spans + payload/absence) — aligned with where retries actually occur, since a retried tool call re-executes byte-identical proposals. **Semantic** re-interpretation (a fresh judgment re-phrasing the same fact) is deliberately not a harness concern: that is plugin `reconcile` + `possibly-equivalent` issues. Identity is **content-based, not range-based**: a re-sweep never double-captures but *can repair omissions* (exercised in the dodged-question walkthrough). Epistemic status is excluded from identity — revising the epistemic reading of unchanged evidence requires explicit supersession, never a silent update.\n3. **Honest absence — holds.** A dodge reads back as `declined (inferred)`, a strip tap as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Absences are **evidence, not agenda**: the re-ask path runs through plugin `validate` → typed issues, with completion evaluation as the backstop for unresolved deferrals on required concepts. Adopted mechanism: the **unaccounted-ask advisory** — a swept range containing an ask with no reply and no capture citing it makes the harness report the fact and block nothing.\n4. **Explicit supersession — holds.** Supersession is single-hop over **active heads only**: superseding an already-superseded capture is refused, which is the lost-update guard (a corrector must confront the current head, so history stays a chain, never a silently forking tree). Sweeps validate and apply atomically; superseded captures remain visible — corrections don't erase history.\n5. **No silent conflict resolution — holds, with the wrinkle.** A bare close is refused; a resolution citing the *agent's* words is refused; only a record citing the user's utterance closes a `conflicting` issue. Wrinkle: the envelope's one creation-time `supersedes` link cannot adjudicate between two *already-existing* alternatives — there are **two supersession channels**: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status while authority sits in the record, suggesting per-capture status be **derived at read time** (echoes the derived-label approach from the formal-verification canon survey, issue 09).\n\n### Amendments to prior decisions (from the HITL reaction)\n\n* **Two validation strata**, amending the operation tiering in Contract decomposition (04): **envelope-level, harness-owned** — hard invariants enforced as refusals (provenance required, value-xor-absence, single-hop supersession) plus computed facts raised as advisories or generic `possibly-equivalent` issues (same-evidence duplicate actives, near-identical payload text — the harness can compare payloads as strings without understanding them) — versus **payload-level, plugin-owned** (`validate`/`reconcile` as already decided). Strengthens the smallest-honest-plugin test: a flat-record plugin gets generic duplicate detection for free.\n* **Op cadence is orchestration policy, not correctness.** Nothing had pinned when `project`/`validate`/`reconcile` run; snapshot-in/deltas-out purity means the harness may run them at any time without changing outcomes. Sweep-completion is the default trigger; the spec states cadence as explicit harness policy.\n* **Resume-time sweep reconciliation.** A session ending between settlement judgment and sweep leaves an unswept tail — a computable fact (entries above the high-water mark). On resume the harness surfaces it as an advisory and the agent judges whether to sweep before proceeding. Facts computed, weights judged.\n\n### Graduated\n\nThe multi-session question raised in the reaction (target state durable beyond sessions; interleaved sessions against one target; re-entry semantics) graduates the map's \"Spec permanence / sessions-roam-across-specs\" fog → [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>). The prototype's decomposition carries it: durable capture store / per-session evidence logs / sweep as sole bridge, with the single-hop refusal doubling as the stale-session guard.\n\n## Comments\n\n**2026-08-07 (prototype built — awaiting your reaction; HITL).** The logic-prototype is done and the mechanics were exercised end-to-end. **Provisional verdict: all five hypotheses hold**, with two design wrinkles surfaced for the spec.\n\n**Assets** (throwaway branch `prototype/11-capture-sweep`, commit d235258):\n\n* [11-capture-sweep.html](<../prototypes/11-capture-sweep.html>) — single-file shareable demo; double-click to open. Also left untracked in the working tree at the same path. Five guided walkthroughs (one per hypothesis, including every deliberately-illegal move) plus a free-play console with evidence-ticking and a sweep-proposal builder. The pure reducer module (no DOM) is the first `<script>` block — the liftable part.\n* `prototypes/driver/` (branch only) — headless sanity driver; `node driver.js` re-runs all five walkthroughs plus edge probes (32 checks, all passing). Also smoke-driven in headless Chrome: every walkthrough completes, refusals land exactly on the three illegal steps, no console errors.\n\n**Per hypothesis:**\n\n1. **Range-level settlement — holds.** The swept high-water mark is the *only* sweep state; nothing per-ask exists anywhere in the model. An ask is just a session entry. The demo's \"✓ Mark this question settled\" button exists solely to explain why it isn't in the vocabulary.\n2. **Sweep idempotence — holds, and sharpened.** Idempotence falls out of *evidence-anchored capture identity*: a capture's dedup key is (evidence spans + payload/absence). That makes idempotence **content-based, not range-based** — a re-sweep of an already-swept range never double-captures *but can repair omissions* (the dodged-question walkthrough does exactly this). This is stronger and more useful than gating on the high-water mark, and is the semantics the spec should pin.\n3. **Honest absence — holds.** A dodged ask reads back as `declined (inferred)`, a tapped strip as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Bonus mechanism worth speccing: a non-blocking **advisory** — when a swept range contains an ask with no reply and no capture citing it, the harness reports the fact and blocks nothing (\"facts computed, weights judged\" applied to sweep honesty).\n4. **Explicit supersession — holds.** Single-hop enforced (superseding an already-superseded capture is refused), sweeps apply atomically, history is never erased. Also surfaced: epistemic status is deliberately *excluded* from capture identity, so re-reading the same evidence with a different epistemic status dedups as a retry — an actual revision must go through explicit supersession. The alternative (epistemic in the key) silently spawns near-duplicate actives.\n5. **Resolution records — holds, with the interesting wrinkle.** Bare close refused; resolution citing the *agent's* words refused; only a record citing the user's utterance closes the issue. **Wrinkle:** the envelope's one creation-time `supersedes` link cannot express adjudication between two *already-existing* alternatives — the resolution record (an event) has to carry that supersession instead. The spec should name both supersession channels: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status (`tentative` in the walkthrough) while the authority lives in the resolution record — which suggests read-time *derived* status, echoing the derived-label idea from the formal-verification canon survey (issue 09).\n\n**To resolve this ticket:** click through the five walkthroughs (and free-play if inclined), react, and we record the verdict + fold the two wrinkles into the map.\n+++",
+      "proposedBodySha256": "7304bb9e8154c58b0926076b1e75b6b7d93be3776443c65e59661b77b402479d",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "e091ded9-5124-43e0-8c01-aa447b17639b",
+      "identifier": "FE-1378",
+      "url": "https://linear.app/hash/issue/FE-1378/multi-session-elicitation-and-durable-target-state-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.948Z",
+      "sourceTitle": "Multi-session elicitation & durable target state [archive]",
+      "sourceDescriptionSha256": "4a2e6fa5bc9e664bf7fed660d561ed2a843aa2f99509734de0773e29b169c8ca",
+      "sourceTitleSha256": "a0a6d108d755c05072d5afcc84ed4ebddb1d01b3b55c339dbfb22662c6bad90a",
+      "oldOuter": "Decided how work survives across conversations: a durable target-document holds all captured knowledge and the full session logs; individual chat sessions are transient, never formally close, and can always resume against the current state. Storage went to the platform adapter, not the plugin — flipping an earlier hypothesis. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Define durable state across elicitation sessions",
+      "proposedOuter": "This decision makes the target document durable, including captured knowledge and complete session logs, while individual chat sessions remain temporary and resumable. It assigns storage to the platform adapter rather than the plugin, reversing the earlier hypothesis. The decision was resolved on 2026-08-10.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/12-multi-session-durable-target.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Multi-session elicitation & durable target state\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nWhat is the multi-session model for elicitation: the target state that endures independently of sessions, the per-session evidence logs, and the semantics of leaving, resuming, and interleaving sessions against one target?\n\nGraduated from the map's \"Spec permanence / sessions-roam-across-specs\" fog by the capture-sweep logic-prototype (issue 11), whose model already decomposes cleanly for this: the capture store (captures, issues, events) as durable, session-independent truth; session logs as per-session evidence streams, each with its own swept high-water mark; the sweep as the only bridge between them. Evidence spans become session-qualified; idempotence keys already anchor on evidence and extend without redesign; the single-hop supersession refusal doubles as the stale-session lost-update guard; \"the world changed since my last entry\" is a computable re-entry fact (captures created/superseded since this session's last sweep).\n\nPrior art (brunch history, from the HITL reaction on issue 11): brunch v1 assumed one-session elicitation and it proved brittle and constraining; v2's direction made the elicited artifact durable beyond and independent of the sessions contributing to it — start a session, leave it unresolved, open another that picks up from the current state of truth, later return to the first, which must then understand that the world moved between its last entries and whatever it writes next.\n\nSub-questions:\n\n* What exactly is durable — captures + issues + events only, or projections/artifacts too? What is stored vs derived?\n* Session identity and lifecycle: what *is* a session in this model (one conversation? one substrate dispatch chain?), and what state is strictly per-session?\n* Interleaved or concurrent sessions against one target: are the single-hop supersession refusal plus a re-entry advisory sufficient coordination, or is more needed (locking, merge, explicit sync events)?\n* Re-entry briefing: what is a resuming agent told — unswept tail, world-moved delta, open issues — and in what form (advisory facts? the interpretation render)?\n* What does this do to the persistence-plugin-owned hypothesis and the storage port (feeds Shipping shape, issue 06) and to the spec's session vocabulary (feeds Assemble the spec, issue 08)?\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-10 (two rounds; frontier exhausted, every branch confirmed).\n\n### The model: durable target-document, transient sessions, sweep as the only bridge\n\n**Terms** (pinned in `CONTEXT.md`): the family/instance collision on \"target\" resolves by compound disambiguation, not a fresh noun — **target-domain** = the artifact family a plugin defines (gherkin, proof obligations); **target-document** = the durable unit sessions attach to: one target-domain + its capture store + its session history. Bare \"target\" stays legal where context disambiguates. The instance-noun names the unit by its *purpose*; the spec states plainly that its authoritative state is the capture store, never the render.\n\n1. **What is durable.** Durable truth = the capture store (captures, issues, events) **plus all session logs** — provenance must resolve forever; discarding swept logs would dead-end every capture's evidence spans. This is \"corrections don't erase history\" applied at the store level. Projections/renders/artifacts are strictly **derived**: cacheable, never authoritative.\n2. **Session identity & lifecycle.** A session is **one substrate conversation** — Pi's own model (the log of all messages: user, agent, tool calls, custom/state messages), which Flue inherits. Strictly per-session state is exactly three things: the evidence log, the swept high-water mark, the pending-affordance slot. **No formal close**: sessions go quiet and stay resumable indefinitely; \"ended\" would be a fiction the harness cannot verify. The ragged edge (ending between settlement and sweep) is already handled by ticket 11's resume-time unswept-tail advisory.\n3. **Concurrency: interleaved-only** (milestone one). The store is **serialized** — sweeps validate and apply atomically, a plain transactional guarantee, not a session lock. Staleness is optimistic: the **single-hop supersession refusal doubles as the stale-session lost-update guard** (a stale session superseding a moved head is refused, and the refusal carries the world-moved facts). Refusal granularity is **whole-sweep atomic** — matches the prototype; re-proposing is cheap once the advisory is digested (per-item partial application → fog). No locking, no merge, no sync events; true simultaneous-sweep coordination → fog, graduating only if a real concurrent consumer appears.\n4. **Re-entry briefing.** Injected **state messages**, following Pi's custom-entry convention: authored *on behalf of the user* (compaction and session-branch summaries are the precedent — the transcript the model reads contains messages from or on behalf of the user summarizing important changes). Advisory-only, agent-facing, with a minimal user-visible insertion notice (as for other state changes). Content = the computed facts: unswept tail, world-moved delta (captures created/superseded and issues opened/closed since this session's last sweep; anchor = session start when it never swept), open issues, pending unanswered affordance. Harness computes, agent weighs — nothing forced; surfacing the world-moved summary conversationally is judgment guidance (kernel-card level), with the interpretation render available on request.\n5. **Provenance principle, sharpened: only the *true* user's side is evidence.** The data model distinguishes true user entries from entries injected on the user's behalf. Capture evidence spans anchor only on true user (and user-affordance-payload) entries; injected advisories live in the log honestly — the session reads back complete — but are **never citable as capture evidence**. This generalizes ticket 11's resolution-record rule (\"must cite the user's utterance\") into one clean principle.\n6. **Completion is derived, never a gate.** A target-document has no lock/terminal state: completion-contract satisfaction is a read-time **derived status** (same family as derived capture status and issue 09's derived labels). A user returning with a correction after \"done\" is the motivating story of this ticket.\n\n### The storage flip (amends the standing hypothesis; feeds Shipping shape 06 and the spec 08)\n\n**Persistence is not plugin-owned — the hypothesis is flipped.** Mapping persistence to the plugin was a conflation; the capture-sweep model already made the store harness mechanism (envelope invariants enforced as store-level refusals). The **storage port is harness-defined and binding-implemented**: the deploy target decides *how*, the plugin never touches persistence, and if storage is addressable from plugin code at all, it is only through **harness-defined methods passed via the injected PluginContext**. This aligns with (and sharpens) ticket 06's capability-list entry \"persist state\" and its remote-parity constraint \"host-owned storage port\".\n\n**Evidence spans carry pointer + quoted excerpt**: session-id + range as the pointer, the load-bearing quote embedded in the capture. Provenance stays self-contained across local/remote differences in substrate log access; the substrate log remains the full record, the excerpt the citable quote.",
+      "innerSha256": "9c8b6e6bcc99322400c0c25629d1f0e4939e8496ba3dfb43cafe064b8144a4a2",
+      "proposedBody": "This decision makes the target document durable, including captured knowledge and complete session logs, while individual chat sessions remain temporary and resumable. It assigns storage to the platform adapter rather than the plugin, reversing the earlier hypothesis. The decision was resolved on 2026-08-10.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/12-multi-session-durable-target.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Multi-session elicitation & durable target state\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nWhat is the multi-session model for elicitation: the target state that endures independently of sessions, the per-session evidence logs, and the semantics of leaving, resuming, and interleaving sessions against one target?\n\nGraduated from the map's \"Spec permanence / sessions-roam-across-specs\" fog by the capture-sweep logic-prototype (issue 11), whose model already decomposes cleanly for this: the capture store (captures, issues, events) as durable, session-independent truth; session logs as per-session evidence streams, each with its own swept high-water mark; the sweep as the only bridge between them. Evidence spans become session-qualified; idempotence keys already anchor on evidence and extend without redesign; the single-hop supersession refusal doubles as the stale-session lost-update guard; \"the world changed since my last entry\" is a computable re-entry fact (captures created/superseded since this session's last sweep).\n\nPrior art (brunch history, from the HITL reaction on issue 11): brunch v1 assumed one-session elicitation and it proved brittle and constraining; v2's direction made the elicited artifact durable beyond and independent of the sessions contributing to it — start a session, leave it unresolved, open another that picks up from the current state of truth, later return to the first, which must then understand that the world moved between its last entries and whatever it writes next.\n\nSub-questions:\n\n* What exactly is durable — captures + issues + events only, or projections/artifacts too? What is stored vs derived?\n* Session identity and lifecycle: what *is* a session in this model (one conversation? one substrate dispatch chain?), and what state is strictly per-session?\n* Interleaved or concurrent sessions against one target: are the single-hop supersession refusal plus a re-entry advisory sufficient coordination, or is more needed (locking, merge, explicit sync events)?\n* Re-entry briefing: what is a resuming agent told — unswept tail, world-moved delta, open issues — and in what form (advisory facts? the interpretation render)?\n* What does this do to the persistence-plugin-owned hypothesis and the storage port (feeds Shipping shape, issue 06) and to the spec's session vocabulary (feeds Assemble the spec, issue 08)?\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-10 (two rounds; frontier exhausted, every branch confirmed).\n\n### The model: durable target-document, transient sessions, sweep as the only bridge\n\n**Terms** (pinned in `CONTEXT.md`): the family/instance collision on \"target\" resolves by compound disambiguation, not a fresh noun — **target-domain** = the artifact family a plugin defines (gherkin, proof obligations); **target-document** = the durable unit sessions attach to: one target-domain + its capture store + its session history. Bare \"target\" stays legal where context disambiguates. The instance-noun names the unit by its *purpose*; the spec states plainly that its authoritative state is the capture store, never the render.\n\n1. **What is durable.** Durable truth = the capture store (captures, issues, events) **plus all session logs** — provenance must resolve forever; discarding swept logs would dead-end every capture's evidence spans. This is \"corrections don't erase history\" applied at the store level. Projections/renders/artifacts are strictly **derived**: cacheable, never authoritative.\n2. **Session identity & lifecycle.** A session is **one substrate conversation** — Pi's own model (the log of all messages: user, agent, tool calls, custom/state messages), which Flue inherits. Strictly per-session state is exactly three things: the evidence log, the swept high-water mark, the pending-affordance slot. **No formal close**: sessions go quiet and stay resumable indefinitely; \"ended\" would be a fiction the harness cannot verify. The ragged edge (ending between settlement and sweep) is already handled by ticket 11's resume-time unswept-tail advisory.\n3. **Concurrency: interleaved-only** (milestone one). The store is **serialized** — sweeps validate and apply atomically, a plain transactional guarantee, not a session lock. Staleness is optimistic: the **single-hop supersession refusal doubles as the stale-session lost-update guard** (a stale session superseding a moved head is refused, and the refusal carries the world-moved facts). Refusal granularity is **whole-sweep atomic** — matches the prototype; re-proposing is cheap once the advisory is digested (per-item partial application → fog). No locking, no merge, no sync events; true simultaneous-sweep coordination → fog, graduating only if a real concurrent consumer appears.\n4. **Re-entry briefing.** Injected **state messages**, following Pi's custom-entry convention: authored *on behalf of the user* (compaction and session-branch summaries are the precedent — the transcript the model reads contains messages from or on behalf of the user summarizing important changes). Advisory-only, agent-facing, with a minimal user-visible insertion notice (as for other state changes). Content = the computed facts: unswept tail, world-moved delta (captures created/superseded and issues opened/closed since this session's last sweep; anchor = session start when it never swept), open issues, pending unanswered affordance. Harness computes, agent weighs — nothing forced; surfacing the world-moved summary conversationally is judgment guidance (kernel-card level), with the interpretation render available on request.\n5. **Provenance principle, sharpened: only the *true* user's side is evidence.** The data model distinguishes true user entries from entries injected on the user's behalf. Capture evidence spans anchor only on true user (and user-affordance-payload) entries; injected advisories live in the log honestly — the session reads back complete — but are **never citable as capture evidence**. This generalizes ticket 11's resolution-record rule (\"must cite the user's utterance\") into one clean principle.\n6. **Completion is derived, never a gate.** A target-document has no lock/terminal state: completion-contract satisfaction is a read-time **derived status** (same family as derived capture status and issue 09's derived labels). A user returning with a correction after \"done\" is the motivating story of this ticket.\n\n### The storage flip (amends the standing hypothesis; feeds Shipping shape 06 and the spec 08)\n\n**Persistence is not plugin-owned — the hypothesis is flipped.** Mapping persistence to the plugin was a conflation; the capture-sweep model already made the store harness mechanism (envelope invariants enforced as store-level refusals). The **storage port is harness-defined and binding-implemented**: the deploy target decides *how*, the plugin never touches persistence, and if storage is addressable from plugin code at all, it is only through **harness-defined methods passed via the injected PluginContext**. This aligns with (and sharpens) ticket 06's capability-list entry \"persist state\" and its remote-parity constraint \"host-owned storage port\".\n\n**Evidence spans carry pointer + quoted excerpt**: session-id + range as the pointer, the load-bearing quote embedded in the capture. Provenance stays self-contained across local/remote differences in substrate log access; the substrate log remains the full record, the excerpt the citable quote.\n+++",
+      "proposedBodySha256": "0ef346b178f18b74049bbc63a61e0f1c4340a1a5675ac6fb1d3f23f608cfb47f",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "a565c058-0b8c-4173-8b71-d22147d2f0b5",
+      "identifier": "FE-1379",
+      "url": "https://linear.app/hash/issue/FE-1379/walking-skeleton-sweep-seam-on-flue-archive",
+      "state": {
+        "name": "Done",
+        "type": "completed"
+      },
+      "parent": {
+        "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+        "identifier": "FE-1366",
+        "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.560Z",
+      "sourceTitle": "Walking skeleton: sweep seam on Flue [archive]",
+      "sourceDescriptionSha256": "77ba77f249d1d1e88dda09de03554a2672f52d91e2e75261cfdbe0520f3c4cb7",
+      "sourceTitleSha256": "4508ec17020f4110e54e4fd9bb6409653fa6051f503485280387d982b90eae6f",
+      "oldOuter": "Built the second walking skeleton on Flue, proving the four remaining platform capabilities the spec depends on (knowing when to harvest, reading conversation history, injecting system notes, and safe storage under retries) — completing the evidence base for the spec. Code on branch `prototype/13-sweep-seam` (brunch-lite repo). Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).",
+      "proposedTitle": "Prove the remaining Flue capabilities",
+      "proposedOuter": "This prototype demonstrated the four remaining Flue capabilities required by the specification: detecting when to collect knowledge, reading conversation history, injecting system notes, and storing data safely during retries. This completed the specification’s evidence base. The code is on branch `prototype/13-sweep-seam`, and the task was resolved on 2026-08-10.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: sweep seam on Flue\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nProve the four substrate capabilities the capture-sweep machinery assumes but no prototype has exercised on Flue — the unproven seam between ticket 10's transport skeleton and ticket 11's synthetic-log logic-prototype, surfaced by the [2026-08-10 consistency pre-pass](<../notes/consistency-prepass-2026-08-10.md>) (items L1–L3):\n\n1. **Settlement trigger** — a substrate lifecycle event (turn-end / agent-settled) that invokes the agent's settlement judgment. Ticket 11 recorded this as \"wiring proof delegated to ticket 10\", but ticket 10 contains no settlement or lifecycle-event finding; the claim was a misattribution (L1).\n2. **Read a session entry range** — harness code reading the entries it sweeps. Ticket 01 found no documented path to Pi's message list from inside a Flue agent; ticket 10 proved read-back only on the ui side via `useFlueAgent`; ticket 11 ran against a synthetic log. The hinge between the two prototypes is proven nowhere (L2).\n3. **Inject an on-behalf-of-user state entry** — the carrier for ticket 12's re-entry briefing. Candidate: Flue's `kind: 'signal'` message with trusted-code attributes (ticket 01 §6), which would also yield the true-user-versus-injected provenance distinction for free.\n4. **Transactional durable store distinct from per-conversation state** — ticket 12 requires whole-sweep-atomic application (and refusals) across sessions; conversation-scoped `usePersistentState` cannot provide it (ticket 01).\n\nSuccess = a minimal Flue walking skeleton (seeded from `prototype/10-flue-roundtrip`) that wires ticket 11's pure reducer (`prototype/11-capture-sweep`) to a real session log through these four capabilities. The resolution amends Shipping shape's six-item substrate-capability list — these are its four missing entries (pre-pass L3) — or records what Flue lacks or forbids and what the Flue binding must therefore absorb (binding-size asymmetry is expected, per ticket 06).\n\nBlocks: [Assemble the spec](<08-assemble-the-spec.md>).\n\n## Answer\n\n> Resolved by walking skeleton + two HITL reaction rounds, 2026-08-10. Real Flue agent + web UI with a live target-document panel, two browser sessions against one target-document, driven live by the user; 21-check headless probe suite passing. Prototype on branch `prototype/13-sweep-seam` (`prototypes/sweep-seam/`; commits 276c0e4 skeleton, bbb3646 HITL fix).\n\n**Overall: all four capabilities hold on Flue — two natively, two absorbed by the binding, none forbidden — with one load-bearing amendment from the HITL rounds: evidence anchoring must be harness-resolved, not model-chosen.**\n\n### Verdict per capability\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is the would-stop control seam: awaited before the response settles; `ctx.append` steers a settlement-check signal into a same-response continuation turn; the hook re-fires at the next would-stop; the response settles only when nothing appends. Trigger computes facts, judgment stays with the agent (declining is legal). Mechanism findings: the hook **fires on** `terminate: true` **suspensions too** (the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn); the nudge itself becomes a session entry, so the trigger needs a **loop guard** (never re-nudge the same latest-user-entry). Observed cadence drift: the model preferred sweeping at reply time without waiting for a nudge — harmless *because* sweeps are content-idempotent and harness-anchored; cadence is policy, exactly as ticket 11 said.\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (`getFlueRuntime` is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** (`GET <agent-url>?view=history`, @flue/sdk) over self-HTTP; works mid-response. The projection is sweep-sufficient: stable ids, stream order, `purpose` **as the provenance discriminator** ('user'/'assistant'/'dispatch'/'advisory'), signal descriptors, tool parts with validated outputs. **The amendment (HITL round 1):** the projection numbering is harness-side knowledge ONLY — hidden advisories inflate it and the model's seq guesses never converge, while its verbatim quotes are flawless. So the model-facing citation currency is the **quoted excerpt**; the harness resolves quotes to entries (user-entries-only candidates; no-match refuses with a repair hint; multi-match anchors latest with an advisory). Sharpens ticket 12's span shape: the excerpt is primary at proposal time, the pointer is derived.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** `ctx.append` (same-response) and `dispatch({kind:'signal'})` (real delivery) share one vocabulary. Caller-defined signals project as system-role / `purpose: 'dispatch'` / `display: 'diagnostic'` with tagName + trusted attributes — **structurally distinct from true user entries, so ticket 12's citable-evidence rule is mechanically enforced** (a capture citing an injected entry is refused). The re-entry briefing worked in every shape: fresh session, resumed session, post-restart session — and in HITL round 2 it produced unscripted **conversational conflict-surfacing**: briefed with \"September 12\" and told \"September 13\", the agent asked instead of overwriting, then swept the correction as a supersession citing both the assertion and the confirmation.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (milestone one: JSON file, tmp+rename atomic, in-process serialization), and every ticket-11 semantic survived the real log: whole-sweep-atomic apply/refuse, content-keyed idempotence (**load-bearing, not optional**, under Flue's at-least-once tool re-execution), single-hop supersession as the stale-session guard. Restart probe: conversations 404 (in-memory, no `db.ts`), store survives, a fresh session answers correctly from its briefing alone.\n\n### Capability-list amendment (Shipping shape, issue 06 — closes pre-pass L3)\n\nThe six-item substrate-capability list gains four entries: **7. subscribe to the would-stop lifecycle seam, with same-response signal steering** (native); **8. read the session's durable entry projection, with provenance-discriminating entry kinds** (binding-absorbed; no in-process API); **9. inject typed non-user signal entries, same-response and as deliveries** (native); **10. provide a transactional durable store outside conversation state** (binding-absorbed entirely). Binding-size asymmetry landed exactly where ticket 06 predicted.\n\n### HITL round 2 — cross-session dynamics observed live\n\nSession-a captured date/time, guests, budget; session-b opened with a contradictory assertion (\"Hilton, September 13\"): briefing → conversational conflict-surfacing → user confirmed → **c4 superseded c1 citing both user entries**. Then the superseded-history payoff: the user said \"the same time we said before, whatever that was\" — the time lived only in the *superseded* capture; the agent resolved it from the briefing's history and captured it as its own fact, honestly marked **inferred**, anchored to the user's actual words. \"Corrections don't erase history\" paying rent. One wrinkle for the spec: **compound payloads make supersession lossy** (c1 bundled date+time; c4 superseded it with date+venue and silently dropped the time until the user's remark rescued it) — capture granularity is plugin `validate`/kernel-card guidance territory. Same stratum as the other live find: a payload can smuggle an absence (`payload: \"not-yet-decided\"`) past the envelope — exactly the payload-level validation ticket 11 assigned to plugins.\n\n### Spec consequences (for issue 08)\n\nEntry identity is harness-side vocabulary; excerpts are the model-facing citation currency (amends the envelope's span story). Judgment prompts must never be the model's only source of mechanical facts (trigger suppression during suspension is correct but starves numbered context). Two payload-level validation examples now exist for the smallest-honest-plugin section. The wake-wart (ticket 10) remains cosmetically noisy (\"I've noted the update…\" doubling) — unchanged spec options.\n\n## Comments\n\n**2026-08-10 (walking skeleton built — awaiting your reaction; HITL).** The skeleton is done and all four capabilities were exercised against the real runtime, live model turns included. **Provisional verdict: all four hold on Flue — two absorbed by the binding as expected, none forbidden.**\n\n**Assets** (branch `prototype/13-sweep-seam`, commit 276c0e4, `prototypes/sweep-seam/`): real Flue agent + web UI with a live target-document panel (`bun run dev`, sessions `?id=session-a`/`session-b` share target-document `demo`); `node probe-seam.mjs` re-runs 18 checks (all passing). README documents the ask/terminate and restart probes.\n\n**Per capability:**\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is exactly the would-stop seam ticket 11 needed: awaited before the response settles, `ctx.append` steers a `settlement-check` signal into a same-response continuation turn, the hook re-fires at the next would-stop, and the response settles only when nothing appends. Trigger computes the facts (numbered unswept tail); judgment stays with the agent (declining is legal). Two mechanism findings: (a) the hook **fires on** `terminate: true` **suspensions too**, so the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn; (b) the nudge itself becomes a session entry, so the trigger must be **loop-guarded** (don't re-nudge the same max-user-seq; persistent `lastNudgedAt`).\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (the runtime getter is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** — `GET <agent-url>?view=history` via `@flue/sdk` — over self-HTTP; works mid-response (both the finish hook and the sweep tool read during the live response). The projection is sweep-sufficient: stable ids, stream order (seq), `purpose` **as the provenance discriminator** (`user` / `assistant` / `dispatch` / `advisory`), signal descriptors, tool parts with validated outputs. Warts: the binding must know its own base URL (env var here); a mid-flight read sees the partial assistant message; >1000-entry paging unprobed. Live-model finding: **entry-seq citation is error-prone for a small model** — the typed refusal steered a mis-cited sweep to correct in two hops (backpressure works), but the spec may prefer harness-resolved excerpt anchoring over model-chosen seqs.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** Two carriers share one vocabulary: `ctx.append` (same-response, no delivery) and `dispatch({kind: 'signal'})` (real delivery). Caller-defined signals project as system-role, `purpose: 'dispatch'`, `display: 'diagnostic'`, with `tagName` + trusted `attributes` — **structurally distinct from true user entries, so ticket 12's provenance rule is mechanically enforceable** (probe: a capture citing an injected entry is refused at validation). The re-entry briefing worked in all three shapes: fresh session, resumed session, and post-restart session — the last answered the user correctly from the briefing alone. Nuance: Flue classifies these as dispatch/diagnostic rather than literally \"on behalf of the user\"; the Pi convention survives as signal + render guidance, and the sharpened citable-evidence rule is *stronger* under Flue's classification.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (JSON file, tmp+rename atomic, in-process serialization — milestone-one local), and **every ticket-11 semantic survived contact with the real log**: whole-sweep-atomic apply/refuse, content-keyed idempotence, single-hop supersession as the stale-session guard (cross-session probe: session-b superseded session-a's capture; a stale re-supersession was refused with world-moved facts). Restart probe: conversations 404 (`stream_not_found` — in-memory, no `db.ts`), the store file survives. Confirms pre-pass L13: Flue's at-least-once tool re-execution makes content-keyed idempotence load-bearing, not optional.\n\n**Proposed capability-list amendment** (Shipping shape 06 — its four missing entries, per pre-pass L3): 7. *subscribe to the would-stop lifecycle seam, with same-response signal steering* (native: `useAgentFinish`/`ctx.append`); 8. *read the session's durable entry projection, with provenance-discriminating entry kinds* (binding-absorbed: history route; no in-process API); 9. *inject typed non-user signal entries, both same-response and as deliveries* (native: append/dispatch, `kind: 'signal'`); 10. *provide a transactional durable store outside conversation state* (binding-absorbed entirely; Flue offers none). Binding-size asymmetry landed exactly where ticket 06 predicted — the Node binding absorbed 8 and 10.\n\n**Incidental Flue facts:** `agentName` must be a string *literal* (the build-time scan rejects a constant reference); injected signals carry `display: 'diagnostic'`, so the ticket-10 UI-filtering lesson extends to them (the skeleton renders them as labeled cards instead — exploded-view-lite, per the map's fog note).\n\n**To resolve this ticket:** drive the skeleton (two browser sessions against one target-document is the fun path: sweep in one, resume the other), react, and we record the verdict + the capability-list amendment + graduate whatever fog the reaction surfaces.\n\n---\n\n**2026-08-10 (HITL reaction #1 → diagnosed and fixed; commit bbb3646).** The user drove session-a and sweeps never converged: an ask-heavy interview, then \"let's sweep\" → five refusals, model deflecting into more questions. Diagnosis from the session log: **the model's verbatim excerpts were flawless in every attempt; every entry seq was a guess** — five attempts, five different numberings, zero convergence. Two compounding causes: (a) the model *cannot* know the projection numbering (hidden `System instructions updated` advisories — the ticket-10 wake-wart — inflate it, and the model never sees them); (b) in an ask-heavy flow the pending guard suppresses every settlement-check, so the numbered tail never re-arrives and a user-requested sweep runs blind.\n\n**The fix, which is itself the sharpened finding: evidence anchoring must be harness-resolved, not model-chosen.** The model now cites only verbatim user quotes (plain strings); the harness — the only party that can see the projection — resolves each quote to its entry (`resolveEvidence`: user-entries-only candidates, no-match refuses with a repair hint, multi-match anchors latest with an advisory note); seq numbers and `upTo` left the model-facing tool contract entirely. Replaying the user's exact failing flow headlessly now converges (the residual refusals en route were *correct* envelope refusals — empty evidence, value-and-absence — which the model repaired). Probe suite extended and made self-contained: 21/21, twice consecutively.\n\nSpec consequences: (1) the questioning-UX/envelope contract should state that **entry identity is harness-side vocabulary; the model-facing citation currency is the quoted excerpt** — this also strengthens ticket 12's \"pointer + quoted excerpt\" span shape (the excerpt is primary at proposal time; the pointer is derived); (2) a payload can *smuggle* an absence (`payload: \"not-yet-decided\"` observed live) — the envelope cannot catch it; that is exactly the payload-level stratum ticket 11 assigned to plugin `validate`, worth an explicit spec example; (3) trigger suppression during suspension is correct, but judgment prompts must never be the model's only source of mechanical facts.\n\nStill open for your reaction: the cross-session dynamics you originally set out to test (sweep in one browser session, resume the other — the headless probes exercise it, but the HITL reaction is the point).",
+      "innerSha256": "6a1ed589c55484beda4a01d588643c6d5835b60653166b164c6a2cd13dc2f728",
+      "proposedBody": "This prototype demonstrated the four remaining Flue capabilities required by the specification: detecting when to collect knowledge, reading conversation history, injecting system notes, and storing data safely during retries. This completed the specification’s evidence base. The code is on branch `prototype/13-sweep-seam`, and the task was resolved on 2026-08-10.\n\n+++🏗️ Agent notes\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: sweep seam on Flue\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nProve the four substrate capabilities the capture-sweep machinery assumes but no prototype has exercised on Flue — the unproven seam between ticket 10's transport skeleton and ticket 11's synthetic-log logic-prototype, surfaced by the [2026-08-10 consistency pre-pass](<../notes/consistency-prepass-2026-08-10.md>) (items L1–L3):\n\n1. **Settlement trigger** — a substrate lifecycle event (turn-end / agent-settled) that invokes the agent's settlement judgment. Ticket 11 recorded this as \"wiring proof delegated to ticket 10\", but ticket 10 contains no settlement or lifecycle-event finding; the claim was a misattribution (L1).\n2. **Read a session entry range** — harness code reading the entries it sweeps. Ticket 01 found no documented path to Pi's message list from inside a Flue agent; ticket 10 proved read-back only on the ui side via `useFlueAgent`; ticket 11 ran against a synthetic log. The hinge between the two prototypes is proven nowhere (L2).\n3. **Inject an on-behalf-of-user state entry** — the carrier for ticket 12's re-entry briefing. Candidate: Flue's `kind: 'signal'` message with trusted-code attributes (ticket 01 §6), which would also yield the true-user-versus-injected provenance distinction for free.\n4. **Transactional durable store distinct from per-conversation state** — ticket 12 requires whole-sweep-atomic application (and refusals) across sessions; conversation-scoped `usePersistentState` cannot provide it (ticket 01).\n\nSuccess = a minimal Flue walking skeleton (seeded from `prototype/10-flue-roundtrip`) that wires ticket 11's pure reducer (`prototype/11-capture-sweep`) to a real session log through these four capabilities. The resolution amends Shipping shape's six-item substrate-capability list — these are its four missing entries (pre-pass L3) — or records what Flue lacks or forbids and what the Flue binding must therefore absorb (binding-size asymmetry is expected, per ticket 06).\n\nBlocks: [Assemble the spec](<08-assemble-the-spec.md>).\n\n## Answer\n\n> Resolved by walking skeleton + two HITL reaction rounds, 2026-08-10. Real Flue agent + web UI with a live target-document panel, two browser sessions against one target-document, driven live by the user; 21-check headless probe suite passing. Prototype on branch `prototype/13-sweep-seam` (`prototypes/sweep-seam/`; commits 276c0e4 skeleton, bbb3646 HITL fix).\n\n**Overall: all four capabilities hold on Flue — two natively, two absorbed by the binding, none forbidden — with one load-bearing amendment from the HITL rounds: evidence anchoring must be harness-resolved, not model-chosen.**\n\n### Verdict per capability\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is the would-stop control seam: awaited before the response settles; `ctx.append` steers a settlement-check signal into a same-response continuation turn; the hook re-fires at the next would-stop; the response settles only when nothing appends. Trigger computes facts, judgment stays with the agent (declining is legal). Mechanism findings: the hook **fires on** `terminate: true` **suspensions too** (the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn); the nudge itself becomes a session entry, so the trigger needs a **loop guard** (never re-nudge the same latest-user-entry). Observed cadence drift: the model preferred sweeping at reply time without waiting for a nudge — harmless *because* sweeps are content-idempotent and harness-anchored; cadence is policy, exactly as ticket 11 said.\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (`getFlueRuntime` is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** (`GET <agent-url>?view=history`, @flue/sdk) over self-HTTP; works mid-response. The projection is sweep-sufficient: stable ids, stream order, `purpose` **as the provenance discriminator** ('user'/'assistant'/'dispatch'/'advisory'), signal descriptors, tool parts with validated outputs. **The amendment (HITL round 1):** the projection numbering is harness-side knowledge ONLY — hidden advisories inflate it and the model's seq guesses never converge, while its verbatim quotes are flawless. So the model-facing citation currency is the **quoted excerpt**; the harness resolves quotes to entries (user-entries-only candidates; no-match refuses with a repair hint; multi-match anchors latest with an advisory). Sharpens ticket 12's span shape: the excerpt is primary at proposal time, the pointer is derived.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** `ctx.append` (same-response) and `dispatch({kind:'signal'})` (real delivery) share one vocabulary. Caller-defined signals project as system-role / `purpose: 'dispatch'` / `display: 'diagnostic'` with tagName + trusted attributes — **structurally distinct from true user entries, so ticket 12's citable-evidence rule is mechanically enforced** (a capture citing an injected entry is refused). The re-entry briefing worked in every shape: fresh session, resumed session, post-restart session — and in HITL round 2 it produced unscripted **conversational conflict-surfacing**: briefed with \"September 12\" and told \"September 13\", the agent asked instead of overwriting, then swept the correction as a supersession citing both the assertion and the confirmation.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (milestone one: JSON file, tmp+rename atomic, in-process serialization), and every ticket-11 semantic survived the real log: whole-sweep-atomic apply/refuse, content-keyed idempotence (**load-bearing, not optional**, under Flue's at-least-once tool re-execution), single-hop supersession as the stale-session guard. Restart probe: conversations 404 (in-memory, no `db.ts`), store survives, a fresh session answers correctly from its briefing alone.\n\n### Capability-list amendment (Shipping shape, issue 06 — closes pre-pass L3)\n\nThe six-item substrate-capability list gains four entries: **7. subscribe to the would-stop lifecycle seam, with same-response signal steering** (native); **8. read the session's durable entry projection, with provenance-discriminating entry kinds** (binding-absorbed; no in-process API); **9. inject typed non-user signal entries, same-response and as deliveries** (native); **10. provide a transactional durable store outside conversation state** (binding-absorbed entirely). Binding-size asymmetry landed exactly where ticket 06 predicted.\n\n### HITL round 2 — cross-session dynamics observed live\n\nSession-a captured date/time, guests, budget; session-b opened with a contradictory assertion (\"Hilton, September 13\"): briefing → conversational conflict-surfacing → user confirmed → **c4 superseded c1 citing both user entries**. Then the superseded-history payoff: the user said \"the same time we said before, whatever that was\" — the time lived only in the *superseded* capture; the agent resolved it from the briefing's history and captured it as its own fact, honestly marked **inferred**, anchored to the user's actual words. \"Corrections don't erase history\" paying rent. One wrinkle for the spec: **compound payloads make supersession lossy** (c1 bundled date+time; c4 superseded it with date+venue and silently dropped the time until the user's remark rescued it) — capture granularity is plugin `validate`/kernel-card guidance territory. Same stratum as the other live find: a payload can smuggle an absence (`payload: \"not-yet-decided\"`) past the envelope — exactly the payload-level validation ticket 11 assigned to plugins.\n\n### Spec consequences (for issue 08)\n\nEntry identity is harness-side vocabulary; excerpts are the model-facing citation currency (amends the envelope's span story). Judgment prompts must never be the model's only source of mechanical facts (trigger suppression during suspension is correct but starves numbered context). Two payload-level validation examples now exist for the smallest-honest-plugin section. The wake-wart (ticket 10) remains cosmetically noisy (\"I've noted the update…\" doubling) — unchanged spec options.\n\n## Comments\n\n**2026-08-10 (walking skeleton built — awaiting your reaction; HITL).** The skeleton is done and all four capabilities were exercised against the real runtime, live model turns included. **Provisional verdict: all four hold on Flue — two absorbed by the binding as expected, none forbidden.**\n\n**Assets** (branch `prototype/13-sweep-seam`, commit 276c0e4, `prototypes/sweep-seam/`): real Flue agent + web UI with a live target-document panel (`bun run dev`, sessions `?id=session-a`/`session-b` share target-document `demo`); `node probe-seam.mjs` re-runs 18 checks (all passing). README documents the ask/terminate and restart probes.\n\n**Per capability:**\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is exactly the would-stop seam ticket 11 needed: awaited before the response settles, `ctx.append` steers a `settlement-check` signal into a same-response continuation turn, the hook re-fires at the next would-stop, and the response settles only when nothing appends. Trigger computes the facts (numbered unswept tail); judgment stays with the agent (declining is legal). Two mechanism findings: (a) the hook **fires on** `terminate: true` **suspensions too**, so the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn; (b) the nudge itself becomes a session entry, so the trigger must be **loop-guarded** (don't re-nudge the same max-user-seq; persistent `lastNudgedAt`).\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (the runtime getter is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** — `GET <agent-url>?view=history` via `@flue/sdk` — over self-HTTP; works mid-response (both the finish hook and the sweep tool read during the live response). The projection is sweep-sufficient: stable ids, stream order (seq), `purpose` **as the provenance discriminator** (`user` / `assistant` / `dispatch` / `advisory`), signal descriptors, tool parts with validated outputs. Warts: the binding must know its own base URL (env var here); a mid-flight read sees the partial assistant message; >1000-entry paging unprobed. Live-model finding: **entry-seq citation is error-prone for a small model** — the typed refusal steered a mis-cited sweep to correct in two hops (backpressure works), but the spec may prefer harness-resolved excerpt anchoring over model-chosen seqs.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** Two carriers share one vocabulary: `ctx.append` (same-response, no delivery) and `dispatch({kind: 'signal'})` (real delivery). Caller-defined signals project as system-role, `purpose: 'dispatch'`, `display: 'diagnostic'`, with `tagName` + trusted `attributes` — **structurally distinct from true user entries, so ticket 12's provenance rule is mechanically enforceable** (probe: a capture citing an injected entry is refused at validation). The re-entry briefing worked in all three shapes: fresh session, resumed session, and post-restart session — the last answered the user correctly from the briefing alone. Nuance: Flue classifies these as dispatch/diagnostic rather than literally \"on behalf of the user\"; the Pi convention survives as signal + render guidance, and the sharpened citable-evidence rule is *stronger* under Flue's classification.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (JSON file, tmp+rename atomic, in-process serialization — milestone-one local), and **every ticket-11 semantic survived contact with the real log**: whole-sweep-atomic apply/refuse, content-keyed idempotence, single-hop supersession as the stale-session guard (cross-session probe: session-b superseded session-a's capture; a stale re-supersession was refused with world-moved facts). Restart probe: conversations 404 (`stream_not_found` — in-memory, no `db.ts`), the store file survives. Confirms pre-pass L13: Flue's at-least-once tool re-execution makes content-keyed idempotence load-bearing, not optional.\n\n**Proposed capability-list amendment** (Shipping shape 06 — its four missing entries, per pre-pass L3): 7. *subscribe to the would-stop lifecycle seam, with same-response signal steering* (native: `useAgentFinish`/`ctx.append`); 8. *read the session's durable entry projection, with provenance-discriminating entry kinds* (binding-absorbed: history route; no in-process API); 9. *inject typed non-user signal entries, both same-response and as deliveries* (native: append/dispatch, `kind: 'signal'`); 10. *provide a transactional durable store outside conversation state* (binding-absorbed entirely; Flue offers none). Binding-size asymmetry landed exactly where ticket 06 predicted — the Node binding absorbed 8 and 10.\n\n**Incidental Flue facts:** `agentName` must be a string *literal* (the build-time scan rejects a constant reference); injected signals carry `display: 'diagnostic'`, so the ticket-10 UI-filtering lesson extends to them (the skeleton renders them as labeled cards instead — exploded-view-lite, per the map's fog note).\n\n**To resolve this ticket:** drive the skeleton (two browser sessions against one target-document is the fun path: sweep in one, resume the other), react, and we record the verdict + the capability-list amendment + graduate whatever fog the reaction surfaces.\n\n---\n\n**2026-08-10 (HITL reaction #1 → diagnosed and fixed; commit bbb3646).** The user drove session-a and sweeps never converged: an ask-heavy interview, then \"let's sweep\" → five refusals, model deflecting into more questions. Diagnosis from the session log: **the model's verbatim excerpts were flawless in every attempt; every entry seq was a guess** — five attempts, five different numberings, zero convergence. Two compounding causes: (a) the model *cannot* know the projection numbering (hidden `System instructions updated` advisories — the ticket-10 wake-wart — inflate it, and the model never sees them); (b) in an ask-heavy flow the pending guard suppresses every settlement-check, so the numbered tail never re-arrives and a user-requested sweep runs blind.\n\n**The fix, which is itself the sharpened finding: evidence anchoring must be harness-resolved, not model-chosen.** The model now cites only verbatim user quotes (plain strings); the harness — the only party that can see the projection — resolves each quote to its entry (`resolveEvidence`: user-entries-only candidates, no-match refuses with a repair hint, multi-match anchors latest with an advisory note); seq numbers and `upTo` left the model-facing tool contract entirely. Replaying the user's exact failing flow headlessly now converges (the residual refusals en route were *correct* envelope refusals — empty evidence, value-and-absence — which the model repaired). Probe suite extended and made self-contained: 21/21, twice consecutively.\n\nSpec consequences: (1) the questioning-UX/envelope contract should state that **entry identity is harness-side vocabulary; the model-facing citation currency is the quoted excerpt** — this also strengthens ticket 12's \"pointer + quoted excerpt\" span shape (the excerpt is primary at proposal time; the pointer is derived); (2) a payload can *smuggle* an absence (`payload: \"not-yet-decided\"` observed live) — the envelope cannot catch it; that is exactly the payload-level stratum ticket 11 assigned to plugin `validate`, worth an explicit spec example; (3) trigger suppression during suspension is correct, but judgment prompts must never be the model's only source of mechanical facts.\n\nStill open for your reaction: the cross-session dynamics you originally set out to test (sweep in one browser session, resume the other — the headless probes exercise it, but the HITL reaction is the point).\n+++",
+      "proposedBodySha256": "dd980892bd4e20374a2f03376349487362168f2ee20c7182b47e8575d1c30e37",
+      "ambiguity": null,
+      "notes": null
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1383.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1383.json
new file mode 100644
index 00000000000..6f40fbb2194
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1383.json
@@ -0,0 +1,535 @@
+{
+  "root": "FE-1383",
+  "generatedAt": "2026-08-20T09:04:03.710797Z",
+  "issueCount": 19,
+  "issues": [
+    {
+      "id": "5e45263d-bf61-4025-b415-cca91df88023",
+      "identifier": "FE-1383",
+      "url": "https://linear.app/hash/issue/FE-1383/build-the-elicitation-harness-to-milestone-one-an-interview-that",
+      "state": {
+        "name": "In progress",
+        "type": "started"
+      },
+      "parent": null,
+      "sourceUpdatedAt": "2026-08-19T16:26:28.251Z",
+      "sourceTitle": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance",
+      "sourceDescriptionSha256": "6ffa6c3bd7e56e39402e2b9b3c4a6dca3a3d926202fcfa19b6d41feecdadf78d",
+      "sourceTitleSha256": "d5fbe781b6392a20e99ebbcd938e2556a3591b1eec6b089aa46e450fc54abd2b",
+      "oldOuter": "The [elicitation kernel spec](<https://github.com/hashintel/brunch-lite/blob/main/docs/planning/elicitation-kernel/spec.md>) is finished and reviewed, but nothing has been built — the repo holds planning documents and no code at all. Until that changes, the September demo has no library to consume: FE-1362 committed the demo to a purpose-built shell driving a new interviewing library, and this is that library.\n\nMilestone one is the walking version of the whole architecture. A person is interviewed in ordinary conversation; the agent captures what they said as evidence-anchored structured meaning; a plugin turns those captures into a real artifact — a Gherkin feature file for the first target — in which every value traces back to a verbatim quote, corrections never erase history, and anything that could not be represented is reported rather than dropped. The sub-issues below are vertical slices of that path, each one demoable or verifiable on its own.\n\nOne capability is deliberately absent. The spec requires a second, harder target to stress the plugin contract before that contract is declared stable, and which target that should be depends on decisions still being resolved on FE-1357 — so the plugin interface stays explicitly unfrozen through this batch, and the last four tickets are a working plan rather than a settled one.",
+      "proposedTitle": "Build the first complete elicitation interview",
+      "proposedOuter": "The elicitation kernel is specified and reviewed, but the repository has no implementation. The September demo depends on this library to interview a person, preserve evidence and corrections, and produce a Gherkin artifact whose values trace to verbatim quotes.\n\nThis milestone builds that complete path through independently verifiable sub-issues. The plugin interface remains unstable until FE-1357 resolves the harder second target, so the final four sub-issues remain a working plan.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Working notes\n\n**Source**: `docs/planning/elicitation-kernel/spec.md` (repo-canonical). Each sub-issue names the spec sections it implements; the spec is the contract, the ticket is the slice.\n\n**Blocking** is expressed through Linear's native blocked-by relations, not restated in bodies. The frontier is whatever is open with no unresolved blocker — currently the scaffold and the capture store, which can run in parallel.\n\n**Readiness**: sub-issues labelled `ready-for-agent` are specified well enough for an agent to pick up from the spec alone. The four in Backlog are not — they are approved in shape but foggy in detail, and each names what has to be settled first. Expect a grilling round at the head of most tickets regardless; this arc is closer to a wayfinding arc than to a queue.\n\n**The contract-freeze caveat** (spec §13): the two-targets-on-each-axis rule says the trivial target must not freeze the plugin contract before the hard target has stressed it. Gherkin is the trivial target. So nothing in this batch ratifies the SDK export surface — that is the last ticket's job, and it is gated on FE-1364.\n\n**Open verification items** from spec §14.5 are folded into the slices that own them, except compaction-versus-durable-history, which is large enough to stand alone.",
+      "innerSha256": "dc692280cc915bda482146be207015d0dcdd034d4ad8fbd09d37c40b2b4897ee",
+      "proposedBody": "The elicitation kernel is specified and reviewed, but the repository has no implementation. The September demo depends on this library to interview a person, preserve evidence and corrections, and produce a Gherkin artifact whose values trace to verbatim quotes.\n\nThis milestone builds that complete path through independently verifiable sub-issues. The plugin interface remains unstable until FE-1357 resolves the harder second target, so the final four sub-issues remain a working plan.\n\n+++🏗️ Agent notes\n## Working notes\n\n**Source**: `docs/planning/elicitation-kernel/spec.md` (repo-canonical). Each sub-issue names the spec sections it implements; the spec is the contract, the ticket is the slice.\n\n**Blocking** is expressed through Linear's native blocked-by relations, not restated in bodies. The frontier is whatever is open with no unresolved blocker — currently the scaffold and the capture store, which can run in parallel.\n\n**Readiness**: sub-issues labelled `ready-for-agent` are specified well enough for an agent to pick up from the spec alone. The four in Backlog are not — they are approved in shape but foggy in detail, and each names what has to be settled first. Expect a grilling round at the head of most tickets regardless; this arc is closer to a wayfinding arc than to a queue.\n\n**The contract-freeze caveat** (spec §13): the two-targets-on-each-axis rule says the trivial target must not freeze the plugin contract before the hard target has stressed it. Gherkin is the trivial target. So nothing in this batch ratifies the SDK export surface — that is the last ticket's job, and it is gated on FE-1364.\n\n**Open verification items** from spec §14.5 are folded into the slices that own them, except compaction-versus-durable-history, which is large enough to stand alone.\n+++",
+      "proposedBodySha256": "9f4da7bc680f1d0762c1d0098a0f98977dcdc7348e80f4d4f2f0a1d31bbea2c0",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "57a4161b-45df-451c-a77c-cfdd3055b6e5",
+      "identifier": "FE-1384",
+      "url": "https://linear.app/hash/issue/FE-1384/generative-test-corpus-over-the-replay-driver",
+      "state": {
+        "name": "Backlog",
+        "type": "backlog"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.528Z",
+      "sourceTitle": "Generative test corpus over the replay driver",
+      "sourceDescriptionSha256": "dc23151710c724730fd5e28460cf1e18ad96ee9b6faf63acf4c4385c7b963ab8",
+      "sourceTitleSha256": "34fd893cbe8f38105a28d034e986b36d093d2bb616f11fd3705d9a89ca11a606",
+      "oldOuter": "",
+      "proposedTitle": "Generate replay tests for the harness rules",
+      "proposedOuter": "Earlier work has accumulated hand-written replay tests, while the ten harness rules are stated as properties. This task will derive generated conversations and values from plugin declarations, run the rules against those sequences without a model or runtime dependency, and retain reduced failures as regression cases.\n\nThe amount of generation needed for milestone one, the role of offline model-generated fixtures, and the fixture refresh process still need decisions.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nTurn the hand-written tests accumulated by the earlier slices into seeds for a generated corpus. The ten harness invariants are literally properties; the generators come from a plugin's declarations rather than its implementation; and conversations themselves become generated command sequences, so pathological interview shapes get found rather than imagined.\n\nSpec: §14.4 (testing strategy), §14.1 (the ten invariants), §12.4 (SDK testing surface).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much generative machinery earns its keep at milestone one versus after a second plugin exists; whether the model-as-offline-generator step is in scope now or is a later luxury; and what the regenerate-on-declaration-change workflow actually looks like in practice.\n\n## Acceptance criteria\n\n- [ ] The ten harness invariants run as executable properties, not as prose\n- [ ] Arbitraries derive from Valibot declarations rather than implementations, so a plugin cannot accidentally test itself against its own bugs\n- [ ] Negative-space properties hold for plugin code: validators total, and projection never emitting an undeclared loss category\n- [ ] Command-sequence testing runs over the envelope-derived alphabet — utter, settle-range, sweep, correct, contradict, reply-with-absence, redirect\n- [ ] Mutation operators generalise the minimal-pairs idea: epistemic-status flips, absence injections, supersession injections\n- [ ] A model plays respondent as an offline generator whose outputs freeze as replayable fixtures — never as a CI oracle; everything in CI runs with no model and no substrate\n- [ ] Fixtures regenerate when declarations change, and the staleness is detectable rather than silent\n- [ ] Shrunk counterexamples are pinned as regressions and read as type-design feedback",
+      "innerSha256": "dc23151710c724730fd5e28460cf1e18ad96ee9b6faf63acf4c4385c7b963ab8",
+      "proposedBody": "Earlier work has accumulated hand-written replay tests, while the ten harness rules are stated as properties. This task will derive generated conversations and values from plugin declarations, run the rules against those sequences without a model or runtime dependency, and retain reduced failures as regression cases.\n\nThe amount of generation needed for milestone one, the role of offline model-generated fixtures, and the fixture refresh process still need decisions.\n\n+++🏗️ Agent notes\n## What to build\n\nTurn the hand-written tests accumulated by the earlier slices into seeds for a generated corpus. The ten harness invariants are literally properties; the generators come from a plugin's declarations rather than its implementation; and conversations themselves become generated command sequences, so pathological interview shapes get found rather than imagined.\n\nSpec: §14.4 (testing strategy), §14.1 (the ten invariants), §12.4 (SDK testing surface).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much generative machinery earns its keep at milestone one versus after a second plugin exists; whether the model-as-offline-generator step is in scope now or is a later luxury; and what the regenerate-on-declaration-change workflow actually looks like in practice.\n\n## Acceptance criteria\n\n- [ ] The ten harness invariants run as executable properties, not as prose\n- [ ] Arbitraries derive from Valibot declarations rather than implementations, so a plugin cannot accidentally test itself against its own bugs\n- [ ] Negative-space properties hold for plugin code: validators total, and projection never emitting an undeclared loss category\n- [ ] Command-sequence testing runs over the envelope-derived alphabet — utter, settle-range, sweep, correct, contradict, reply-with-absence, redirect\n- [ ] Mutation operators generalise the minimal-pairs idea: epistemic-status flips, absence injections, supersession injections\n- [ ] A model plays respondent as an offline generator whose outputs freeze as replayable fixtures — never as a CI oracle; everything in CI runs with no model and no substrate\n- [ ] Fixtures regenerate when declarations change, and the staleness is detectable rather than silent\n- [ ] Shrunk counterexamples are pinned as regressions and read as type-design feedback\n+++",
+      "proposedBodySha256": "55bb83d8bcc9e1729b3697bff5f94bcf24e0f04e7ba26a06226561574391f8fb",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "089776c5-6a5c-4fa8-aaed-26e0aa5705de",
+      "identifier": "FE-1385",
+      "url": "https://linear.app/hash/issue/FE-1385/dev-app-target-gallery-and-diagnostic-probe-surface",
+      "state": {
+        "name": "Backlog",
+        "type": "backlog"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.147Z",
+      "sourceTitle": "Dev app — target gallery and diagnostic probe surface",
+      "sourceDescriptionSha256": "1bd36079855c694a19c2c16781b8fe79cb03ea9ed3cd3bbce9b31f3ba0993cb4",
+      "sourceTitleSha256": "7e4a538631309c52c61b4d6d4e1d405aa54ba435c20f18e8684b3f2a020ceedb",
+      "oldOuter": "",
+      "proposedTitle": "Expand the dev app into a target gallery and diagnostic view",
+      "proposedOuter": "The dev app currently serves as a test UI. This task will make it support local development, side-by-side target demonstrations, and a diagnostic view of session state, tool traffic, suspensions, and injected signals.\n\nThe required diagnostic depth, the timing of a gallery before a second target exists, and the actions a colleague must perform without help remain unsettled.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nPromote the dev app from a test surface into the chartered three-role vehicle the spec describes: the local development loop, a colleague-facing gallery where several targets can be demoed side by side, and a diagnostic view that shows the machinery rather than only the chat.\n\nThe diagnostic role is the one worth protecting. It exists because reacting to a system's internals is a different activity from reacting to its conversation, and the fog note that surfaced it asked for parallel state readout with labelled moving parts — pending slot, high-water mark, tool traffic, suspension boundaries, injected signals.\n\nSpec: §12.5 (dev app roles, deferred ui package), §7.6 (renderer seam), §12.1 (host-authored agent module).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much of the exploded-view instrumentation belongs here versus later; whether the gallery is genuinely needed before a second target exists to gallery; and what a colleague is meant to be able to do unaided.\n\n## Acceptance criteria\n\n- [ ] The local dev loop runs against the available plugins with one agent per target and static per-agent tool sets\n- [ ] Parallel tabbed sessions work across targets without cross-contamination\n- [ ] The diagnostic surface shows per-session state and tool traffic alongside the conversation, with the moving parts labelled\n- [ ] Affordance renderers live in the dev app, with the ui affordance package deliberately deferred\n- [ ] Remote-parity constraints are visibly respected: one agent serving many conversations, pinned agent name, storage port owned outside the plugin, no dynamic agent creation",
+      "innerSha256": "1bd36079855c694a19c2c16781b8fe79cb03ea9ed3cd3bbce9b31f3ba0993cb4",
+      "proposedBody": "The dev app currently serves as a test UI. This task will make it support local development, side-by-side target demonstrations, and a diagnostic view of session state, tool traffic, suspensions, and injected signals.\n\nThe required diagnostic depth, the timing of a gallery before a second target exists, and the actions a colleague must perform without help remain unsettled.\n\n+++🏗️ Agent notes\n## What to build\n\nPromote the dev app from a test surface into the chartered three-role vehicle the spec describes: the local development loop, a colleague-facing gallery where several targets can be demoed side by side, and a diagnostic view that shows the machinery rather than only the chat.\n\nThe diagnostic role is the one worth protecting. It exists because reacting to a system's internals is a different activity from reacting to its conversation, and the fog note that surfaced it asked for parallel state readout with labelled moving parts — pending slot, high-water mark, tool traffic, suspension boundaries, injected signals.\n\nSpec: §12.5 (dev app roles, deferred ui package), §7.6 (renderer seam), §12.1 (host-authored agent module).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much of the exploded-view instrumentation belongs here versus later; whether the gallery is genuinely needed before a second target exists to gallery; and what a colleague is meant to be able to do unaided.\n\n## Acceptance criteria\n\n- [ ] The local dev loop runs against the available plugins with one agent per target and static per-agent tool sets\n- [ ] Parallel tabbed sessions work across targets without cross-contamination\n- [ ] The diagnostic surface shows per-session state and tool traffic alongside the conversation, with the moving parts labelled\n- [ ] Affordance renderers live in the dev app, with the ui affordance package deliberately deferred\n- [ ] Remote-parity constraints are visibly respected: one agent serving many conversations, pinned agent name, storage port owned outside the plugin, no dynamic agent creation\n+++",
+      "proposedBodySha256": "4006e0abface3b93c193d635f3637c22af1ec196f0df75173d77cb228edbf4ea",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "bd45303d-7024-476e-9640-0ab24815a08c",
+      "identifier": "FE-1386",
+      "url": "https://linear.app/hash/issue/FE-1386/verify-compaction-leaves-the-durable-entry-projection-intact",
+      "state": {
+        "name": "Backlog",
+        "type": "backlog"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.302Z",
+      "sourceTitle": "Verify compaction leaves the durable entry projection intact",
+      "sourceDescriptionSha256": "b032d11e90f77e094632a0437a00a3b19ba43f3b74d851fda5f9983d7059a675",
+      "sourceTitleSha256": "e290d7dbfc6823fb2391b9835c7851aac4dcfd7266cbcca1076a83916a843bc0",
+      "oldOuter": "",
+      "proposedTitle": "Test durable history across transcript compaction",
+      "proposedOuter": "The specification says transcript compaction may reduce model context without removing entries that evidence references resolve, but no test has crossed a real compaction boundary. This investigation will determine whether old evidence pointers and session state survive, then record either confirmation or the exact archive work the binding must perform.\n\nThe test design depends in part on whether Flue provides a compaction definition.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nAn answer to the one durability claim in the spec that nothing has tested. Pi-family substrates compact long transcripts, and the spec asserts that compaction may shrink what the model re-reads but never what the store can resolve. No prototype has ever driven a session across a compaction boundary, so the assertion is currently unverified.\n\nThe outcome is knowledge, not a feature: either the durable entry projection survives compaction unmodified, or we learn exactly what the binding has to preserve itself and the archive mechanism absorbs it.\n\nSpec: §9.7 (context compaction versus the durable log), §14.5 (open verification items).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail — and partly dependent on whether Flue ships a compaction definition at all, which is worth establishing before designing the test.\n\n## Acceptance criteria\n\n- [ ] A session is genuinely driven across a compaction boundary, not simulated\n- [ ] Evidence pointers created before compaction still resolve afterwards\n- [ ] Either the durable projection is confirmed compaction-independent, or the entries compaction prunes are enumerated and the archive's absorption of them is verified\n- [ ] Per-session harness state is confirmed to live outside the transcript and survive\n- [ ] If a compaction definition is supplied, injected signals and affordance tool parts are confirmed to need no protected status\n- [ ] The finding is written up and the spec section updated from unverified to settled either way",
+      "innerSha256": "b032d11e90f77e094632a0437a00a3b19ba43f3b74d851fda5f9983d7059a675",
+      "proposedBody": "The specification says transcript compaction may reduce model context without removing entries that evidence references resolve, but no test has crossed a real compaction boundary. This investigation will determine whether old evidence pointers and session state survive, then record either confirmation or the exact archive work the binding must perform.\n\nThe test design depends in part on whether Flue provides a compaction definition.\n\n+++🏗️ Agent notes\n## What to build\n\nAn answer to the one durability claim in the spec that nothing has tested. Pi-family substrates compact long transcripts, and the spec asserts that compaction may shrink what the model re-reads but never what the store can resolve. No prototype has ever driven a session across a compaction boundary, so the assertion is currently unverified.\n\nThe outcome is knowledge, not a feature: either the durable entry projection survives compaction unmodified, or we learn exactly what the binding has to preserve itself and the archive mechanism absorbs it.\n\nSpec: §9.7 (context compaction versus the durable log), §14.5 (open verification items).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail — and partly dependent on whether Flue ships a compaction definition at all, which is worth establishing before designing the test.\n\n## Acceptance criteria\n\n- [ ] A session is genuinely driven across a compaction boundary, not simulated\n- [ ] Evidence pointers created before compaction still resolve afterwards\n- [ ] Either the durable projection is confirmed compaction-independent, or the entries compaction prunes are enumerated and the archive's absorption of them is verified\n- [ ] Per-session harness state is confirmed to live outside the transcript and survive\n- [ ] If a compaction definition is supplied, injected signals and affordance tool parts are confirmed to need no protected status\n- [ ] The finding is written up and the spec section updated from unverified to settled either way\n+++",
+      "proposedBodySha256": "d7f821b94ba0d31f3b02ffd7b4769331a9cb4b80299d2794f3c0fdede05c14bd",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "445c6b39-0e2f-4684-887d-e9e28da79023",
+      "identifier": "FE-1387",
+      "url": "https://linear.app/hash/issue/FE-1387/author-the-second-pack-and-freeze-the-plugin-contract",
+      "state": {
+        "name": "Backlog",
+        "type": "backlog"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.344Z",
+      "sourceTitle": "Author the second pack and freeze the plugin contract",
+      "sourceDescriptionSha256": "0e246edd61bf61e1ca4ca67103d4f396f0d7b1d11611474727197431788ca94b",
+      "sourceTitleSha256": "1e34347c94852da08269de757dd7c58086a76b740fcff0e69c8104de4853eff7",
+      "oldOuter": "",
+      "proposedTitle": "Choose a second target and stabilize the plugin interface",
+      "proposedOuter": "Gherkin alone cannot establish a stable plugin interface because it does not exercise evidence grading, graph-shaped payloads, or derived domain labels. This task will build a harder second target through the same harness, record the interface changes it requires, and then judge the interface against the specified proof obligations.\n\nFE-1364 must first choose between the specified assurance-argument target and the demo's process-model target; that choice also determines whether this work is demo-critical.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe ticket that makes the plugin contract real. A second, harder target gets authored against the SDK, stressing the parts a Gherkin file never touches — evidence grading, a payload graph rather than a flat list, derived domain labels — and only once it has done so is the export surface declared stable.\n\n**Which second target is not yet decided, and is not this ticket's to decide.** The spec names an assurance-argument plugin and specifies it in buildable detail. But FE-1362 committed the September demo to a process-model plugin, which would make that the natural second target and leave assurance as specified-but-unbuilt. The answer depends on FE-1364, and it changes this ticket's urgency as well as its content: if the second target is the process-model plugin, this stops being milestone-one cleanup and becomes demo-critical path.\n\nSpec: §13 (portfolio and hybrid order), §13.2–13.3 (the assurance argument, if that is the target), §14.2–14.3 (proof obligations, gating tests), §11.5 (generic strategy quiver).\n\n## Not yet ready for an agent\n\nBlocked on FE-1364 for the target decision. A working plan, not a settled one.\n\n## Acceptance criteria\n\n- [ ] The second target is chosen, with the reasoning recorded\n- [ ] Its packs are authored and it runs end to end through the same harness, sharing no code with the gherkin plugin beyond the SDK\n- [ ] The reprojection gating test passes: capture once, project into materially different targets, verify agreement\n- [ ] The black-box authoring test runs — public SDK and docs handed to someone who has not read core, counting concepts, boilerplate, and escape hatches\n- [ ] Every contract change the second target forced is recorded, since each one is evidence about what gherkin alone failed to stress\n- [ ] Any interviewing technique that turned out to operate on envelope vocabulary rather than domain vocabulary is identified as candidate strategy-quiver content rather than buried in a plugin pack\n- [ ] The five proof obligations are judged against the hourglass, and the SDK export surface is declared stable",
+      "innerSha256": "0e246edd61bf61e1ca4ca67103d4f396f0d7b1d11611474727197431788ca94b",
+      "proposedBody": "Gherkin alone cannot establish a stable plugin interface because it does not exercise evidence grading, graph-shaped payloads, or derived domain labels. This task will build a harder second target through the same harness, record the interface changes it requires, and then judge the interface against the specified proof obligations.\n\nFE-1364 must first choose between the specified assurance-argument target and the demo's process-model target; that choice also determines whether this work is demo-critical.\n\n+++🏗️ Agent notes\n## What to build\n\nThe ticket that makes the plugin contract real. A second, harder target gets authored against the SDK, stressing the parts a Gherkin file never touches — evidence grading, a payload graph rather than a flat list, derived domain labels — and only once it has done so is the export surface declared stable.\n\n**Which second target is not yet decided, and is not this ticket's to decide.** The spec names an assurance-argument plugin and specifies it in buildable detail. But FE-1362 committed the September demo to a process-model plugin, which would make that the natural second target and leave assurance as specified-but-unbuilt. The answer depends on FE-1364, and it changes this ticket's urgency as well as its content: if the second target is the process-model plugin, this stops being milestone-one cleanup and becomes demo-critical path.\n\nSpec: §13 (portfolio and hybrid order), §13.2–13.3 (the assurance argument, if that is the target), §14.2–14.3 (proof obligations, gating tests), §11.5 (generic strategy quiver).\n\n## Not yet ready for an agent\n\nBlocked on FE-1364 for the target decision. A working plan, not a settled one.\n\n## Acceptance criteria\n\n- [ ] The second target is chosen, with the reasoning recorded\n- [ ] Its packs are authored and it runs end to end through the same harness, sharing no code with the gherkin plugin beyond the SDK\n- [ ] The reprojection gating test passes: capture once, project into materially different targets, verify agreement\n- [ ] The black-box authoring test runs — public SDK and docs handed to someone who has not read core, counting concepts, boilerplate, and escape hatches\n- [ ] Every contract change the second target forced is recorded, since each one is evidence about what gherkin alone failed to stress\n- [ ] Any interviewing technique that turned out to operate on envelope vocabulary rather than domain vocabulary is identified as candidate strategy-quiver content rather than buried in a plugin pack\n- [ ] The five proof obligations are judged against the hourglass, and the SDK export surface is declared stable\n+++",
+      "proposedBodySha256": "b1912a23596a7a926364882ee864accbfa54a69eb59464441e23a3fabb503f9c",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "39202ed3-e7bc-40ae-af73-38bcc35f39b3",
+      "identifier": "FE-1388",
+      "url": "https://linear.app/hash/issue/FE-1388/scaffold-the-bun-workspace-and-prove-the-ci-smoke",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.054Z",
+      "sourceTitle": "Scaffold the Bun workspace and prove the CI smoke",
+      "sourceDescriptionSha256": "5b79a1a15bf83d384bc11b114188db2252eeec734c0299f196f56f83c59a4d94",
+      "sourceTitleSha256": "1f553d53fd1c4493bf1808505a85c8275a908f377cc646c3d822d7ee9cc4a4b7",
+      "oldOuter": "",
+      "proposedTitle": "Create the Bun workspace and enforce dependency boundaries",
+      "proposedOuter": "The repository needs a Bun workspace that builds and tests from a clean checkout before feature work begins. This task will create the specified core, Flue binding, Gherkin plugin, and dev-app boundaries, then enforce their dependency direction in CI without model credentials or network access.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nA Bun-workspace monorepo that builds and tests green from empty, with the architectural boundaries in place from the first commit rather than retrofitted later. Nothing user-visible happens yet; what this delivers is that every later slice lands into a structure that already refuses the wrong dependency direction.\n\nSpec: §12.2 (package topology), §12.3 (naming), §12.4 (schemas), §12.5 (CI smoke), §10 (recorded Flue facts the implementation must respect).\n\n## Acceptance criteria\n\n- [ ] `bun test` and `vite build` both pass from a clean checkout, with no model key and no network access\n- [ ] Packages exist per the spec's topology with its role prefixes: `core` (plugin SDK as its export surface) with a `core/testing` subpath, `binding-flue`, `plugin-gherkin`, and a dev app owning the agent module, mount, and conversation store\n- [ ] The dependency invariants hold and are mechanically checkable, not just documented: plugins resolve `core` only — never the binding, never Flue; `core` imports no substrate; the binding imports both\n- [ ] Valibot is the schema library at every boundary; no Standard-Schema conversion seam\n- [ ] The recorded Flue constraints are respected by construction: vite pinned to ^8, `'use agent'` as the agent module's first statement, `agentName` a pinned string literal\n- [ ] Tool-name prefix derives from the product name and bakes in neither \"elicit\" nor \"brunch\"",
+      "innerSha256": "5b79a1a15bf83d384bc11b114188db2252eeec734c0299f196f56f83c59a4d94",
+      "proposedBody": "The repository needs a Bun workspace that builds and tests from a clean checkout before feature work begins. This task will create the specified core, Flue binding, Gherkin plugin, and dev-app boundaries, then enforce their dependency direction in CI without model credentials or network access.\n\n+++🏗️ Agent notes\n## What to build\n\nA Bun-workspace monorepo that builds and tests green from empty, with the architectural boundaries in place from the first commit rather than retrofitted later. Nothing user-visible happens yet; what this delivers is that every later slice lands into a structure that already refuses the wrong dependency direction.\n\nSpec: §12.2 (package topology), §12.3 (naming), §12.4 (schemas), §12.5 (CI smoke), §10 (recorded Flue facts the implementation must respect).\n\n## Acceptance criteria\n\n- [ ] `bun test` and `vite build` both pass from a clean checkout, with no model key and no network access\n- [ ] Packages exist per the spec's topology with its role prefixes: `core` (plugin SDK as its export surface) with a `core/testing` subpath, `binding-flue`, `plugin-gherkin`, and a dev app owning the agent module, mount, and conversation store\n- [ ] The dependency invariants hold and are mechanically checkable, not just documented: plugins resolve `core` only — never the binding, never Flue; `core` imports no substrate; the binding imports both\n- [ ] Valibot is the schema library at every boundary; no Standard-Schema conversion seam\n- [ ] The recorded Flue constraints are respected by construction: vite pinned to ^8, `'use agent'` as the agent module's first statement, `agentName` a pinned string literal\n- [ ] Tool-name prefix derives from the product name and bakes in neither \"elicit\" nor \"brunch\"\n+++",
+      "proposedBodySha256": "40fbfa55a43bdec883dfb46aef82c776b3ee10a693a225a96a0bc84c38663073",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "28ceb592-7d61-40a4-b11a-b8dfde57e7eb",
+      "identifier": "FE-1389",
+      "url": "https://linear.app/hash/issue/FE-1389/walking-skeleton-the-harness-asks-a-free-text-question-and-binds-the",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:28.046Z",
+      "sourceTitle": "Walking skeleton — the harness asks a free-text question and binds the reply",
+      "sourceDescriptionSha256": "3623852992eec05f9567c745d0d253773713feb486dbef929fc28db16f7a317c",
+      "sourceTitleSha256": "02a0530dca8c589424e2bc9a4813afe1a1cf33887212424ba50fdeba8cb20a49",
+      "oldOuter": "",
+      "proposedTitle": "Implement the first suspended free-text question",
+      "proposedOuter": "The harness needs to ask a free-text question, suspend the turn, receive a typed answer, and continue a real dev-app conversation. This task will move the proven prototype mechanism into the main workspace while keeping the question out of instructions and binding replies mechanically to the single pending affordance.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe first thing a person can actually use: open the dev app, and the agent asks a free-text question, waits, receives the typed answer, and carries on the conversation with the answer in hand. This is the turn-suspension protocol the harness has to own because Flue has no ask-the-user primitive, proven in the real tree rather than on a prototype branch.\n\nThe prototype on `prototype/10-flue-roundtrip` already established the mechanism; this ports it in and hardens the two rulings that came after it — no instruction interpolation, and mechanical reply binding.\n\nSpec: §7.1–7.4, §7.7, §9.2 (pending-affordance slot), §10 capabilities 1–5, §12.1.\n\n## Acceptance criteria\n\n- [ ] A person can hold a multi-turn conversation in the dev app in which the agent asks free-text questions and receives answers\n- [ ] Turn suspension works through a terminating ask tool plus the pending affordance in per-session state, with the answer arriving as a fresh dispatch\n- [ ] The pending question is never interpolated into instructions — it rides the ask tool's result — and no \"instructions updated\" advisory wake occurs per ask (spec §14.5 wake-wart residue: confirm no other instruction-state write path re-triggers it)\n- [ ] Reply binding is harness-mechanical off the single-pending invariant: no echo token, no reliance on the model remembering an id\n- [ ] Durable affordance identity and payload ride the ask tool's output part, not the data channel\n- [ ] A second interactive affordance in the same batch is rejected as mechanism, not as instruction\n- [ ] Every question renders through the markdown floor, so a ui that knows only the envelope shows something usable",
+      "innerSha256": "3623852992eec05f9567c745d0d253773713feb486dbef929fc28db16f7a317c",
+      "proposedBody": "The harness needs to ask a free-text question, suspend the turn, receive a typed answer, and continue a real dev-app conversation. This task will move the proven prototype mechanism into the main workspace while keeping the question out of instructions and binding replies mechanically to the single pending affordance.\n\n+++🏗️ Agent notes\n## What to build\n\nThe first thing a person can actually use: open the dev app, and the agent asks a free-text question, waits, receives the typed answer, and carries on the conversation with the answer in hand. This is the turn-suspension protocol the harness has to own because Flue has no ask-the-user primitive, proven in the real tree rather than on a prototype branch.\n\nThe prototype on `prototype/10-flue-roundtrip` already established the mechanism; this ports it in and hardens the two rulings that came after it — no instruction interpolation, and mechanical reply binding.\n\nSpec: §7.1–7.4, §7.7, §9.2 (pending-affordance slot), §10 capabilities 1–5, §12.1.\n\n## Acceptance criteria\n\n- [ ] A person can hold a multi-turn conversation in the dev app in which the agent asks free-text questions and receives answers\n- [ ] Turn suspension works through a terminating ask tool plus the pending affordance in per-session state, with the answer arriving as a fresh dispatch\n- [ ] The pending question is never interpolated into instructions — it rides the ask tool's result — and no \"instructions updated\" advisory wake occurs per ask (spec §14.5 wake-wart residue: confirm no other instruction-state write path re-triggers it)\n- [ ] Reply binding is harness-mechanical off the single-pending invariant: no echo token, no reliance on the model remembering an id\n- [ ] Durable affordance identity and payload ride the ask tool's output part, not the data channel\n- [ ] A second interactive affordance in the same batch is rejected as mechanism, not as instruction\n- [ ] Every question renders through the markdown floor, so a ui that knows only the envelope shows something usable\n+++",
+      "proposedBodySha256": "defe642e2c766097597b2634056e955f6f0c1a2feff5afc74a1d0ebdb2f2ae1f",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "c58d731d-378e-4e4a-a0ea-b879dc32a259",
+      "identifier": "FE-1390",
+      "url": "https://linear.app/hash/issue/FE-1390/capture-envelope-storage-port-and-the-local-capture-store",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.947Z",
+      "sourceTitle": "Capture envelope, storage port, and the local capture store",
+      "sourceDescriptionSha256": "dce103e6c13f999a39d866e51e61826185cc97f34dd221baa2a8b8f55bf77826",
+      "sourceTitleSha256": "79014f58a3fcbcbe710117e024203f408d2c85b31178827f4e2a1f2f7c50d74b",
+      "oldOuter": "",
+      "proposedTitle": "Implement capture history and local persistence",
+      "proposedOuter": "The harness needs a local store for captures, corrections, contradictions, retractions, and resolution records that never overwrites history. This task will define the capture envelope and persistence port, derive status when reading, reject invalid lifecycle changes, and apply each sweep atomically without requiring a model or runtime.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe capture store and the envelope that sits in it — drivable end to end from tests with no model and no substrate, which is the whole point of the design. You can write a capture, correct it, contradict it, retract it, and read back a coherent history in which nothing was silently overwritten and every status was computed rather than stored.\n\nSpec: §5 (capture envelope), §5.1 (absence states), §6.2 (envelope-level validation), §8.3–8.5 (idempotence, supersession, resolution records), §9.6 (the storage port), §10 capability 10.\n\n## Acceptance criteria\n\n- [ ] The storage port is harness-defined and binding-implemented; nothing in the plugin surface can reach persistence\n- [ ] The envelope carries a harness-minted id alongside a content-derived dedup key that excludes epistemic status, so re-reading the same evidence differently requires explicit supersession\n- [ ] Value-XOR-absence is enforced as a refusal, and the six absence states are distinct capture values that never collapse into null or negation\n- [ ] Supersession is single-hop over active heads only; superseding an already-superseded capture is refused, and that refusal carries the world-moved facts\n- [ ] Superseded captures stay inspectable forever and never read as active\n- [ ] A `conflicting` issue closes only through a resolution record citing the true user's utterance; a bare close is refused, and so is a record citing the agent's words\n- [ ] Retraction is an explicit stored event citing the user, naming no successor, and is the only path to retracted status\n- [ ] No status field is stored anywhere — envelope status derives at read time from links, records, and events\n- [ ] Writes are serialized and application is whole-sweep-atomic: a sweep applies entirely or refuses entirely\n- [ ] Harness invariants 2, 4, 5, 7, 9, and 10 hold as executable tests",
+      "innerSha256": "dce103e6c13f999a39d866e51e61826185cc97f34dd221baa2a8b8f55bf77826",
+      "proposedBody": "The harness needs a local store for captures, corrections, contradictions, retractions, and resolution records that never overwrites history. This task will define the capture envelope and persistence port, derive status when reading, reject invalid lifecycle changes, and apply each sweep atomically without requiring a model or runtime.\n\n+++🏗️ Agent notes\n## What to build\n\nThe capture store and the envelope that sits in it — drivable end to end from tests with no model and no substrate, which is the whole point of the design. You can write a capture, correct it, contradict it, retract it, and read back a coherent history in which nothing was silently overwritten and every status was computed rather than stored.\n\nSpec: §5 (capture envelope), §5.1 (absence states), §6.2 (envelope-level validation), §8.3–8.5 (idempotence, supersession, resolution records), §9.6 (the storage port), §10 capability 10.\n\n## Acceptance criteria\n\n- [ ] The storage port is harness-defined and binding-implemented; nothing in the plugin surface can reach persistence\n- [ ] The envelope carries a harness-minted id alongside a content-derived dedup key that excludes epistemic status, so re-reading the same evidence differently requires explicit supersession\n- [ ] Value-XOR-absence is enforced as a refusal, and the six absence states are distinct capture values that never collapse into null or negation\n- [ ] Supersession is single-hop over active heads only; superseding an already-superseded capture is refused, and that refusal carries the world-moved facts\n- [ ] Superseded captures stay inspectable forever and never read as active\n- [ ] A `conflicting` issue closes only through a resolution record citing the true user's utterance; a bare close is refused, and so is a record citing the agent's words\n- [ ] Retraction is an explicit stored event citing the user, naming no successor, and is the only path to retracted status\n- [ ] No status field is stored anywhere — envelope status derives at read time from links, records, and events\n- [ ] Writes are serialized and application is whole-sweep-atomic: a sweep applies entirely or refuses entirely\n- [ ] Harness invariants 2, 4, 5, 7, 9, and 10 hold as executable tests\n+++",
+      "proposedBodySha256": "f0dc9265aa9d3f660adb48215dd7eb608e3f637540e58f568abeda7d2954fd41",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "ada53da7-e738-4cfe-9798-8d12aa650867",
+      "identifier": "FE-1391",
+      "url": "https://linear.app/hash/issue/FE-1391/durable-entry-projection-harness-resolved-anchoring-and-the-session",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-20T08:02:56.636Z",
+      "sourceTitle": "Durable entry projection, harness-resolved anchoring, and the session-log archive",
+      "sourceDescriptionSha256": "464a7faf1c52aa7bbc16b542aee5d1085fff78cd671575e61dd832e2ec6295d0",
+      "sourceTitleSha256": "64ec7826e8f32ec6ab84c8a8b36879fb5b9b6c7153d9f5ff3fca2616a42ff230",
+      "oldOuter": "",
+      "proposedTitle": "Resolve evidence quotes to durable conversation entries",
+      "proposedOuter": "Captures must cite durable user entries, but the model is reliable with verbatim quotes rather than entry numbers. This task will resolve each quote against true user entries, reject missing or invalid evidence, retain every read entry in the archive, and keep cited entries retrievable independently of runtime history retention.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe bridge between a live conversation and the store: given a session someone has actually talked into, the harness can take a verbatim quote and work out which entry it came from — and can keep those entries retrievable forever, independently of whatever the substrate decides to retain.\n\nThis exists because the model cannot be trusted with entry numbers and can be trusted with quotes. Ticket 13's HITL rounds on the prior map found the model's quotes flawless and its sequence guesses never once convergent, so anchoring is harness-resolved and entry identity never appears in the model-facing contract.\n\nSpec: §5 (evidence spans), §8.2 (harness-resolved anchoring), §9.4 (provenance), §9.6 (session-log archive), §10 capability 8.\n\n## Acceptance criteria\n\n- [ ] The binding can read the session's durable entry projection with provenance-discriminating entry kinds, absorbing the absence of an in-process API\n- [ ] A verbatim quote resolves to an entry pointer against true-user entries only; the stored span carries both excerpt and pointer, resolved exactly once at application time\n- [ ] No match refuses with a repair hint rather than guessing; multiple matches anchor the latest and attach an advisory note\n- [ ] Sequence numbers and range bounds appear nowhere in the model-facing tool contract\n- [ ] A capture citing an injected non-user entry is refused at validation\n- [ ] Archive-on-read holds: every entry the binding reads is retained in the target-document store, and every entry a capture points to is retrievable from the archive indefinitely\n- [ ] Base-URL discovery for the history projection is resolved rather than hardcoded, and paging behaviour beyond a thousand entries is either handled or explicitly bounded with a recorded finding",
+      "innerSha256": "464a7faf1c52aa7bbc16b542aee5d1085fff78cd671575e61dd832e2ec6295d0",
+      "proposedBody": "Captures must cite durable user entries, but the model is reliable with verbatim quotes rather than entry numbers. This task will resolve each quote against true user entries, reject missing or invalid evidence, retain every read entry in the archive, and keep cited entries retrievable independently of runtime history retention.\n\n+++🏗️ Agent notes\n## What to build\n\nThe bridge between a live conversation and the store: given a session someone has actually talked into, the harness can take a verbatim quote and work out which entry it came from — and can keep those entries retrievable forever, independently of whatever the substrate decides to retain.\n\nThis exists because the model cannot be trusted with entry numbers and can be trusted with quotes. Ticket 13's HITL rounds on the prior map found the model's quotes flawless and its sequence guesses never once convergent, so anchoring is harness-resolved and entry identity never appears in the model-facing contract.\n\nSpec: §5 (evidence spans), §8.2 (harness-resolved anchoring), §9.4 (provenance), §9.6 (session-log archive), §10 capability 8.\n\n## Acceptance criteria\n\n- [ ] The binding can read the session's durable entry projection with provenance-discriminating entry kinds, absorbing the absence of an in-process API\n- [ ] A verbatim quote resolves to an entry pointer against true-user entries only; the stored span carries both excerpt and pointer, resolved exactly once at application time\n- [ ] No match refuses with a repair hint rather than guessing; multiple matches anchor the latest and attach an advisory note\n- [ ] Sequence numbers and range bounds appear nowhere in the model-facing tool contract\n- [ ] A capture citing an injected non-user entry is refused at validation\n- [ ] Archive-on-read holds: every entry the binding reads is retained in the target-document store, and every entry a capture points to is retrievable from the archive indefinitely\n- [ ] Base-URL discovery for the history projection is resolved rather than hardcoded, and paging behaviour beyond a thousand entries is either handled or explicitly bounded with a recorded finding\n+++",
+      "proposedBodySha256": "aeedcc412dc46db7b394b87cbba8a15f97dbce6274debaf43903a3ebe2d76c9b",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "949f63b0-938f-4f2a-981e-909bf3d41af1",
+      "identifier": "FE-1392",
+      "url": "https://linear.app/hash/issue/FE-1392/settlement-trigger-and-sweep-the-first-captured-statement",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-20T08:02:56.825Z",
+      "sourceTitle": "Settlement trigger and sweep — the first captured statement",
+      "sourceDescriptionSha256": "7a58e8a4d7e8960c3b41b0b0a91396e7c14f002f3fbf68ec63aa3dfdc8e46b3b",
+      "sourceTitleSha256": "dc560fe9d1bf4ae882310eb8563baa90c49375e0ab8009a2069bddb5877fe98f",
+      "oldOuter": "",
+      "proposedTitle": "Capture settled conversation statements safely",
+      "proposedOuter": "The harness can ask questions but cannot yet turn a completed topic into stored meaning. This task will detect an unswept conversation range, let the agent judge whether it has settled, and store quote-anchored captures through an atomic operation that is safe to repeat. It will also preserve the high-water mark and report unanswered asks without blocking capture.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe slice the whole architecture is for. You say something in conversation; the agent judges that the topic has closed; it sweeps what you said into the store as captures anchored to your actual words; and the sweep is safe to run twice. After this ticket the system genuinely elicits — it just has nothing domain-shaped to do with the result yet.\n\nSpec: §8.1 (settlement trigger and judgment), §8.3 (sweep idempotence), §8.6 (unaccounted-ask advisory), §6.4 (cadence as policy), §10 capabilities 7 and 9.\n\n## Acceptance criteria\n\n- [ ] A conversation about something substantive produces captures in the store, each anchored to a verbatim quote from the person's own turns\n- [ ] Settlement decomposes into trigger and judgment: the harness computes the unswept tail and steers a settlement-check signal into a same-response continuation turn; the agent decides whether the range has settled, and declining is legal\n- [ ] The trigger's two guards hold — it fires on suspensions too, so a pending affordance suppresses the nudge; and it never re-nudges the same latest user entry\n- [ ] Re-sweeping a range creates no duplicate captures and does repair omissions, because identity is content-keyed rather than range-keyed — load-bearing under at-least-once tool re-execution\n- [ ] A sweep containing an ask with no reply and no capture citing it reports the fact as an advisory and blocks nothing\n- [ ] The swept high-water mark advances as per-session state and survives independently of the transcript\n- [ ] Running projection and validation at read time rather than at sweep completion changes no outcome",
+      "innerSha256": "7a58e8a4d7e8960c3b41b0b0a91396e7c14f002f3fbf68ec63aa3dfdc8e46b3b",
+      "proposedBody": "The harness can ask questions but cannot yet turn a completed topic into stored meaning. This task will detect an unswept conversation range, let the agent judge whether it has settled, and store quote-anchored captures through an atomic operation that is safe to repeat. It will also preserve the high-water mark and report unanswered asks without blocking capture.\n\n+++🏗️ Agent notes\n## What to build\n\nThe slice the whole architecture is for. You say something in conversation; the agent judges that the topic has closed; it sweeps what you said into the store as captures anchored to your actual words; and the sweep is safe to run twice. After this ticket the system genuinely elicits — it just has nothing domain-shaped to do with the result yet.\n\nSpec: §8.1 (settlement trigger and judgment), §8.3 (sweep idempotence), §8.6 (unaccounted-ask advisory), §6.4 (cadence as policy), §10 capabilities 7 and 9.\n\n## Acceptance criteria\n\n- [ ] A conversation about something substantive produces captures in the store, each anchored to a verbatim quote from the person's own turns\n- [ ] Settlement decomposes into trigger and judgment: the harness computes the unswept tail and steers a settlement-check signal into a same-response continuation turn; the agent decides whether the range has settled, and declining is legal\n- [ ] The trigger's two guards hold — it fires on suspensions too, so a pending affordance suppresses the nudge; and it never re-nudges the same latest user entry\n- [ ] Re-sweeping a range creates no duplicate captures and does repair omissions, because identity is content-keyed rather than range-keyed — load-bearing under at-least-once tool re-execution\n- [ ] A sweep containing an ask with no reply and no capture citing it reports the fact as an advisory and blocks nothing\n- [ ] The swept high-water mark advances as per-session state and survives independently of the transcript\n- [ ] Running projection and validation at read time rather than at sweep completion changes no outcome\n+++",
+      "proposedBodySha256": "54c4e793ce5850dd2d7fb2b40feec458ad06930eaf355ff29c9dedbebcaec22d",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "c0126528-3d55-4e1f-9ff1-baad5689c7ec",
+      "identifier": "FE-1393",
+      "url": "https://linear.app/hash/issue/FE-1393/plugin-sdk-and-the-gherkin-plugin-the-first-projected-artifact",
+      "state": {
+        "name": "Todo",
+        "type": "unstarted"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:25.951Z",
+      "sourceTitle": "Plugin SDK and the gherkin plugin — the first projected artifact",
+      "sourceDescriptionSha256": "eb4be2fba6a05bdbcdace930230c21ca24be097e2d707bcbf8441cebeb1367c8",
+      "sourceTitleSha256": "c19a8e89dc13b6eb7cf8b1e023e20a8f82ef1d254ab865caf2fdea5e2a463a3a",
+      "oldOuter": "",
+      "proposedTitle": "Produce the first Gherkin artifact through the plugin SDK",
+      "proposedOuter": "The first complete artifact should turn an interview about a feature into a valid Gherkin file and a typed report of information Gherkin cannot represent. This task will implement the pure plugin operations, injected harness context, authoring packs, validation, and failure atomicity needed for that path.\n\nThe SDK remains unstable until a harder second target tests the interface.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe first end-to-end artifact. Someone is interviewed about a feature and gets back a valid Gherkin feature file, together with an honest report of everything they said that the file could not represent. This is where the plugin contract stops being a design and starts being something a plugin author actually programs against.\n\n**Explicit non-goal: this ticket does not freeze the plugin contract.** Gherkin is the trivial target, and the spec's two-targets rule forbids letting it fix the interface before a hard target has stressed it. Build the SDK surface, exercise it, and leave it declared unstable.\n\nSpec: §6.1 (operations and calling convention), §4 (inversion of control, PluginContext), §11.1–11.3 (what a plugin owns, pack form, smallest honest plugin), §13.1 (gherkin).\n\n## Acceptance criteria\n\n- [ ] An interview about a feature yields a parse-valid `.feature` file plus a typed loss report using the declared vocabulary\n- [ ] The four operations are pure and snapshot-in/deltas-out: they receive an immutable snapshot and return observations, issues, and deltas; the harness validates and applies; no operation addresses storage, the user, or the model\n- [ ] Harness capabilities reach the plugin only through a narrow injected PluginContext, and milestone one defines no storage-addressable methods on it at all\n- [ ] The plugin ships an ElicitationPack — kernel cards, completion contract, clarification hints — and a ProjectionPack with required project and validate, authored to the `writing-for-agents` standard and Principle v2\n- [ ] Validation is parse validity plus an optional pack-declared step-lexicon check, needing no external project\n- [ ] Validators are total: they never throw, and always return typed issues\n- [ ] Issues are namespaced to their producer, so a target-originated requirement never silently reads as a harness-level one\n- [ ] A failed operation leaves no partially applied deltas\n- [ ] The smallest-honest-plugin bar is checked, not assumed: a flat record list plus one validator must suffice, and every contract addition made here is justified against the bar it raises\n- [ ] The SDK export surface is documented as unstable pending a second target",
+      "innerSha256": "eb4be2fba6a05bdbcdace930230c21ca24be097e2d707bcbf8441cebeb1367c8",
+      "proposedBody": "The first complete artifact should turn an interview about a feature into a valid Gherkin file and a typed report of information Gherkin cannot represent. This task will implement the pure plugin operations, injected harness context, authoring packs, validation, and failure atomicity needed for that path.\n\nThe SDK remains unstable until a harder second target tests the interface.\n\n+++🏗️ Agent notes\n## What to build\n\nThe first end-to-end artifact. Someone is interviewed about a feature and gets back a valid Gherkin feature file, together with an honest report of everything they said that the file could not represent. This is where the plugin contract stops being a design and starts being something a plugin author actually programs against.\n\n**Explicit non-goal: this ticket does not freeze the plugin contract.** Gherkin is the trivial target, and the spec's two-targets rule forbids letting it fix the interface before a hard target has stressed it. Build the SDK surface, exercise it, and leave it declared unstable.\n\nSpec: §6.1 (operations and calling convention), §4 (inversion of control, PluginContext), §11.1–11.3 (what a plugin owns, pack form, smallest honest plugin), §13.1 (gherkin).\n\n## Acceptance criteria\n\n- [ ] An interview about a feature yields a parse-valid `.feature` file plus a typed loss report using the declared vocabulary\n- [ ] The four operations are pure and snapshot-in/deltas-out: they receive an immutable snapshot and return observations, issues, and deltas; the harness validates and applies; no operation addresses storage, the user, or the model\n- [ ] Harness capabilities reach the plugin only through a narrow injected PluginContext, and milestone one defines no storage-addressable methods on it at all\n- [ ] The plugin ships an ElicitationPack — kernel cards, completion contract, clarification hints — and a ProjectionPack with required project and validate, authored to the `writing-for-agents` standard and Principle v2\n- [ ] Validation is parse validity plus an optional pack-declared step-lexicon check, needing no external project\n- [ ] Validators are total: they never throw, and always return typed issues\n- [ ] Issues are namespaced to their producer, so a target-originated requirement never silently reads as a harness-level one\n- [ ] A failed operation leaves no partially applied deltas\n- [ ] The smallest-honest-plugin bar is checked, not assumed: a flat record list plus one validator must suffice, and every contract addition made here is justified against the bar it raises\n- [ ] The SDK export surface is documented as unstable pending a second target\n+++",
+      "proposedBodySha256": "f6f67f0efd78658558aef82cc28f25b8b515941ec928ca56ca5dd72bf10cf9db",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "8c23b17b-b220-4879-959c-ed759084f158",
+      "identifier": "FE-1394",
+      "url": "https://linear.app/hash/issue/FE-1394/conflict-supersession-and-the-interpretation-render",
+      "state": {
+        "name": "Todo",
+        "type": "unstarted"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.378Z",
+      "sourceTitle": "Conflict, supersession, and the interpretation render",
+      "sourceDescriptionSha256": "59342c6a55a213c528d8566c757ac6a85af9a08819e19af57664798e93b8d2ef",
+      "sourceTitleSha256": "300684bbdff69dcc7f9ee11eb17102a826a7e24bfd5cc9b47d7c2cc6fa5c6693",
+      "oldOuter": "",
+      "proposedTitle": "Preserve conflicts until the user resolves them",
+      "proposedOuter": "When a person contradicts an earlier statement, both interpretations must remain visible until the person resolves the conflict. This task will store the alternatives and resolution evidence, distinguish correction paths, and render the harness's interpretation with uncertainty intact. It will also keep interactive questions separate from informational renders and distinguish answered, redirected, and unanswered outcomes.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nWhat happens when someone changes their mind or contradicts themselves. Say something, say something incompatible later, and both readings stay live and visible until you explicitly settle which one holds — the system never quietly picks. Alongside it, the one affordance the harness must own itself: the render that shows you what it thinks you said, with the uncertainty intact.\n\nSpec: §6.3 (issues versus advisories), §7.5 (transport outcomes), §7.6 (interpretation render), §8.4–8.5 (supersession channels, resolution records).\n\n## Acceptance criteria\n\n- [ ] Contradicting yourself surfaces a `conflicting` issue with both interpretations live as alternatives, and neither is silently dropped\n- [ ] Resolving it produces a resolution record citing your own words; the winning capture keeps its original epistemic status and authority lives in the record\n- [ ] The two supersession channels are distinguishable in the store: a creation-time link for sweep-time correction, a resolution record for issue-time adjudication between existing alternatives\n- [ ] The interpretation render is harness-owned and shows envelope vocabulary — epistemic status, absence states, live alternatives, derived status — with a plain JSON default and a plugin-optional typed renderer seam that is actually exercised by the gherkin plugin\n- [ ] Non-interactive renders ride their own tool output parts and never contend for the affordance slot, so an ask and a render in one batch cannot clobber each other\n- [ ] Transport outcomes record as answered, redirected, or unanswered, distinct from epistemic absence; a topic change mid-question reads as redirected\n- [ ] Advisories are computed and ephemeral — never stored, never blocking — and issues are stored and close only explicitly\n- [ ] Harness invariants 1, 2, and 6 hold as executable tests",
+      "innerSha256": "59342c6a55a213c528d8566c757ac6a85af9a08819e19af57664798e93b8d2ef",
+      "proposedBody": "When a person contradicts an earlier statement, both interpretations must remain visible until the person resolves the conflict. This task will store the alternatives and resolution evidence, distinguish correction paths, and render the harness's interpretation with uncertainty intact. It will also keep interactive questions separate from informational renders and distinguish answered, redirected, and unanswered outcomes.\n\n+++🏗️ Agent notes\n## What to build\n\nWhat happens when someone changes their mind or contradicts themselves. Say something, say something incompatible later, and both readings stay live and visible until you explicitly settle which one holds — the system never quietly picks. Alongside it, the one affordance the harness must own itself: the render that shows you what it thinks you said, with the uncertainty intact.\n\nSpec: §6.3 (issues versus advisories), §7.5 (transport outcomes), §7.6 (interpretation render), §8.4–8.5 (supersession channels, resolution records).\n\n## Acceptance criteria\n\n- [ ] Contradicting yourself surfaces a `conflicting` issue with both interpretations live as alternatives, and neither is silently dropped\n- [ ] Resolving it produces a resolution record citing your own words; the winning capture keeps its original epistemic status and authority lives in the record\n- [ ] The two supersession channels are distinguishable in the store: a creation-time link for sweep-time correction, a resolution record for issue-time adjudication between existing alternatives\n- [ ] The interpretation render is harness-owned and shows envelope vocabulary — epistemic status, absence states, live alternatives, derived status — with a plain JSON default and a plugin-optional typed renderer seam that is actually exercised by the gherkin plugin\n- [ ] Non-interactive renders ride their own tool output parts and never contend for the affordance slot, so an ask and a render in one batch cannot clobber each other\n- [ ] Transport outcomes record as answered, redirected, or unanswered, distinct from epistemic absence; a topic change mid-question reads as redirected\n- [ ] Advisories are computed and ephemeral — never stored, never blocking — and issues are stored and close only explicitly\n- [ ] Harness invariants 1, 2, and 6 hold as executable tests\n+++",
+      "proposedBodySha256": "a6a5b27cfa217b16df8239bc9f3383ce5fdf8b8f42957f4ad47b9f01de7e7fc4",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "b81c6610-f6fd-4669-bbf3-ed6b62696394",
+      "identifier": "FE-1395",
+      "url": "https://linear.app/hash/issue/FE-1395/the-full-affordance-set-choices-questionnaire-chaining-and-the-absence",
+      "state": {
+        "name": "Todo",
+        "type": "unstarted"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.675Z",
+      "sourceTitle": "The full affordance set — choices, questionnaire chaining, and the absence strip",
+      "sourceDescriptionSha256": "2a5426c3cda4bfd5d3b5e7451880acfb2000efd8f906ae9512651fa23aa94d01",
+      "sourceTitleSha256": "3c8ed19b489983343fae2ea6dcbced4c87330e476f984fb75fa9937fb1974f67",
+      "oldOuter": "",
+      "proposedTitle": "Add choices, questionnaires, and explicit absence replies",
+      "proposedOuter": "The harness currently has only free-text questions. This task will add single-choice, multi-choice, and locally chained questionnaires, plus explicit replies for unknown, inapplicable, and deferred answers.\n\nBecause inbound replies are strings, the transport must distinguish a UI action from identical typed prose; clients that only render markdown will continue to produce honestly inferred absences.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nThe rest of the ways the harness can ask something. Beyond free text: pick one, pick several, and a questionnaire that walks several questions locally without a model turn between them. Plus the absence strip — the one-tap way to say \"I don't know\", \"doesn't apply\", or \"decide later\" — and the transport mechanism that makes a tap genuinely distinguishable from typed prose.\n\nThat last part is load-bearing and easy to get wrong. Inbound replies are string-only, so a bare string cannot tell a one-tap \"not applicable\" from someone typing the words. Tap-ness has to be a transport fact or the system will claim certainty it hasn't earned.\n\nSpec: §7.2 (baseline forms, questionnaire chaining, markdown floor), §5.1 (absence states, reserved reply encoding), §7.7 (recorded transport facts).\n\n## Acceptance criteria\n\n- [ ] Single-choice and multi-choice questions work end to end, rendering and returning through the same evidence path as free text\n- [ ] A questionnaire is one affordance with N steps: the payload carries all the questions, the ui walks them locally, answers return individually or batched, and no intermediate model turns occur\n- [ ] The absence strip's three labels map onto their absence states, and absences land as first-class capture values\n- [ ] A reply parsing as the reserved encoding, arriving while its affordance is pending, is transport-explicit; every other reply is conversational and yields absences marked inferred\n- [ ] Structured taps are optional for a ui, not required: a ui affording only the markdown floor produces no encoding and honestly yields inferred-only absences\n- [ ] Plugin custom forms register as progressive enhancement keyed on form tag, with payloads opaque at the tool boundary and validated harness-side against plugin declarations on read-back\n- [ ] Every form carries a markdown floor\n- [ ] Deferred and declined behave differently downstream: completion evaluation chases a deferral and treats a decline as a boundary that only an explicit act can close",
+      "innerSha256": "2a5426c3cda4bfd5d3b5e7451880acfb2000efd8f906ae9512651fa23aa94d01",
+      "proposedBody": "The harness currently has only free-text questions. This task will add single-choice, multi-choice, and locally chained questionnaires, plus explicit replies for unknown, inapplicable, and deferred answers.\n\nBecause inbound replies are strings, the transport must distinguish a UI action from identical typed prose; clients that only render markdown will continue to produce honestly inferred absences.\n\n+++🏗️ Agent notes\n## What to build\n\nThe rest of the ways the harness can ask something. Beyond free text: pick one, pick several, and a questionnaire that walks several questions locally without a model turn between them. Plus the absence strip — the one-tap way to say \"I don't know\", \"doesn't apply\", or \"decide later\" — and the transport mechanism that makes a tap genuinely distinguishable from typed prose.\n\nThat last part is load-bearing and easy to get wrong. Inbound replies are string-only, so a bare string cannot tell a one-tap \"not applicable\" from someone typing the words. Tap-ness has to be a transport fact or the system will claim certainty it hasn't earned.\n\nSpec: §7.2 (baseline forms, questionnaire chaining, markdown floor), §5.1 (absence states, reserved reply encoding), §7.7 (recorded transport facts).\n\n## Acceptance criteria\n\n- [ ] Single-choice and multi-choice questions work end to end, rendering and returning through the same evidence path as free text\n- [ ] A questionnaire is one affordance with N steps: the payload carries all the questions, the ui walks them locally, answers return individually or batched, and no intermediate model turns occur\n- [ ] The absence strip's three labels map onto their absence states, and absences land as first-class capture values\n- [ ] A reply parsing as the reserved encoding, arriving while its affordance is pending, is transport-explicit; every other reply is conversational and yields absences marked inferred\n- [ ] Structured taps are optional for a ui, not required: a ui affording only the markdown floor produces no encoding and honestly yields inferred-only absences\n- [ ] Plugin custom forms register as progressive enhancement keyed on form tag, with payloads opaque at the tool boundary and validated harness-side against plugin declarations on read-back\n- [ ] Every form carries a markdown floor\n- [ ] Deferred and declined behave differently downstream: completion evaluation chases a deferral and treats a decline as a boundary that only an explicit act can close\n+++",
+      "proposedBodySha256": "07e67eccc99d2e90e1f9951c405eb487c11b187f28cc1252b81ebadeab545b76",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "759b76d1-bb18-4159-acea-61a478f4139f",
+      "identifier": "FE-1396",
+      "url": "https://linear.app/hash/issue/FE-1396/re-entry-briefing-resume-reconciliation-and-restart-durability",
+      "state": {
+        "name": "Todo",
+        "type": "unstarted"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:25.918Z",
+      "sourceTitle": "Re-entry briefing, resume reconciliation, and restart durability",
+      "sourceDescriptionSha256": "a107fcbcc646a6054c66bd208141252bda7298308546c689e1fcf9d0ff79d797",
+      "sourceTitleSha256": "81da9d71280d7fa1fd21ba19d101e1cd02d113fd2e626f425d50ea302efe93f8",
+      "oldOuter": "",
+      "proposedTitle": "Restore interview context after resume and restart",
+      "proposedOuter": "A returning interview must reflect captures, conflicts, unswept conversation, and a pending question that changed while the agent was away. This task will compute and inject that briefing, preserve all session state through restart, and prevent injected system facts from being cited as user evidence. Completion remains derived when reading, so a later correction follows the normal path.",
+      "extractionMethod": "heading-first-whole-body-as-inner",
+      "innerRecord": "## What to build\n\nComing back. Quit an interview halfway, restart the process, return later, and the agent picks up knowing what changed while it was away — what was captured or superseded, which issues opened or closed, what was left unswept, and which question is still hanging. It says so in the conversation rather than pretending continuity.\n\nThe subtle requirement is that the briefing must be in the log honestly without ever becoming evidence. It is injected on the user's behalf, so it looks like the user's side of the conversation — and a capture citing it would launder the system's own words into the person's mouth.\n\nSpec: §9.1–9.3 (durable document, per-session state, re-entry briefing), §9.4 (provenance), §9.5 (completion derived), §8.7 (resume-time sweep reconciliation), §14.5 (restart durability).\n\n## Acceptance criteria\n\n- [ ] Resuming a session after the world moved injects a state message whose content is computed facts only: unswept tail, captures created or superseded and issues opened or closed since this session last swept, open issues, pending unanswered affordance\n- [ ] The briefing is advisory — it forces nothing, and the agent weighs it\n- [ ] A minimal user-visible insertion notice accompanies every injected state message\n- [ ] Injected entries project as structurally non-user, so citing one as evidence is mechanically refused rather than merely discouraged\n- [ ] An unswept tail left by a session that ended between judgment and sweep surfaces on resume, and the agent judges whether to sweep before proceeding\n- [ ] The briefing works in all three shapes: fresh session, resumed session, and post-restart\n- [ ] Full-stack durability holds with a real conversation store: captures, session logs, high-water mark, and pending slot all survive a process restart\n- [ ] A new session binds to its target-document through immutable creation data; dispatching an existing conversation id resumes against the document's current state\n- [ ] Completion is a read-time derived status with no lock and no terminal state — someone returning with a correction after \"done\" is handled normally",
+      "innerSha256": "a107fcbcc646a6054c66bd208141252bda7298308546c689e1fcf9d0ff79d797",
+      "proposedBody": "A returning interview must reflect captures, conflicts, unswept conversation, and a pending question that changed while the agent was away. This task will compute and inject that briefing, preserve all session state through restart, and prevent injected system facts from being cited as user evidence. Completion remains derived when reading, so a later correction follows the normal path.\n\n+++🏗️ Agent notes\n## What to build\n\nComing back. Quit an interview halfway, restart the process, return later, and the agent picks up knowing what changed while it was away — what was captured or superseded, which issues opened or closed, what was left unswept, and which question is still hanging. It says so in the conversation rather than pretending continuity.\n\nThe subtle requirement is that the briefing must be in the log honestly without ever becoming evidence. It is injected on the user's behalf, so it looks like the user's side of the conversation — and a capture citing it would launder the system's own words into the person's mouth.\n\nSpec: §9.1–9.3 (durable document, per-session state, re-entry briefing), §9.4 (provenance), §9.5 (completion derived), §8.7 (resume-time sweep reconciliation), §14.5 (restart durability).\n\n## Acceptance criteria\n\n- [ ] Resuming a session after the world moved injects a state message whose content is computed facts only: unswept tail, captures created or superseded and issues opened or closed since this session last swept, open issues, pending unanswered affordance\n- [ ] The briefing is advisory — it forces nothing, and the agent weighs it\n- [ ] A minimal user-visible insertion notice accompanies every injected state message\n- [ ] Injected entries project as structurally non-user, so citing one as evidence is mechanically refused rather than merely discouraged\n- [ ] An unswept tail left by a session that ended between judgment and sweep surfaces on resume, and the agent judges whether to sweep before proceeding\n- [ ] The briefing works in all three shapes: fresh session, resumed session, and post-restart\n- [ ] Full-stack durability holds with a real conversation store: captures, session logs, high-water mark, and pending slot all survive a process restart\n- [ ] A new session binds to its target-document through immutable creation data; dispatching an existing conversation id resumes against the document's current state\n- [ ] Completion is a read-time derived status with no lock and no terminal state — someone returning with a correction after \"done\" is handled normally\n+++",
+      "proposedBodySha256": "0c94f9741b654e832cafa85eb2b27193a0a91a29d588f8873699c6630477af43",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "92c6f2e4-11eb-42e7-b3aa-4327a9a2e405",
+      "identifier": "FE-1399",
+      "url": "https://linear.app/hash/issue/FE-1399/make-the-ci-gates-and-dev-app-fail-loudly-where-review-found-they-fail",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.590Z",
+      "sourceTitle": "Make the CI gates and dev app fail loudly where review found they fail silently",
+      "sourceDescriptionSha256": "6b0a691af9b858b532b0ac30b62f352fcf19afc87071534e5f6ea25b13cc6379",
+      "sourceTitleSha256": "2dccdd3bedc0bb7b28b086c4a1c0c8da6c68a894767abe0713ba8b3550a581d7",
+      "oldOuter": "The FE-1361 code review swept the whole repo and verified five findings that fall outside that ticket's scope. Three sit in the merge gates themselves: the checks that are supposed to keep workspace boundaries honest can currently go red on an innocent comment-only edit, silently skip any newly added workspace group, and let a misspelled tool operation name compile — so the gates either cry wolf or pass vacuously, which matters most in a repo whose gates are its main safety net. The other two are silent-failure seams in the dev app: a route path duplicates the one identifier the codebase pins as never-drifting, and the production asset route serves a narrower set of files than the client build can emit, so the first added font or image would break production only. All five have verified failure scenarios; each fix is small and none blocks current work.",
+      "proposedTitle": "Fix verified silent failures in CI and the dev app",
+      "proposedOuter": "The FE-1361 review confirmed five small failures outside that issue's scope. Three CI checks can reject harmless text, omit new workspace groups, or accept misspelled tool operations; two dev-app routes duplicate a pinned identifier or fail on asset types the client build may emit.\n\nThis task will make those checks and routes report the verified failures without changing unrelated behavior; none currently blocks other work.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Findings (verified by the FE-1361 review, 2026-08-13)\n\n1. `test/boundaries.test.ts:218` — agent-module detection is a bare substring match for `'use agent'` over raw file text, so a comment mentioning the directive turns any dev source file into an \"agent module\" and fails two assertions (CI red on a comment-only change; `test/build-artifact.test.ts:44` shares the filter). Fix: anchor detection to the first statement — the comment-stripping logic at lines 231–233 already exists.\n2. `test/workspace.ts:49` — `workspacePackages()` hardcodes `[packages, apps]` instead of deriving from (or asserting agreement with) root `package.json`'s `workspaces` globs, so a new workspace group escapes every boundary invariant as a vacuous pass; `directoriesIn()` also returns `[]` for a missing parent, so a renamed group degrades silently. Fix: assert the hardcoded group set equals the workspaces globs.\n3. `packages/core/src/naming.ts:60` — `toolName(operation)` takes plain `string` instead of the `Operation` union exported two lines above (the union has zero consumers), so `toolName('aks')` compiles and ships a misnamed model-facing tool. Fix: narrow the parameter type.\n4. `apps/dev/src/app.ts:19` — the mount path hardcodes `'brunch-gherkin-elicitor'` although `GherkinElicitor.agentName` is imported in the same file; a copy-pasted second agent would shadow the mount while tests stay green. Fix: `` app.route(`/agents/${GherkinElicitor.agentName}`, …) ``.\n5. `apps/dev/src/app.ts:36` — the production `/assets/:file` route allowlists only `.js|.css|.map` and reads hits as UTF-8, so any other emitted asset 404s in production (works in vite dev), and extending the allowlist without switching to a Buffer read would corrupt binary bytes.\n\nFull verdicts and failure scenarios are in the FE-1361 review record; the two findings that touched FE-1361's own files (typecheck-gate coverage, migrated-doc links) were fixed on its branch and are not part of this ticket.",
+      "innerSha256": "e7bbd746c9bcb2d4c9922968d638266edff9b833de4e22b655d8ac0ee22f3456",
+      "proposedBody": "The FE-1361 review confirmed five small failures outside that issue's scope. Three CI checks can reject harmless text, omit new workspace groups, or accept misspelled tool operations; two dev-app routes duplicate a pinned identifier or fail on asset types the client build may emit.\n\nThis task will make those checks and routes report the verified failures without changing unrelated behavior; none currently blocks other work.\n\n+++🏗️ Agent notes\n## Findings (verified by the FE-1361 review, 2026-08-13)\n\n1. `test/boundaries.test.ts:218` — agent-module detection is a bare substring match for `'use agent'` over raw file text, so a comment mentioning the directive turns any dev source file into an \"agent module\" and fails two assertions (CI red on a comment-only change; `test/build-artifact.test.ts:44` shares the filter). Fix: anchor detection to the first statement — the comment-stripping logic at lines 231–233 already exists.\n2. `test/workspace.ts:49` — `workspacePackages()` hardcodes `[packages, apps]` instead of deriving from (or asserting agreement with) root `package.json`'s `workspaces` globs, so a new workspace group escapes every boundary invariant as a vacuous pass; `directoriesIn()` also returns `[]` for a missing parent, so a renamed group degrades silently. Fix: assert the hardcoded group set equals the workspaces globs.\n3. `packages/core/src/naming.ts:60` — `toolName(operation)` takes plain `string` instead of the `Operation` union exported two lines above (the union has zero consumers), so `toolName('aks')` compiles and ships a misnamed model-facing tool. Fix: narrow the parameter type.\n4. `apps/dev/src/app.ts:19` — the mount path hardcodes `'brunch-gherkin-elicitor'` although `GherkinElicitor.agentName` is imported in the same file; a copy-pasted second agent would shadow the mount while tests stay green. Fix: `` app.route(`/agents/${GherkinElicitor.agentName}`, …) ``.\n5. `apps/dev/src/app.ts:36` — the production `/assets/:file` route allowlists only `.js|.css|.map` and reads hits as UTF-8, so any other emitted asset 404s in production (works in vite dev), and extending the allowlist without switching to a Buffer read would corrupt binary bytes.\n\nFull verdicts and failure scenarios are in the FE-1361 review record; the two findings that touched FE-1361's own files (typecheck-gate coverage, migrated-doc links) were fixed on its branch and are not part of this ticket.\n+++",
+      "proposedBodySha256": "6f61e0111c600a72b881095599a12642ed57f332b979714194258f12796ce758",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "8605481d-96b5-4ada-8b7c-5b40cc78d560",
+      "identifier": "FE-1400",
+      "url": "https://linear.app/hash/issue/FE-1400/close-the-review-found-gaps-where-the-gates-dev-app-and-baseline",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.709Z",
+      "sourceTitle": "Close the review-found gaps where the gates, dev app, and baseline runner still fail silently",
+      "sourceDescriptionSha256": "ea04928499443681cda2c797a268fe7c62b970dacb49d787ada0a84d2e516257",
+      "sourceTitleSha256": "4e4a7a42972cd87205b806f4c89d7ba44e0ab2ddb6efa1abbab18de34022ed39",
+      "oldOuter": "During the FE-1397 tie-off, a full adversarially-verified review of the branch stack's diff against main surfaced ten confirmed correctness findings plus a handful of cleanups — none in the FE-1397 docs themselves, all in earlier branches' work. The common thread is uncomfortable: several of the checks FE-1399 added *to make silent failures loud* can themselves pass vacuously (a build-artifact witness matched by bootstrap code regardless of what got bundled, nested `test/` directories escaping every boundary invariant, a CI-gate check satisfied by commented-out gates, known-gap predicates that an empty stub file flips). Alongside those: the dev app's durable conversation store resolves its default path against the launch directory — the exact restart-durability failure the file's own comment says it exists to prevent — and the baseline runner can silently drop or truncate its main deliverable and dies on a single network blip hours into a paid run. The always-loaded agent instructions also still describe the triage roles as five verbatim labels, contradicting the rewritten triage doc's state/label mapping.\n\nThis ticket bundles all fixes as one refactor, executed as small always-green commits: documentation truth first, then the test-integrity fixes (each proven by temporarily breaking the guarded property and watching the gate go red), then the one behavioral dev-app fix, then baseline-runner robustness, then the cleanup tail. Filed from the FE-1397 thread's review output; to be claimed and run in a follow-up session.",
+      "proposedTitle": "Strengthen verification, dev storage, and the baseline runner",
+      "proposedOuter": "The FE-1397 review confirmed ten correctness problems and several smaller cleanups in earlier branches. Verification checks can pass without testing the claimed property, the dev store can appear empty after launch from another directory, and the baseline runner can omit or truncate its artifact or stop after a transient network failure. The always-loaded triage guidance also contradicts the current state-and-label mapping.\n\nThis task will fix those areas through small green commits, proving each strengthened check by making the guarded property fail temporarily. The official Anthropic SDK is preferred for runner retries and usage accounting, but a local retry implementation remains an acceptable fallback if the dependency is rejected.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Commits (ordered by safety; each leaves the codebase green)\n\n 1. Align the always-loaded agent instructions' triage one-liner with the triage doc's actual state/label mapping (only three roles remain labels; `needs-triage` and `wontfix` are workflow states).\n 2. Replace the vacuous build-artifact witnesses with strings that only survive if the agent mount and the conversation-store module actually reached the bundle.\n 3. Make the boundaries suite's first-statement check accept every directive form the workspace lexicon already declares legal, by reusing the shared directive pattern instead of a literal comparison; fold in the dedup of the pinned-identity and model-key regexes duplicated across the two suites.\n 4. Make the workspace walker's source/test partition total: a file in a nested test directory is either governed by the test-hermeticity rules or included as source — nothing falls through silently. Red-proof with a fixture that previously escaped.\n 5. Strengthen the CI-gate check to match against comment-stripped (or parsed) workflow steps so a disabled gate reads as absent.\n 6. Re-encode the known-gaps predicates as \"the verification actually runs\" (content/execution checks) instead of \"a file with this exact name exists\", in both directions (stub files must not close a gap; differently-named real closures must).\n 7. Anchor the dev app's default SQLite path to the module location instead of the working directory, mirroring how the UI root is already anchored; add a test asserting launch-directory independence.\n 8. Baseline runner: widen code-fence matching (case, trailing space, digits/hyphens, CRLF) and warn loudly when no model artifact could be extracted despite a \"delivered\" verdict.\n 9. Baseline runner: propagate the truncation flag through continuation stitching so an incomplete final delivery is marked incomplete and the operator is told the escape hatch exists.\n10. Baseline runner: retry network-level failures and honor retry-after — preferably by replacing the hand-rolled HTTP client with the official Anthropic SDK, which also fixes the undercounted cache-token usage.\n11. Cleanup tail, split as convenient: serve dev static assets via the framework's nested-path-capable routing and importable MIME table; un-hard-code the root build script's single-app filter; stop building the app twice per CI run and cache dependencies; remove the baseline runner's parallel message array and dead field; derive the boundary suite's package list instead of hard-coding it.\n\n## Findings inventory (verified evidence; paths current as of the FE-1397 stack tip)\n\n| # | Where | Finding |\n| -- | -- | -- |\n| 1 | `test/build-artifact.test.ts:82` | `toContain('createAgentRouter')` matches a preserved bootstrap JSDoc comment and `toContain('sqlite')` matches the bootstrap's unconditional default-adapter import — the test passes even if `app.ts`'s mount or `src/db.ts` never reach the build. Robust witnesses exist: the `app.route(...)` mount string and the `BRUNCH_DEV_DB_PATH`/`.data-wipe-me` strings unique to `db.ts`. |\n| 2 | `test/workspace.ts:149` (with `:128`) | `sourceFiles()` prunes `test`/`tests`/`__tests__` at any depth while `testFiles()` only collects top-level test dirs — production code under e.g. `src/test/` escapes the substrate-import ban, schema-library check, and identity-duplication scan, and isn't governed by test-hermeticity either. |\n| 3 | `apps/dev/src/db.ts:17` | Default store path `./.data-wipe-me/conversations.db` is cwd-relative; launching from a different directory silently creates a fresh empty DB. Anchor via `import.meta.url` as `app.ts` does for `uiRoot`. |\n| 4 | `test/boundaries.test.ts:239` | First-statement check requires the literal `'use agent';` exactly, while `workspace.ts`'s `AGENT_DIRECTIVE_STATEMENT` (line 168) accepts both quote styles, optional semicolon, and trailing comments — forms the suite's own fixtures assert are legal fail spuriously. |\n| 5 | `docs/planning/process-model-elicitation/baseline/run.ts:213` | `largestCodeBlock`'s fence regex ```` /```[a-z]*\\n/ ```` misses ```` ```JSON ````, trailing-space, digit/hyphen info strings, and CRLF — `writeArtifacts` (line 294) then skips the model artifact with no warning while the transcript header says delivered. |\n| 6 | `run.ts:165` | Continuation stitching caps at 4 pieces and discards `result.truncated` — a still-truncated final delivery is written as complete; nothing tells the operator `--continue-final` was needed. |\n| 7 | `run.ts:111` | Only HTTP 429/5xx are retried; a rejected `fetch` (TCP reset, DNS blip) crashes the run. Fixed `attempt*15s` backoff ignores `retry-after`. The hand-typed `ApiResponse` omits cache-token usage fields, undercounting cost. The official SDK replaces all of it. |\n| 8 | `test/boundaries.test.ts:323` | CI-gate check is `workflow.includes(gate)` over raw YAML text — a commented-out or `if: false` gate still passes. |\n| 9 | `test/known-gaps.ts:54` | Every `closed()` predicate is `existsSync` on one speculative future path: a real closure under another name stays \"open\" forever (banner rot), while `touch`ing the expected path closes the gap with nothing verified. |\n| 10 | `AGENTS.md:19` (mirrored via `CLAUDE.md` symlink) | Says the five triage roles are \"used verbatim as their own label strings\"; `docs/agents/triage-labels.md` now maps `needs-triage` → state **Triage** and `wontfix` → state **Canceled**, leaving only three as labels. |\n\nCleanup tail (verified, lower stakes): `apps/dev/src/assets.ts` hand-rolled `:file` route can't match nested paths and duplicates hono's importable `getMimeType`; root `package.json` build script hard-codes `--filter '@brunch/dev'`; the full app build runs twice per CI run (build-artifact `beforeAll` + dedicated Build step) with no bun dependency cache; `run.ts` carries an `expertMessages` parallel array and a dead `interviewerTurns` field; `boundaries.test.ts` hard-codes the four-package list and two-scope substrate denylist.\n\n## Decision document\n\n* Modules touched: the repo-level verification suites (`test/`), the dev app's store and asset serving, the baseline runner script, the always-loaded agent instructions.\n* No interface or schema changes; no production API surface exists yet. The one behavioral change visible outside tests is the dev store's default path resolution (env var override unchanged).\n* Architectural stance: gate fixes must encode the *property*, not a proxy (witness strings unique to the guarded module; parsed rather than substring-matched workflow; executed-verification rather than file-existence). This is the FE-1399 charter applied to FE-1399's own checks.\n* Baseline runner: prefer deleting the hand-rolled client in favor of the official SDK over patching it — fewer lines, retry/retry-after/typed usage for free. If the SDK dependency is unwanted in a planning script, the fallback is try/catch around fetch + retry-after parsing.\n\n## Testing decisions\n\n* Most of this work *is* the test layer, so the discipline is red-proofs: for each strengthened gate, temporarily introduce the violation it exists to catch (nested `src/test/` file importing the substrate; commented-out CI gate; stub gap file; missing db.ts in the bundle) and watch it fail before restoring green.\n* The dev store path fix gets a unit test asserting the resolved path is launch-directory-independent; prior art in `apps/dev/test/assets.test.ts`.\n* The baseline runner sits behind the typecheck gate only (FE-1361); extract its parsing helpers (`largestCodeBlock`, stitching) into testable pure functions if a red-proof is wanted, otherwise verify by targeted invocation — a full paid run is not required to exercise fence parsing.\n\n## Out of scope\n\n* The FE-1397 worked-examples docs and `ir-design.md` (no findings there).\n* Redesigning the known-gaps mechanism itself — only the predicate strength changes.\n* Anything inside `@flue/*` bootstrap behavior (the vacuous witnesses are our tests' problem, not Flue's).\n* The refuted review candidates (resume double-count, sequential awaits, symlink-cycle walker, dev HMR gap, stale map pointer) — checked and dismissed, listed here so they aren't re-litigated.",
+      "innerSha256": "aa47cdaca48abf4436fbda2ab03d226e6c93c97f1dc3d4ee6bf0e1ad66e92f29",
+      "proposedBody": "The FE-1397 review confirmed ten correctness problems and several smaller cleanups in earlier branches. Verification checks can pass without testing the claimed property, the dev store can appear empty after launch from another directory, and the baseline runner can omit or truncate its artifact or stop after a transient network failure. The always-loaded triage guidance also contradicts the current state-and-label mapping.\n\nThis task will fix those areas through small green commits, proving each strengthened check by making the guarded property fail temporarily. The official Anthropic SDK is preferred for runner retries and usage accounting, but a local retry implementation remains an acceptable fallback if the dependency is rejected.\n\n+++🏗️ Agent notes\n## Commits (ordered by safety; each leaves the codebase green)\n\n 1. Align the always-loaded agent instructions' triage one-liner with the triage doc's actual state/label mapping (only three roles remain labels; `needs-triage` and `wontfix` are workflow states).\n 2. Replace the vacuous build-artifact witnesses with strings that only survive if the agent mount and the conversation-store module actually reached the bundle.\n 3. Make the boundaries suite's first-statement check accept every directive form the workspace lexicon already declares legal, by reusing the shared directive pattern instead of a literal comparison; fold in the dedup of the pinned-identity and model-key regexes duplicated across the two suites.\n 4. Make the workspace walker's source/test partition total: a file in a nested test directory is either governed by the test-hermeticity rules or included as source — nothing falls through silently. Red-proof with a fixture that previously escaped.\n 5. Strengthen the CI-gate check to match against comment-stripped (or parsed) workflow steps so a disabled gate reads as absent.\n 6. Re-encode the known-gaps predicates as \"the verification actually runs\" (content/execution checks) instead of \"a file with this exact name exists\", in both directions (stub files must not close a gap; differently-named real closures must).\n 7. Anchor the dev app's default SQLite path to the module location instead of the working directory, mirroring how the UI root is already anchored; add a test asserting launch-directory independence.\n 8. Baseline runner: widen code-fence matching (case, trailing space, digits/hyphens, CRLF) and warn loudly when no model artifact could be extracted despite a \"delivered\" verdict.\n 9. Baseline runner: propagate the truncation flag through continuation stitching so an incomplete final delivery is marked incomplete and the operator is told the escape hatch exists.\n10. Baseline runner: retry network-level failures and honor retry-after — preferably by replacing the hand-rolled HTTP client with the official Anthropic SDK, which also fixes the undercounted cache-token usage.\n11. Cleanup tail, split as convenient: serve dev static assets via the framework's nested-path-capable routing and importable MIME table; un-hard-code the root build script's single-app filter; stop building the app twice per CI run and cache dependencies; remove the baseline runner's parallel message array and dead field; derive the boundary suite's package list instead of hard-coding it.\n\n## Findings inventory (verified evidence; paths current as of the FE-1397 stack tip)\n\n| # | Where | Finding |\n| -- | -- | -- |\n| 1 | `test/build-artifact.test.ts:82` | `toContain('createAgentRouter')` matches a preserved bootstrap JSDoc comment and `toContain('sqlite')` matches the bootstrap's unconditional default-adapter import — the test passes even if `app.ts`'s mount or `src/db.ts` never reach the build. Robust witnesses exist: the `app.route(...)` mount string and the `BRUNCH_DEV_DB_PATH`/`.data-wipe-me` strings unique to `db.ts`. |\n| 2 | `test/workspace.ts:149` (with `:128`) | `sourceFiles()` prunes `test`/`tests`/`__tests__` at any depth while `testFiles()` only collects top-level test dirs — production code under e.g. `src/test/` escapes the substrate-import ban, schema-library check, and identity-duplication scan, and isn't governed by test-hermeticity either. |\n| 3 | `apps/dev/src/db.ts:17` | Default store path `./.data-wipe-me/conversations.db` is cwd-relative; launching from a different directory silently creates a fresh empty DB. Anchor via `import.meta.url` as `app.ts` does for `uiRoot`. |\n| 4 | `test/boundaries.test.ts:239` | First-statement check requires the literal `'use agent';` exactly, while `workspace.ts`'s `AGENT_DIRECTIVE_STATEMENT` (line 168) accepts both quote styles, optional semicolon, and trailing comments — forms the suite's own fixtures assert are legal fail spuriously. |\n| 5 | `docs/planning/process-model-elicitation/baseline/run.ts:213` | `largestCodeBlock`'s fence regex ```` /```[a-z]*\\n/ ```` misses ```` ```JSON ````, trailing-space, digit/hyphen info strings, and CRLF — `writeArtifacts` (line 294) then skips the model artifact with no warning while the transcript header says delivered. |\n| 6 | `run.ts:165` | Continuation stitching caps at 4 pieces and discards `result.truncated` — a still-truncated final delivery is written as complete; nothing tells the operator `--continue-final` was needed. |\n| 7 | `run.ts:111` | Only HTTP 429/5xx are retried; a rejected `fetch` (TCP reset, DNS blip) crashes the run. Fixed `attempt*15s` backoff ignores `retry-after`. The hand-typed `ApiResponse` omits cache-token usage fields, undercounting cost. The official SDK replaces all of it. |\n| 8 | `test/boundaries.test.ts:323` | CI-gate check is `workflow.includes(gate)` over raw YAML text — a commented-out or `if: false` gate still passes. |\n| 9 | `test/known-gaps.ts:54` | Every `closed()` predicate is `existsSync` on one speculative future path: a real closure under another name stays \"open\" forever (banner rot), while `touch`ing the expected path closes the gap with nothing verified. |\n| 10 | `AGENTS.md:19` (mirrored via `CLAUDE.md` symlink) | Says the five triage roles are \"used verbatim as their own label strings\"; `docs/agents/triage-labels.md` now maps `needs-triage` → state **Triage** and `wontfix` → state **Canceled**, leaving only three as labels. |\n\nCleanup tail (verified, lower stakes): `apps/dev/src/assets.ts` hand-rolled `:file` route can't match nested paths and duplicates hono's importable `getMimeType`; root `package.json` build script hard-codes `--filter '@brunch/dev'`; the full app build runs twice per CI run (build-artifact `beforeAll` + dedicated Build step) with no bun dependency cache; `run.ts` carries an `expertMessages` parallel array and a dead `interviewerTurns` field; `boundaries.test.ts` hard-codes the four-package list and two-scope substrate denylist.\n\n## Decision document\n\n* Modules touched: the repo-level verification suites (`test/`), the dev app's store and asset serving, the baseline runner script, the always-loaded agent instructions.\n* No interface or schema changes; no production API surface exists yet. The one behavioral change visible outside tests is the dev store's default path resolution (env var override unchanged).\n* Architectural stance: gate fixes must encode the *property*, not a proxy (witness strings unique to the guarded module; parsed rather than substring-matched workflow; executed-verification rather than file-existence). This is the FE-1399 charter applied to FE-1399's own checks.\n* Baseline runner: prefer deleting the hand-rolled client in favor of the official SDK over patching it — fewer lines, retry/retry-after/typed usage for free. If the SDK dependency is unwanted in a planning script, the fallback is try/catch around fetch + retry-after parsing.\n\n## Testing decisions\n\n* Most of this work *is* the test layer, so the discipline is red-proofs: for each strengthened gate, temporarily introduce the violation it exists to catch (nested `src/test/` file importing the substrate; commented-out CI gate; stub gap file; missing db.ts in the bundle) and watch it fail before restoring green.\n* The dev store path fix gets a unit test asserting the resolved path is launch-directory-independent; prior art in `apps/dev/test/assets.test.ts`.\n* The baseline runner sits behind the typecheck gate only (FE-1361); extract its parsing helpers (`largestCodeBlock`, stitching) into testable pure functions if a red-proof is wanted, otherwise verify by targeted invocation — a full paid run is not required to exercise fence parsing.\n\n## Out of scope\n\n* The FE-1397 worked-examples docs and `ir-design.md` (no findings there).\n* Redesigning the known-gaps mechanism itself — only the predicate strength changes.\n* Anything inside `@flue/*` bootstrap behavior (the vacuous witnesses are our tests' problem, not Flue's).\n* The refuted review candidates (resume double-count, sequential awaits, symlink-cycle walker, dev HMR gap, stale map pointer) — checked and dismissed, listed here so they aren't re-litigated.\n+++",
+      "proposedBodySha256": "455650e8879394b140c44596d5ef20860837dc292bfdb7de9334251f316ed8fb",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "8e71ae1b-cdab-4071-929c-9d42090ea8fa",
+      "identifier": "FE-1419",
+      "url": "https://linear.app/hash/issue/FE-1419/close-the-seams-where-the-capture-store-and-verification-gates-claim",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:27.978Z",
+      "sourceTitle": "Close the seams where the capture store and verification gates claim more than they enforce",
+      "sourceDescriptionSha256": "8943da27bdc24725789f0721adc47978caad9bc3dc841c5086d8bd7860c07b59",
+      "sourceTitleSha256": "c7839e241c62f56c68fa6c425f55035423c76bda7a42bdbb9916214a3d0ffdca",
+      "oldOuter": "An inductive review of the open PR comments (2026-08-14) found two seams that still claim more than their implementations support. The capture store applies different rule sets at command time, persisted-parse time, and lifecycle-transition time — so a command can return success for a snapshot the next read rejects, and an open conflict can end up with no legal way to close. And the verification layer still infers runtime facts from source text: substring and regex proxies stand in for \"the gap closed\", \"CI ran this gate\", \"this test is hermetic\". Until these close, green gates and successful commands overstate what is actually guaranteed — the same silent-failure family the FE-1399/FE-1400 sweeps addressed, one level deeper (two of the queue's commits replace countermeasures FE-1400 itself introduced).\n\nThe plan is a nine-commit queue that gives each contract one owner and makes negative results precise; it is authored and ready to execute.",
+      "proposedTitle": "Align capture-store rules and verification claims",
+      "proposedOuter": "A review of open PR comments found that the capture store applies different rules when accepting commands, parsing persisted data, and changing lifecycle state. A successful command can therefore create data that the next read rejects or leave a conflict with no legal resolution. Verification checks also infer runtime behavior from source text, so green checks can overstate what ran.\n\nThe prepared nine-commit plan assigns each rule one owner and replaces these proxies with precise negative results after FE-1390 and FE-1400 land.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Execution record\n\n* Plan document: `docs/planning/legibility-sweep/refactor-queue-2026-08-14.md` — problem statement, nine ordered commits, interface/schema/lifecycle decisions, testing decisions, out-of-scope list.\n* Provenance: inductive review over the open stack's PR comments; second-order findings against FE-1400's own countermeasures (citation-token gap closure → explicit open-gap ledger whose entries are deleted by the proof commit; parsed-step matching → exact declared commands).\n* Depends on the FE-1390 capture store and FE-1400 verification changes landing first (the queue refactors both).",
+      "innerSha256": "d5eac9c8540f56560f6533189b2bc55fd99ee58d3e3b9babb0cf7a1407f917d3",
+      "proposedBody": "A review of open PR comments found that the capture store applies different rules when accepting commands, parsing persisted data, and changing lifecycle state. A successful command can therefore create data that the next read rejects or leave a conflict with no legal resolution. Verification checks also infer runtime behavior from source text, so green checks can overstate what ran.\n\nThe prepared nine-commit plan assigns each rule one owner and replaces these proxies with precise negative results after FE-1390 and FE-1400 land.\n\n+++🏗️ Agent notes\n## Execution record\n\n* Plan document: `docs/planning/legibility-sweep/refactor-queue-2026-08-14.md` — problem statement, nine ordered commits, interface/schema/lifecycle decisions, testing decisions, out-of-scope list.\n* Provenance: inductive review over the open stack's PR comments; second-order findings against FE-1400's own countermeasures (citation-token gap closure → explicit open-gap ledger whose entries are deleted by the proof commit; parsed-step matching → exact declared commands).\n* Depends on the FE-1390 capture store and FE-1400 verification changes landing first (the queue refactors both).\n+++",
+      "proposedBodySha256": "0d367277ab01bc746b565a17e83383b1c10954de679b147fb0d04088406f2633",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "cc085f83-5540-4120-978e-0c4a2be33f68",
+      "identifier": "FE-1420",
+      "url": "https://linear.app/hash/issue/FE-1420/the-affordance-protocol-survives-retries-unknown-forms-and-abandoned",
+      "state": {
+        "name": "Todo",
+        "type": "unstarted"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:26.642Z",
+      "sourceTitle": "The affordance protocol survives retries, unknown forms, and abandoned asks",
+      "sourceDescriptionSha256": "81b2a078103ec981c418c6d8583f31e301dd47b5025e06e967b13f9143b7123c",
+      "sourceTitleSha256": "3bfff13eaf86dd08b581c3c256de11384d3a0322712bec45e72909d23488c045",
+      "oldOuter": "The FE-1389 deep-read (notes/deep-read-fe-1389.md, from the FE-1401 remediation sweep) found three places where the new ask/affordance protocol fails unsafely rather than safely. Flue re-executes tools at-least-once, and a re-executed ask mints the identical affordance — but the pending-slot guard checks only that the slot is occupied, so a benign retry is refused as if the model had asked a second question. The dev UI validates the whole concrete free-text form and renders nothing on a parse failure, so the first affordance of any other form will blank instead of falling back to the markdown floor the spec requires (§7.2/§7.7 — the envelope needs its own schema with the payload opaque). And an ask whose reply never arrives occupies the slot forever: nothing records an `unanswered` outcome (§7.5) and no advisory reports the stuck state (§8.6), so every later ask is refused silently.\n\nNone of these blocks the walking skeleton — they are the hardening it deliberately deferred — but the retry refusal will start firing as soon as anything (like the settlement trigger) makes re-execution common, and the markdown floor breaks the moment a second affordance form lands.",
+      "proposedTitle": "Make affordance handling safe under retries and abandonment",
+      "proposedOuter": "The FE-1389 review found three unsafe cases in the ask protocol. A retry of the same ask is rejected as a second question, an unknown form can blank the UI instead of showing markdown, and an abandoned ask can occupy the pending position forever.\n\nThese defects do not block the first free-text flow, but retries will become common with settlement and new forms will require the fallback. This task will make identical retries idempotent, parse the envelope separately from its opaque payload, and record unanswered outcomes so later asks can proceed.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Execution record\n\nFindings, from the deep-read (file refs as of 81e9ce0):\n\n1. **Retry misreported as duplicate ask** — `packages/binding-flue/src/index.ts` pending-slot updater tests `current !== null`; should tolerate `current.id === affordance.id` (id is deterministic in `toolCallId`, so re-execution is detectable). One-line fix + a test that replays the same tool call.\n2. **Markdown floor absent in the UI** — `apps/dev/src/ui/chat.tsx` `safeParse(FreeTextAffordance, part.data)` returns null on failure. Needs an envelope-only schema (id / form / markdown, payload opaque) rendered as the fallback; ticket 10 §5 proved the intended behavior.\n3. **No escape from an occupied slot** — slot clears only on `kind: 'user'` delivery; spec §7.5's `unanswered` outcome and §8.6's unaccounted-ask advisory are the intended relief valves, neither exists.\n\nSource: docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md (builder's account, \"genuinely bug-shaped\" items 1–3).",
+      "innerSha256": "8d0fad5ee0201cf6c7e62778cd97d219beee824653bbfd520bdae507714c5392",
+      "proposedBody": "The FE-1389 review found three unsafe cases in the ask protocol. A retry of the same ask is rejected as a second question, an unknown form can blank the UI instead of showing markdown, and an abandoned ask can occupy the pending position forever.\n\nThese defects do not block the first free-text flow, but retries will become common with settlement and new forms will require the fallback. This task will make identical retries idempotent, parse the envelope separately from its opaque payload, and record unanswered outcomes so later asks can proceed.\n\n+++🏗️ Agent notes\n## Execution record\n\nFindings, from the deep-read (file refs as of 81e9ce0):\n\n1. **Retry misreported as duplicate ask** — `packages/binding-flue/src/index.ts` pending-slot updater tests `current !== null`; should tolerate `current.id === affordance.id` (id is deterministic in `toolCallId`, so re-execution is detectable). One-line fix + a test that replays the same tool call.\n2. **Markdown floor absent in the UI** — `apps/dev/src/ui/chat.tsx` `safeParse(FreeTextAffordance, part.data)` returns null on failure. Needs an envelope-only schema (id / form / markdown, payload opaque) rendered as the fallback; ticket 10 §5 proved the intended behavior.\n3. **No escape from an occupied slot** — slot clears only on `kind: 'user'` delivery; spec §7.5's `unanswered` outcome and §8.6's unaccounted-ask advisory are the intended relief valves, neither exists.\n\nSource: docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md (builder's account, \"genuinely bug-shaped\" items 1–3).\n+++",
+      "proposedBodySha256": "e3a2d292c30c5432dc867421b1137d16b31a7550f4523bb853a13306c80fdbaf",
+      "ambiguity": null,
+      "notes": null
+    },
+    {
+      "id": "91a93db7-c088-4b26-a521-0385d2db713a",
+      "identifier": "FE-1422",
+      "url": "https://linear.app/hash/issue/FE-1422/the-ask-protocol-is-substrate-portable-mechanism-moves-from-the-flue",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "5e45263d-bf61-4025-b415-cca91df88023",
+        "identifier": "FE-1383",
+        "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+      },
+      "sourceUpdatedAt": "2026-08-20T08:02:56.900Z",
+      "sourceTitle": "The ask protocol is substrate-portable: mechanism moves from the Flue binding into core",
+      "sourceDescriptionSha256": "896c07b62ab8f586a5b0a3e91d47dd2227e5e69ab4b76c60e2ee33afea3de43d",
+      "sourceTitleSha256": "2f1e7a4a1dc36d322f689117372148fc36b8b32010e7c5a83ad8b5164882edd3",
+      "oldOuter": "The walking skeleton put the whole ask/suspension protocol inside the Flue binding: the affordance id scheme, the one-live-affordance rule, the reply-binding signal payload, and the elicitation instruction text all live interleaved with hook wiring in binding-flue/src/index.ts, while packages/core exports only schemas and naming. That is the spec's second-binding test failing in spirit (§14.2): a second binding would have to re-implement the protocol rather than reuse it, and every slice that adds mechanism the same way deepens the debt — the sweep work (FE-1392) is the next one that would.\n\nThe fix is an extraction, not a redesign: a pure ask-protocol module in core (mint an affordance from question + call id, the one-live guard as a pure decision, the signal payload builder, the instruction fragments), with useElicitation reduced to hook wiring — hooks in, protocol calls out. Scheduled ahead of FE-1392 so sweep mechanism can start in core the same way (sweep-protocol) from day one.",
+      "proposedTitle": "Move the portable ask protocol into core",
+      "proposedOuter": "The walking skeleton placed reusable ask behavior inside the Flue binding, including identity, the one-live rule, reply signals, and instruction text. A second runtime binding would have to reproduce that behavior, and settlement work would deepen the duplication.\n\nThis task will extract pure ask decisions and builders into core while leaving only Flue hook translation in the binding. It is scheduled before FE-1392 so new settlement behavior begins in the portable module.",
+      "extractionMethod": "first-standalone-divider",
+      "innerRecord": "## Execution record\n\n* Findings and evidence: remediation ledger A1 (docs/planning/legibility-sweep/remediation-plan-2026-08-17.md), topology rule N1 (docs/planning/_shared/topology.md — names the four exports that are portable mechanism vs. the hook wiring that correctly stays), deep-read docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md.\n* Acceptance: binding-flue/src/index.ts contains no protocol decisions, only hook translation; the walking-skeleton integration test (do-not-weaken) stays green unmodified — it pins behavior, not placement.\n* Blocks FE-1392 by design (sequencing: docs/planning/_shared/CONVERGENCE.md, second evaluation).",
+      "innerSha256": "301dbadb8c2872e43533c31fcfa09671e4f425b015f1407526a856406f701fcb",
+      "proposedBody": "The walking skeleton placed reusable ask behavior inside the Flue binding, including identity, the one-live rule, reply signals, and instruction text. A second runtime binding would have to reproduce that behavior, and settlement work would deepen the duplication.\n\nThis task will extract pure ask decisions and builders into core while leaving only Flue hook translation in the binding. It is scheduled before FE-1392 so new settlement behavior begins in the portable module.\n\n+++🏗️ Agent notes\n## Execution record\n\n* Findings and evidence: remediation ledger A1 (docs/planning/legibility-sweep/remediation-plan-2026-08-17.md), topology rule N1 (docs/planning/_shared/topology.md — names the four exports that are portable mechanism vs. the hook wiring that correctly stays), deep-read docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md.\n* Acceptance: binding-flue/src/index.ts contains no protocol decisions, only hook translation; the walking-skeleton integration test (do-not-weaken) stays green unmodified — it pins behavior, not placement.\n* Blocks FE-1392 by design (sequencing: docs/planning/_shared/CONVERGENCE.md, second evaluation).\n+++",
+      "proposedBodySha256": "a19b212cc099044874f9f41cc967ac913aac5dc427be25bdc4e3481b9e191336",
+      "ambiguity": null,
+      "notes": null
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1401.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1401.json
new file mode 100644
index 00000000000..18fde7af212
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1401.json
@@ -0,0 +1,119 @@
+{
+  "root": "FE-1401",
+  "generatedAt": "2026-08-20T09:03:34Z",
+  "issueCount": 4,
+  "issues": [
+    {
+      "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+      "identifier": "FE-1401",
+      "url": "https://linear.app/hash/issue/FE-1401/resolve-the-follow-ups-from-the-stack-legibility-session",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": null,
+      "sourceUpdatedAt": "2026-08-19T16:20:28.561Z",
+      "sourceTitle": "Resolve the follow-ups from the stack legibility session",
+      "sourceDescriptionSha256": "add5a3da06b366dbc9fe4cdc44b9ce161d2775c8b43fb18af380b2fe2c9c9d5e",
+      "sourceTitleSha256": "3eb163af50263452be68f66950600c587100fa854645791d88be95fddb53e306",
+      "oldOuter": "I'm running a read-through of the open stack (FE-1374 up to FE-1390), aimed at regaining legibility over the top four branches before they land. The read-through is already surfacing more than branch understanding: process insights, a doc drift, and a couple of tooling ideas worth carrying forward. This issue is the resolution sweep for that session — everything we uncover, solve, design, or decide gets captured here and driven to a resolution, so the session's yield doesn't evaporate when the context does.\n\nThe session is in progress; items accrue below as they surface. Anything that grows real work graduates to its own sub-issue.",
+      "proposedTitle": "Resolve the stack legibility follow-ups",
+      "proposedOuter": "A read-through of the open stack from FE-1374 through FE-1390 is restoring a shared understanding of the top four branches before they land. It is also identifying process lessons, documentation drift, and tooling ideas that need a durable resolution. This issue records and resolves each finding so that the session's results remain available after the working context ends.\n\nThe session is still in progress. Findings accumulate in the execution record, and any finding that requires substantial work becomes a sub-issue.",
+      "extractionMethod": "standalone-divider",
+      "innerRecord": "## Findings ledger\n\n**1. CONTEXT.md authority-voice drift (fix).** The *Artifact boundary* glossary entry still opens \"The decided integration posture between elicitor and Petrinaut (FE-1362)\". The demo-vehicle posture is a recommendation to PM, not a ratified decision — FE-1363's entries carry the corrected voice (\"recommended to PM, not ratified\"), but the correction never propagated backward to the FE-1362-era entry beside them. Reword to recommendation voice; while there, scan the rest of the glossary for the same drift.\n\n**2. Institute the cognitive-common-ground protocol (practice).** At the close of any work arc with significant agent-generated output, produce legibility artifacts that aid review and re-establish shared understanding — from plain-language/STE prose re-renderings up to exploded-view logic prototypes. FE-1374's spec renderings were the incidental prototype: re-rendering in a different register acted as a review instrument, and the round-2 read-through of those renderings fed four real changes back into the spec. Two parts: repeat the move within this session (a prose rendering of what the top four branches establish — FE-1390's capture-store semantics especially), and write the practice down (likely a `docs/agents/` home; exact placement open).\n\n**3. Port ln-induct into dogsled as** `ds-induct` **(tooling).** The induction skill at `brunch/.agents/skills/ln-induct/` — treat point review-findings as samples from a latent fault-type, abstract to the lowest rung that is both mechanically searchable and names a repair, triage-gate before auditing — should be ported into the dogsled skill system, with graduation targets renamed to the dogsled family: `ds-code-review`'s Standards axis gains a contract/verification-integrity baseline section alongside the Fowler smells, each entry carrying *what it is → how to fix → how to probe* (these lenses are invisible in the hunk; they're detected by interrogation, e.g. \"feed the gate nothing, demand red\"). Graduation is two-tier and composing: prose priors accrue in dogsled and travel via plugin; per-repo, instances get pinned as categorical boundary tests wherever a mechanical predicate exists (the Dan Luu regression-capture principle). Repo-side wiring stays in CLAUDE.local.md only — the tracked repo must not depend on dogsled being present.\n\n**4. Write up the two induced lenses with their evidence trails (graduation candidates).**\n\n* *The vacuously green check* — a gate that passes because it inspected nothing. Three-PR recurrence: FE-1388 (`sourceFiles()` returning `[]` for unfamiliar layouts; decorative oxlint), FE-1399 (`workspacePackages()` passing every boundary invariant on an empty list), FE-1400 (vacuous build-artifact witnesses; CI gates matched against raw YAML text).\n* *The parallel copy of a pinned truth* — the same fact maintained in two places, one drifting silently. Recurrence: FE-1399 (mount path now derives from `agentName`), FE-1400 (pinned-literal check routed through `pinnedIdentities`; expert's view derived instead of a parallel array; topology pin derived instead of hard-coded).\n\nEach instance was caught by a fresh post-hoc review pass rather than by a standing lens at authoring time — that gap is the value the port in item 3 is meant to recover.",
+      "innerSha256": "f99c1280b8f7c73cd932a953bf8a8df0651f655b393f773cc88d46d0e49da113",
+      "proposedBody": "A read-through of the open stack from FE-1374 through FE-1390 is restoring a shared understanding of the top four branches before they land. It is also identifying process lessons, documentation drift, and tooling ideas that need a durable resolution. This issue records and resolves each finding so that the session's results remain available after the working context ends.\n\nThe session is still in progress. Findings accumulate in the execution record, and any finding that requires substantial work becomes a sub-issue.\n\n+++🏗️ Agent notes\n## Findings ledger\n\n**1. CONTEXT.md authority-voice drift (fix).** The *Artifact boundary* glossary entry still opens \"The decided integration posture between elicitor and Petrinaut (FE-1362)\". The demo-vehicle posture is a recommendation to PM, not a ratified decision — FE-1363's entries carry the corrected voice (\"recommended to PM, not ratified\"), but the correction never propagated backward to the FE-1362-era entry beside them. Reword to recommendation voice; while there, scan the rest of the glossary for the same drift.\n\n**2. Institute the cognitive-common-ground protocol (practice).** At the close of any work arc with significant agent-generated output, produce legibility artifacts that aid review and re-establish shared understanding — from plain-language/STE prose re-renderings up to exploded-view logic prototypes. FE-1374's spec renderings were the incidental prototype: re-rendering in a different register acted as a review instrument, and the round-2 read-through of those renderings fed four real changes back into the spec. Two parts: repeat the move within this session (a prose rendering of what the top four branches establish — FE-1390's capture-store semantics especially), and write the practice down (likely a `docs/agents/` home; exact placement open).\n\n**3. Port ln-induct into dogsled as** `ds-induct` **(tooling).** The induction skill at `brunch/.agents/skills/ln-induct/` — treat point review-findings as samples from a latent fault-type, abstract to the lowest rung that is both mechanically searchable and names a repair, triage-gate before auditing — should be ported into the dogsled skill system, with graduation targets renamed to the dogsled family: `ds-code-review`'s Standards axis gains a contract/verification-integrity baseline section alongside the Fowler smells, each entry carrying *what it is → how to fix → how to probe* (these lenses are invisible in the hunk; they're detected by interrogation, e.g. \"feed the gate nothing, demand red\"). Graduation is two-tier and composing: prose priors accrue in dogsled and travel via plugin; per-repo, instances get pinned as categorical boundary tests wherever a mechanical predicate exists (the Dan Luu regression-capture principle). Repo-side wiring stays in CLAUDE.local.md only — the tracked repo must not depend on dogsled being present.\n\n**4. Write up the two induced lenses with their evidence trails (graduation candidates).**\n\n* *The vacuously green check* — a gate that passes because it inspected nothing. Three-PR recurrence: FE-1388 (`sourceFiles()` returning `[]` for unfamiliar layouts; decorative oxlint), FE-1399 (`workspacePackages()` passing every boundary invariant on an empty list), FE-1400 (vacuous build-artifact witnesses; CI gates matched against raw YAML text).\n* *The parallel copy of a pinned truth* — the same fact maintained in two places, one drifting silently. Recurrence: FE-1399 (mount path now derives from `agentName`), FE-1400 (pinned-literal check routed through `pinnedIdentities`; expert's view derived instead of a parallel array; topology pin derived instead of hard-coded).\n\nEach instance was caught by a fresh post-hoc review pass rather than by a standing lens at authoring time — that gap is the value the port in item 3 is meant to recover.\n+++",
+      "proposedBodySha256": "6d9c0240f357a91e06128af6bd7c3a37b319c5b66a62569d1efd20bf2b94d6d7",
+      "ambiguity": [],
+      "notes": []
+    },
+    {
+      "id": "c7ddbae5-80e1-45ec-b3a3-7f80bd3b4b16",
+      "identifier": "FE-1424",
+      "url": "https://linear.app/hash/issue/FE-1424/the-documentation-protocol-runs-end-to-end-inbox-settled-planning",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+        "identifier": "FE-1401",
+        "title": "Resolve the follow-ups from the stack legibility session"
+      },
+      "sourceUpdatedAt": "2026-08-20T08:02:56.935Z",
+      "sourceTitle": "The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable",
+      "sourceDescriptionSha256": "25338da8862bddb99fe1703004fd71da6f90c544df8a3026c5ac2db39bdc8451",
+      "sourceTitleSha256": "4ba41dff52f65d73eb3a91251a5f2f5593dd20f33ee17b935bd4f4fa0a53f03c",
+      "oldOuter": "",
+      "proposedTitle": "Complete the documentation protocol",
+      "proposedOuter": "The repository's documentation rules defined where files belong and how each work arc closes, but the project had not applied them end to end. This issue carries out the rules and incorporates the amendments Lu approved on 2026-08-17.\n\nThe work settles all seven inbox documents, reorganizes shared and effort-specific planning files, and adds a test for complete index coverage and directory structure. It also combines the three arc-close procedures and establishes how living documents reference issues and repair stale status language. Freshness remains a procedural review because a mechanical check could report success without proving that the text is current.",
+      "extractionMethod": "whole-body-as-inner",
+      "innerRecord": "The documentation protocol (`docs/agents/documentation.md`) specified zones and a sweep that were never fully executed, and practice drifted past it in two places. Ratified by Lu 2026-08-17, this issue runs it and amends it:\n\n1. **Settle the inbox**: create the specified-but-never-created `docs/reference/`, settle all seven inbox documents there, update INDEX rows and every inbound link (repo and Linear descriptions).\n2. **Reshape** `docs/planning/`: cross-effort *living* documents (CONVERGENCE, topology, the Flue cheatsheet) move to `docs/planning/_shared/`; dated *records* (remediation plan, patterns audit, refactor queue) move into a `legibility-sweep/` effort directory. Rule: the planning top level contains only directories; living docs never carry dates, records always do.\n3. **Gate INDEX coverage**: a `test/docs-index.test.ts` asserting set equality between files under `docs/**` and INDEX rows (both directions), plus the planning-top-level structural rule — red-proved like the other boundary gates. Freshness stays procedural (a mechanical freshness check would be a dead gate).\n4. **Consolidate arc-close**: the three arc-close procedures scattered across `legibility.md` (consolidation), `issue-tracker.md` (registry audit), and `documentation.md` (inbox sweep) become one triggerable checklist at `docs/agents/arc-close.md`, with a thin project-level skill wrapper.\n5. **Ephemeral-reference convention** (into `documentation.md`): issue IDs glossed at first mention in living docs; load-bearing only in the tracking layer; tense repair at arc close.",
+      "innerSha256": "25338da8862bddb99fe1703004fd71da6f90c544df8a3026c5ac2db39bdc8451",
+      "proposedBody": "The repository's documentation rules defined where files belong and how each work arc closes, but the project had not applied them end to end. This issue carries out the rules and incorporates the amendments Lu approved on 2026-08-17.\n\nThe work settles all seven inbox documents, reorganizes shared and effort-specific planning files, and adds a test for complete index coverage and directory structure. It also combines the three arc-close procedures and establishes how living documents reference issues and repair stale status language. Freshness remains a procedural review because a mechanical check could report success without proving that the text is current.\n\n+++🏗️ Agent notes\nThe documentation protocol (`docs/agents/documentation.md`) specified zones and a sweep that were never fully executed, and practice drifted past it in two places. Ratified by Lu 2026-08-17, this issue runs it and amends it:\n\n1. **Settle the inbox**: create the specified-but-never-created `docs/reference/`, settle all seven inbox documents there, update INDEX rows and every inbound link (repo and Linear descriptions).\n2. **Reshape** `docs/planning/`: cross-effort *living* documents (CONVERGENCE, topology, the Flue cheatsheet) move to `docs/planning/_shared/`; dated *records* (remediation plan, patterns audit, refactor queue) move into a `legibility-sweep/` effort directory. Rule: the planning top level contains only directories; living docs never carry dates, records always do.\n3. **Gate INDEX coverage**: a `test/docs-index.test.ts` asserting set equality between files under `docs/**` and INDEX rows (both directions), plus the planning-top-level structural rule — red-proved like the other boundary gates. Freshness stays procedural (a mechanical freshness check would be a dead gate).\n4. **Consolidate arc-close**: the three arc-close procedures scattered across `legibility.md` (consolidation), `issue-tracker.md` (registry audit), and `documentation.md` (inbox sweep) become one triggerable checklist at `docs/agents/arc-close.md`, with a thin project-level skill wrapper.\n5. **Ephemeral-reference convention** (into `documentation.md`): issue IDs glossed at first mention in living docs; load-bearing only in the tracking layer; tense repair at arc close.\n+++",
+      "proposedBodySha256": "9f30239aa39c9e0dd9d0478056848f5cdd26e2dec9a468e01e6e79cd37c38127",
+      "ambiguity": [],
+      "notes": [
+        "The unheaded numbered body is the issue's execution record, so the migration preserves the whole source body inside Agent notes."
+      ]
+    },
+    {
+      "id": "a3bcc46c-adb3-4b34-9668-42448b9295e3",
+      "identifier": "FE-1432",
+      "url": "https://linear.app/hash/issue/FE-1432/the-stacks-open-review-threads-are-adjudicated-fixed-owned-or-refused",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+        "identifier": "FE-1401",
+        "title": "Resolve the follow-ups from the stack legibility session"
+      },
+      "sourceUpdatedAt": "2026-08-20T08:02:56.984Z",
+      "sourceTitle": "The stack's open review threads are adjudicated: fixed, owned, or refused on the record",
+      "sourceDescriptionSha256": "4280899d06e4ac85fef832eaaaa5f9bb08c388105125b5369808b5c7354d0688",
+      "sourceTitleSha256": "87232791cdfbe95bb69b3bcb846ca1a9b0057306d8b5c372fcd11b3336da9a43",
+      "oldOuter": "A cross-stack review of the unresolved inline PR threads ran 2026-08-18: 24 threads across 10 PRs, of which 9 were resolved with evidence-backed upstack replies and 15 remain open. The review also induced five reusable lenses, and the findings that survived under them are concrete: two capture-store closure gaps (overlapping conflicts can strand one another, and the persisted parser accepts a duplicate `issue-closed` event the command API refuses to produce), two completion-metadata drops (expert truncation is discarded, and a non-final interviewer response can stay truncated past the continuation cap without being marked incomplete), a boundary-honesty gap (`plugin-gherkin` declares `valibot` without importing it, and the boundary test checks the dependency relation in one direction only), and two test-setup holes (the capture-store test ignores setup results and leans on non-null assertions; the walking-skeleton integration test can throw while inspecting an absent reply context).\n\nFWIW several of these are not new discoveries — they are FE-1419's deliberate out-of-scope list coming due (unused-dependency cleanup, expert-truncation handling, advisory-loop tuning were all named there and deferred). This ticket is the FE-1401-style consolidation point: done means every row in the queue document lands in a commit, moves to a named owner, or is refused with a reply on its PR thread — and the 15 still-open threads each get the same adjudication.",
+      "proposedTitle": "Resolve the stack's open review threads",
+      "proposedOuter": "A review on 2026-08-18 covered 24 unresolved inline threads across 10 PRs. Nine threads now have evidence-backed replies, while 15 remain open. The review found two capture-store closure problems, two cases where completion metadata is lost, one dependency-check problem, and two unsafe test setups.\n\nSeveral findings repeat work that FE-1419 explicitly deferred. This issue is complete when every queue entry and each remaining thread is fixed in a commit, assigned to a named owner, or declined with a reply on the PR thread.",
+      "extractionMethod": "standalone-divider",
+      "innerRecord": "## Execution record\n\n* **Queue document (repo-canonical):** `docs/planning/legibility-sweep/review-remediation-2026-08-18.md` — ledger rows with provenance, owners, and dispositions\n* **Provenance:** PR-thread review 2026-08-18 (24 threads / 10 PRs; 9 resolved upstack at review time; lenses 1–5 induced, three graduation proposals recorded for the tooling side)\n* **Prior art:** `refactor-queue-2026-08-14.md` → FE-1419 (executed); `remediation-plan-2026-08-17.md` ledgers A/B — same lineage, same exit rule (rows leave by commit, ticket, or decision)",
+      "innerSha256": "0fbd1bee2c01279349d7153444b398ce50eed5c2b1858847aa457ba5eff62a02",
+      "proposedBody": "A review on 2026-08-18 covered 24 unresolved inline threads across 10 PRs. Nine threads now have evidence-backed replies, while 15 remain open. The review found two capture-store closure problems, two cases where completion metadata is lost, one dependency-check problem, and two unsafe test setups.\n\nSeveral findings repeat work that FE-1419 explicitly deferred. This issue is complete when every queue entry and each remaining thread is fixed in a commit, assigned to a named owner, or declined with a reply on the PR thread.\n\n+++🏗️ Agent notes\n## Execution record\n\n* **Queue document (repo-canonical):** `docs/planning/legibility-sweep/review-remediation-2026-08-18.md` — ledger rows with provenance, owners, and dispositions\n* **Provenance:** PR-thread review 2026-08-18 (24 threads / 10 PRs; 9 resolved upstack at review time; lenses 1–5 induced, three graduation proposals recorded for the tooling side)\n* **Prior art:** `refactor-queue-2026-08-14.md` → FE-1419 (executed); `remediation-plan-2026-08-17.md` ledgers A/B — same lineage, same exit rule (rows leave by commit, ticket, or decision)\n+++",
+      "proposedBodySha256": "5d722009e1a8d693b9447eb4653f647eb65cdda6d75643220a0dec00c064e6df",
+      "ambiguity": [],
+      "notes": []
+    },
+    {
+      "id": "3aca4d07-14b9-4b2e-a413-41fd61801cb0",
+      "identifier": "FE-1451",
+      "url": "https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan",
+      "state": {
+        "name": "Ready for review",
+        "type": "started"
+      },
+      "parent": {
+        "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+        "identifier": "FE-1401",
+        "title": "Resolve the follow-ups from the stack legibility session"
+      },
+      "sourceUpdatedAt": "2026-08-19T16:20:28.510Z",
+      "sourceTitle": "Keep issues, comments, and PRs easy to scan",
+      "sourceDescriptionSha256": "91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb",
+      "sourceTitleSha256": "37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c",
+      "oldOuter": "Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](<https://github.com/hashintel/internal-agents/pull/20>). The change is ready for review in [brunch-lite PR #23](<https://github.com/hashintel/brunch-lite/pull/23>).",
+      "proposedTitle": "Keep issues, comments, and PRs easy to scan",
+      "proposedOuter": "Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](<https://github.com/hashintel/internal-agents/pull/20>). The change is ready for review in [brunch-lite PR #23](<https://github.com/hashintel/brunch-lite/pull/23>).",
+      "extractionMethod": "existing-agent-notes",
+      "innerRecord": "Design settled 2026-08-19 in a working session with Lu. A scratch issue (FE-1450, since deleted) proved that the collapsed-section syntax survives create, read, update, and second-read operations in issue bodies and comments, and renders closed.\n\nChanges to `docs/agents/issue-writing.md` and `docs/agents/issue-tracker.md`:\n\n* Root titles start with an active verb and name the task compactly. Planning and research remain valid tasks: use verbs such as `plan`, `map`, `decide`, or `test`. A title names an implementation only after that implementation becomes the agreed task.\n* The visible summary is owned by the human driving the work, even when an agent writes on that person's behalf. An agent fetches and reads the current raw body before every change, preserves human edits, and never pushes a stale local draft. `🏗️ Agent notes` remains agent-maintained.\n* When an issue comes from user, stakeholder, or teammate feedback, quote and link the source when the issue's audience can read it.\n* The contract and execution record use one canonical collapsed-section label: `+++🏗️ Agent notes` in Linear and `<details><summary>🏗️ Agent notes</summary>` on GitHub. Copy the fixed string from the writing rules because the emoji carries U+FE0F.\n* A comment's visible content states a decision or a change in confidence, risk, or scope in one or two short sentences. Implementation detail goes in `🏗️ Agent notes` in the comment or issue body. Progress narration stays in the issue body. The resolution comment keeps its length exemption: a verdict paragraph first, then `🏗️ Agent notes`.\n* The technical-writing rules apply first. Industry-standard terms are free everywhere. Terms from technical literature belong in `🏗️ Agent notes` only when no plainer exact phrase fits; a visible summary also requires a definition and a `CONTEXT.md` entry. Do not coin a term for an issue. An inherited local term stays in `🏗️ Agent notes`.\n* The org `technical-writing` skill in PR #20 above governs word choice; `issue-writing.md` governs structure. Its word list applies to all prose immediately, regardless of the PR's merge state. Exact machine text is exempt.\n* Project updates reach the widest audience. They contain only a summary and the native health field, omit empty sections, and are drafted from issue-comment changes since the previous update. A `brunch-agent` project is planned as their home.\n* `issue-tracker.md` says to read raw descriptions through `linear api` GraphQL rather than `issue view`, which prepends a header that corrupts a fetch, edit, and push operation. Linear's normalization of collapsed-section spacing and bullet markers is expected. Issue references use full URLs so Linear renders them as links.\n\nVerification: `test/docs-index.test.ts` plus the repo's standard checks. This change edits Markdown only. The branch stacks on `ln/fe-1433-petrinaut-integration-spec` because the main worktree is occupied by another agent.\n\n",
+      "innerSha256": "5f7e7ccafc96dae7ca37a344d1196404fc760e3443ad6370e4e05ddb530062b2",
+      "proposedBody": "Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](<https://github.com/hashintel/internal-agents/pull/20>). The change is ready for review in [brunch-lite PR #23](<https://github.com/hashintel/brunch-lite/pull/23>).\n\n+++🏗️ Agent notes\nDesign settled 2026-08-19 in a working session with Lu. A scratch issue (FE-1450, since deleted) proved that the collapsed-section syntax survives create, read, update, and second-read operations in issue bodies and comments, and renders closed.\n\nChanges to `docs/agents/issue-writing.md` and `docs/agents/issue-tracker.md`:\n\n* Root titles start with an active verb and name the task compactly. Planning and research remain valid tasks: use verbs such as `plan`, `map`, `decide`, or `test`. A title names an implementation only after that implementation becomes the agreed task.\n* The visible summary is owned by the human driving the work, even when an agent writes on that person's behalf. An agent fetches and reads the current raw body before every change, preserves human edits, and never pushes a stale local draft. `🏗️ Agent notes` remains agent-maintained.\n* When an issue comes from user, stakeholder, or teammate feedback, quote and link the source when the issue's audience can read it.\n* The contract and execution record use one canonical collapsed-section label: `+++🏗️ Agent notes` in Linear and `<details><summary>🏗️ Agent notes</summary>` on GitHub. Copy the fixed string from the writing rules because the emoji carries U+FE0F.\n* A comment's visible content states a decision or a change in confidence, risk, or scope in one or two short sentences. Implementation detail goes in `🏗️ Agent notes` in the comment or issue body. Progress narration stays in the issue body. The resolution comment keeps its length exemption: a verdict paragraph first, then `🏗️ Agent notes`.\n* The technical-writing rules apply first. Industry-standard terms are free everywhere. Terms from technical literature belong in `🏗️ Agent notes` only when no plainer exact phrase fits; a visible summary also requires a definition and a `CONTEXT.md` entry. Do not coin a term for an issue. An inherited local term stays in `🏗️ Agent notes`.\n* The org `technical-writing` skill in PR #20 above governs word choice; `issue-writing.md` governs structure. Its word list applies to all prose immediately, regardless of the PR's merge state. Exact machine text is exempt.\n* Project updates reach the widest audience. They contain only a summary and the native health field, omit empty sections, and are drafted from issue-comment changes since the previous update. A `brunch-agent` project is planned as their home.\n* `issue-tracker.md` says to read raw descriptions through `linear api` GraphQL rather than `issue view`, which prepends a header that corrupts a fetch, edit, and push operation. Linear's normalization of collapsed-section spacing and bullet markers is expected. Issue references use full URLs so Linear renders them as links.\n\nVerification: `test/docs-index.test.ts` plus the repo's standard checks. This change edits Markdown only. The branch stacks on `ln/fe-1433-petrinaut-integration-spec` because the main worktree is occupied by another agent.\n\n+++",
+      "proposedBodySha256": "f3c0def466d97d8a92bdb6e3d91b35b39c5d8f3fca5d5dac07670daaf2f10fad",
+      "ambiguity": [],
+      "notes": [
+        "The source opener contains a space after +++; the proposed body normalizes only that structural opener."
+      ]
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1406.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1406.json
new file mode 100644
index 00000000000..dfd5f876a58
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-proposals-FE-1406.json
@@ -0,0 +1,33 @@
+{
+  "root": "FE-1406",
+  "generatedAt": "2026-08-20T09:03:34Z",
+  "issueCount": 1,
+  "issues": [
+    {
+      "id": "1d188788-347a-4612-8da9-4fdfb09d0377",
+      "identifier": "FE-1406",
+      "url": "https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies",
+      "state": {
+        "name": "Next up",
+        "type": "unstarted"
+      },
+      "parent": null,
+      "sourceUpdatedAt": "2026-08-19T16:20:27.749Z",
+      "sourceTitle": "Design reusable elicitation strategies",
+      "sourceDescriptionSha256": "c5698449d7a48b8b4f4f1b3f9dead3407ae1a737b26c62c6034528c809b993f9",
+      "sourceTitleSha256": "9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2",
+      "oldOuter": "An elicitation should adapt to what the user is trying to achieve and how much effort they can give, instead of running through a fixed list of questions. The harness already names reusable interview situations, but it has no shared guidance for beginning an interview, proposing likely answers for correction, or deciding which uncertainties still warrant questions.\n\nThis issue will design reusable, domain-independent interviewing guidance. It includes an opening strategy that establishes the objective, its context and scope, and the user's available time, intended use, and tolerance for suggested assumptions within the first turn or two. It also covers proposing a broad draft for correction when time is short, while keeping confirmed statements, declared defaults, and unresolved suggestions visibly distinct.",
+      "proposedTitle": "Design reusable elicitation strategies",
+      "proposedOuter": "An elicitation should adapt to the user's objective and available effort. The harness names reusable interview situations but lacks shared guidance for opening an interview, proposing likely answers for correction, and choosing which uncertainties warrant questions.\n\nThis issue designs that guidance. The opening establishes objective, context, scope, time, intended use, and tolerance for assumptions; proposal and correction keep confirmed statements, defaults, and suggestions distinct. The scope settled on 2026-08-19, while three mechanics remain unresolved: use model-gap cues without walking the schema, distinguish session stopping from model completion, and decide whether inferred interaction preferences require stored state.",
+      "extractionMethod": "existing-agent-notes",
+      "innerRecord": "The kernel spec names this harness-side library the generic strategy quiver (§11.5). Guidance ownership follows vocabulary ownership: these cards teach how to work situations the shared capture envelope can name, while plugin cards teach what to notice in a domain. Plugins compose the shared cards into their packs at authoring time.\n\n## Scope settled 2026-08-19\n\n* Kickoff is a form the agent fills implicitly, not four literal questions. It establishes: objective; why and with respect to what; inclusion and exclusion boundaries; and the interaction posture inferred from available time, intended use, required confidence, and tolerance for agent-proposed assumptions.\n* Optimize for low user effort to reach an acceptably grounded model, not for turn count. A one-turn questionnaire can score well on turns while making the experience worse.\n* Strategy varies with the inferred posture: explore openly when appetite is high; synthesize and invite correction when it is constrained; propose low-risk structure and question only high-impact uncertainty in mixed cases.\n* Proposal-and-correction is a generic strategy and an appetite-compensation strategy. A generated guess remains a suggestion until the user confirms or corrects it. Only declared plugin defaults may enter as `defaulted`; the IR must not present a model guess as user-grounded evidence.\n* The shared capability set is: ask, propose, contrast, expose assumptions and gaps, capture corrections, and stop with visible gaps. The quiver says how to combine those capabilities. Plugins supply domain imperatives, target shapes, motifs, defaults, and the uncertainties that matter. The agent chooses among applicable strategies.\n* The existing card set remains in scope: conflict, competing alternatives, ambiguity, weak or missing evidence, absence clusters, and choice-point pressure. Card form remains Detects / Goal / contrastive Questions / Artifacts unless this design pass finds that kickoff or proposal-and-correction needs a different form.\n\n## Design seams to resolve\n\n* The plugin contract's `firesWhen` table mechanically produces next-question candidates from model gaps. This issue must preserve those cues as candidates without turning the interview into a schema walk; kickoff also occurs before those slot-state cues exist.\n* Session stopping and model completion are distinct. A constrained session may stop with a useful, structurally broad model containing confirmed proposals, declared defaults, and visible gaps.\n* “Appetite” is a continuously inferred interaction posture, not necessarily a stored field or fixed user-facing mode.\n\n## Prior design basis\n\nThe spec named but did not design the quiver, with milestone one shipping generic guidance in plugin packs. Reference shapes are ln-grill, ln-disambiguate, the `elicitation_style` trichotomy, and the assurance plugin's stress-the-argument split. [FE-1397](https://linear.app/hash/issue/FE-1397) routed recurring choice-point technique to the quiver. [FE-1403](https://linear.app/hash/issue/FE-1403) authors and tags envelope-vocabulary cards inside the CPS pack so they can graduate here.\n\nInputs when work starts: spec §11.5; the FE-1397 routing verdict and worked examples; FE-1403's tagged generic cards; the assurance plugin's §13.2 generic/domain decomposition; and the 2026-08-19 kickoff/appetite design discussion recorded above. Related: [FE-1357](https://linear.app/hash/issue/FE-1357), [FE-1402](https://linear.app/hash/issue/FE-1402), [FE-1403](https://linear.app/hash/issue/FE-1403), [FE-1431](https://linear.app/hash/issue/FE-1431).\n\n",
+      "innerSha256": "3441bc967c62c4084377fe1de062ec618d820c501c81d50743337fb2ac673094",
+      "proposedBody": "An elicitation should adapt to the user's objective and available effort. The harness names reusable interview situations but lacks shared guidance for opening an interview, proposing likely answers for correction, and choosing which uncertainties warrant questions.\n\nThis issue designs that guidance. The opening establishes objective, context, scope, time, intended use, and tolerance for assumptions; proposal and correction keep confirmed statements, defaults, and suggestions distinct. The scope settled on 2026-08-19, while three mechanics remain unresolved: use model-gap cues without walking the schema, distinguish session stopping from model completion, and decide whether inferred interaction preferences require stored state.\n\n+++🏗️ Agent notes\nThe kernel spec names this harness-side library the generic strategy quiver (§11.5). Guidance ownership follows vocabulary ownership: these cards teach how to work situations the shared capture envelope can name, while plugin cards teach what to notice in a domain. Plugins compose the shared cards into their packs at authoring time.\n\n## Scope settled 2026-08-19\n\n* Kickoff is a form the agent fills implicitly, not four literal questions. It establishes: objective; why and with respect to what; inclusion and exclusion boundaries; and the interaction posture inferred from available time, intended use, required confidence, and tolerance for agent-proposed assumptions.\n* Optimize for low user effort to reach an acceptably grounded model, not for turn count. A one-turn questionnaire can score well on turns while making the experience worse.\n* Strategy varies with the inferred posture: explore openly when appetite is high; synthesize and invite correction when it is constrained; propose low-risk structure and question only high-impact uncertainty in mixed cases.\n* Proposal-and-correction is a generic strategy and an appetite-compensation strategy. A generated guess remains a suggestion until the user confirms or corrects it. Only declared plugin defaults may enter as `defaulted`; the IR must not present a model guess as user-grounded evidence.\n* The shared capability set is: ask, propose, contrast, expose assumptions and gaps, capture corrections, and stop with visible gaps. The quiver says how to combine those capabilities. Plugins supply domain imperatives, target shapes, motifs, defaults, and the uncertainties that matter. The agent chooses among applicable strategies.\n* The existing card set remains in scope: conflict, competing alternatives, ambiguity, weak or missing evidence, absence clusters, and choice-point pressure. Card form remains Detects / Goal / contrastive Questions / Artifacts unless this design pass finds that kickoff or proposal-and-correction needs a different form.\n\n## Design seams to resolve\n\n* The plugin contract's `firesWhen` table mechanically produces next-question candidates from model gaps. This issue must preserve those cues as candidates without turning the interview into a schema walk; kickoff also occurs before those slot-state cues exist.\n* Session stopping and model completion are distinct. A constrained session may stop with a useful, structurally broad model containing confirmed proposals, declared defaults, and visible gaps.\n* “Appetite” is a continuously inferred interaction posture, not necessarily a stored field or fixed user-facing mode.\n\n## Prior design basis\n\nThe spec named but did not design the quiver, with milestone one shipping generic guidance in plugin packs. Reference shapes are ln-grill, ln-disambiguate, the `elicitation_style` trichotomy, and the assurance plugin's stress-the-argument split. [FE-1397](https://linear.app/hash/issue/FE-1397) routed recurring choice-point technique to the quiver. [FE-1403](https://linear.app/hash/issue/FE-1403) authors and tags envelope-vocabulary cards inside the CPS pack so they can graduate here.\n\nInputs when work starts: spec §11.5; the FE-1397 routing verdict and worked examples; FE-1403's tagged generic cards; the assurance plugin's §13.2 generic/domain decomposition; and the 2026-08-19 kickoff/appetite design discussion recorded above. Related: [FE-1357](https://linear.app/hash/issue/FE-1357), [FE-1402](https://linear.app/hash/issue/FE-1402), [FE-1403](https://linear.app/hash/issue/FE-1403), [FE-1431](https://linear.app/hash/issue/FE-1431).\n\n\n+++",
+      "proposedBodySha256": "92e3c8c7ea2c008bdad40a9fa6cf7fc820928b09c21962a0fb01dff89ccbeafb",
+      "ambiguity": [],
+      "notes": [
+        "The source opener contains a space after +++; the proposed body normalizes only that structural opener."
+      ]
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-source.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-source.json
new file mode 100644
index 00000000000..44943d46951
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/linear-source.json
@@ -0,0 +1,1501 @@
+{
+  "data": {
+    "issues": {
+      "nodes": [
+        {
+          "id": "3aca4d07-14b9-4b2e-a413-41fd61801cb0",
+          "identifier": "FE-1451",
+          "title": "Keep issues, comments, and PRs easy to scan",
+          "description": "Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](<https://github.com/hashintel/internal-agents/pull/20>). The change is ready for review in [brunch-lite PR #23](<https://github.com/hashintel/brunch-lite/pull/23>).\n\n+++ 🏗️ Agent notes\n\nDesign settled 2026-08-19 in a working session with Lu. A scratch issue (FE-1450, since deleted) proved that the collapsed-section syntax survives create, read, update, and second-read operations in issue bodies and comments, and renders closed.\n\nChanges to `docs/agents/issue-writing.md` and `docs/agents/issue-tracker.md`:\n\n* Root titles start with an active verb and name the task compactly. Planning and research remain valid tasks: use verbs such as `plan`, `map`, `decide`, or `test`. A title names an implementation only after that implementation becomes the agreed task.\n* The visible summary is owned by the human driving the work, even when an agent writes on that person's behalf. An agent fetches and reads the current raw body before every change, preserves human edits, and never pushes a stale local draft. `🏗️ Agent notes` remains agent-maintained.\n* When an issue comes from user, stakeholder, or teammate feedback, quote and link the source when the issue's audience can read it.\n* The contract and execution record use one canonical collapsed-section label: `+++🏗️ Agent notes` in Linear and `<details><summary>🏗️ Agent notes</summary>` on GitHub. Copy the fixed string from the writing rules because the emoji carries U+FE0F.\n* A comment's visible content states a decision or a change in confidence, risk, or scope in one or two short sentences. Implementation detail goes in `🏗️ Agent notes` in the comment or issue body. Progress narration stays in the issue body. The resolution comment keeps its length exemption: a verdict paragraph first, then `🏗️ Agent notes`.\n* The technical-writing rules apply first. Industry-standard terms are free everywhere. Terms from technical literature belong in `🏗️ Agent notes` only when no plainer exact phrase fits; a visible summary also requires a definition and a `CONTEXT.md` entry. Do not coin a term for an issue. An inherited local term stays in `🏗️ Agent notes`.\n* The org `technical-writing` skill in PR #20 above governs word choice; `issue-writing.md` governs structure. Its word list applies to all prose immediately, regardless of the PR's merge state. Exact machine text is exempt.\n* Project updates reach the widest audience. They contain only a summary and the native health field, omit empty sections, and are drafted from issue-comment changes since the previous update. A `brunch-agent` project is planned as their home.\n* `issue-tracker.md` says to read raw descriptions through `linear api` GraphQL rather than `issue view`, which prepends a header that corrupts a fetch, edit, and push operation. Linear's normalization of collapsed-section spacing and bullet markers is expected. Issue references use full URLs so Linear renders them as links.\n\nVerification: `test/docs-index.test.ts` plus the repo's standard checks. This change edits Markdown only. The branch stacks on `ln/fe-1433-petrinaut-integration-spec` because the main worktree is occupied by another agent.\n\n+++",
+          "url": "https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan",
+          "createdAt": "2026-08-19T11:47:39.090Z",
+          "updatedAt": "2026-08-19T16:20:28.510Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+            "identifier": "FE-1401",
+            "title": "Resolve the follow-ups from the stack legibility session"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "9e9da676-3d1a-40b3-8fe8-2b327b1b164a",
+          "identifier": "FE-1449",
+          "title": "A structured brunch question suspends and resumes visibly in Petrinaut",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe next working prototype pulls the proven seams together and remains as the base for later demo work. In Petrinaut's real panel, the actual brunch agent invokes its existing structured `brunch_ask` affordance; a host-supplied component renders the current free-text form; submitting it resumes the suspended Flue conversation through `transport-aisdk`; and the next agent turn appears in the same panel.\n\nThis slice must settle provenance at the wire boundary. A human response submitted by the registered ask component travels in an AI SDK tool-output-shaped message, but it is not a machine tool result. Only a response matching the currently pending brunch ask and its stable tool-call id may be projected into the harness's user-affordance reply path; stale, forged, duplicate, or unrelated tool outputs must not become user evidence. Petrinaut mutation outputs remain non-user machine entries. FE-1395 will extend the form catalog later without replacing this transport distinction.\n\nThe prototype is deliberately legible: normal chat renders reasoning and text, the custom ask component renders its structured question and awaiting/submitted state, and an opt-in inspector or diagnostic surface shows request/turn boundaries, part kinds, correlation ids, suspension, return, and resumption. This observability is committed and tested, while remaining structurally excluded from evidence.\n\n## Acceptance criteria\n\n- [ ] The actual agent invokes `brunch_ask`; Petrinaut renders it through the host component; one submitted answer resumes the same Flue conversation and produces the next visible agent turn\n- [ ] The current free-text affordance envelope and markdown floor are consumed without inventing the choice/questionnaire schemas owned by FE-1395\n- [ ] Only the currently pending ask's correlated human submission becomes a user-affordance reply and may be cited as evidence; stale, forged, duplicate, and non-ask tool outputs fail or remain non-user\n- [ ] Awaiting → submitted → resumed state and stable ids are visibly inspectable alongside the normal panel output\n- [ ] The runnable integration, component registration, server path, and automated proof remain committed; the prototype requires no fetch shim or disposable harness\n- [ ] Contract tests cover the translated ask part and return POST; a real-panel test or runnable story proves the custom component lifecycle\n\n## Blocked by\n\n* FE-1436 (durable real-panel transport and server path)\n* FE-1448 (generic host-supplied interactive tool components in Petrinaut)\n* FE-1422 (portable ask protocol in core)\n* FE-1434 (suspension and machine-result provenance verdict)\n\n## Coordination\n\nFE-1395 owns the later form catalog and reserved structured-tap encoding. This slice proves the transport-level distinction and current free-text form only; FE-1395 consumes it rather than designing a second component mechanism.",
+          "url": "https://linear.app/hash/issue/FE-1449/a-structured-brunch-question-suspends-and-resumes-visibly-in-petrinaut",
+          "createdAt": "2026-08-19T11:18:07.651Z",
+          "updatedAt": "2026-08-19T16:20:28.606Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "In progress", "type": "started" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "f0069303-9b58-47fc-b298-bf96711edff6",
+          "identifier": "FE-1448",
+          "title": "Petrinaut hosts render their own interactive chat tools",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nPetrinaut hosts can supply custom interactive chat-tool components through the public `aiAssistant` configuration. Today the panel has the right internal pattern — an interactive-tool definition with input parsing, a widget, awaiting/submitted state, and `addToolOutput` submission — but its registry is private and hard-coded to Petrinaut's own `applyAutoLayout` tool. Unknown dynamic tools are rejected before a host can render or handle them.\n\nAdd a generic, typed host extension in `@hashintel/petrinaut` and prove it with a synthetic host tool in tests and a visible story or equivalent runnable surface. Built-in Petrinaut tools must keep their behavior; unknown unregistered tools must still fail loudly. This is durable product code in `hashintel/hash`, not a brunch-specific patch or a throwaway spike. It establishes the renderer/handler mechanism only; FE-1395 continues to own the final choice, questionnaire, absence-strip, and plugin-form catalog.\n\n## Acceptance criteria\n\n- [ ] A host can register a tool name, input parser/schema, interactive React component, and submitted-output contract through the public `aiAssistant` API\n- [ ] A registered dynamic tool renders inline with stable `toolCallId`, awaiting/submitted state, and exactly one submitted output available to the AI SDK follow-up\n- [ ] Existing Petrinaut interactive and mutation tools are unchanged, and an unregistered dynamic tool still fails loudly\n- [ ] The public type/API and lifecycle are documented and proved by focused tests plus a visible story or equivalent runnable example\n- [ ] `@hashintel/petrinaut` contains no brunch-specific names, schemas, or components\n- [ ] The implementation is committed on an isolated `hashintel/hash` branch; no temporary monkey-patch or browser shim is part of the proof\n\n## Blocked by\n\nNone. FE-1435 is evidence for the current panel behavior, not a remaining execution blocker.",
+          "url": "https://linear.app/hash/issue/FE-1448/petrinaut-hosts-render-their-own-interactive-chat-tools",
+          "createdAt": "2026-08-19T11:17:52.656Z",
+          "updatedAt": "2026-08-19T16:20:27.813Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "a2741e14-e15a-49a4-b989-59a8eb7d22de",
+          "identifier": "FE-1442",
+          "title": "Captures and completion accounting render live in the demo site",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe presenter-facing differentiation surface: the elicitor's captures — with provenance — and its completion accounting render live in the demo site while the interview runs. This is the demo's core claim made visible: durable capture, accounting, and provenance are exactly what the incumbent prompt-in-a-panel cannot show. The integration spec deliberately deferred the design decision — app-level UI beside the panel vs. a generic `PetrinautSlots` extension — to this ticket's start, when the wiring exists to design against.\n\nInput edge, not a blocker: what the accounting *means* deepens as the process-model plugin lattice (FE-1364 → FE-1387) lands, but harness-side captures and derived completion exist independently of it.\n\n## Acceptance criteria\n\n- [ ] The placement decision (app-level UI vs. `PetrinautSlots`) is recorded before build, with reasoning\n- [ ] Live captures with provenance and completion accounting are visible during an elicitation session\n- [ ] The surface is contained per boundary discipline: app-level, or a generic slots extension usable by any host\n- [ ] The presenter can show capture → net correspondence during the demo without leaving the page\n\n## Blocked by\n\n* FE-1440 (the shipped elicitor mode this surface lives inside)",
+          "url": "https://linear.app/hash/issue/FE-1442/captures-and-completion-accounting-render-live-in-the-demo-site",
+          "createdAt": "2026-08-18T16:30:07.936Z",
+          "updatedAt": "2026-08-19T16:20:27.003Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "09de65ee-2a80-44e3-aa0d-121a839793da",
+          "identifier": "FE-1441",
+          "title": "The elicitor server runs on HASH infrastructure behind the pre-remote gates",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe elicitor server runs on HASH infrastructure — owned jointly with infra, who confirmed Postgres exists and deployment is unblocked once the code lives in `hashintel/hash`. This adds a Postgres-backed storage-port implementation inside the binding (ADR-0002 N5: one implementation per binding × deploy target; the file-path assumption never leaks above the binding), and the public front door: per-principal and per-IP rate limiting plus a CORS origin allowlist, since the localStorage UID is identification, not authentication.\n\nFE-1423 carries the ratified pre-remote gates and blocks this ticket: its auth gate is discharged by FE-1439, restart durability by FE-1396 (existing relation), but runtime telemetry and persisted-state versioning/backup remain FE-1423's own and must hold before the URL leaves the machine.\n\n## Acceptance criteria\n\n- [ ] The server runs on HASH infrastructure with Postgres-backed storage behind the unchanged storage port\n- [ ] Rate limiting (per-principal and per-IP) and the origin allowlist are active at the front door\n- [ ] Every FE-1423 gate is checked off before public exposure\n- [ ] The deployment target's specifics (host, CI, backup expectations) are recorded where infra work is recorded\n\n## Blocked by\n\n* FE-1439 (private sessions — the owner key and principal resolution this exposes publicly)\n* FE-1437 (monorepo import — deployment presumes the code lives in `hashintel/hash`)\n* FE-1423 (pre-remote gates — telemetry and state-versioning remain open there)",
+          "url": "https://linear.app/hash/issue/FE-1441/the-elicitor-server-runs-on-hash-infrastructure-behind-the-pre-remote",
+          "createdAt": "2026-08-18T16:29:43.110Z",
+          "updatedAt": "2026-08-19T16:20:26.907Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "74d0a20a-63f7-40fd-939a-36badc7cdc7b",
+          "identifier": "FE-1440",
+          "title": "demo.petrinaut.org ships the elicitor behind its chat panel",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\n[demo.petrinaut.org](<http://demo.petrinaut.org>) ships an elicitor mode for real: the wiring that tickets FE-1436/38/39 ran against a local checkout is committed to `hashintel/hash` — a brunch route or mode flag in petrinaut-website, the localStorage UID bootstrap, and the transport swap pointing the chat panel at the remote elicitor server. All of it stays app-level (the existing Actual-mode brunch route is the containment precedent), and the stock assistant path is untouched when the mode is off. Any Petrinaut-library change discovered here is made as a generic host extension, never brunch-specific code — ADR-0004's boundary discipline.\n\nInput edge, not a blocker: the demo's *content* — captures projecting into a running net — converges from the process-model plugin lattice (FE-1364 → FE-1387 second-target decision). This ticket's wiring is complete and verifiable without it.\n\n## Acceptance criteria\n\n- [ ] [demo.petrinaut.org](<http://demo.petrinaut.org>) (or its preview deployment) offers the elicitor mode reaching the remote server\n- [ ] All brunch-specific code sits at app level; no `@hashintel/petrinaut` change beyond generic host extensions\n- [ ] The stock assistant path is byte-for-byte unaffected when the mode is off\n- [ ] Removing the mode later would touch only app-level files\n\n## Blocked by\n\n* FE-1438 (client-tool round-trip — the behavior the mode ships)\n* FE-1439 (private sessions — the UID bootstrap this commits)\n* FE-1437 (monorepo import — the wiring lands in `hashintel/hash` only after the code lives there)",
+          "url": "https://linear.app/hash/issue/FE-1440/demopetrinautorg-ships-the-elicitor-behind-its-chat-panel",
+          "createdAt": "2026-08-18T16:29:42.210Z",
+          "updatedAt": "2026-08-19T16:20:26.864Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "9ef17013-2343-49cb-83df-356022621061",
+          "identifier": "FE-1439",
+          "title": "Elicitation sessions are private per browser and survive a reload",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nA visitor's elicitation is theirs: it survives a page reload, and another browser cannot see or alter it. The demo site mints a random UID into localStorage and sends it on every transport request; the host-authored server layer resolves principal → session set; the harness stays principal-free (session-id keyed). The storage port gains an **opaque owner key**, stamped at session creation — cross-principal access fails as a store-level refusal, the port's existing enforcement idiom, red-proved per the FE-1419 discipline.\n\nThe principal is deliberately ui-shell-owned (spec §4) so HASH's Ory identity can replace the localStorage UID later without touching the harness. The UID is identification, not authentication — the demo threat model accepts this; the front-door mitigations (rate limiting, origin allowlist) are the deployment ticket's. This ticket implements the auth/per-conversation-authorization gate of FE-1423 for the elicitor server. The kernel spec §9.6 owner-key amendment lands here.\n\n## Acceptance criteria\n\n- [ ] Reloading the page resumes the same session and transcript; a different browser profile cannot read or write it\n- [ ] The owner key is opaque to the binding; cross-principal refusals are proved red-first at the store seam\n- [ ] The harness remains principal-free — no principal type appears in `core`\n- [ ] Spec §9.6 gains the owner-key amendment in the same change\n- [ ] FE-1423's auth gate is checked off with a pointer here\n\n## Blocked by\n\n* FE-1436 (conversation slice — the server and wire path this scopes)",
+          "url": "https://linear.app/hash/issue/FE-1439/elicitation-sessions-are-private-per-browser-and-survive-a-reload",
+          "createdAt": "2026-08-18T16:29:06.129Z",
+          "updatedAt": "2026-08-19T16:20:26.834Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "d700fad6-f04b-4191-91b1-a7efcd5942ca",
+          "identifier": "FE-1438",
+          "title": "The elicitor builds and repairs the net through Petrinaut's client-executed tools",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe demo's central beat: answering the elicitor's questions makes the net appear and change on the Petrinaut canvas. The elicitor drives the panel's existing client-executed tool surface — the panel runs known tools against the live editor and posts the outputs back — via a new **external-tool round-trip protocol** in `core`, sitting beside the ask protocol on the same suspension floor and shaped by the suspension spike's verdict (FE-1434) on batch-vs-pending-slot.\n\nThe elicitor's Petrinaut tools are generated from `petrinaut-core`'s exported tool schemas, so the tool surface tracks Petrinaut's own contract rather than a hand-copied one. Provenance is a hard invariant: returned tool outputs enter as machine entries, mechanically excluded from evidence-span anchoring (§9.4) — capture spans only ever cite the user. Retries and duplicate dispatches are idempotent per the affordance-protocol guarantees FE-1420 establishes.\n\n**Coordination note (soft, deliberate):** FE-1395's questionnaire chaining stands on the same pending-slot batching ground. Either may land first, but not concurrently by different agents — whichever lands first writes the §7.3/§7.4 amendment; the other consumes it.\n\n## Acceptance criteria\n\n- [ ] Answering in the panel produces net mutations on the canvas through client-executed tools, and the elicitor sees TypeScript diagnostics after code-writing mutations\n- [ ] The round-trip protocol lives in `core`, tested substrate-free at the ask-protocol seam (FE-1422's extraction is the prior art)\n- [ ] Tool schemas are generated from `petrinaut-core`'s contract, not hand-copied\n- [ ] Returned tool outputs are machine entries: citing one as evidence is mechanically refused, red-proved\n- [ ] A duplicate dispatch of the same tool outputs does not double-apply\n- [ ] The §7.3/§7.4 amendment has landed — here or already via FE-1395, per the coordination rule\n\n## Blocked by\n\n* FE-1434 (suspension spike — the batch-binding verdict shapes the protocol)\n* FE-1436 (conversation slice — the wire path this rides on)\n* FE-1422 (ask protocol in core — the protocol home this extends)\n* Coordinate with (not blocked by): FE-1395",
+          "url": "https://linear.app/hash/issue/FE-1438/the-elicitor-builds-and-repairs-the-net-through-petrinauts-client",
+          "createdAt": "2026-08-18T16:29:05.349Z",
+          "updatedAt": "2026-08-19T16:26:26.410Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "6657aae7-2640-462d-8cdd-033c3395fb20",
+          "identifier": "FE-1437",
+          "title": "@hashintel/brunch-agent lives in hashintel/hash with its history preserved",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe move: the library becomes `@hashintel/brunch-agent` and is imported into `hashintel/hash` with git history preserved, as a sibling of `@hashintel/petrinaut`, adopting the hash toolchain (the Bun workspace scaffolding is an accepted write-off, per FE-1388's own trade-off note). Harness-internal work continues in this repo up to the move and travels with the history import.\n\nTwo preconditions per ADR-0004: the spikes have reported (FE-1434, FE-1435 — blocking relations), and the currently open PRs have merged (the FE-1388/89/90/99 review stack — a state-of-the-world gate, not a ticket edge). The §12.2 import note and the §13/N3 amendment (demo shell retired; `apps/dev` remains the local harness) land with the move.\n\n## Acceptance criteria\n\n- [ ] The package builds and its full test suite runs green under the hash toolchain\n- [ ] Git history is preserved: blame on moved files reaches pre-import commits\n- [ ] Boundary discipline survives the move as enforced gates: `@hashintel/petrinaut` remains elicitor-agnostic, `@hashintel/brunch-agent` renderer-agnostic, applications the only meeting point\n- [ ] Kernel spec §12.2 (import note) and §13/ADR-0002-N3 (no demo shell) amendments land with the move\n\n## Blocked by\n\n* FE-1434 (suspension spike — the import waits for the spikes to report)\n* FE-1435 (adapter spike — same gate)\n* Prose precondition: the open review stack merges first",
+          "url": "https://linear.app/hash/issue/FE-1437/hashintelbrunch-agent-lives-in-hashintelhash-with-its-history",
+          "createdAt": "2026-08-18T16:28:26.809Z",
+          "updatedAt": "2026-08-19T16:20:27.220Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "ab26c181-64ab-43e1-bd8a-1aebcb27a961",
+          "identifier": "FE-1436",
+          "title": "The elicitor answers conversation turns in Petrinaut's real chat panel",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## What to build\n\nThe first durable tracer bullet: a locally-run Petrinaut panel holds a real conversation with the actual elicitor — text and reasoning only, no editor mutations yet. This turns the adapter spike's throwaway harness into production-intent code: a `transport-aisdk` package (the server end of the UI shell's reply transport — harness-level parts translated to UI-message-stream chunks, using the `ai` package for stream encoding only; inference stays on Pi's adapter layer) plus a thin host-authored server module around the harness.\n\nThe working integration is not a disposable prototype. Its server route, launch path, transport implementation, and verification fixtures are committed and become the base for the structured-ask and editor-tool slices. The local integration mode should make the protocol legible while it runs: request/turn boundaries, emitted part kinds, stable message/tool-call ids, and terminal state are observable without editing fixtures or attaching a debugger. That visibility is diagnostic metadata or an inspector surface; it must not be fed back as user evidence.\n\nThe wire seam becomes the contract-test surface here: tests drive the server exactly as the panel's wrapped transport does, replaying the spike's golden fixtures, so panel compatibility is provable without a browser. The kernel spec §12.2 amendment (the new `transport-*` role prefix and the package itself) lands in the same change — spec stays true to code.\n\n## Acceptance criteria\n\n- [ ] A locally-run panel (local `hashintel/hash` checkout) converses with the actual elicitor end to end\n- [ ] The runnable server/transport path is committed production-intent code; no browser fetch shim or disposable server loop remains necessary\n- [ ] `transport-aisdk` consumes harness-level parts only; the boundary gates prove it imports neither the binding nor Flue\n- [ ] Wire-seam contract tests replay the golden fixtures against the real server — no browser in CI\n- [ ] The local integration visibly exposes request/turn boundaries, emitted part kinds, stable ids, and completion state without laundering diagnostics into user evidence\n- [ ] Kernel spec §12.2 gains the `transport-*` prefix and the new package in the same change (`adapter-*`/`wrapper-*` stay avoided terms)\n\n## Blocked by\n\n* FE-1435 (adapter spike — feasibility and the golden fixtures)",
+          "url": "https://linear.app/hash/issue/FE-1436/the-elicitor-answers-conversation-turns-in-petrinauts-real-chat-panel",
+          "createdAt": "2026-08-18T16:28:26.051Z",
+          "updatedAt": "2026-08-20T08:02:57.380Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "be347053-9e39-4bdf-a2ae-480413f8e122",
+          "identifier": "FE-1435",
+          "title": "Spike: does a harness-driven stream drive Petrinaut's real chat panel?",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## Question\n\nCan a server translating harness-level parts into the AI SDK v6 UI-message-stream protocol drive Petrinaut's real chat panel? The panel wraps whatever transport the host supplies with its own decorators, so the whole integration rests on our stream being indistinguishable from the stock one — text and reasoning render, server-executed tool parts render through the panel's default summaries, client tool calls execute against the live editor, and the diagnostics decorator fires.\n\nThis is the second gating spike. It is a throwaway prototype of the `transport-aisdk` layer, run against a local `hashintel/hash` checkout with zero commits there. Its transcript is the durable output: frozen as the golden fixtures the wire-seam contract tests replay from then on (freeze/replay posture per kernel spec §14.4).\n\n## Acceptance criteria\n\n- [ ] The real panel renders streamed text and reasoning from the prototype server\n- [ ] A client tool call round-trips: the panel executes it and posts the outputs back\n- [ ] Server-executed tool parts render via the panel's default tool summaries\n- [ ] The diagnostics decorator fires on the wrapped transport\n- [ ] The full transcript (POST bodies including batched tool outputs; SSE chunk streams) is frozen as golden fixtures\n- [ ] A written verdict; zero commits to `hashintel/hash`\n\n## Blocked by\n\nNone — can start immediately, in parallel with the suspension spike (a fake server loop suffices; no suspension machinery needed).",
+          "url": "https://linear.app/hash/issue/FE-1435/spike-does-a-harness-driven-stream-drive-petrinauts-real-chat-panel",
+          "createdAt": "2026-08-18T16:27:48.712Z",
+          "updatedAt": "2026-08-20T08:02:57.126Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "8d6d702a-baa1-4c5a-8f7a-d6bb3cd26569",
+          "identifier": "FE-1434",
+          "title": "Spike: does Flue turn suspension carry batched client-tool round-trips?",
+          "description": "## Parent\n\nFE-1433 (the integration spec; ADR-0004 is the decision record).\n\n## Question\n\nCan Flue end a turn with client-tool calls pending and resume on a later dispatch — per-session state intact, the batched outputs re-entering the loop as machine entries? This is the first of the spec's two gating spikes: the external-tool round-trip is designed to ride the same suspension floor as the ask protocol (one substrate capability, two core protocols), and that only holds if the substrate carries the shape.\n\nThe verdict feeds two consumers: the external-tool round-trip protocol ticket (this graph) and FE-1395's questionnaire chaining, which stands on the same pending-slot batching ground. Failure here is not failure of the harness: it selects the spec's doc-handle fallback for the demo and files as evidence toward a `binding-pi`.\n\nSpec: integration spec (FE-1433) testing decisions; kernel spec §7.3/§7.4 (suspension, one live affordance), §9.4 (provenance discrimination), §10 (binding capabilities).\n\n## Acceptance criteria\n\n- [ ] A written verdict records whether terminate-with-pending plus resume-on-dispatch holds, referencing the probe code or transcript\n- [ ] The verdict states whether batched outputs (several tool results in one dispatch) bind cleanly, and adjudicates batch-as-pending-slot-variant vs. a parallel channel — or names exactly what remains undecided for the protocol ticket\n- [ ] Returned tool outputs demonstrably enter as non-user entries (never anchorable as evidence)\n- [ ] Observed round-trip counts are noted against the tool-call-per-element scaling concern (survey §6d: a 40-place net is ~100 mutations)\n- [ ] On failure: the doc-handle fallback is selected in writing and the evidence filed toward a second binding\n\n## Blocked by\n\nNone — can start immediately. The spike is throwaway; only the verdict persists.",
+          "url": "https://linear.app/hash/issue/FE-1434/spike-does-flue-turn-suspension-carry-batched-client-tool-round-trips",
+          "createdAt": "2026-08-18T16:27:47.691Z",
+          "updatedAt": "2026-08-20T08:02:57.068Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+            "identifier": "FE-1433",
+            "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "0237ff1c-c090-46b9-bc8b-5e0887f34897",
+          "identifier": "FE-1433",
+          "title": "The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server",
+          "description": "The 2026-08-18 integration meeting settled the September demo's staging: the elicitor is presented inside [demo.petrinaut.org](<http://demo.petrinaut.org>)'s existing chat panel, not in a separate demo application. The brunch elicitor therefore runs as a remote server that Petrinaut's chat UI talks to through its host-pluggable transport, with the elicitor's sessions, captures, and IRs persisted server-side and keyed to the visitor's browser. The library is renamed `@hashintel/brunch-agent` and will be imported (with git history) into the `hashintel/hash` monorepo as a sibling of `@hashintel/petrinaut` once the currently open PRs merge.\n\nThis issue carries the integration spec for that architecture. The decision itself is recorded in ADR-0004 (`docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md`), which supersedes the demo-shell recommendation (`docs/planning/process-model-elicitation/recommendation-demo-vehicle.md`). The spec document is at `docs/planning/process-model-elicitation/petrinaut-integration-spec.md` — seams, user stories, implementation and testing decisions, and the spike-gated questions.\n\nThe two original spikes have now reported. Flue carries batched suspension through a non-user signal (FE-1434), and the AI SDK v6 wire shape drives Petrinaut's real panel (FE-1435). A third seam surfaced before implementation: Petrinaut's internal interactive-tool registry is not host-extensible, and a human answer returned through an AI SDK tool-output-shaped message must not be confused with a machine tool result. FE-1448 adds the generic host component mechanism; FE-1449 is the durable, visibly inspectable prototype that proves the actual brunch ask suspends and resumes without laundering provenance.\n\nRelated: FE-1333 (the integration-definition ticket this spec answers; closes on the ADR), FE-1357 (parent map).\n\n---\n\n## Delivery graph\n\nThe spec's execution breakdown, including the edges into the pre-existing build and demo maps. Blocker on the left, blocked on the right.\n\n```text\nlegend:\n  [ready]        dependency-clear\n  [done]         evidence or implementation complete\n  [open]         not started, dependencies remain\n  -[hard]->      Linear blocking relation (functional or must-prove-first)\n  -[coord]->     either order, never concurrent by different agents;\n                 whichever lands first writes the §7.3/§7.4 amendment\n  -[input]->     design dependency, not a blocker\n  -[state-gate]  precondition on the state of the world, not a ticket\n\nnodes (this graph):\n  FE-1434: spike [done]  #suspension\n  FE-1435: spike [done]  #adapter\n  FE-1436: slice [ready] #durable-conversation-in-panel\n  FE-1448: slice [ready] #host-interactive-tool-components (hashintel/hash)\n  FE-1449: slice [open]  #visible-structured-ask-prototype\n  FE-1438: slice [open]  #client-tool-round-trip\n  FE-1439: slice [open]  #private-sessions\n  FE-1437: move  [open]  #monorepo-import\n  FE-1440: wiring [open] #website-elicitor-mode\n  FE-1441: deploy [open] #infra\n  FE-1442: surface [open] #interpretation-render\n\nnodes (pre-existing, cross-map):\n  FE-1422: capability [in review] #ask-protocol-in-core (build map)\n  FE-1395: capability [open]      #full-affordance-catalog (build map)\n  FE-1396: capability [open]      #restart-durability (build map)\n  FE-1423: release-gate [open]    #pre-remote-gates (demo map)\n  FE-1364 -> FE-1387: plugin lattice [in motion] #demo-content\n\nedges:\n  FE-1435 -[hard]-> FE-1436\n  FE-1436, FE-1448, FE-1422, FE-1434 -[hard]-> FE-1449\n  FE-1449 -[hard]-> FE-1438\n  FE-1395 -[coord]-> FE-1438, FE-1449\n  FE-1434, FE-1435 -[hard]-> FE-1437\n  FE-1436 -[hard]-> FE-1439\n  FE-1437, FE-1438, FE-1439 -[hard]-> FE-1440\n  FE-1437, FE-1439, FE-1423 -[hard]-> FE-1441\n  FE-1396 -[hard]-> FE-1423\n  FE-1440 -[hard]-> FE-1442\n  FE-1364/FE-1387 lattice -[input]-> FE-1440, FE-1442\n  open review stack (FE-1388/89/90/99) -[state-gate]-> FE-1437\n\nfrontier:\n  now: FE-1436 in brunch-lite and FE-1448 in hashintel/hash, in parallel\n  next proof: FE-1449, a durable real-panel ask round-trip with visible lifecycle\n  after proof: FE-1438 and FE-1439; FE-1437 only when its review-stack gate clears\n\nstack topology (brunch-lite):\n  FE-1433 -> FE-1434 -> FE-1435 -> FE-1436 -> FE-1449 -> FE-1438 ...\n  FE-1448 is a coordinated hashintel/hash branch and cannot share this Git ancestry.\n```\n\nAdjudications recorded alongside this breakdown: FE-1362 re-resolved to ADR-0004; FE-1333 answered by it; FE-1331 un-deferred; FE-1330 path updated; FE-1423 re-scoped from demo shell to elicitor server (auth gate → FE-1439); FE-1387 pressure note (staging makes the process-model plugin the demo-content path). FE-1449 deliberately uses only the current free-text affordance; FE-1395 retains ownership of choices, questionnaire chaining, absence taps, and plugin forms.",
+          "url": "https://linear.app/hash/issue/FE-1433/the-elicitor-serves-demopetrinautorgs-chat-panel-from-a-remote-brunch",
+          "createdAt": "2026-08-18T16:02:33.101Z",
+          "updatedAt": "2026-08-20T08:02:57.029Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "a3bcc46c-adb3-4b34-9668-42448b9295e3",
+          "identifier": "FE-1432",
+          "title": "The stack's open review threads are adjudicated: fixed, owned, or refused on the record",
+          "description": "A cross-stack review of the unresolved inline PR threads ran 2026-08-18: 24 threads across 10 PRs, of which 9 were resolved with evidence-backed upstack replies and 15 remain open. The review also induced five reusable lenses, and the findings that survived under them are concrete: two capture-store closure gaps (overlapping conflicts can strand one another, and the persisted parser accepts a duplicate `issue-closed` event the command API refuses to produce), two completion-metadata drops (expert truncation is discarded, and a non-final interviewer response can stay truncated past the continuation cap without being marked incomplete), a boundary-honesty gap (`plugin-gherkin` declares `valibot` without importing it, and the boundary test checks the dependency relation in one direction only), and two test-setup holes (the capture-store test ignores setup results and leans on non-null assertions; the walking-skeleton integration test can throw while inspecting an absent reply context).\n\nFWIW several of these are not new discoveries — they are FE-1419's deliberate out-of-scope list coming due (unused-dependency cleanup, expert-truncation handling, advisory-loop tuning were all named there and deferred). This ticket is the FE-1401-style consolidation point: done means every row in the queue document lands in a commit, moves to a named owner, or is refused with a reply on its PR thread — and the 15 still-open threads each get the same adjudication.\n\n---\n\n## Execution record\n\n* **Queue document (repo-canonical):** `docs/planning/legibility-sweep/review-remediation-2026-08-18.md` — ledger rows with provenance, owners, and dispositions\n* **Provenance:** PR-thread review 2026-08-18 (24 threads / 10 PRs; 9 resolved upstack at review time; lenses 1–5 induced, three graduation proposals recorded for the tooling side)\n* **Prior art:** `refactor-queue-2026-08-14.md` → FE-1419 (executed); `remediation-plan-2026-08-17.md` ledgers A/B — same lineage, same exit rule (rows leave by commit, ticket, or decision)",
+          "url": "https://linear.app/hash/issue/FE-1432/the-stacks-open-review-threads-are-adjudicated-fixed-owned-or-refused",
+          "createdAt": "2026-08-18T11:50:28.029Z",
+          "updatedAt": "2026-08-20T08:02:56.984Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+            "identifier": "FE-1401",
+            "title": "Resolve the follow-ups from the stack legibility session"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "8dab8aa3-64a8-4777-ac99-a39095d365ce",
+          "identifier": "FE-1431",
+          "title": "Plugin authoring becomes declarative: a domain is two schemas and two tables",
+          "description": "Today every new elicitation domain looks like an engineering project: the capture store says how evidence is kept, but nothing says what a domain author must write down to make the machinery elicit *their* domain, and nothing turns a pile of typed captures into the thing the user wants — a model of their plant, their feature, their system. Completion questions (\"is this model good enough to answer my objective?\") have no model to be asked of, and semantic judgments risk hiding inside read paths where nobody can audit them.\n\nThe FE-1405 shapes work settled an answer, now written up as a provisional spec: a plugin is **two schemas and two small tables** — declare your domain's node kinds and slots, declare the typed proposals that fill them (annotated with how to elicit each), and say what your completion anchors demand; fold rules mostly derive. The elicited model is derived from captures by a pure fold (ADR-0003), all interpretation happens at write time as contestable captures, and model gaps mechanically cue grounded follow-up candidates. Interviewing strategy decides whether to ask, propose a likely structure for correction, or leave a visible gap. The spec is desk-validated on the baseline transcripts and cross-plugin thumbnails (Gherkin, formal verification, CPS); its ratification condition is a full worked pass across three plugin targets, and its open questions are carried as first-class sections with owning tickets rather than folded into the design.\n\n---\n\n## Execution record\n\n* **Spec (repo-canonical):** `docs/planning/process-model-elicitation/plugin-contract-spec.md`\n* **Decision it builds on:** `docs/adr/0003-three-register-ir.md` (three registers; write-time-only semantics; promotion never refusal; acceptance oracle)\n* **Status:** provisional — the FE-1397-style ratification pass is the condition for removing the marker\n* **Test seams (accepted 2026-08-18):** the pure fold as the single golden seam (hand-worked C1 capture sets → asserted slot states; seed gold set doubles as FE-1407 rubric material); the acceptance oracle as an executable structural test; contract validation against the harness meta-schema + table-driven fold-rule derivation tests\n* **Open strains with owners (spec §Open strains):** grade sources worked pass → FE-1393; support closure → FE-1393/FE-1402; temporal patterns roped off; sweep-time concentration mitigations → FE-1392/FE-1403/FE-1407; absence locator → FE-1383 seam (CONVERGENCE)\n* **Strategy boundary (2026-08-19):** `firesWhen` remains a mechanical source of candidates, not an instruction to ask every question. [FE-1406](https://linear.app/hash/issue/FE-1406) owns kickoff, candidate selection, proposal-and-correction, and the rule that generated suggestions do not become captures before confirmation. Kickoff occurs before slot-state cues exist, so ratification must not assume all interviewing starts from `firesWhen`.\n* **Consumers:** FE-1393 (fold engine / plugin SDK — boundary table + machinery typology are its design input), FE-1392 (sweep executor — JSON-Schema tool input, honest defaults), FE-1402 (completion over slot states), FE-1403 (technique cards — `firesWhen`/`technique` hook points), FE-1406 (generic strategy over candidates), FE-1407 (gold set)",
+          "url": "https://linear.app/hash/issue/FE-1431/plugin-authoring-becomes-declarative-a-domain-is-two-schemas-and-two",
+          "createdAt": "2026-08-18T11:29:01.438Z",
+          "updatedAt": "2026-08-19T16:20:27.703Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "c7ddbae5-80e1-45ec-b3a3-7f80bd3b4b16",
+          "identifier": "FE-1424",
+          "title": "The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable",
+          "description": "The documentation protocol (`docs/agents/documentation.md`) specified zones and a sweep that were never fully executed, and practice drifted past it in two places. Ratified by Lu 2026-08-17, this issue runs it and amends it:\n\n1. **Settle the inbox**: create the specified-but-never-created `docs/reference/`, settle all seven inbox documents there, update INDEX rows and every inbound link (repo and Linear descriptions).\n2. **Reshape** `docs/planning/`: cross-effort *living* documents (CONVERGENCE, topology, the Flue cheatsheet) move to `docs/planning/_shared/`; dated *records* (remediation plan, patterns audit, refactor queue) move into a `legibility-sweep/` effort directory. Rule: the planning top level contains only directories; living docs never carry dates, records always do.\n3. **Gate INDEX coverage**: a `test/docs-index.test.ts` asserting set equality between files under `docs/**` and INDEX rows (both directions), plus the planning-top-level structural rule — red-proved like the other boundary gates. Freshness stays procedural (a mechanical freshness check would be a dead gate).\n4. **Consolidate arc-close**: the three arc-close procedures scattered across `legibility.md` (consolidation), `issue-tracker.md` (registry audit), and `documentation.md` (inbox sweep) become one triggerable checklist at `docs/agents/arc-close.md`, with a thin project-level skill wrapper.\n5. **Ephemeral-reference convention** (into `documentation.md`): issue IDs glossed at first mention in living docs; load-bearing only in the tracking layer; tense repair at arc close.",
+          "url": "https://linear.app/hash/issue/FE-1424/the-documentation-protocol-runs-end-to-end-inbox-settled-planning",
+          "createdAt": "2026-08-17T12:54:55.064Z",
+          "updatedAt": "2026-08-20T08:02:56.935Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+            "identifier": "FE-1401",
+            "title": "Resolve the follow-ups from the stack legibility session"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "6346d433-bc32-4c3b-a26d-bec83a8a14ca",
+          "identifier": "FE-1423",
+          "title": "The demo shell is safe to expose beyond localhost",
+          "description": "The mounted Flue agent route is public today: anyone who can reach the server can open or continue conversations under any conversation id. That is fine on localhost and disqualifying the moment the URL leaves the machine. This ticket carries the gates that must hold before the demo shell is exposed beyond localhost. It blocks remote exposure, not the demo itself.\n\nOrigin: the Flue-vs-tilde analysis's recommended course (`docs/reference/amp-analysis-flue-vs-tilde.md`), carried through the architecture cheatsheet's reconciliation section (`docs/planning/_shared/flue-architecture-cheatsheet.md`) and the routing table's pre-remote row (`docs/agents/flue-routing.md`), and tracked as Ledger A10 in `docs/planning/legibility-sweep/remediation-plan-2026-08-17.md`. On 2026-08-17 Lu ratified these as **requirements**, not recommendations — a demo deployment conversation with infra is already underway, so the gates are schedule-relevant now.\n\n## Gates\n\n- [ ] **Authentication + per-conversation authorization** on the mounted route — a caller can reach only conversations they own. Per the routing guide, auth belongs in app middleware around the explicit mounts in `app.ts`, not inside agents.\n- [ ] **Runtime telemetry** — wire the `observe()` → OTel path so a remote failure is visible. Design note (Lu, 2026-08-17): inspection is the floor, not the ceiling — the intent is to incorporate traces (reasoning, skills, tool use) into our own feedback loops and oracles as we develop. Build the floor so it doesn't preclude that: structured, attributable spans, not just a liveness signal.\n- [ ] **Persisted-state versioning and backup expectations** — decide what happens to durable state across our own schema changes (the capture store already parses on read; Flue's format versioning refuses to start on mismatch — our stance on migration vs. refusal is undecided), and what backup means on the chosen deploy target.\n- [ ] **Restart durability** — owned by FE-1396 (blocking relation); listed here so the gate checklist is complete in one place.\n\n## Deploy-target note\n\nADR-0002 rule N5 applies: a new deploy target means a new storage-port implementation inside the binding package (the Cloudflare case is per-object SQLite behind the same `CaptureStore` port). The file-path assumption never leaks above the binding.",
+          "url": "https://linear.app/hash/issue/FE-1423/the-demo-shell-is-safe-to-expose-beyond-localhost",
+          "createdAt": "2026-08-17T12:35:57.956Z",
+          "updatedAt": "2026-08-19T16:20:27.185Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "91a93db7-c088-4b26-a521-0385d2db713a",
+          "identifier": "FE-1422",
+          "title": "The ask protocol is substrate-portable: mechanism moves from the Flue binding into core",
+          "description": "The walking skeleton put the whole ask/suspension protocol inside the Flue binding: the affordance id scheme, the one-live-affordance rule, the reply-binding signal payload, and the elicitation instruction text all live interleaved with hook wiring in binding-flue/src/index.ts, while packages/core exports only schemas and naming. That is the spec's second-binding test failing in spirit (§14.2): a second binding would have to re-implement the protocol rather than reuse it, and every slice that adds mechanism the same way deepens the debt — the sweep work (FE-1392) is the next one that would.\n\nThe fix is an extraction, not a redesign: a pure ask-protocol module in core (mint an affordance from question + call id, the one-live guard as a pure decision, the signal payload builder, the instruction fragments), with useElicitation reduced to hook wiring — hooks in, protocol calls out. Scheduled ahead of FE-1392 so sweep mechanism can start in core the same way (sweep-protocol) from day one.\n\n---\n\n## Execution record\n\n* Findings and evidence: remediation ledger A1 (docs/planning/legibility-sweep/remediation-plan-2026-08-17.md), topology rule N1 (docs/planning/_shared/topology.md — names the four exports that are portable mechanism vs. the hook wiring that correctly stays), deep-read docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md.\n* Acceptance: binding-flue/src/index.ts contains no protocol decisions, only hook translation; the walking-skeleton integration test (do-not-weaken) stays green unmodified — it pins behavior, not placement.\n* Blocks FE-1392 by design (sequencing: docs/planning/_shared/CONVERGENCE.md, second evaluation).",
+          "url": "https://linear.app/hash/issue/FE-1422/the-ask-protocol-is-substrate-portable-mechanism-moves-from-the-flue",
+          "createdAt": "2026-08-17T12:18:55.028Z",
+          "updatedAt": "2026-08-20T08:02:56.900Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "cc085f83-5540-4120-978e-0c4a2be33f68",
+          "identifier": "FE-1420",
+          "title": "The affordance protocol survives retries, unknown forms, and abandoned asks",
+          "description": "The FE-1389 deep-read (notes/deep-read-fe-1389.md, from the FE-1401 remediation sweep) found three places where the new ask/affordance protocol fails unsafely rather than safely. Flue re-executes tools at-least-once, and a re-executed ask mints the identical affordance — but the pending-slot guard checks only that the slot is occupied, so a benign retry is refused as if the model had asked a second question. The dev UI validates the whole concrete free-text form and renders nothing on a parse failure, so the first affordance of any other form will blank instead of falling back to the markdown floor the spec requires (§7.2/§7.7 — the envelope needs its own schema with the payload opaque). And an ask whose reply never arrives occupies the slot forever: nothing records an `unanswered` outcome (§7.5) and no advisory reports the stuck state (§8.6), so every later ask is refused silently.\n\nNone of these blocks the walking skeleton — they are the hardening it deliberately deferred — but the retry refusal will start firing as soon as anything (like the settlement trigger) makes re-execution common, and the markdown floor breaks the moment a second affordance form lands.\n\n---\n\n## Execution record\n\nFindings, from the deep-read (file refs as of 81e9ce0):\n\n1. **Retry misreported as duplicate ask** — `packages/binding-flue/src/index.ts` pending-slot updater tests `current !== null`; should tolerate `current.id === affordance.id` (id is deterministic in `toolCallId`, so re-execution is detectable). One-line fix + a test that replays the same tool call.\n2. **Markdown floor absent in the UI** — `apps/dev/src/ui/chat.tsx` `safeParse(FreeTextAffordance, part.data)` returns null on failure. Needs an envelope-only schema (id / form / markdown, payload opaque) rendered as the fallback; ticket 10 §5 proved the intended behavior.\n3. **No escape from an occupied slot** — slot clears only on `kind: 'user'` delivery; spec §7.5's `unanswered` outcome and §8.6's unaccounted-ask advisory are the intended relief valves, neither exists.\n\nSource: docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md (builder's account, \"genuinely bug-shaped\" items 1–3).",
+          "url": "https://linear.app/hash/issue/FE-1420/the-affordance-protocol-survives-retries-unknown-forms-and-abandoned",
+          "createdAt": "2026-08-17T10:36:08.997Z",
+          "updatedAt": "2026-08-19T16:20:26.642Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "8e71ae1b-cdab-4071-929c-9d42090ea8fa",
+          "identifier": "FE-1419",
+          "title": "Close the seams where the capture store and verification gates claim more than they enforce",
+          "description": "An inductive review of the open PR comments (2026-08-14) found two seams that still claim more than their implementations support. The capture store applies different rule sets at command time, persisted-parse time, and lifecycle-transition time — so a command can return success for a snapshot the next read rejects, and an open conflict can end up with no legal way to close. And the verification layer still infers runtime facts from source text: substring and regex proxies stand in for \"the gap closed\", \"CI ran this gate\", \"this test is hermetic\". Until these close, green gates and successful commands overstate what is actually guaranteed — the same silent-failure family the FE-1399/FE-1400 sweeps addressed, one level deeper (two of the queue's commits replace countermeasures FE-1400 itself introduced).\n\nThe plan is a nine-commit queue that gives each contract one owner and makes negative results precise; it is authored and ready to execute.\n\n---\n\n## Execution record\n\n* Plan document: `docs/planning/legibility-sweep/refactor-queue-2026-08-14.md` — problem statement, nine ordered commits, interface/schema/lifecycle decisions, testing decisions, out-of-scope list.\n* Provenance: inductive review over the open stack's PR comments; second-order findings against FE-1400's own countermeasures (citation-token gap closure → explicit open-gap ledger whose entries are deleted by the proof commit; parsed-step matching → exact declared commands).\n* Depends on the FE-1390 capture store and FE-1400 verification changes landing first (the queue refactors both).",
+          "url": "https://linear.app/hash/issue/FE-1419/close-the-seams-where-the-capture-store-and-verification-gates-claim",
+          "createdAt": "2026-08-17T10:16:58.617Z",
+          "updatedAt": "2026-08-19T16:20:27.978Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "402ad841-52a0-4c54-adae-908ac23af642",
+          "identifier": "FE-1407",
+          "title": "Catalogue the frontier-elicitor failure modes the published instruments cannot see",
+          "description": "## Question\n\n**What are the failure modes of a frontier-model elicitor — catalogued at the level where our instruments can detect them and our machinery can be held accountable for preventing them?** The Bano/Ferrari taxonomy scored both baseline conditions nearly clean because it was built from human-novice mistakes; the failures that actually occurred (the pleasantry loop, deliverable deferral, silent hardening, the phantom-second-session exit, coverage blindness invisible to self-report) live outside its categories. [FE-1361](https://linear.app/hash/issue/FE-1361/baseline-control-what-does-one-shot-ai-elicitation-already-achieve) demonstrated that our real adversary has a different failure distribution than any published instrument measures. Every future scoring pass — FE-1404's condition 3, the eventual evaluation proxy, regression checks when the substrate model upgrades — needs a taxonomy built from *this* distribution.\n\nSeed entries from the baseline, each with its observed instance, its detection signature, and the machinery layer accountable for it: the pleasantry loop (interview over, deliverable never coming; no-progress detection); deliverable deferral behind self-prescribed data pulls (C1 — note the cause was a virtue: refusal to invent); the phantom commitment (C2's second session — see the nuance below); silent hardening (vague utterance → precise constant filed as confirmed; write-time epistemic status); never-asked coverage blindness (self-report structurally cannot see it; computed coverage); complementary-miss luck (one run's coverage is materially chance; same); the dead-artifact delivery (specification instead of loadable model; validate + project); invented-instrument leakage (the SHADE scale, the truck schedule — fabrications *inside* confirmed rows).\n\nOne entry needs care rather than prohibition: **deferral is not itself a failure**. The architecture supports multi-session elicitation against a target-document (sessions go quiet rather than close), and real practice has legitimate deferrals everywhere. The failure mode is *deferral without deposit* — deferring work without materializing it as stored state (typed `missing` issues, recorded absences, a re-entry briefing to inherit). C2's second-session move would have been *correct behavior* on the real architecture; it failed in the baseline because nothing persisted, so deferral equalled loss. The catalogue must distinguish licensed deferral (deposit made, adjudication updated) from evasive deferral (deferral substituting for adjudication), or condition 3's scoring will punish the wrong thing.\n\nMethod: sweep both baseline transcripts plus the literature's failure inventories (LLMREI's premature-ending, ReqElicitGym's budget exhaustion, Bano's residually-applicable items) into a typed catalogue: name, mechanism (why a trained-cooperative model produces it), detection signature (what an instrument or classifier looks for), accountable layer (disposition / technique / machinery, per the [FE-1361](https://linear.app/hash/issue/FE-1361/baseline-control-what-does-one-shot-ai-elicitation-already-achieve) three-layer read), and prevention claim (which harness mechanism or pack element claims to prevent it — so each entry doubles as a testable claim against the September build).\n\nOut of scope: building detectors or evals (the catalogue specifies them; the evaluation-proxy work builds them); fixing any failure mode.\n\nDone when: the catalogue lands under `docs/planning/process-model-elicitation/` with the seed entries elaborated and the transcript sweep done; FE-1404's scoring section references it; and each entry's prevention claim names the mechanism that will be held to it.",
+          "url": "https://linear.app/hash/issue/FE-1407/catalogue-the-frontier-elicitor-failure-modes-the-published",
+          "createdAt": "2026-08-14T12:17:27.404Z",
+          "updatedAt": "2026-08-19T16:19:49.974Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "1d188788-347a-4612-8da9-4fdfb09d0377",
+          "identifier": "FE-1406",
+          "title": "Design reusable elicitation strategies",
+          "description": "An elicitation should adapt to what the user is trying to achieve and how much effort they can give, instead of running through a fixed list of questions. The harness already names reusable interview situations, but it has no shared guidance for beginning an interview, proposing likely answers for correction, or deciding which uncertainties still warrant questions.\n\nThis issue will design reusable, domain-independent interviewing guidance. It includes an opening strategy that establishes the objective, its context and scope, and the user's available time, intended use, and tolerance for suggested assumptions within the first turn or two. It also covers proposing a broad draft for correction when time is short, while keeping confirmed statements, declared defaults, and unresolved suggestions visibly distinct.\n\n+++ 🏗️ Agent notes\n\nThe kernel spec names this harness-side library the generic strategy quiver (§11.5). Guidance ownership follows vocabulary ownership: these cards teach how to work situations the shared capture envelope can name, while plugin cards teach what to notice in a domain. Plugins compose the shared cards into their packs at authoring time.\n\n## Scope settled 2026-08-19\n\n* Kickoff is a form the agent fills implicitly, not four literal questions. It establishes: objective; why and with respect to what; inclusion and exclusion boundaries; and the interaction posture inferred from available time, intended use, required confidence, and tolerance for agent-proposed assumptions.\n* Optimize for low user effort to reach an acceptably grounded model, not for turn count. A one-turn questionnaire can score well on turns while making the experience worse.\n* Strategy varies with the inferred posture: explore openly when appetite is high; synthesize and invite correction when it is constrained; propose low-risk structure and question only high-impact uncertainty in mixed cases.\n* Proposal-and-correction is a generic strategy and an appetite-compensation strategy. A generated guess remains a suggestion until the user confirms or corrects it. Only declared plugin defaults may enter as `defaulted`; the IR must not present a model guess as user-grounded evidence.\n* The shared capability set is: ask, propose, contrast, expose assumptions and gaps, capture corrections, and stop with visible gaps. The quiver says how to combine those capabilities. Plugins supply domain imperatives, target shapes, motifs, defaults, and the uncertainties that matter. The agent chooses among applicable strategies.\n* The existing card set remains in scope: conflict, competing alternatives, ambiguity, weak or missing evidence, absence clusters, and choice-point pressure. Card form remains Detects / Goal / contrastive Questions / Artifacts unless this design pass finds that kickoff or proposal-and-correction needs a different form.\n\n## Design seams to resolve\n\n* The plugin contract's `firesWhen` table mechanically produces next-question candidates from model gaps. This issue must preserve those cues as candidates without turning the interview into a schema walk; kickoff also occurs before those slot-state cues exist.\n* Session stopping and model completion are distinct. A constrained session may stop with a useful, structurally broad model containing confirmed proposals, declared defaults, and visible gaps.\n* “Appetite” is a continuously inferred interaction posture, not necessarily a stored field or fixed user-facing mode.\n\n## Prior design basis\n\nThe spec named but did not design the quiver, with milestone one shipping generic guidance in plugin packs. Reference shapes are ln-grill, ln-disambiguate, the `elicitation_style` trichotomy, and the assurance plugin's stress-the-argument split. [FE-1397](https://linear.app/hash/issue/FE-1397) routed recurring choice-point technique to the quiver. [FE-1403](https://linear.app/hash/issue/FE-1403) authors and tags envelope-vocabulary cards inside the CPS pack so they can graduate here.\n\nInputs when work starts: spec §11.5; the FE-1397 routing verdict and worked examples; FE-1403's tagged generic cards; the assurance plugin's §13.2 generic/domain decomposition; and the 2026-08-19 kickoff/appetite design discussion recorded above. Related: [FE-1357](https://linear.app/hash/issue/FE-1357), [FE-1402](https://linear.app/hash/issue/FE-1402), [FE-1403](https://linear.app/hash/issue/FE-1403), [FE-1431](https://linear.app/hash/issue/FE-1431).\n\n+++",
+          "url": "https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies",
+          "createdAt": "2026-08-14T10:44:26.136Z",
+          "updatedAt": "2026-08-19T16:20:27.749Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Next up", "type": "unstarted" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "ded249b6-f8a0-47bd-b7be-9f77950faba4",
+          "identifier": "FE-1405",
+          "title": "Draft the CPS payload interiors: annotated shapes for the ten kinds, worked from baseline utterances",
+          "description": "## Question\n\n**What are the CPS payloads' interiors — and do answer-shaped fields carry the elicitation the way the catalog alone cannot?** The IR work validated kind *catalogs* (FE-1364, FE-1397): named kinds, prose \"Holds\" descriptions, projection targets. No worked example across all four targets drafts a field-level payload schema or a single concrete capture instance — as of today the payload type system is names over unstructured prose. The spec already demands more (§11.2, Principle v2: annotated shapes for everything produced; shallow wire schemas with deep requiredness in validators); nothing has scheduled it before the work that needs it.\n\nAnd the rehearsal tickets need it: computed coverage can only see kind-level holes without fields; a completion contract can only adjudicate \"an activity capture exists\", never \"this activity lacks its duration distribution\"; clarification hints and the quantile protocol attach to fields, not kinds. This ticket therefore blocks FE-1402 and FE-1403.\n\nThe design tension to hold, from the evidence-granularity property: fields must be **answer-shaped, not artifact-shaped** — slots mirror what an expert can say (actor, inputs, outcome, duration-as-quantiles, the rationale attribute, absence-typed everywhere), never what the net needs (that factoring is `project`'s work). A schema whose unfilled slots read as natural next questions is doing elicitation-strategic work; a schema that mirrors Petrinaut's element fields is the granularity violation in type form.\n\nMethod, in the FE-1397 mold plus one grade harder: draft annotated shapes for the ten CPS kinds (the seven September-required kinds at full depth; the other three may stay shallow), then ground them in worked *instances* — take real utterances from the C1/C2 baseline transcripts and write the captures they should yield as concrete payloads, including at least one absence-valued, one quantile-carrying, one `prescribed|practiced`-split, and one multi-capture-per-utterance case. An utterance the schema cannot hold without distortion is a finding against the schema, not the utterance.\n\nOut of scope: envelope changes (interiors live inside the opaque payload half); the Gherkin/BPMN interiors (the CPS set is the September design; siblings follow in plugin-spec authoring if the exercise bends Layer A, that is a finding to hand back).\n\nDone when: annotated shapes for all ten kinds with per-field elicitation affordances (quantile-elicited, absence-typed, evidence-anchored, regime-attributed); a worked-instance set from real transcript utterances; any Layer-A friction recorded; and the shapes handed to FE-1402 (contract computes over fields) and FE-1403 (cards aim at fields).",
+          "url": "https://linear.app/hash/issue/FE-1405/draft-the-cps-payload-interiors-annotated-shapes-for-the-ten-kinds",
+          "createdAt": "2026-08-14T10:44:25.256Z",
+          "updatedAt": "2026-08-20T08:02:56.864Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "221bd3f2-132e-49bc-893a-4e3ffb395521",
+          "identifier": "FE-1404",
+          "title": "Run the armed baseline (condition 3): completion contract and pack guidance against the simulated expert",
+          "description": "## Question\n\n**Do the drafted completion contract and pack guidance close the machinery-shaped gaps a prompt alone could not — before the harness exists?** FE-1361's condition 2 established what one page of guidance buys and what it demonstrably cannot fix; the readout's instrument notes already anticipate a condition 3. This is that run: the same simulated-expert setup, armed with the completion contract drafted and desk-rehearsed in its sibling ticket and the surviving card set from the guidance-assembly ticket, plus the three instrument fixes the readout prescribed — single-session framing stated up front (no co-created multi-session fiction), the impatience probe repositioned to interview phase rather than exchange count, and a no-progress detector so a pleasantry loop stops cheaply instead of burning budget invisibly.\n\nThe run is the strategy layer's analog of FE-1397: the decide → validate step between the design and the spec, so that plugin-spec authoring inherits rehearsed machinery rather than untested shapes. Scored the same way as conditions 1 and 2, against the same readout dimensions, with particular attention to the two adjudication failure modes and the never-asked coverage class. The desk rehearsal (T1) can only replay the past; this run tests whether the contract changes the *interviewer's behavior* — ending, re-prioritizing, refusing the deferral.\n\nOut of scope: any harness or store mechanism — this stays a prompt-and-protocol experiment like its predecessors, and gaps that need the store (durable capture, enforced epistemic status, provenance spans) are expected to remain open here; they belong to the walking-skeleton work, not this instrument.\n\nDone when: transcript, raw log, and a scored readout comparing condition 3 to condition 2 land under `docs/planning/process-model-elicitation/baseline/`; amendments flow back to the contract and card set; and the combined verdict is handed to plugin-spec authoring.",
+          "url": "https://linear.app/hash/issue/FE-1404/run-the-armed-baseline-condition-3-completion-contract-and-pack",
+          "createdAt": "2026-08-14T10:23:54.066Z",
+          "updatedAt": "2026-08-19T16:19:48.957Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Next up", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "daa7f328-8825-4001-b89d-8b9e971dd60f",
+          "identifier": "FE-1403",
+          "title": "Assemble the CPS pack's interviewing guidance and desk-test it where the baseline was weak",
+          "description": "## Question\n\n**Does the imported interviewing guidance assemble into pack content that fires where the bare model is weak — and only there?** FE-1360 stocked the armory: four probe catalogues imported verbatim as ready pack content (CDM, ACTA, the 35-type typology, premortem), the two-phase interview architecture, the quantile/IDEA protocol for quantities. FE-1364 settled where guidance lives (ElicitationPack question-guidance; motif quiver scaffold-yes/generator-no). But nothing between here and plugin-spec authoring assembles that material into actual kernel cards (Detects / Goal / contrastive Questions / Artifacts) and clarification hints for the CPS plugin — the map currently has motif-quiver content scoped into \"Plugin spec authoring\", which means the first time the cards exist is inside the spec, unvalidated.\n\nCards aim at payload fields, not bare kinds: a card's Questions and Artifacts target the slots FE-1405 defines (an activity's missing duration quantiles, an unattributed regime, an absence left untyped), which is why this ticket is blocked by FE-1405 — without interiors the verdicts below go vacuous.\n\nThe baseline headline makes assembly a real design problem rather than transcription: the bare model already interviews objectives-first, probes unwritten rules, and keeps an assumptions register unprompted. A card that restates instinct is dead weight the elicitor pays for on every turn. So each drafted card needs a verdict against the transcripts: does it fire at a moment where the baseline demonstrably failed (the ramp-scrap hole that self-report couldn't see; the silent hardening of the truck schedule; the quantile protocol C2 only partially held), or does it fire where the bare model already succeeded (conflict-point depth, penalty-weight co-construction) and therefore needs demotion or deletion?\n\nPer spec §11.5's milestone-one posture, generic technique ships inside this pack rather than being excluded: cards that operate on envelope vocabulary (conflict, ambiguity, weak evidence, absence clusters, choice-point pressure) are authored here alongside the domain cards, **tagged as envelope-vocabulary generics** so they can graduate to the harness quiver (FE-1406) instead of being lost in the CPS pack. The generic/domain split per card is itself a deliverable — the assurance plugin's §13.2 decomposition is the worked example.\n\nOut of scope: designing the quiver as a harness capability (FE-1406 owns that); completion adjudication, which has its own ticket (FE-1402).\n\nDone when: a drafted CPS card set plus clarification hints, each card tagged domain / envelope-generic; a per-card verdict (fires-where-instinct-fails / redundant-with-instinct / untestable-at-desk) grounded in transcript citations; and the surviving set handed to plugin-spec authoring, with the generic-tagged cards referenced from FE-1406.",
+          "url": "https://linear.app/hash/issue/FE-1403/assemble-the-cps-packs-interviewing-guidance-and-desk-test-it-where",
+          "createdAt": "2026-08-14T10:23:53.069Z",
+          "updatedAt": "2026-08-19T16:19:48.641Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Next up", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "c4c5f121-2a79-4696-9711-d49002c43da2",
+          "identifier": "FE-1402",
+          "title": "Decide when an elicitation is complete or should stop",
+          "description": "## Question\n\n**Can a drafted completion contract adjudicate a real engagement — including ending it?** The baseline readout's gap #1 is the sharpest observed failure in the whole experiment: neither condition could end the engagement, and the two failure modes (C1's deliverable-deferral loop; C2's open-ended multi-session fiction) are both the absence of adjudication, not of reporting — the v0 checklist improved completeness *reporting* while nothing *adjudicated* it. The IR design commits to the mechanism's shape (question-relative completion anchored on `objective` captures over a static floor, interview opens on objectives) but not its computation: what \"every objective has its supporting kinds covered\" means operationally, what the floor checks, and what behavior the contract licenses when it is satisfied or stalled.\n\nThis is the same situation Layer A was in before FE-1397 — a ratified shape with an unvalidated interior — and it gets the same treatment: draft the computation, then rehearse it retroactively at the desk. The transcripts and the scoring materials already exist. Replay the drafted contract over both baseline transcripts (with the answer key as the coverage oracle) and record, per exchange: what the contract's state would have been, at which point it would have adjudicated done / not-done / stalled, and whether it catches the two observed failure modes. A contract that cannot stop the eleven-turn pleasantry loop, or that declares the C2 engagement complete while the ramp-scrap hole is open, fails the rehearsal.\n\nDesign input from [https://linear.app/hash/issue/FE-1406:](<https://linear.app/hash/issue/FE-1406:>) model completion and session stopping are distinct. A user with limited time may stop with a useful partial model, provided confirmed statements, declared defaults, assumptions, and remaining gaps stay visible. The rehearsal must therefore distinguish “complete enough for the objective” from “best useful result within this session's appetite,” rather than treating every early stop as completion or failure.\n\nOut of scope: harness implementation (the contract's evaluation is a `project`-style read-time computation; September builds it), and any change to the envelope — this is plugin-payload and pack territory.\n\nDone when: the contract computation is drafted at plugin-spec grade; a rehearsal memo scores it against both transcripts exchange-by-exchange; amendments from the rehearsal are folded back; the stopping result above is represented without weakening completion; and the result is handed to plugin-spec authoring alongside the FE-1397 handoff list.",
+          "url": "https://linear.app/hash/issue/FE-1402/decide-when-an-elicitation-is-complete-or-should-stop",
+          "createdAt": "2026-08-14T10:23:51.964Z",
+          "updatedAt": "2026-08-19T16:19:47.912Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Next up", "type": "unstarted" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "0c59beed-e026-4a86-aabc-deaebb39e892",
+          "identifier": "FE-1401",
+          "title": "Resolve the follow-ups from the stack legibility session",
+          "description": "I'm running a read-through of the open stack (FE-1374 up to FE-1390), aimed at regaining legibility over the top four branches before they land. The read-through is already surfacing more than branch understanding: process insights, a doc drift, and a couple of tooling ideas worth carrying forward. This issue is the resolution sweep for that session — everything we uncover, solve, design, or decide gets captured here and driven to a resolution, so the session's yield doesn't evaporate when the context does.\n\nThe session is in progress; items accrue below as they surface. Anything that grows real work graduates to its own sub-issue.\n\n---\n\n## Findings ledger\n\n**1. CONTEXT.md authority-voice drift (fix).** The *Artifact boundary* glossary entry still opens \"The decided integration posture between elicitor and Petrinaut (FE-1362)\". The demo-vehicle posture is a recommendation to PM, not a ratified decision — FE-1363's entries carry the corrected voice (\"recommended to PM, not ratified\"), but the correction never propagated backward to the FE-1362-era entry beside them. Reword to recommendation voice; while there, scan the rest of the glossary for the same drift.\n\n**2. Institute the cognitive-common-ground protocol (practice).** At the close of any work arc with significant agent-generated output, produce legibility artifacts that aid review and re-establish shared understanding — from plain-language/STE prose re-renderings up to exploded-view logic prototypes. FE-1374's spec renderings were the incidental prototype: re-rendering in a different register acted as a review instrument, and the round-2 read-through of those renderings fed four real changes back into the spec. Two parts: repeat the move within this session (a prose rendering of what the top four branches establish — FE-1390's capture-store semantics especially), and write the practice down (likely a `docs/agents/` home; exact placement open).\n\n**3. Port ln-induct into dogsled as** `ds-induct` **(tooling).** The induction skill at `brunch/.agents/skills/ln-induct/` — treat point review-findings as samples from a latent fault-type, abstract to the lowest rung that is both mechanically searchable and names a repair, triage-gate before auditing — should be ported into the dogsled skill system, with graduation targets renamed to the dogsled family: `ds-code-review`'s Standards axis gains a contract/verification-integrity baseline section alongside the Fowler smells, each entry carrying *what it is → how to fix → how to probe* (these lenses are invisible in the hunk; they're detected by interrogation, e.g. \"feed the gate nothing, demand red\"). Graduation is two-tier and composing: prose priors accrue in dogsled and travel via plugin; per-repo, instances get pinned as categorical boundary tests wherever a mechanical predicate exists (the Dan Luu regression-capture principle). Repo-side wiring stays in CLAUDE.local.md only — the tracked repo must not depend on dogsled being present.\n\n**4. Write up the two induced lenses with their evidence trails (graduation candidates).**\n\n* *The vacuously green check* — a gate that passes because it inspected nothing. Three-PR recurrence: FE-1388 (`sourceFiles()` returning `[]` for unfamiliar layouts; decorative oxlint), FE-1399 (`workspacePackages()` passing every boundary invariant on an empty list), FE-1400 (vacuous build-artifact witnesses; CI gates matched against raw YAML text).\n* *The parallel copy of a pinned truth* — the same fact maintained in two places, one drifting silently. Recurrence: FE-1399 (mount path now derives from `agentName`), FE-1400 (pinned-literal check routed through `pinnedIdentities`; expert's view derived instead of a parallel array; topology pin derived instead of hard-coded).\n\nEach instance was caught by a fresh post-hoc review pass rather than by a standing lens at authoring time — that gap is the value the port in item 3 is meant to recover.",
+          "url": "https://linear.app/hash/issue/FE-1401/resolve-the-follow-ups-from-the-stack-legibility-session",
+          "createdAt": "2026-08-14T09:37:51.851Z",
+          "updatedAt": "2026-08-19T16:20:28.561Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "8605481d-96b5-4ada-8b7c-5b40cc78d560",
+          "identifier": "FE-1400",
+          "title": "Close the review-found gaps where the gates, dev app, and baseline runner still fail silently",
+          "description": "During the FE-1397 tie-off, a full adversarially-verified review of the branch stack's diff against main surfaced ten confirmed correctness findings plus a handful of cleanups — none in the FE-1397 docs themselves, all in earlier branches' work. The common thread is uncomfortable: several of the checks FE-1399 added *to make silent failures loud* can themselves pass vacuously (a build-artifact witness matched by bootstrap code regardless of what got bundled, nested `test/` directories escaping every boundary invariant, a CI-gate check satisfied by commented-out gates, known-gap predicates that an empty stub file flips). Alongside those: the dev app's durable conversation store resolves its default path against the launch directory — the exact restart-durability failure the file's own comment says it exists to prevent — and the baseline runner can silently drop or truncate its main deliverable and dies on a single network blip hours into a paid run. The always-loaded agent instructions also still describe the triage roles as five verbatim labels, contradicting the rewritten triage doc's state/label mapping.\n\nThis ticket bundles all fixes as one refactor, executed as small always-green commits: documentation truth first, then the test-integrity fixes (each proven by temporarily breaking the guarded property and watching the gate go red), then the one behavioral dev-app fix, then baseline-runner robustness, then the cleanup tail. Filed from the FE-1397 thread's review output; to be claimed and run in a follow-up session.\n\n---\n\n## Commits (ordered by safety; each leaves the codebase green)\n\n 1. Align the always-loaded agent instructions' triage one-liner with the triage doc's actual state/label mapping (only three roles remain labels; `needs-triage` and `wontfix` are workflow states).\n 2. Replace the vacuous build-artifact witnesses with strings that only survive if the agent mount and the conversation-store module actually reached the bundle.\n 3. Make the boundaries suite's first-statement check accept every directive form the workspace lexicon already declares legal, by reusing the shared directive pattern instead of a literal comparison; fold in the dedup of the pinned-identity and model-key regexes duplicated across the two suites.\n 4. Make the workspace walker's source/test partition total: a file in a nested test directory is either governed by the test-hermeticity rules or included as source — nothing falls through silently. Red-proof with a fixture that previously escaped.\n 5. Strengthen the CI-gate check to match against comment-stripped (or parsed) workflow steps so a disabled gate reads as absent.\n 6. Re-encode the known-gaps predicates as \"the verification actually runs\" (content/execution checks) instead of \"a file with this exact name exists\", in both directions (stub files must not close a gap; differently-named real closures must).\n 7. Anchor the dev app's default SQLite path to the module location instead of the working directory, mirroring how the UI root is already anchored; add a test asserting launch-directory independence.\n 8. Baseline runner: widen code-fence matching (case, trailing space, digits/hyphens, CRLF) and warn loudly when no model artifact could be extracted despite a \"delivered\" verdict.\n 9. Baseline runner: propagate the truncation flag through continuation stitching so an incomplete final delivery is marked incomplete and the operator is told the escape hatch exists.\n10. Baseline runner: retry network-level failures and honor retry-after — preferably by replacing the hand-rolled HTTP client with the official Anthropic SDK, which also fixes the undercounted cache-token usage.\n11. Cleanup tail, split as convenient: serve dev static assets via the framework's nested-path-capable routing and importable MIME table; un-hard-code the root build script's single-app filter; stop building the app twice per CI run and cache dependencies; remove the baseline runner's parallel message array and dead field; derive the boundary suite's package list instead of hard-coding it.\n\n## Findings inventory (verified evidence; paths current as of the FE-1397 stack tip)\n\n| # | Where | Finding |\n| -- | -- | -- |\n| 1 | `test/build-artifact.test.ts:82` | `toContain('createAgentRouter')` matches a preserved bootstrap JSDoc comment and `toContain('sqlite')` matches the bootstrap's unconditional default-adapter import — the test passes even if `app.ts`'s mount or `src/db.ts` never reach the build. Robust witnesses exist: the `app.route(...)` mount string and the `BRUNCH_DEV_DB_PATH`/`.data-wipe-me` strings unique to `db.ts`. |\n| 2 | `test/workspace.ts:149` (with `:128`) | `sourceFiles()` prunes `test`/`tests`/`__tests__` at any depth while `testFiles()` only collects top-level test dirs — production code under e.g. `src/test/` escapes the substrate-import ban, schema-library check, and identity-duplication scan, and isn't governed by test-hermeticity either. |\n| 3 | `apps/dev/src/db.ts:17` | Default store path `./.data-wipe-me/conversations.db` is cwd-relative; launching from a different directory silently creates a fresh empty DB. Anchor via `import.meta.url` as `app.ts` does for `uiRoot`. |\n| 4 | `test/boundaries.test.ts:239` | First-statement check requires the literal `'use agent';` exactly, while `workspace.ts`'s `AGENT_DIRECTIVE_STATEMENT` (line 168) accepts both quote styles, optional semicolon, and trailing comments — forms the suite's own fixtures assert are legal fail spuriously. |\n| 5 | `docs/planning/process-model-elicitation/baseline/run.ts:213` | `largestCodeBlock`'s fence regex ```` /```[a-z]*\\n/ ```` misses ```` ```JSON ````, trailing-space, digit/hyphen info strings, and CRLF — `writeArtifacts` (line 294) then skips the model artifact with no warning while the transcript header says delivered. |\n| 6 | `run.ts:165` | Continuation stitching caps at 4 pieces and discards `result.truncated` — a still-truncated final delivery is written as complete; nothing tells the operator `--continue-final` was needed. |\n| 7 | `run.ts:111` | Only HTTP 429/5xx are retried; a rejected `fetch` (TCP reset, DNS blip) crashes the run. Fixed `attempt*15s` backoff ignores `retry-after`. The hand-typed `ApiResponse` omits cache-token usage fields, undercounting cost. The official SDK replaces all of it. |\n| 8 | `test/boundaries.test.ts:323` | CI-gate check is `workflow.includes(gate)` over raw YAML text — a commented-out or `if: false` gate still passes. |\n| 9 | `test/known-gaps.ts:54` | Every `closed()` predicate is `existsSync` on one speculative future path: a real closure under another name stays \"open\" forever (banner rot), while `touch`ing the expected path closes the gap with nothing verified. |\n| 10 | `AGENTS.md:19` (mirrored via `CLAUDE.md` symlink) | Says the five triage roles are \"used verbatim as their own label strings\"; `docs/agents/triage-labels.md` now maps `needs-triage` → state **Triage** and `wontfix` → state **Canceled**, leaving only three as labels. |\n\nCleanup tail (verified, lower stakes): `apps/dev/src/assets.ts` hand-rolled `:file` route can't match nested paths and duplicates hono's importable `getMimeType`; root `package.json` build script hard-codes `--filter '@brunch/dev'`; the full app build runs twice per CI run (build-artifact `beforeAll` + dedicated Build step) with no bun dependency cache; `run.ts` carries an `expertMessages` parallel array and a dead `interviewerTurns` field; `boundaries.test.ts` hard-codes the four-package list and two-scope substrate denylist.\n\n## Decision document\n\n* Modules touched: the repo-level verification suites (`test/`), the dev app's store and asset serving, the baseline runner script, the always-loaded agent instructions.\n* No interface or schema changes; no production API surface exists yet. The one behavioral change visible outside tests is the dev store's default path resolution (env var override unchanged).\n* Architectural stance: gate fixes must encode the *property*, not a proxy (witness strings unique to the guarded module; parsed rather than substring-matched workflow; executed-verification rather than file-existence). This is the FE-1399 charter applied to FE-1399's own checks.\n* Baseline runner: prefer deleting the hand-rolled client in favor of the official SDK over patching it — fewer lines, retry/retry-after/typed usage for free. If the SDK dependency is unwanted in a planning script, the fallback is try/catch around fetch + retry-after parsing.\n\n## Testing decisions\n\n* Most of this work *is* the test layer, so the discipline is red-proofs: for each strengthened gate, temporarily introduce the violation it exists to catch (nested `src/test/` file importing the substrate; commented-out CI gate; stub gap file; missing db.ts in the bundle) and watch it fail before restoring green.\n* The dev store path fix gets a unit test asserting the resolved path is launch-directory-independent; prior art in `apps/dev/test/assets.test.ts`.\n* The baseline runner sits behind the typecheck gate only (FE-1361); extract its parsing helpers (`largestCodeBlock`, stitching) into testable pure functions if a red-proof is wanted, otherwise verify by targeted invocation — a full paid run is not required to exercise fence parsing.\n\n## Out of scope\n\n* The FE-1397 worked-examples docs and `ir-design.md` (no findings there).\n* Redesigning the known-gaps mechanism itself — only the predicate strength changes.\n* Anything inside `@flue/*` bootstrap behavior (the vacuous witnesses are our tests' problem, not Flue's).\n* The refuted review candidates (resume double-count, sequential awaits, symlink-cycle walker, dev HMR gap, stale map pointer) — checked and dismissed, listed here so they aren't re-litigated.",
+          "url": "https://linear.app/hash/issue/FE-1400/close-the-review-found-gaps-where-the-gates-dev-app-and-baseline",
+          "createdAt": "2026-08-13T13:03:10.280Z",
+          "updatedAt": "2026-08-19T16:20:26.709Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "92c6f2e4-11eb-42e7-b3aa-4327a9a2e405",
+          "identifier": "FE-1399",
+          "title": "Make the CI gates and dev app fail loudly where review found they fail silently",
+          "description": "The FE-1361 code review swept the whole repo and verified five findings that fall outside that ticket's scope. Three sit in the merge gates themselves: the checks that are supposed to keep workspace boundaries honest can currently go red on an innocent comment-only edit, silently skip any newly added workspace group, and let a misspelled tool operation name compile — so the gates either cry wolf or pass vacuously, which matters most in a repo whose gates are its main safety net. The other two are silent-failure seams in the dev app: a route path duplicates the one identifier the codebase pins as never-drifting, and the production asset route serves a narrower set of files than the client build can emit, so the first added font or image would break production only. All five have verified failure scenarios; each fix is small and none blocks current work.\n\n---\n\n## Findings (verified by the FE-1361 review, 2026-08-13)\n\n1. `test/boundaries.test.ts:218` — agent-module detection is a bare substring match for `'use agent'` over raw file text, so a comment mentioning the directive turns any dev source file into an \"agent module\" and fails two assertions (CI red on a comment-only change; `test/build-artifact.test.ts:44` shares the filter). Fix: anchor detection to the first statement — the comment-stripping logic at lines 231–233 already exists.\n2. `test/workspace.ts:49` — `workspacePackages()` hardcodes `[packages, apps]` instead of deriving from (or asserting agreement with) root `package.json`'s `workspaces` globs, so a new workspace group escapes every boundary invariant as a vacuous pass; `directoriesIn()` also returns `[]` for a missing parent, so a renamed group degrades silently. Fix: assert the hardcoded group set equals the workspaces globs.\n3. `packages/core/src/naming.ts:60` — `toolName(operation)` takes plain `string` instead of the `Operation` union exported two lines above (the union has zero consumers), so `toolName('aks')` compiles and ships a misnamed model-facing tool. Fix: narrow the parameter type.\n4. `apps/dev/src/app.ts:19` — the mount path hardcodes `'brunch-gherkin-elicitor'` although `GherkinElicitor.agentName` is imported in the same file; a copy-pasted second agent would shadow the mount while tests stay green. Fix: `` app.route(`/agents/${GherkinElicitor.agentName}`, …) ``.\n5. `apps/dev/src/app.ts:36` — the production `/assets/:file` route allowlists only `.js|.css|.map` and reads hits as UTF-8, so any other emitted asset 404s in production (works in vite dev), and extending the allowlist without switching to a Buffer read would corrupt binary bytes.\n\nFull verdicts and failure scenarios are in the FE-1361 review record; the two findings that touched FE-1361's own files (typecheck-gate coverage, migrated-doc links) were fixed on its branch and are not part of this ticket.",
+          "url": "https://linear.app/hash/issue/FE-1399/make-the-ci-gates-and-dev-app-fail-loudly-where-review-found-they-fail",
+          "createdAt": "2026-08-13T11:43:34.706Z",
+          "updatedAt": "2026-08-19T16:20:26.590Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "20911d42-e5e5-422e-b335-d099f0223cab",
+          "identifier": "FE-1397",
+          "title": "Validate the generic IR definition against worked payload designs (Gherkin, CPS, +1)",
+          "description": "## Question\n\n**Which properties of the generic IR definition survive contact with real payload designs?** The architecture-level definition ([`ir-design.md`, Layer A](<https://github.com/hashintel/brunch-lite/blob/main/docs/planning/process-model-elicitation/ir-design.md>)) was conditionally ratified in FE-1364: ratification requires drafting speculative payload type systems across at least three plugin targets at different complexity levels — Gherkin (thin, known), CPS (thick; the FE-1364 Layer-B design is worked example #2), and a third to triangulate (the kernel spec names BPMN/process-mining as the third dev target; elicit-lean is the deferred alternative) — then checking which MUST/MAY properties hold, which bend, and which content migrates harness-ward.\n\nExpectations to test rather than avoid: sublimation pressure is the norm — drafting the assurance plugin moved content harness-ward into the generic strategy quiver, and the same is expected of the CPS facets. A kind migrating to the harness is a finding, not a failure.\n\nOut of scope here: running the examples through a working harness — Layer-A claims stay provisional until that happens, but the September build will exercise it regardless.\n\nDone when: a verdict per Layer-A property (survives / amended / demoted to guidance), amendments applied to `ir-design.md`, and the result handed to the plugin-spec authoring work.",
+          "url": "https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-definition-against-worked-payload-designs",
+          "createdAt": "2026-08-13T09:10:33.845Z",
+          "updatedAt": "2026-08-19T16:19:46.091Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "759b76d1-bb18-4159-acea-61a478f4139f",
+          "identifier": "FE-1396",
+          "title": "Re-entry briefing, resume reconciliation, and restart durability",
+          "description": "## What to build\n\nComing back. Quit an interview halfway, restart the process, return later, and the agent picks up knowing what changed while it was away — what was captured or superseded, which issues opened or closed, what was left unswept, and which question is still hanging. It says so in the conversation rather than pretending continuity.\n\nThe subtle requirement is that the briefing must be in the log honestly without ever becoming evidence. It is injected on the user's behalf, so it looks like the user's side of the conversation — and a capture citing it would launder the system's own words into the person's mouth.\n\nSpec: §9.1–9.3 (durable document, per-session state, re-entry briefing), §9.4 (provenance), §9.5 (completion derived), §8.7 (resume-time sweep reconciliation), §14.5 (restart durability).\n\n## Acceptance criteria\n\n- [ ] Resuming a session after the world moved injects a state message whose content is computed facts only: unswept tail, captures created or superseded and issues opened or closed since this session last swept, open issues, pending unanswered affordance\n- [ ] The briefing is advisory — it forces nothing, and the agent weighs it\n- [ ] A minimal user-visible insertion notice accompanies every injected state message\n- [ ] Injected entries project as structurally non-user, so citing one as evidence is mechanically refused rather than merely discouraged\n- [ ] An unswept tail left by a session that ended between judgment and sweep surfaces on resume, and the agent judges whether to sweep before proceeding\n- [ ] The briefing works in all three shapes: fresh session, resumed session, and post-restart\n- [ ] Full-stack durability holds with a real conversation store: captures, session logs, high-water mark, and pending slot all survive a process restart\n- [ ] A new session binds to its target-document through immutable creation data; dispatching an existing conversation id resumes against the document's current state\n- [ ] Completion is a read-time derived status with no lock and no terminal state — someone returning with a correction after \"done\" is handled normally",
+          "url": "https://linear.app/hash/issue/FE-1396/re-entry-briefing-resume-reconciliation-and-restart-durability",
+          "createdAt": "2026-08-13T08:32:54.698Z",
+          "updatedAt": "2026-08-19T16:20:25.918Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "b81c6610-f6fd-4669-bbf3-ed6b62696394",
+          "identifier": "FE-1395",
+          "title": "The full affordance set — choices, questionnaire chaining, and the absence strip",
+          "description": "## What to build\n\nThe rest of the ways the harness can ask something. Beyond free text: pick one, pick several, and a questionnaire that walks several questions locally without a model turn between them. Plus the absence strip — the one-tap way to say \"I don't know\", \"doesn't apply\", or \"decide later\" — and the transport mechanism that makes a tap genuinely distinguishable from typed prose.\n\nThat last part is load-bearing and easy to get wrong. Inbound replies are string-only, so a bare string cannot tell a one-tap \"not applicable\" from someone typing the words. Tap-ness has to be a transport fact or the system will claim certainty it hasn't earned.\n\nSpec: §7.2 (baseline forms, questionnaire chaining, markdown floor), §5.1 (absence states, reserved reply encoding), §7.7 (recorded transport facts).\n\n## Acceptance criteria\n\n- [ ] Single-choice and multi-choice questions work end to end, rendering and returning through the same evidence path as free text\n- [ ] A questionnaire is one affordance with N steps: the payload carries all the questions, the ui walks them locally, answers return individually or batched, and no intermediate model turns occur\n- [ ] The absence strip's three labels map onto their absence states, and absences land as first-class capture values\n- [ ] A reply parsing as the reserved encoding, arriving while its affordance is pending, is transport-explicit; every other reply is conversational and yields absences marked inferred\n- [ ] Structured taps are optional for a ui, not required: a ui affording only the markdown floor produces no encoding and honestly yields inferred-only absences\n- [ ] Plugin custom forms register as progressive enhancement keyed on form tag, with payloads opaque at the tool boundary and validated harness-side against plugin declarations on read-back\n- [ ] Every form carries a markdown floor\n- [ ] Deferred and declined behave differently downstream: completion evaluation chases a deferral and treats a decline as a boundary that only an explicit act can close",
+          "url": "https://linear.app/hash/issue/FE-1395/the-full-affordance-set-choices-questionnaire-chaining-and-the-absence",
+          "createdAt": "2026-08-13T08:32:53.299Z",
+          "updatedAt": "2026-08-19T16:20:26.675Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "8c23b17b-b220-4879-959c-ed759084f158",
+          "identifier": "FE-1394",
+          "title": "Conflict, supersession, and the interpretation render",
+          "description": "## What to build\n\nWhat happens when someone changes their mind or contradicts themselves. Say something, say something incompatible later, and both readings stay live and visible until you explicitly settle which one holds — the system never quietly picks. Alongside it, the one affordance the harness must own itself: the render that shows you what it thinks you said, with the uncertainty intact.\n\nSpec: §6.3 (issues versus advisories), §7.5 (transport outcomes), §7.6 (interpretation render), §8.4–8.5 (supersession channels, resolution records).\n\n## Acceptance criteria\n\n- [ ] Contradicting yourself surfaces a `conflicting` issue with both interpretations live as alternatives, and neither is silently dropped\n- [ ] Resolving it produces a resolution record citing your own words; the winning capture keeps its original epistemic status and authority lives in the record\n- [ ] The two supersession channels are distinguishable in the store: a creation-time link for sweep-time correction, a resolution record for issue-time adjudication between existing alternatives\n- [ ] The interpretation render is harness-owned and shows envelope vocabulary — epistemic status, absence states, live alternatives, derived status — with a plain JSON default and a plugin-optional typed renderer seam that is actually exercised by the gherkin plugin\n- [ ] Non-interactive renders ride their own tool output parts and never contend for the affordance slot, so an ask and a render in one batch cannot clobber each other\n- [ ] Transport outcomes record as answered, redirected, or unanswered, distinct from epistemic absence; a topic change mid-question reads as redirected\n- [ ] Advisories are computed and ephemeral — never stored, never blocking — and issues are stored and close only explicitly\n- [ ] Harness invariants 1, 2, and 6 hold as executable tests",
+          "url": "https://linear.app/hash/issue/FE-1394/conflict-supersession-and-the-interpretation-render",
+          "createdAt": "2026-08-13T08:32:52.029Z",
+          "updatedAt": "2026-08-19T16:20:26.378Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "c0126528-3d55-4e1f-9ff1-baad5689c7ec",
+          "identifier": "FE-1393",
+          "title": "Plugin SDK and the gherkin plugin — the first projected artifact",
+          "description": "## What to build\n\nThe first end-to-end artifact. Someone is interviewed about a feature and gets back a valid Gherkin feature file, together with an honest report of everything they said that the file could not represent. This is where the plugin contract stops being a design and starts being something a plugin author actually programs against.\n\n**Explicit non-goal: this ticket does not freeze the plugin contract.** Gherkin is the trivial target, and the spec's two-targets rule forbids letting it fix the interface before a hard target has stressed it. Build the SDK surface, exercise it, and leave it declared unstable.\n\nSpec: §6.1 (operations and calling convention), §4 (inversion of control, PluginContext), §11.1–11.3 (what a plugin owns, pack form, smallest honest plugin), §13.1 (gherkin).\n\n## Acceptance criteria\n\n- [ ] An interview about a feature yields a parse-valid `.feature` file plus a typed loss report using the declared vocabulary\n- [ ] The four operations are pure and snapshot-in/deltas-out: they receive an immutable snapshot and return observations, issues, and deltas; the harness validates and applies; no operation addresses storage, the user, or the model\n- [ ] Harness capabilities reach the plugin only through a narrow injected PluginContext, and milestone one defines no storage-addressable methods on it at all\n- [ ] The plugin ships an ElicitationPack — kernel cards, completion contract, clarification hints — and a ProjectionPack with required project and validate, authored to the `writing-for-agents` standard and Principle v2\n- [ ] Validation is parse validity plus an optional pack-declared step-lexicon check, needing no external project\n- [ ] Validators are total: they never throw, and always return typed issues\n- [ ] Issues are namespaced to their producer, so a target-originated requirement never silently reads as a harness-level one\n- [ ] A failed operation leaves no partially applied deltas\n- [ ] The smallest-honest-plugin bar is checked, not assumed: a flat record list plus one validator must suffice, and every contract addition made here is justified against the bar it raises\n- [ ] The SDK export surface is documented as unstable pending a second target",
+          "url": "https://linear.app/hash/issue/FE-1393/plugin-sdk-and-the-gherkin-plugin-the-first-projected-artifact",
+          "createdAt": "2026-08-13T08:32:50.822Z",
+          "updatedAt": "2026-08-19T16:20:25.951Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "949f63b0-938f-4f2a-981e-909bf3d41af1",
+          "identifier": "FE-1392",
+          "title": "Settlement trigger and sweep — the first captured statement",
+          "description": "## What to build\n\nThe slice the whole architecture is for. You say something in conversation; the agent judges that the topic has closed; it sweeps what you said into the store as captures anchored to your actual words; and the sweep is safe to run twice. After this ticket the system genuinely elicits — it just has nothing domain-shaped to do with the result yet.\n\nSpec: §8.1 (settlement trigger and judgment), §8.3 (sweep idempotence), §8.6 (unaccounted-ask advisory), §6.4 (cadence as policy), §10 capabilities 7 and 9.\n\n## Acceptance criteria\n\n- [ ] A conversation about something substantive produces captures in the store, each anchored to a verbatim quote from the person's own turns\n- [ ] Settlement decomposes into trigger and judgment: the harness computes the unswept tail and steers a settlement-check signal into a same-response continuation turn; the agent decides whether the range has settled, and declining is legal\n- [ ] The trigger's two guards hold — it fires on suspensions too, so a pending affordance suppresses the nudge; and it never re-nudges the same latest user entry\n- [ ] Re-sweeping a range creates no duplicate captures and does repair omissions, because identity is content-keyed rather than range-keyed — load-bearing under at-least-once tool re-execution\n- [ ] A sweep containing an ask with no reply and no capture citing it reports the fact as an advisory and blocks nothing\n- [ ] The swept high-water mark advances as per-session state and survives independently of the transcript\n- [ ] Running projection and validation at read time rather than at sweep completion changes no outcome",
+          "url": "https://linear.app/hash/issue/FE-1392/settlement-trigger-and-sweep-the-first-captured-statement",
+          "createdAt": "2026-08-13T08:32:49.692Z",
+          "updatedAt": "2026-08-20T08:02:56.825Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "ada53da7-e738-4cfe-9798-8d12aa650867",
+          "identifier": "FE-1391",
+          "title": "Durable entry projection, harness-resolved anchoring, and the session-log archive",
+          "description": "## What to build\n\nThe bridge between a live conversation and the store: given a session someone has actually talked into, the harness can take a verbatim quote and work out which entry it came from — and can keep those entries retrievable forever, independently of whatever the substrate decides to retain.\n\nThis exists because the model cannot be trusted with entry numbers and can be trusted with quotes. Ticket 13's HITL rounds on the prior map found the model's quotes flawless and its sequence guesses never once convergent, so anchoring is harness-resolved and entry identity never appears in the model-facing contract.\n\nSpec: §5 (evidence spans), §8.2 (harness-resolved anchoring), §9.4 (provenance), §9.6 (session-log archive), §10 capability 8.\n\n## Acceptance criteria\n\n- [ ] The binding can read the session's durable entry projection with provenance-discriminating entry kinds, absorbing the absence of an in-process API\n- [ ] A verbatim quote resolves to an entry pointer against true-user entries only; the stored span carries both excerpt and pointer, resolved exactly once at application time\n- [ ] No match refuses with a repair hint rather than guessing; multiple matches anchor the latest and attach an advisory note\n- [ ] Sequence numbers and range bounds appear nowhere in the model-facing tool contract\n- [ ] A capture citing an injected non-user entry is refused at validation\n- [ ] Archive-on-read holds: every entry the binding reads is retained in the target-document store, and every entry a capture points to is retrievable from the archive indefinitely\n- [ ] Base-URL discovery for the history projection is resolved rather than hardcoded, and paging behaviour beyond a thousand entries is either handled or explicitly bounded with a recorded finding",
+          "url": "https://linear.app/hash/issue/FE-1391/durable-entry-projection-harness-resolved-anchoring-and-the-session",
+          "createdAt": "2026-08-13T08:32:48.577Z",
+          "updatedAt": "2026-08-20T08:02:56.636Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "c58d731d-378e-4e4a-a0ea-b879dc32a259",
+          "identifier": "FE-1390",
+          "title": "Capture envelope, storage port, and the local capture store",
+          "description": "## What to build\n\nThe capture store and the envelope that sits in it — drivable end to end from tests with no model and no substrate, which is the whole point of the design. You can write a capture, correct it, contradict it, retract it, and read back a coherent history in which nothing was silently overwritten and every status was computed rather than stored.\n\nSpec: §5 (capture envelope), §5.1 (absence states), §6.2 (envelope-level validation), §8.3–8.5 (idempotence, supersession, resolution records), §9.6 (the storage port), §10 capability 10.\n\n## Acceptance criteria\n\n- [ ] The storage port is harness-defined and binding-implemented; nothing in the plugin surface can reach persistence\n- [ ] The envelope carries a harness-minted id alongside a content-derived dedup key that excludes epistemic status, so re-reading the same evidence differently requires explicit supersession\n- [ ] Value-XOR-absence is enforced as a refusal, and the six absence states are distinct capture values that never collapse into null or negation\n- [ ] Supersession is single-hop over active heads only; superseding an already-superseded capture is refused, and that refusal carries the world-moved facts\n- [ ] Superseded captures stay inspectable forever and never read as active\n- [ ] A `conflicting` issue closes only through a resolution record citing the true user's utterance; a bare close is refused, and so is a record citing the agent's words\n- [ ] Retraction is an explicit stored event citing the user, naming no successor, and is the only path to retracted status\n- [ ] No status field is stored anywhere — envelope status derives at read time from links, records, and events\n- [ ] Writes are serialized and application is whole-sweep-atomic: a sweep applies entirely or refuses entirely\n- [ ] Harness invariants 2, 4, 5, 7, 9, and 10 hold as executable tests",
+          "url": "https://linear.app/hash/issue/FE-1390/capture-envelope-storage-port-and-the-local-capture-store",
+          "createdAt": "2026-08-13T08:32:47.079Z",
+          "updatedAt": "2026-08-19T16:20:27.947Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "28ceb592-7d61-40a4-b11a-b8dfde57e7eb",
+          "identifier": "FE-1389",
+          "title": "Walking skeleton — the harness asks a free-text question and binds the reply",
+          "description": "## What to build\n\nThe first thing a person can actually use: open the dev app, and the agent asks a free-text question, waits, receives the typed answer, and carries on the conversation with the answer in hand. This is the turn-suspension protocol the harness has to own because Flue has no ask-the-user primitive, proven in the real tree rather than on a prototype branch.\n\nThe prototype on `prototype/10-flue-roundtrip` already established the mechanism; this ports it in and hardens the two rulings that came after it — no instruction interpolation, and mechanical reply binding.\n\nSpec: §7.1–7.4, §7.7, §9.2 (pending-affordance slot), §10 capabilities 1–5, §12.1.\n\n## Acceptance criteria\n\n- [ ] A person can hold a multi-turn conversation in the dev app in which the agent asks free-text questions and receives answers\n- [ ] Turn suspension works through a terminating ask tool plus the pending affordance in per-session state, with the answer arriving as a fresh dispatch\n- [ ] The pending question is never interpolated into instructions — it rides the ask tool's result — and no \"instructions updated\" advisory wake occurs per ask (spec §14.5 wake-wart residue: confirm no other instruction-state write path re-triggers it)\n- [ ] Reply binding is harness-mechanical off the single-pending invariant: no echo token, no reliance on the model remembering an id\n- [ ] Durable affordance identity and payload ride the ask tool's output part, not the data channel\n- [ ] A second interactive affordance in the same batch is rejected as mechanism, not as instruction\n- [ ] Every question renders through the markdown floor, so a ui that knows only the envelope shows something usable",
+          "url": "https://linear.app/hash/issue/FE-1389/walking-skeleton-the-harness-asks-a-free-text-question-and-binds-the",
+          "createdAt": "2026-08-13T08:32:45.721Z",
+          "updatedAt": "2026-08-19T16:20:28.046Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "39202ed3-e7bc-40ae-af73-38bcc35f39b3",
+          "identifier": "FE-1388",
+          "title": "Scaffold the Bun workspace and prove the CI smoke",
+          "description": "## What to build\n\nA Bun-workspace monorepo that builds and tests green from empty, with the architectural boundaries in place from the first commit rather than retrofitted later. Nothing user-visible happens yet; what this delivers is that every later slice lands into a structure that already refuses the wrong dependency direction.\n\nSpec: §12.2 (package topology), §12.3 (naming), §12.4 (schemas), §12.5 (CI smoke), §10 (recorded Flue facts the implementation must respect).\n\n## Acceptance criteria\n\n- [ ] `bun test` and `vite build` both pass from a clean checkout, with no model key and no network access\n- [ ] Packages exist per the spec's topology with its role prefixes: `core` (plugin SDK as its export surface) with a `core/testing` subpath, `binding-flue`, `plugin-gherkin`, and a dev app owning the agent module, mount, and conversation store\n- [ ] The dependency invariants hold and are mechanically checkable, not just documented: plugins resolve `core` only — never the binding, never Flue; `core` imports no substrate; the binding imports both\n- [ ] Valibot is the schema library at every boundary; no Standard-Schema conversion seam\n- [ ] The recorded Flue constraints are respected by construction: vite pinned to ^8, `'use agent'` as the agent module's first statement, `agentName` a pinned string literal\n- [ ] Tool-name prefix derives from the product name and bakes in neither \"elicit\" nor \"brunch\"",
+          "url": "https://linear.app/hash/issue/FE-1388/scaffold-the-bun-workspace-and-prove-the-ci-smoke",
+          "createdAt": "2026-08-13T08:32:26.908Z",
+          "updatedAt": "2026-08-19T16:20:27.054Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [{ "name": "ready-for-agent" }] }
+        },
+        {
+          "id": "445c6b39-0e2f-4684-887d-e9e28da79023",
+          "identifier": "FE-1387",
+          "title": "Author the second pack and freeze the plugin contract",
+          "description": "## What to build\n\nThe ticket that makes the plugin contract real. A second, harder target gets authored against the SDK, stressing the parts a Gherkin file never touches — evidence grading, a payload graph rather than a flat list, derived domain labels — and only once it has done so is the export surface declared stable.\n\n**Which second target is not yet decided, and is not this ticket's to decide.** The spec names an assurance-argument plugin and specifies it in buildable detail. But FE-1362 committed the September demo to a process-model plugin, which would make that the natural second target and leave assurance as specified-but-unbuilt. The answer depends on FE-1364, and it changes this ticket's urgency as well as its content: if the second target is the process-model plugin, this stops being milestone-one cleanup and becomes demo-critical path.\n\nSpec: §13 (portfolio and hybrid order), §13.2–13.3 (the assurance argument, if that is the target), §14.2–14.3 (proof obligations, gating tests), §11.5 (generic strategy quiver).\n\n## Not yet ready for an agent\n\nBlocked on FE-1364 for the target decision. A working plan, not a settled one.\n\n## Acceptance criteria\n\n- [ ] The second target is chosen, with the reasoning recorded\n- [ ] Its packs are authored and it runs end to end through the same harness, sharing no code with the gherkin plugin beyond the SDK\n- [ ] The reprojection gating test passes: capture once, project into materially different targets, verify agreement\n- [ ] The black-box authoring test runs — public SDK and docs handed to someone who has not read core, counting concepts, boilerplate, and escape hatches\n- [ ] Every contract change the second target forced is recorded, since each one is evidence about what gherkin alone failed to stress\n- [ ] Any interviewing technique that turned out to operate on envelope vocabulary rather than domain vocabulary is identified as candidate strategy-quiver content rather than buried in a plugin pack\n- [ ] The five proof obligations are judged against the hourglass, and the SDK export surface is declared stable",
+          "url": "https://linear.app/hash/issue/FE-1387/author-the-second-pack-and-freeze-the-plugin-contract",
+          "createdAt": "2026-08-13T08:31:55.791Z",
+          "updatedAt": "2026-08-19T16:20:26.344Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Backlog", "type": "backlog" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "bd45303d-7024-476e-9640-0ab24815a08c",
+          "identifier": "FE-1386",
+          "title": "Verify compaction leaves the durable entry projection intact",
+          "description": "## What to build\n\nAn answer to the one durability claim in the spec that nothing has tested. Pi-family substrates compact long transcripts, and the spec asserts that compaction may shrink what the model re-reads but never what the store can resolve. No prototype has ever driven a session across a compaction boundary, so the assertion is currently unverified.\n\nThe outcome is knowledge, not a feature: either the durable entry projection survives compaction unmodified, or we learn exactly what the binding has to preserve itself and the archive mechanism absorbs it.\n\nSpec: §9.7 (context compaction versus the durable log), §14.5 (open verification items).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail — and partly dependent on whether Flue ships a compaction definition at all, which is worth establishing before designing the test.\n\n## Acceptance criteria\n\n- [ ] A session is genuinely driven across a compaction boundary, not simulated\n- [ ] Evidence pointers created before compaction still resolve afterwards\n- [ ] Either the durable projection is confirmed compaction-independent, or the entries compaction prunes are enumerated and the archive's absorption of them is verified\n- [ ] Per-session harness state is confirmed to live outside the transcript and survive\n- [ ] If a compaction definition is supplied, injected signals and affordance tool parts are confirmed to need no protected status\n- [ ] The finding is written up and the spec section updated from unverified to settled either way",
+          "url": "https://linear.app/hash/issue/FE-1386/verify-compaction-leaves-the-durable-entry-projection-intact",
+          "createdAt": "2026-08-13T08:31:54.450Z",
+          "updatedAt": "2026-08-19T16:20:26.302Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Backlog", "type": "backlog" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "089776c5-6a5c-4fa8-aaed-26e0aa5705de",
+          "identifier": "FE-1385",
+          "title": "Dev app — target gallery and diagnostic probe surface",
+          "description": "## What to build\n\nPromote the dev app from a test surface into the chartered three-role vehicle the spec describes: the local development loop, a colleague-facing gallery where several targets can be demoed side by side, and a diagnostic view that shows the machinery rather than only the chat.\n\nThe diagnostic role is the one worth protecting. It exists because reacting to a system's internals is a different activity from reacting to its conversation, and the fog note that surfaced it asked for parallel state readout with labelled moving parts — pending slot, high-water mark, tool traffic, suspension boundaries, injected signals.\n\nSpec: §12.5 (dev app roles, deferred ui package), §7.6 (renderer seam), §12.1 (host-authored agent module).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much of the exploded-view instrumentation belongs here versus later; whether the gallery is genuinely needed before a second target exists to gallery; and what a colleague is meant to be able to do unaided.\n\n## Acceptance criteria\n\n- [ ] The local dev loop runs against the available plugins with one agent per target and static per-agent tool sets\n- [ ] Parallel tabbed sessions work across targets without cross-contamination\n- [ ] The diagnostic surface shows per-session state and tool traffic alongside the conversation, with the moving parts labelled\n- [ ] Affordance renderers live in the dev app, with the ui affordance package deliberately deferred\n- [ ] Remote-parity constraints are visibly respected: one agent serving many conversations, pinned agent name, storage port owned outside the plugin, no dynamic agent creation",
+          "url": "https://linear.app/hash/issue/FE-1385/dev-app-target-gallery-and-diagnostic-probe-surface",
+          "createdAt": "2026-08-13T08:31:50.602Z",
+          "updatedAt": "2026-08-19T16:20:26.147Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Backlog", "type": "backlog" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "57a4161b-45df-451c-a77c-cfdd3055b6e5",
+          "identifier": "FE-1384",
+          "title": "Generative test corpus over the replay driver",
+          "description": "## What to build\n\nTurn the hand-written tests accumulated by the earlier slices into seeds for a generated corpus. The ten harness invariants are literally properties; the generators come from a plugin's declarations rather than its implementation; and conversations themselves become generated command sequences, so pathological interview shapes get found rather than imagined.\n\nSpec: §14.4 (testing strategy), §14.1 (the ten invariants), §12.4 (SDK testing surface).\n\n## Not yet ready for an agent\n\nApproved in shape, foggy in detail. Worth settling first: how much generative machinery earns its keep at milestone one versus after a second plugin exists; whether the model-as-offline-generator step is in scope now or is a later luxury; and what the regenerate-on-declaration-change workflow actually looks like in practice.\n\n## Acceptance criteria\n\n- [ ] The ten harness invariants run as executable properties, not as prose\n- [ ] Arbitraries derive from Valibot declarations rather than implementations, so a plugin cannot accidentally test itself against its own bugs\n- [ ] Negative-space properties hold for plugin code: validators total, and projection never emitting an undeclared loss category\n- [ ] Command-sequence testing runs over the envelope-derived alphabet — utter, settle-range, sweep, correct, contradict, reply-with-absence, redirect\n- [ ] Mutation operators generalise the minimal-pairs idea: epistemic-status flips, absence injections, supersession injections\n- [ ] A model plays respondent as an offline generator whose outputs freeze as replayable fixtures — never as a CI oracle; everything in CI runs with no model and no substrate\n- [ ] Fixtures regenerate when declarations change, and the staleness is detectable rather than silent\n- [ ] Shrunk counterexamples are pinned as regressions and read as type-design feedback",
+          "url": "https://linear.app/hash/issue/FE-1384/generative-test-corpus-over-the-replay-driver",
+          "createdAt": "2026-08-13T08:31:49.586Z",
+          "updatedAt": "2026-08-19T16:20:26.528Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Backlog", "type": "backlog" },
+          "parent": {
+            "id": "5e45263d-bf61-4025-b415-cca91df88023",
+            "identifier": "FE-1383",
+            "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance"
+          },
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "5e45263d-bf61-4025-b415-cca91df88023",
+          "identifier": "FE-1383",
+          "title": "Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance",
+          "description": "The [elicitation kernel spec](<https://github.com/hashintel/brunch-lite/blob/main/docs/planning/elicitation-kernel/spec.md>) is finished and reviewed, but nothing has been built — the repo holds planning documents and no code at all. Until that changes, the September demo has no library to consume: FE-1362 committed the demo to a purpose-built shell driving a new interviewing library, and this is that library.\n\nMilestone one is the walking version of the whole architecture. A person is interviewed in ordinary conversation; the agent captures what they said as evidence-anchored structured meaning; a plugin turns those captures into a real artifact — a Gherkin feature file for the first target — in which every value traces back to a verbatim quote, corrections never erase history, and anything that could not be represented is reported rather than dropped. The sub-issues below are vertical slices of that path, each one demoable or verifiable on its own.\n\nOne capability is deliberately absent. The spec requires a second, harder target to stress the plugin contract before that contract is declared stable, and which target that should be depends on decisions still being resolved on FE-1357 — so the plugin interface stays explicitly unfrozen through this batch, and the last four tickets are a working plan rather than a settled one.\n\n---\n\n## Working notes\n\n**Source**: `docs/planning/elicitation-kernel/spec.md` (repo-canonical). Each sub-issue names the spec sections it implements; the spec is the contract, the ticket is the slice.\n\n**Blocking** is expressed through Linear's native blocked-by relations, not restated in bodies. The frontier is whatever is open with no unresolved blocker — currently the scaffold and the capture store, which can run in parallel.\n\n**Readiness**: sub-issues labelled `ready-for-agent` are specified well enough for an agent to pick up from the spec alone. The four in Backlog are not — they are approved in shape but foggy in detail, and each names what has to be settled first. Expect a grilling round at the head of most tickets regardless; this arc is closer to a wayfinding arc than to a queue.\n\n**The contract-freeze caveat** (spec §13): the two-targets-on-each-axis rule says the trivial target must not freeze the plugin contract before the hard target has stressed it. Gherkin is the trivial target. So nothing in this batch ratifies the SDK export surface — that is the last ticket's job, and it is gated on FE-1364.\n\n**Open verification items** from spec §14.5 are folded into the slices that own them, except compaction-versus-durable-history, which is large enough to stand alone.",
+          "url": "https://linear.app/hash/issue/FE-1383/build-the-elicitation-harness-to-milestone-one-an-interview-that",
+          "createdAt": "2026-08-13T08:31:30.587Z",
+          "updatedAt": "2026-08-19T16:26:28.251Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "In progress", "type": "started" },
+          "parent": null,
+          "labels": { "nodes": [{ "name": "map" }] }
+        },
+        {
+          "id": "cce6e4e4-84cb-407c-9428-315007c3c830",
+          "identifier": "FE-1382",
+          "title": "Source dossier: published fleet-maintenance models + operational data for the truck-fleet case",
+          "description": "## Question\n\nWhat published, already-elicited models and public operational data exist for truck-fleet predictive maintenance — enough to author a demanding situation pack, a reference \"before\" net, and an answer key without access to a live domain expert?\n\nSpecifically:\n\n1. **Published models** — Petri-net, simulation, or condition-based-maintenance (CBM) models of vehicle-fleet maintenance in the academic and industry literature. These are the \"models already elicited from domain experts\" Yannis pointed at (Slack, 2026-08-11); each is a candidate grounding for the reference net. Note especially any that model per-vehicle degradation state gating maintenance events — the dynamic-colouring archetype from the literature review (FE-1360, §6.3).\n2. **Public operational data** — telematics datasets, failure/reliability records, maintenance logs (the use-case DB entry claims \"real fleet data is available to the public\"). What exists, under what licence, at what granularity?\n3. **Domain texture for the situation pack** — the operational facts a fleet-maintenance manager would actually know: depot/bay/technician structure, spare-parts logistics, route types and their wear profiles, dispatch pressure, the rules nobody wrote down. Sources: practitioner literature, industry reports, case studies.\n\nDeliverable: a source dossier markdown in the repo (`docs/planning/process-model-elicitation/research/`), findings on a throwaway `research/truck-fleet-dossier` branch per the map's research-ticket convention.\n\nContext: resolves the sourcing half of the FE-1363 decision (truck fleet as working-hypothesis use case, pending team ratification ~18 Aug). The situation-pack authoring itself is deliberately *not* ticketed yet — findings fold into PRO-99 commentary first.",
+          "url": "https://linear.app/hash/issue/FE-1382/source-dossier-published-fleet-maintenance-models-operational-data-for",
+          "createdAt": "2026-08-12T16:12:15.352Z",
+          "updatedAt": "2026-08-19T16:20:26.109Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "a565c058-0b8c-4173-8b71-d22147d2f0b5",
+          "identifier": "FE-1379",
+          "title": "Walking skeleton: sweep seam on Flue [archive]",
+          "description": "Built the second walking skeleton on Flue, proving the four remaining platform capabilities the spec depends on (knowing when to harvest, reading conversation history, injecting system notes, and safe storage under retries) — completing the evidence base for the spec. Code on branch `prototype/13-sweep-seam` (brunch-lite repo). Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/13-walking-skeleton-sweep-seam.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: sweep seam on Flue\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nProve the four substrate capabilities the capture-sweep machinery assumes but no prototype has exercised on Flue — the unproven seam between ticket 10's transport skeleton and ticket 11's synthetic-log logic-prototype, surfaced by the [2026-08-10 consistency pre-pass](<../notes/consistency-prepass-2026-08-10.md>) (items L1–L3):\n\n1. **Settlement trigger** — a substrate lifecycle event (turn-end / agent-settled) that invokes the agent's settlement judgment. Ticket 11 recorded this as \"wiring proof delegated to ticket 10\", but ticket 10 contains no settlement or lifecycle-event finding; the claim was a misattribution (L1).\n2. **Read a session entry range** — harness code reading the entries it sweeps. Ticket 01 found no documented path to Pi's message list from inside a Flue agent; ticket 10 proved read-back only on the ui side via `useFlueAgent`; ticket 11 ran against a synthetic log. The hinge between the two prototypes is proven nowhere (L2).\n3. **Inject an on-behalf-of-user state entry** — the carrier for ticket 12's re-entry briefing. Candidate: Flue's `kind: 'signal'` message with trusted-code attributes (ticket 01 §6), which would also yield the true-user-versus-injected provenance distinction for free.\n4. **Transactional durable store distinct from per-conversation state** — ticket 12 requires whole-sweep-atomic application (and refusals) across sessions; conversation-scoped `usePersistentState` cannot provide it (ticket 01).\n\nSuccess = a minimal Flue walking skeleton (seeded from `prototype/10-flue-roundtrip`) that wires ticket 11's pure reducer (`prototype/11-capture-sweep`) to a real session log through these four capabilities. The resolution amends Shipping shape's six-item substrate-capability list — these are its four missing entries (pre-pass L3) — or records what Flue lacks or forbids and what the Flue binding must therefore absorb (binding-size asymmetry is expected, per ticket 06).\n\nBlocks: [Assemble the spec](<08-assemble-the-spec.md>).\n\n## Answer\n\n> Resolved by walking skeleton + two HITL reaction rounds, 2026-08-10. Real Flue agent + web UI with a live target-document panel, two browser sessions against one target-document, driven live by the user; 21-check headless probe suite passing. Prototype on branch `prototype/13-sweep-seam` (`prototypes/sweep-seam/`; commits 276c0e4 skeleton, bbb3646 HITL fix).\n\n**Overall: all four capabilities hold on Flue — two natively, two absorbed by the binding, none forbidden — with one load-bearing amendment from the HITL rounds: evidence anchoring must be harness-resolved, not model-chosen.**\n\n### Verdict per capability\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is the would-stop control seam: awaited before the response settles; `ctx.append` steers a settlement-check signal into a same-response continuation turn; the hook re-fires at the next would-stop; the response settles only when nothing appends. Trigger computes facts, judgment stays with the agent (declining is legal). Mechanism findings: the hook **fires on** `terminate: true` **suspensions too** (the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn); the nudge itself becomes a session entry, so the trigger needs a **loop guard** (never re-nudge the same latest-user-entry). Observed cadence drift: the model preferred sweeping at reply time without waiting for a nudge — harmless *because* sweeps are content-idempotent and harness-anchored; cadence is policy, exactly as ticket 11 said.\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (`getFlueRuntime` is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** (`GET <agent-url>?view=history`, @flue/sdk) over self-HTTP; works mid-response. The projection is sweep-sufficient: stable ids, stream order, `purpose` **as the provenance discriminator** ('user'/'assistant'/'dispatch'/'advisory'), signal descriptors, tool parts with validated outputs. **The amendment (HITL round 1):** the projection numbering is harness-side knowledge ONLY — hidden advisories inflate it and the model's seq guesses never converge, while its verbatim quotes are flawless. So the model-facing citation currency is the **quoted excerpt**; the harness resolves quotes to entries (user-entries-only candidates; no-match refuses with a repair hint; multi-match anchors latest with an advisory). Sharpens ticket 12's span shape: the excerpt is primary at proposal time, the pointer is derived.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** `ctx.append` (same-response) and `dispatch({kind:'signal'})` (real delivery) share one vocabulary. Caller-defined signals project as system-role / `purpose: 'dispatch'` / `display: 'diagnostic'` with tagName + trusted attributes — **structurally distinct from true user entries, so ticket 12's citable-evidence rule is mechanically enforced** (a capture citing an injected entry is refused). The re-entry briefing worked in every shape: fresh session, resumed session, post-restart session — and in HITL round 2 it produced unscripted **conversational conflict-surfacing**: briefed with \"September 12\" and told \"September 13\", the agent asked instead of overwriting, then swept the correction as a supersession citing both the assertion and the confirmation.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (milestone one: JSON file, tmp+rename atomic, in-process serialization), and every ticket-11 semantic survived the real log: whole-sweep-atomic apply/refuse, content-keyed idempotence (**load-bearing, not optional**, under Flue's at-least-once tool re-execution), single-hop supersession as the stale-session guard. Restart probe: conversations 404 (in-memory, no `db.ts`), store survives, a fresh session answers correctly from its briefing alone.\n\n### Capability-list amendment (Shipping shape, issue 06 — closes pre-pass L3)\n\nThe six-item substrate-capability list gains four entries: **7. subscribe to the would-stop lifecycle seam, with same-response signal steering** (native); **8. read the session's durable entry projection, with provenance-discriminating entry kinds** (binding-absorbed; no in-process API); **9. inject typed non-user signal entries, same-response and as deliveries** (native); **10. provide a transactional durable store outside conversation state** (binding-absorbed entirely). Binding-size asymmetry landed exactly where ticket 06 predicted.\n\n### HITL round 2 — cross-session dynamics observed live\n\nSession-a captured date/time, guests, budget; session-b opened with a contradictory assertion (\"Hilton, September 13\"): briefing → conversational conflict-surfacing → user confirmed → **c4 superseded c1 citing both user entries**. Then the superseded-history payoff: the user said \"the same time we said before, whatever that was\" — the time lived only in the *superseded* capture; the agent resolved it from the briefing's history and captured it as its own fact, honestly marked **inferred**, anchored to the user's actual words. \"Corrections don't erase history\" paying rent. One wrinkle for the spec: **compound payloads make supersession lossy** (c1 bundled date+time; c4 superseded it with date+venue and silently dropped the time until the user's remark rescued it) — capture granularity is plugin `validate`/kernel-card guidance territory. Same stratum as the other live find: a payload can smuggle an absence (`payload: \"not-yet-decided\"`) past the envelope — exactly the payload-level validation ticket 11 assigned to plugins.\n\n### Spec consequences (for issue 08)\n\nEntry identity is harness-side vocabulary; excerpts are the model-facing citation currency (amends the envelope's span story). Judgment prompts must never be the model's only source of mechanical facts (trigger suppression during suspension is correct but starves numbered context). Two payload-level validation examples now exist for the smallest-honest-plugin section. The wake-wart (ticket 10) remains cosmetically noisy (\"I've noted the update…\" doubling) — unchanged spec options.\n\n## Comments\n\n**2026-08-10 (walking skeleton built — awaiting your reaction; HITL).** The skeleton is done and all four capabilities were exercised against the real runtime, live model turns included. **Provisional verdict: all four hold on Flue — two absorbed by the binding as expected, none forbidden.**\n\n**Assets** (branch `prototype/13-sweep-seam`, commit 276c0e4, `prototypes/sweep-seam/`): real Flue agent + web UI with a live target-document panel (`bun run dev`, sessions `?id=session-a`/`session-b` share target-document `demo`); `node probe-seam.mjs` re-runs 18 checks (all passing). README documents the ask/terminate and restart probes.\n\n**Per capability:**\n\n1. **Settlement trigger — PROVEN, native.** `useAgentFinish` is exactly the would-stop seam ticket 11 needed: awaited before the response settles, `ctx.append` steers a `settlement-check` signal into a same-response continuation turn, the hook re-fires at the next would-stop, and the response settles only when nothing appends. Trigger computes the facts (numbered unswept tail); judgment stays with the agent (declining is legal). Two mechanism findings: (a) the hook **fires on** `terminate: true` **suspensions too**, so the pending-affordance guard is load-bearing — without it the nudge would append into a suspended ask turn; (b) the nudge itself becomes a session entry, so the trigger must be **loop-guarded** (don't re-nudge the same max-user-seq; persistent `lastNudgedAt`).\n2. **Read a session entry range — PROVEN, binding-absorbed.** No in-process path from agent code to the conversation store exists (the runtime getter is private; lifecycle contexts expose only tool names). The binding reads the **public durable-history projection** — `GET <agent-url>?view=history` via `@flue/sdk` — over self-HTTP; works mid-response (both the finish hook and the sweep tool read during the live response). The projection is sweep-sufficient: stable ids, stream order (seq), `purpose` **as the provenance discriminator** (`user` / `assistant` / `dispatch` / `advisory`), signal descriptors, tool parts with validated outputs. Warts: the binding must know its own base URL (env var here); a mid-flight read sees the partial assistant message; >1000-entry paging unprobed. Live-model finding: **entry-seq citation is error-prone for a small model** — the typed refusal steered a mis-cited sweep to correct in two hops (backpressure works), but the spec may prefer harness-resolved excerpt anchoring over model-chosen seqs.\n3. **Inject an on-behalf-of-user state entry — PROVEN, native.** Two carriers share one vocabulary: `ctx.append` (same-response, no delivery) and `dispatch({kind: 'signal'})` (real delivery). Caller-defined signals project as system-role, `purpose: 'dispatch'`, `display: 'diagnostic'`, with `tagName` + trusted `attributes` — **structurally distinct from true user entries, so ticket 12's provenance rule is mechanically enforceable** (probe: a capture citing an injected entry is refused at validation). The re-entry briefing worked in all three shapes: fresh session, resumed session, and post-restart session — the last answered the user correctly from the briefing alone. Nuance: Flue classifies these as dispatch/diagnostic rather than literally \"on behalf of the user\"; the Pi convention survives as signal + render guidance, and the sharpened citable-evidence rule is *stronger* under Flue's classification.\n4. **Transactional durable store — PROVEN as binding-owned; Flue neither provides nor forbids it.** `usePersistentState` is conversation-scoped by design; no cross-conversation store surface is public. The binding owns the target-document store (JSON file, tmp+rename atomic, in-process serialization — milestone-one local), and **every ticket-11 semantic survived contact with the real log**: whole-sweep-atomic apply/refuse, content-keyed idempotence, single-hop supersession as the stale-session guard (cross-session probe: session-b superseded session-a's capture; a stale re-supersession was refused with world-moved facts). Restart probe: conversations 404 (`stream_not_found` — in-memory, no `db.ts`), the store file survives. Confirms pre-pass L13: Flue's at-least-once tool re-execution makes content-keyed idempotence load-bearing, not optional.\n\n**Proposed capability-list amendment** (Shipping shape 06 — its four missing entries, per pre-pass L3): 7. *subscribe to the would-stop lifecycle seam, with same-response signal steering* (native: `useAgentFinish`/`ctx.append`); 8. *read the session's durable entry projection, with provenance-discriminating entry kinds* (binding-absorbed: history route; no in-process API); 9. *inject typed non-user signal entries, both same-response and as deliveries* (native: append/dispatch, `kind: 'signal'`); 10. *provide a transactional durable store outside conversation state* (binding-absorbed entirely; Flue offers none). Binding-size asymmetry landed exactly where ticket 06 predicted — the Node binding absorbed 8 and 10.\n\n**Incidental Flue facts:** `agentName` must be a string *literal* (the build-time scan rejects a constant reference); injected signals carry `display: 'diagnostic'`, so the ticket-10 UI-filtering lesson extends to them (the skeleton renders them as labeled cards instead — exploded-view-lite, per the map's fog note).\n\n**To resolve this ticket:** drive the skeleton (two browser sessions against one target-document is the fun path: sweep in one, resume the other), react, and we record the verdict + the capability-list amendment + graduate whatever fog the reaction surfaces.\n\n---\n\n**2026-08-10 (HITL reaction #1 → diagnosed and fixed; commit bbb3646).** The user drove session-a and sweeps never converged: an ask-heavy interview, then \"let's sweep\" → five refusals, model deflecting into more questions. Diagnosis from the session log: **the model's verbatim excerpts were flawless in every attempt; every entry seq was a guess** — five attempts, five different numberings, zero convergence. Two compounding causes: (a) the model *cannot* know the projection numbering (hidden `System instructions updated` advisories — the ticket-10 wake-wart — inflate it, and the model never sees them); (b) in an ask-heavy flow the pending guard suppresses every settlement-check, so the numbered tail never re-arrives and a user-requested sweep runs blind.\n\n**The fix, which is itself the sharpened finding: evidence anchoring must be harness-resolved, not model-chosen.** The model now cites only verbatim user quotes (plain strings); the harness — the only party that can see the projection — resolves each quote to its entry (`resolveEvidence`: user-entries-only candidates, no-match refuses with a repair hint, multi-match anchors latest with an advisory note); seq numbers and `upTo` left the model-facing tool contract entirely. Replaying the user's exact failing flow headlessly now converges (the residual refusals en route were *correct* envelope refusals — empty evidence, value-and-absence — which the model repaired). Probe suite extended and made self-contained: 21/21, twice consecutively.\n\nSpec consequences: (1) the questioning-UX/envelope contract should state that **entry identity is harness-side vocabulary; the model-facing citation currency is the quoted excerpt** — this also strengthens ticket 12's \"pointer + quoted excerpt\" span shape (the excerpt is primary at proposal time; the pointer is derived); (2) a payload can *smuggle* an absence (`payload: \"not-yet-decided\"` observed live) — the envelope cannot catch it; that is exactly the payload-level stratum ticket 11 assigned to plugin `validate`, worth an explicit spec example; (3) trigger suppression during suspension is correct, but judgment prompts must never be the model's only source of mechanical facts.\n\nStill open for your reaction: the cross-session dynamics you originally set out to test (sweep in one browser session, resume the other — the headless probes exercise it, but the HITL reaction is the point).",
+          "url": "https://linear.app/hash/issue/FE-1379/walking-skeleton-sweep-seam-on-flue-archive",
+          "createdAt": "2026-08-11T15:35:22.043Z",
+          "updatedAt": "2026-08-19T16:20:26.560Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "e091ded9-5124-43e0-8c01-aa447b17639b",
+          "identifier": "FE-1378",
+          "title": "Multi-session elicitation & durable target state [archive]",
+          "description": "Decided how work survives across conversations: a durable target-document holds all captured knowledge and the full session logs; individual chat sessions are transient, never formally close, and can always resume against the current state. Storage went to the platform adapter, not the plugin — flipping an earlier hypothesis. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/12-multi-session-durable-target.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Multi-session elicitation & durable target state\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-10\n\n## Question\n\nWhat is the multi-session model for elicitation: the target state that endures independently of sessions, the per-session evidence logs, and the semantics of leaving, resuming, and interleaving sessions against one target?\n\nGraduated from the map's \"Spec permanence / sessions-roam-across-specs\" fog by the capture-sweep logic-prototype (issue 11), whose model already decomposes cleanly for this: the capture store (captures, issues, events) as durable, session-independent truth; session logs as per-session evidence streams, each with its own swept high-water mark; the sweep as the only bridge between them. Evidence spans become session-qualified; idempotence keys already anchor on evidence and extend without redesign; the single-hop supersession refusal doubles as the stale-session lost-update guard; \"the world changed since my last entry\" is a computable re-entry fact (captures created/superseded since this session's last sweep).\n\nPrior art (brunch history, from the HITL reaction on issue 11): brunch v1 assumed one-session elicitation and it proved brittle and constraining; v2's direction made the elicited artifact durable beyond and independent of the sessions contributing to it — start a session, leave it unresolved, open another that picks up from the current state of truth, later return to the first, which must then understand that the world moved between its last entries and whatever it writes next.\n\nSub-questions:\n\n* What exactly is durable — captures + issues + events only, or projections/artifacts too? What is stored vs derived?\n* Session identity and lifecycle: what *is* a session in this model (one conversation? one substrate dispatch chain?), and what state is strictly per-session?\n* Interleaved or concurrent sessions against one target: are the single-hop supersession refusal plus a re-entry advisory sufficient coordination, or is more needed (locking, merge, explicit sync events)?\n* Re-entry briefing: what is a resuming agent told — unswept tail, world-moved delta, open issues — and in what form (advisory facts? the interpretation render)?\n* What does this do to the persistence-plugin-owned hypothesis and the storage port (feeds Shipping shape, issue 06) and to the spec's session vocabulary (feeds Assemble the spec, issue 08)?\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-10 (two rounds; frontier exhausted, every branch confirmed).\n\n### The model: durable target-document, transient sessions, sweep as the only bridge\n\n**Terms** (pinned in `CONTEXT.md`): the family/instance collision on \"target\" resolves by compound disambiguation, not a fresh noun — **target-domain** = the artifact family a plugin defines (gherkin, proof obligations); **target-document** = the durable unit sessions attach to: one target-domain + its capture store + its session history. Bare \"target\" stays legal where context disambiguates. The instance-noun names the unit by its *purpose*; the spec states plainly that its authoritative state is the capture store, never the render.\n\n1. **What is durable.** Durable truth = the capture store (captures, issues, events) **plus all session logs** — provenance must resolve forever; discarding swept logs would dead-end every capture's evidence spans. This is \"corrections don't erase history\" applied at the store level. Projections/renders/artifacts are strictly **derived**: cacheable, never authoritative.\n2. **Session identity & lifecycle.** A session is **one substrate conversation** — Pi's own model (the log of all messages: user, agent, tool calls, custom/state messages), which Flue inherits. Strictly per-session state is exactly three things: the evidence log, the swept high-water mark, the pending-affordance slot. **No formal close**: sessions go quiet and stay resumable indefinitely; \"ended\" would be a fiction the harness cannot verify. The ragged edge (ending between settlement and sweep) is already handled by ticket 11's resume-time unswept-tail advisory.\n3. **Concurrency: interleaved-only** (milestone one). The store is **serialized** — sweeps validate and apply atomically, a plain transactional guarantee, not a session lock. Staleness is optimistic: the **single-hop supersession refusal doubles as the stale-session lost-update guard** (a stale session superseding a moved head is refused, and the refusal carries the world-moved facts). Refusal granularity is **whole-sweep atomic** — matches the prototype; re-proposing is cheap once the advisory is digested (per-item partial application → fog). No locking, no merge, no sync events; true simultaneous-sweep coordination → fog, graduating only if a real concurrent consumer appears.\n4. **Re-entry briefing.** Injected **state messages**, following Pi's custom-entry convention: authored *on behalf of the user* (compaction and session-branch summaries are the precedent — the transcript the model reads contains messages from or on behalf of the user summarizing important changes). Advisory-only, agent-facing, with a minimal user-visible insertion notice (as for other state changes). Content = the computed facts: unswept tail, world-moved delta (captures created/superseded and issues opened/closed since this session's last sweep; anchor = session start when it never swept), open issues, pending unanswered affordance. Harness computes, agent weighs — nothing forced; surfacing the world-moved summary conversationally is judgment guidance (kernel-card level), with the interpretation render available on request.\n5. **Provenance principle, sharpened: only the *true* user's side is evidence.** The data model distinguishes true user entries from entries injected on the user's behalf. Capture evidence spans anchor only on true user (and user-affordance-payload) entries; injected advisories live in the log honestly — the session reads back complete — but are **never citable as capture evidence**. This generalizes ticket 11's resolution-record rule (\"must cite the user's utterance\") into one clean principle.\n6. **Completion is derived, never a gate.** A target-document has no lock/terminal state: completion-contract satisfaction is a read-time **derived status** (same family as derived capture status and issue 09's derived labels). A user returning with a correction after \"done\" is the motivating story of this ticket.\n\n### The storage flip (amends the standing hypothesis; feeds Shipping shape 06 and the spec 08)\n\n**Persistence is not plugin-owned — the hypothesis is flipped.** Mapping persistence to the plugin was a conflation; the capture-sweep model already made the store harness mechanism (envelope invariants enforced as store-level refusals). The **storage port is harness-defined and binding-implemented**: the deploy target decides *how*, the plugin never touches persistence, and if storage is addressable from plugin code at all, it is only through **harness-defined methods passed via the injected PluginContext**. This aligns with (and sharpens) ticket 06's capability-list entry \"persist state\" and its remote-parity constraint \"host-owned storage port\".\n\n**Evidence spans carry pointer + quoted excerpt**: session-id + range as the pointer, the load-bearing quote embedded in the capture. Provenance stays self-contained across local/remote differences in substrate log access; the substrate log remains the full record, the excerpt the citable quote.",
+          "url": "https://linear.app/hash/issue/FE-1378/multi-session-elicitation-and-durable-target-state-archive",
+          "createdAt": "2026-08-11T15:35:20.903Z",
+          "updatedAt": "2026-08-19T16:20:26.948Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "49c26a41-68c6-45a6-9148-14bdfe39a170",
+          "identifier": "FE-1377",
+          "title": "Logic-prototype: capture sweep & settlement [archive]",
+          "description": "Built an isolated prototype proving the knowledge-capture mechanics: deciding when a stretch of conversation is ready to harvest, harvesting it repeatably without double-counting, recording \"no answer\" as real information, and correcting earlier captures without erasing history. Code on branch `prototype/11-capture-sweep` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/11-logic-prototype-capture-sweep.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Logic-prototype: capture sweep & settlement\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDo the session-as-evidence capture mechanics hold up when implemented in isolation (no substrate — mechanism semantics only)? Build a logic-prototype of the harness's sweep machinery over a synthetic session log.\n\nWorking hypotheses to prove or refute (delegated from the Questioning-UX contract, issue 05):\n\n* **Range-level settlement**: settlement is declared over ranges of conversation (a vein closing), never per-question — the agent judges *when* a range has settled; the harness provides the bookkeeping (swept high-water mark). Per-question \"settled\" events are the rejected alternative (exchange-pair machinery through the back door).\n* **Sweep idempotence**: re-sweeping a range never double-captures (the retries-idempotent kernel invariant, exercised at the sweep level).\n* **Cancelled/redirected questions at sweep time**: an ask affordance committed to session but answered by cancellation, silence, or topic-change must read back honestly — as absence evidence, not as an answer.\n* **Supersession across sweeps**: a later range's captures superseding an earlier range's, via the envelope's one `supersedes` link and explicit events only.\n* **Conflict-resolution record**: a `conflicting` issue closes only via an explicit resolution record — a capture-layer event citing the user's utterance as evidence; the harness refuses to close the issue without it (the \"no silent conflict resolution\" invariant moved from wire to store).\n\n## Answer\n\n> Resolved by logic-prototype + HITL reaction, 2026-08-07. Prototype on throwaway branch `prototype/11-capture-sweep` (commit d235258): single-file demo ([11-capture-sweep.html](<../prototypes/11-capture-sweep.html>), working-tree copy left untracked for double-clicking) + headless driver (32 checks passing) + browser walkthrough smoke (refusals land exactly on the deliberately-illegal steps, no console errors). The pure reducer module — the liftable part — is the demo's first script block.\n\n### Verdict: all five hypotheses hold, each sharpened\n\n1. **Range-level settlement — holds.** Zero per-ask state exists anywhere in the model; the swept high-water mark is the only sweep bookkeeping. Sharpened by the reaction: settlement decomposes into **trigger** (when to invoke the judgment — substrate lifecycle events such as turn-end/agent-settled; wiring proof delegated to ticket 10) and **judgment** (the agent names `upTo`). The race with concurrent user input is benign by construction: a sweep asserts only \"read up to N,\" never \"conversation paused\" — new entries land above the high-water mark, in the next range.\n2. **Sweep idempotence — holds, split in two.** The harness guarantee is **mechanical** idempotence via evidence-anchored capture identity (dedup key = evidence spans + payload/absence) — aligned with where retries actually occur, since a retried tool call re-executes byte-identical proposals. **Semantic** re-interpretation (a fresh judgment re-phrasing the same fact) is deliberately not a harness concern: that is plugin `reconcile` + `possibly-equivalent` issues. Identity is **content-based, not range-based**: a re-sweep never double-captures but *can repair omissions* (exercised in the dodged-question walkthrough). Epistemic status is excluded from identity — revising the epistemic reading of unchanged evidence requires explicit supersession, never a silent update.\n3. **Honest absence — holds.** A dodge reads back as `declined (inferred)`, a strip tap as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Absences are **evidence, not agenda**: the re-ask path runs through plugin `validate` → typed issues, with completion evaluation as the backstop for unresolved deferrals on required concepts. Adopted mechanism: the **unaccounted-ask advisory** — a swept range containing an ask with no reply and no capture citing it makes the harness report the fact and block nothing.\n4. **Explicit supersession — holds.** Supersession is single-hop over **active heads only**: superseding an already-superseded capture is refused, which is the lost-update guard (a corrector must confront the current head, so history stays a chain, never a silently forking tree). Sweeps validate and apply atomically; superseded captures remain visible — corrections don't erase history.\n5. **No silent conflict resolution — holds, with the wrinkle.** A bare close is refused; a resolution citing the *agent's* words is refused; only a record citing the user's utterance closes a `conflicting` issue. Wrinkle: the envelope's one creation-time `supersedes` link cannot adjudicate between two *already-existing* alternatives — there are **two supersession channels**: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status while authority sits in the record, suggesting per-capture status be **derived at read time** (echoes the derived-label approach from the formal-verification canon survey, issue 09).\n\n### Amendments to prior decisions (from the HITL reaction)\n\n* **Two validation strata**, amending the operation tiering in Contract decomposition (04): **envelope-level, harness-owned** — hard invariants enforced as refusals (provenance required, value-xor-absence, single-hop supersession) plus computed facts raised as advisories or generic `possibly-equivalent` issues (same-evidence duplicate actives, near-identical payload text — the harness can compare payloads as strings without understanding them) — versus **payload-level, plugin-owned** (`validate`/`reconcile` as already decided). Strengthens the smallest-honest-plugin test: a flat-record plugin gets generic duplicate detection for free.\n* **Op cadence is orchestration policy, not correctness.** Nothing had pinned when `project`/`validate`/`reconcile` run; snapshot-in/deltas-out purity means the harness may run them at any time without changing outcomes. Sweep-completion is the default trigger; the spec states cadence as explicit harness policy.\n* **Resume-time sweep reconciliation.** A session ending between settlement judgment and sweep leaves an unswept tail — a computable fact (entries above the high-water mark). On resume the harness surfaces it as an advisory and the agent judges whether to sweep before proceeding. Facts computed, weights judged.\n\n### Graduated\n\nThe multi-session question raised in the reaction (target state durable beyond sessions; interleaved sessions against one target; re-entry semantics) graduates the map's \"Spec permanence / sessions-roam-across-specs\" fog → [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>). The prototype's decomposition carries it: durable capture store / per-session evidence logs / sweep as sole bridge, with the single-hop refusal doubling as the stale-session guard.\n\n## Comments\n\n**2026-08-07 (prototype built — awaiting your reaction; HITL).** The logic-prototype is done and the mechanics were exercised end-to-end. **Provisional verdict: all five hypotheses hold**, with two design wrinkles surfaced for the spec.\n\n**Assets** (throwaway branch `prototype/11-capture-sweep`, commit d235258):\n\n* [11-capture-sweep.html](<../prototypes/11-capture-sweep.html>) — single-file shareable demo; double-click to open. Also left untracked in the working tree at the same path. Five guided walkthroughs (one per hypothesis, including every deliberately-illegal move) plus a free-play console with evidence-ticking and a sweep-proposal builder. The pure reducer module (no DOM) is the first `<script>` block — the liftable part.\n* `prototypes/driver/` (branch only) — headless sanity driver; `node driver.js` re-runs all five walkthroughs plus edge probes (32 checks, all passing). Also smoke-driven in headless Chrome: every walkthrough completes, refusals land exactly on the three illegal steps, no console errors.\n\n**Per hypothesis:**\n\n1. **Range-level settlement — holds.** The swept high-water mark is the *only* sweep state; nothing per-ask exists anywhere in the model. An ask is just a session entry. The demo's \"✓ Mark this question settled\" button exists solely to explain why it isn't in the vocabulary.\n2. **Sweep idempotence — holds, and sharpened.** Idempotence falls out of *evidence-anchored capture identity*: a capture's dedup key is (evidence spans + payload/absence). That makes idempotence **content-based, not range-based** — a re-sweep of an already-swept range never double-captures *but can repair omissions* (the dodged-question walkthrough does exactly this). This is stronger and more useful than gating on the high-water mark, and is the semantics the spec should pin.\n3. **Honest absence — holds.** A dodged ask reads back as `declined (inferred)`, a tapped strip as `deferred (explicit)`; neither is an answer, and transport outcome never conflates with epistemic absence. Bonus mechanism worth speccing: a non-blocking **advisory** — when a swept range contains an ask with no reply and no capture citing it, the harness reports the fact and blocks nothing (\"facts computed, weights judged\" applied to sweep honesty).\n4. **Explicit supersession — holds.** Single-hop enforced (superseding an already-superseded capture is refused), sweeps apply atomically, history is never erased. Also surfaced: epistemic status is deliberately *excluded* from capture identity, so re-reading the same evidence with a different epistemic status dedups as a retry — an actual revision must go through explicit supersession. The alternative (epistemic in the key) silently spawns near-duplicate actives.\n5. **Resolution records — holds, with the interesting wrinkle.** Bare close refused; resolution citing the *agent's* words refused; only a record citing the user's utterance closes the issue. **Wrinkle:** the envelope's one creation-time `supersedes` link cannot express adjudication between two *already-existing* alternatives — the resolution record (an event) has to carry that supersession instead. The spec should name both supersession channels: the link (sweep-time correction) and the resolution record (issue-time adjudication). Related: the winning capture keeps its original epistemic status (`tentative` in the walkthrough) while the authority lives in the resolution record — which suggests read-time *derived* status, echoing the derived-label idea from the formal-verification canon survey (issue 09).\n\n**To resolve this ticket:** click through the five walkthroughs (and free-play if inclined), react, and we record the verdict + fold the two wrinkles into the map.",
+          "url": "https://linear.app/hash/issue/FE-1377/logic-prototype-capture-sweep-and-settlement-archive",
+          "createdAt": "2026-08-11T15:35:19.388Z",
+          "updatedAt": "2026-08-19T16:20:26.491Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "f1ae0996-3c1f-4dcd-90a3-703b8681a7c3",
+          "identifier": "FE-1376",
+          "title": "Walking skeleton: Flue question round-trip [archive]",
+          "description": "Built a working skeleton on real Flue proving a structured question can travel from the agent to the user and the answer back — with the discovered constraint that only one live question can be pending at a time, which became a rule in the spec. Code on branch `prototype/10-flue-roundtrip` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Walking skeleton: Flue question round-trip\n\nType: prototype\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 05\n\n## Question\n\nDoes the one-channel questioning transport hold up in a real Flue agent + web UI? Build a walking skeleton — real Flue agent, minimal elicitor stub (no plugin), one question round-trip: structured ask affordance emitted via a single kernel-owned data channel (`form` tag + markdown-baseline payload), answer returned as string dispatch, interpretation recorded to the session.\n\nProves or refutes (proof obligations delegated from the Questioning-UX contract, issue 05):\n\n* The **one-channel multiplex** working hypothesis: one fixed `data-exchange` channel, forms discriminated inside the payload, plugin widgets as progressive enhancement.\n* The **data-part update-in-place vs. append** contradiction in Flue's docs (hooks reference says in-place; streaming protocol + `AgentReply.data` say append) — runtime check.\n* Whether a reply needs an **echo token** binding it to the question asked, or whether transcript adjacency + agent interpretation suffice.\n* What the **turn-suspension protocol** actually needs to persist (`terminate: true` tool + fresh-dispatch answer) — and how a cancelled/redirected question reads back from the session.\n* UI-side **rendering ergonomics**: branching on the form tag, markdown fallback for unknown forms, `purpose`/`display` filtering of non-user-facing traffic.\n\n## Answer\n\n> Resolved by walking skeleton, 2026-08-07. Real Flue agent (`@flue/runtime` 2.0.3, vite 8, Node target, no db) + React UI (`useFlueAgent`), driven live over multiple conversations: full round-trips through single-choice, free-text, an unknown form, absence-strip taps, and a redirect. Prototype captured on branch `prototype/10-flue-roundtrip` (`prototypes/flue-roundtrip/` — README documents the probes; `probe-stream.mjs` is the SSE-level evidence).\n\n**Overall: the transport holds — with one load-bearing amendment.** The one-channel questioning transport survives contact with the real runtime, but the fixed data channel is a *one-live-affordance slot per message*, not an accumulating log, so affordance **identity** must ride the ask tool's output part, not the channel.\n\n### Verdict per proof obligation\n\n1. **One-channel multiplex: PROVEN, amended.** One `data-exchange` channel carried three forms (single-choice, free-text, and the deliberately unknown `rating-stars`); the UI branched on the `form` tag, rendered widgets for known forms and the markdown floor for the unknown one, and reply transport stayed string-only throughout. **The amendment:** writes to one channel name materialize *last-write-wins per assistant message* — forced two `ask_user` calls in one turn, and the first question's affordance was silently clobbered from the durable record (both `dynamic-tool` parts survived, with inputs and validated outputs). So: the channel is a \"current affordance\" surface; per-ask identity and payload belong on the ask tool's `output` (Flue's React docs bless exactly this — tool output parts exist \"so applications can render custom tool interfaces\"). A kernel invariant follows: **the ask tool must reject a second ask in the same batch** (mechanism, not instruction — the stub's instruction-level \"one question at a time\" held until deliberately overridden, but the guarantee belongs in the tool).\n2. **Update-in-place vs append: SETTLED — update-in-place, at every layer.** The hooks reference wins; the streaming protocol's \"append\" describes delta chunks, not part materialization. Evidence: two same-channel writes (`draft` → `open`) produced two SSE deltas but every snapshot held exactly one part; durable history holds one part (final value); even `readSubmissionReply`'s \"emit order\" array returns one entry. Clients DO see intermediate values live (progress rendering works); only the final value persists.\n3. **Echo token: NOT NEEDED for the tested shapes — adjacency + persistent pending state suffice.** All replies were bare strings (typed text, choice-button labels, absence taps, a mid-stream redirect); the agent bound every one to the correct `exchangeId` because the pending question (with its id) is interpolated into the instructions from `usePersistentState`. The binding evidence is the `record_interpretation` tool part citing the exchangeId — session evidence, exactly as issue 05 hypothesized. Untested residual: simultaneous multiple open questions (ruled out by the one-ask invariant above) and long-delay/interleaved answers.\n4. **Turn suspension: WORKS, with a wake wart.** `terminate: true` + pending question in `usePersistentState` + answer-as-fresh-dispatch is sufficient; nothing else needed persisting. A cancelled/redirected question reads back cleanly: the affordance part stays in the transcript, and the `record_interpretation` part (`outcome: redirected`, `epistemicStatus: stated`) is the resolution evidence — the store-level guarantee issue 05 wanted. **The wart:** writing pending-state that's interpolated into instructions triggers a \"System instructions updated\" advisory *after* the terminating batch, which wakes the model for an extra turn that emits redundant \"I'm still waiting…\" text — one wasted model call per ask, plus transcript noise. Spec options: don't interpolate the pending question into instructions (keep it in state only, or narrate it inside the ask tool's result), or accept and UI-filter. Related fact: a mixed batch (non-terminating `record_interpretation` + terminating `ask_user`) still suspended correctly.\n5. **Rendering ergonomics: PROVEN.** Form-tag branching, markdown fallback, and read-back of a whole past conversation from durable history (including resolved-question dimming derived purely from `record_interpretation` parts in the transcript — no side store) all worked first try. Messages carry `purpose` and `display` fields (`display: \"diagnostic\"` on the advisory noise) — the UI must filter on them; the skeleton didn't at first, and the advisories rendered as visible cards.\n\n### Incidental facts worth the spec's attention\n\n* `@flue/vite` **hard-requires vite ^8** (its `parseAstAsync` TS support); on vite 6 the `'use agent'` scan dies with a bare parse error. The directive must also be the file's first statement.\n* **The Flue dev controller gives** `app.ts` **the entire request space** — no fall-through to vite's HTML serving — so a co-located browser UI is served by the Hono app itself (vite still transforms module requests, but react-refresh/HMR is off the table without a second server). A real deployment would face the same: the ui shell is a separate app or app-served static assets.\n* Data-channel writes are Valibot-validated per write; `body: v.any()` works fine as the opaque plugin-payload slot with typed envelope fields around it.\n* Restart durability untested by design (no `db.ts` → process-memory conversations; a restart wipes them — consistent with the deploy-target-owns-persistence hypothesis).\n\n## Comments\n\n**2026-08-07 (user, post-resolution):** Ratified reading of the questionnaire dimension against the clobbering finding — the whole questionnaire is a **single affordance with multiple steps**, not per-question affordances. The **one-ask-per-batch invariant stands** even though one ask may carry multiple questions passed in the same call. **Progression is UI-driven**: the payload carries all N questions, the ui walks them locally, answers return as evidence (individually or batched), and the agent interprets on settlement — zero intermediate model turns, sidestepping the wake-wart. Interpretation-on-settlement hands off to the capture-sweep semantics in ticket 11.",
+          "url": "https://linear.app/hash/issue/FE-1376/walking-skeleton-flue-question-round-trip-archive",
+          "createdAt": "2026-08-11T15:35:18.440Z",
+          "updatedAt": "2026-08-19T16:20:26.447Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "2375aced-d1bc-4e3c-8b00-88ebc8ea2e8c",
+          "identifier": "FE-1375",
+          "title": "Formal-verification canon survey [archive]",
+          "description": "Checked the second practice subject against the formal-verification literature. Verdict: \"proof obligations\" was the wrong name — a category error to verification readers — so the subject was renamed to the assurance argument, aligned to the GSN standard with vocabulary borrowed from Dafny. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/09-formal-verification-canon-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Formal-verification canon survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\n> **Rename decided 2026-08-10** (HITL, during spec-assembly prep): the second target is the **assurance argument** — GSN's own noun, per this ticket's verdict that \"proof obligations\" reads as a category error. Package: `plugin-assurance` (was `plugin-proof-obligations` in the Shipping-shape topology). References to `elicit-proof-obligations` below are the historical name.\n\nWhat existing canon should the `elicit-proof-obligations` output contract hew to, and — written didactically, for a reader new to formal verification — what does a verification workflow *actually do*: what are its artifacts, what is one trying to produce, where does the human effort go?\n\nSpecifically:\n\n* **Dafny's contract vocabulary** (`requires` / `ensures` / `invariant` / `decreases`, pre/postconditions, loop invariants): how practitioners actually express obligations, and how much of that vocabulary transfers to a language-agnostic claim DAG\n* **Proof-obligation workflow 101**: in Dafny/Lean/TLA+-style work, what is the day-to-day loop (state → obligation → discharge/failure → refine)? What does \"an obligation\" look like as an artifact? What roles do assumptions/axioms play?\n* **Geolog / ARIA relevance**: what is Geolog (ARIA program context — axiom sets ostensibly addressed via Datalog-like queries), and does its shape align with our acyclicity + Datalog-closure validator design?\n* **Recommendation**: what our claim-DAG format should align to — which canon's vocabulary, which parts to adopt vs. leave, and what the smallest canonical-feeling output contract for milestone one looks like\n\nContext: the portfolio decision (issue 07) adopted zil-lean's *ideas* (assurance lattice, PROVED/CONDITIONAL/WEAK/BROKEN ladder, Datalog-closure validation) but rejected its format as unproven; the output contract should feel native to people who do this work.\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Formal-Verification Canon Survey — for the `elicit-proof-obligations` target\n\n## 1. Proof-obligation workflow 101\n\n**The daily loop (Dafny-style, most concrete of the three).** You write code *and* annotations in the same file. You hit save. The verifier translates your program into a pile of logical formulas called **verification conditions (VCs)** and asks an automated prover whether each is valid. Dafny specifically \"verif[ies] that the program meets its specifications, by translating the program to verification conditions and checking those with Boogie and an SMT solver, typically Z3\" ([Dafny Reference Manual §13.1](<https://dafny.org/latest/DafnyRef/DafnyRef>)). Green = discharged. Red = an assertion the solver could not prove. You then edit *the annotations, not usually the code*, and re-run. Loop time is seconds-to-minutes; Midspiral reports \"proofs often take more than 10 minutes to run\" on real domains ([midspiral.com](<https://midspiral.com/blog/from-intent-to-proof-dafny-verification-for-web-apps/>)).\n\n**What a proof obligation *is*.** It is machine-generated, not human-authored. The human writes *contracts*; the tool derives obligations from them. Worked micro-example:\n\n```dafny\nmethod Decrement(n: int) returns (m: int)\n  requires n > 0        // precondition — caller must establish\n  ensures m == n - 1    // postcondition — callee must establish\n  ensures m >= 0\n{ m := n - 1; }\n```\n\nFrom those three lines the verifier generates roughly: (a) *assuming* `n > 0` and the body's effect, prove `m == n-1`; (b) same, prove `m >= 0`; (c) at every call site of `Decrement`, prove `n > 0` holds there. Add a loop and you get more: the invariant holds on entry, is preserved by one iteration, and (with the negated guard) implies what follows — \"The `invariant` clause is effectively a precondition and it along with the negation of the loop test condition provides the postcondition. The `decreases` clause is used to prove termination\" (Dafny RM §7.6). Termination needs the `decreases` expression to both *decrease* and be *bounded below* ([Dafny tutorial, Termination](<https://dafny.org/dafny/OnlineTutorial/guide>)).\n\n**\"Discharging\"** = the prover established that VC. Nobody hand-writes it. **On failure there are exactly two diagnoses** and telling them apart is the actual skill: \"there are two main causes for Dafny verification errors: specifications that are inconsistent with the code, and situations where it is not 'clever' enough to prove the required properties\" (Dafny tutorial). Failure gives you an error at a source location, optionally a counterexample — which Dafny explicitly downgrades to a hint: \"Dafny cannot guarantee that the counterexample it reports provably violates the assertion... should be inspected manually and treated as a hint\" (RM §13.7.1).\n\n**Where human effort goes.** Not into proofs — into *specs, invariants, and hints*. Concretely: strengthening a loop invariant; adding a `lemma` (\"a lemma states a logical fact, summarizing an inference that the verifier cannot do on its own,\" RM §6.3.3); hiding irrelevant facts so the solver focuses (\"sometimes less information is better for the solver,\" RM §8.20.2). Midspiral's numbers make the shape vivid: same kernel, \"counter domain (~50 lines of proofs) and the Kanban domain (~1,400 lines of proofs).\"\n\n**Durable vs. ephemeral artifacts.** Durable: the specification (contracts, invariants), the lemma corpus, and — critically — **the ledger of things assumed rather than proved**. Ephemeral: SMT queries, counterexamples, timings, proof-search traces. And the canon is explicit that the durable spec is the weak point: \"Proofs guarantee that the implementation satisfies the specification. They don't guarantee that the specification is what you actually wanted... The human still owns the spec\" (Midspiral, *Methodology Limitations*). That sentence is the entire justification for your product.\n\n## 2. Dafny's contract vocabulary — what transfers\n\n| Keyword | Meaning | Transfers to a claim DAG about an arbitrary system? |\n| -- | -- | -- |\n| `requires` | precondition, obligation on the *caller* | **Yes** — the canonical name for \"this claim's premise / what must hold for my guarantee to mean anything\" |\n| `ensures` | postcondition, obligation on the *callee* | **Yes** — canonical for \"guarantee\" |\n| `invariant` | property preserved across steps | **Yes** — reads naturally as a system-level always-true claim |\n| `decreases` | termination measure | **Partial** — as a *well-foundedness witness* it's the honest canonical way to license a cycle; otherwise program-bound |\n| `modifies` / `reads` | frame conditions | **No** — \"framing only applies to the heap, or memory accessed through references\" (RM §7.1.4). Inherently program text. |\n| `assert` | prove this here | **Yes** — an obligation you accept |\n| `assume` | take this on faith | **Yes** — this *is* your \"assumption with review status\" |\n| ghost state | spec-only variables, erased at compile | **No** — an artifact of having a compiler |\n| `lemma` | named reusable inference step | **Yes** — maps directly to your lemma record |\n\nThe single most transferable thing in the Dafny ecosystem is not a keyword: it is `dafny audit`, which \"reports issues in the Dafny code that might limit the soundness claims of verification\" and flags declarations marked `{:axiom}`, `{:verify false}`, `{:extern}` with contracts, any `assume` in a body, and `decreases *` — because \"the key purpose of the `audit` command is to ensure that all assumptions are intentional and acknowledged\" (RM §13.6.1.8). It emits a **Markdown table**. That is, near-verbatim, the output artifact you are building. Adopt its framing.\n\n## 3. Adjacent canons\n\n**TLA+.** Obligation-like artifact: an *invariant* or *temporal property* checked against a state machine. Two tools, two epistemics. TLC does bounded exhaustive search: it \"builds a finite state model... performs a breadth-first search... If TLC discovers a state which violates a system invariant, it halts and provides a state trace path\" ([Wikipedia](<https://en.wikipedia.org/wiki/TLA%2B>)). TLAPS does real proof: proofs are \"transformed into individual obligations which are sent to back-end provers\" (Isabelle, Zenon, Z3), and are \"hierarchically structured, easing refactoring and enabling non-linear development: work can begin on later steps before all prior steps are verified.\" **Fit: strong on structure** — hierarchical, obligation-per-step, partial completion is normal — but the vocabulary (`Init`, `Next`, `[]`, fairness) presumes a state machine you don't have.\n\n**Lean / Isabelle.** Artifacts: `definition` / `lemma` / `theorem`, organized in namespaces, with `axiom` a first-class declaration kind ([Lean Language Reference §8](<https://lean-lang.org/doc/reference/latest/>)). The culture-critical mechanism is `sorry`**-tracking**: a proof left incomplete still typechecks but taints the result, and `#print axioms` reveals the taint. **Fit: excellent for your lemma/theorem/assumption trichotomy and for the CONDITIONAL rung** — \"proved, but modulo these named holes\" is native theorem-prover thinking.\n\n**Alloy.** Vocabulary: `sig` (signatures define vocabulary), `fact` (always-true constraints), `pred`, `fun`, `assert` — checked by a SAT-based model finder within a bounded scope ([Wikipedia](<https://en.wikipedia.org/wiki/Alloy_(specification_language)>)). \"Lightweight formal methods\": finds counterexamples, never proves. **Fit: weaker on vocabulary, but philosophically closest to milestone one** — you too are doing a cheap, bounded, always-terminating check that surfaces defects rather than certifying correctness. Borrow the *stance*, not the nouns.\n\n**GSN (assurance cases).** Six core element types: **Goal** (a claim), **Strategy** (the nature of the inference from a goal to its sub-goals), **Solution** (a reference to evidence), **Context**, **Assumption**, **Justification** (rationale). Two link types: **SupportedBy** (inferential or evidential) and **InContextOf** (relating Context/Assumption/Justification to Goals and Strategies). Goals and Strategies may be marked **Undeveloped** — \"a line of argument has not been developed yet.\" Large arguments modularize via **away goals** ([GSN Community Standard v1, FAA-hosted PDF](<https://www.faa.gov/about/office_org/headquarters_offices/ang/redac/redac-sas-201503-gsn-community-standard-v1.pdf>); [SCSC GSN](<https://scsc.uk/gsn>); GSN liaises with OMG's [SACM](<https://www.omg.org/spec/SACM/>)). **Fit: best of the four for interviewed claims about an arbitrary system.** It was designed for exactly your situation — a human argues that a system is adequate, with heterogeneous evidence, in a graph, where \"not yet argued\" is a legitimate node state.\n\n## 4. Geolog / ARIA — negative result, stated plainly\n\n**No ARIA / Safeguarded AI / davidad artifact named \"Geolog\" could be found.** Searches across `geolog + davidad`, `geolog + Safeguarded AI`, `geolog + Datalog + verification kernel`, and GitHub returned nothing. The ARIA [Programme Thesis v2](<https://aria.org.uk/media/ikrkutfk/safeguarded-ai-programme-thesis-v2.pdf>) is an image-heavy PDF whose text could not be extracted; the [funded projects page](<https://aria.org.uk/opportunity-spaces/mathematics-for-safe-ai/safeguarded-ai/funded-projects>) and the [TA1.1 Theory call](<https://aria.org.uk/media/tfkjkjxy/aria-safeguarded-ai-ta11-theory-call-for-proposals.pdf>) describe \"computationally practicable mathematical representations and formal semantics\" without naming a logic. **Do not build on a claim that ARIA ships something called Geolog.**\n\n**What \"Geolog\" actually names in the literature** (documented): a logic-programming language for **coherent logic**, the language whose queries Skolem machines compute (Fisher & Bezem, *Skolem Machines*; Bezem & Coquand, *Automating Coherent Logic*). Coherent logic is \"a restriction of first-order logic due to Skolem that is proof-theoretically tractable\"; geometric logic is its infinitary generalisation, with axioms written as sequents built from `⊤, ∧, ⊥, ⋁, ∃, =`, and models \"preserved and reflected by geometric morphisms\" ([Wikipedia: Geometric logic](<https://en.wikipedia.org/wiki/Geometric_logic>); [nLab: geometric theory](<https://ncatlab.org/nlab/show/geometric+logic>)). There is a separate, unrelated *Geolog* for GIS/spatial Prolog ([arXiv:2109.08295](<https://arxiv.org/abs/2109.08295>)).\n\n**Does the shape align with acyclicity + Datalog closure?** Yes, and non-trivially. Coherent-logic provers are **forward-chaining fixpoint engines** — \"the first automated theorem prover based on coherent logic, Euclid, was developed in Prolog and its inference system relied on a forward-chaining mechanism,\" computing \"the fixpoint for a geometric configuration\" ([Automating Coherent Logic, Springer](<https://link.springer.com/chapter/10.1007/11591191_18>); [A Deductive Database Approach to Automated Geometry Theorem Proving](<https://link.springer.com/article/10.1023/A:1006171315513>)). Datalog is precisely the ∃-free, ⋁-free fragment of that. **(Inference):** the validator is a Datalog restriction of a coherent-logic saturation engine, which is a genuinely canonical lineage you can cite — Geolog is the *right ancestor* to name, just not an ARIA one. Honest caveat: coherent logic in general is undecidable; Datalog is not. The restriction is what buys determinism.\n\n*(Adjacent, real, and possibly what was half-remembered: ARIA-adjacent work on **Kolm**, \"an early-stage decentralized proof database designed to interoperate with Lean\" — mentioned in [a davidad interview](<https://www.cognitiverevolution.ai/alignment-with-awakening-davidad-on-moral-realism-ai-wisdom-why-his-p-doom-is-down-to-5/>), with usable tools projected end of 2027. Single-source; treat as unconfirmed.)*\n\n## 5. RECOMMENDATION\n\n**Align to a GSN skeleton with Dafny nouns on the claim fields and Lean/Dafny-audit semantics on the status ladder.** GSN because it is the only canon designed for *argued* claims about a system by humans with mixed evidence; Dafny because `requires`/`ensures`/`invariant`/`lemma` are the words verification people reach for first and cost nothing to adopt; `dafny audit` because it is literally the deliverable.\n\n**Adopt:** GSN's Goal / Strategy / Solution / Assumption / Justification vocabulary and its two link types; Dafny's `requires`/`ensures`/`invariant`/`lemma`/`assumption`; Lean's `sorry`-taint semantics; `dafny audit`'s \"list of intentional, acknowledged assumptions\" as the primary output.\n**Leave:** `modifies`/`reads` (heap-bound), ghost state, TLA+'s temporal operators, Alloy's `sig`/scope machinery.\n\n### Smallest canonical-feeling milestone-one contract\n\n**One record type,** `Statement`**, with a** `kind` **discriminant** (avoids five near-identical schemas):\n\n* `id`, `kind` ∈ {`goal`, `strategy`, `assumption`, `lemma`, `theorem`, `guarantee`, `constraint`, `evidence`, `justification`, `context`}\n* `statement` — one natural-language sentence, indicative mood\n* `owner`, `review_status` ∈ {`unreviewed`, `accepted`, `disputed`, `retired`} *(assumptions only; from* `dafny audit`*)*\n* `criticality` ∈ {`catastrophic`, `major`, `minor`} — **note: this comes from safety engineering (DAL/SIL/ASIL), not from Dafny/Lean, which have no notion of it.** Source it there and say so.\n* `evidence_refs[]`, `provenance` (transcript span), `developed: bool` (GSN Undeveloped)\n\n**Four edge kinds:**\n\n1. `supports` (GSN SupportedBy — inferential; child → parent)\n2. `evidenced_by` (GSN SupportedBy — evidential; claim → evidence)\n3. `requires` (Dafny precondition; claim → premise it needs)\n4. `in_context_of` (GSN InContextOf; claim → assumption/context/justification)\n\nOnly `supports`, `evidenced_by`, `requires` are load-bearing for status. `in_context_of` is scoping.\n\n**Derived status, stratified:**\n\n* **S0** `refuted(X)` if evidence marked contradicting; `open(X)` if `kind=assumption ∧ review_status ∈ {unreviewed, disputed}`\n* **S1** `BROKEN(X)` if `refuted(X)` ∨ ∃ load-bearing child `BROKEN` *(pure positive recursion — closes first)*\n* **S2** `WEAK(X)` if ¬BROKEN ∧ (`¬developed` ∨ (no `evidenced_by` ∧ no `supports`))\n* **S3** `CONDITIONAL(X)` if ¬BROKEN ∧ ¬WEAK ∧ ∃ transitively-reachable `open` assumption\n* **S4** `PROVED(X)` if ¬BROKEN ∧ ¬WEAK ∧ ¬CONDITIONAL\n\nNegation only ever looks at a lower stratum — that is the stratification the validator must enforce, alongside acyclicity of the three load-bearing edge kinds.\n\n### Where canon conflicts with already-made decisions\n\n1. **The four-rung ladder is not canon; the audit list is.** Dafny and Lean are binary (verified / not) *plus an enumerated list of soundness caveats*. **Canon should win on emphasis:** make the per-claim status a derived UI label, and make the **assumption ledger** — every `open` assumption with its owner, review status, and which guarantees it taints — the headline artifact. Ship it as a Markdown table, like `dafny audit`.\n2. **Acyclicity is stricter than canon.** Lean and Dafny permit mutual recursion licensed by a `decreases` measure. **The acyclicity decision should win for milestone one** — it makes validation trivially decidable and the failure message legible — but record it as a deliberate restriction and name `decreases` as the future escape hatch. That framing reads as informed rather than naive to a verification reader.\n3. **GSN is deliberately *not* computed.** A GSN goal structure is a human argument; nobody derives a verdict from it mechanically. The Datalog closure must therefore be sold as a **well-formedness and taint-propagation check, not an assurance verdict.** Never let the UI say a claim is \"proved\" unqualified. Borrow Alloy's honest stance: this finds defects; it does not certify.\n4. **\"Proof obligation\" is a term of art for a machine-generated VC.** We are eliciting *contracts and claims*, from which obligations would later be generated. Calling the output \"proof obligations\" will read as a category error to a Dafny user. **Prefer \"obligation ledger,\" \"claim structure,\" or \"assurance argument.\"**\n\n## 6. Unreached sources\n\n* ARIA **Safeguarded AI Programme Thesis v1.2 / v2** — PDFs are image-based; no text extraction. Likely the single highest-value unread source for Q4.\n* **GSN Community Standard v3 (SCSC-141C)** — download endpoint returns a redirect stub, not the PDF. GSN element definitions come from the FAA-hosted v1 plus secondary literature; v3 may have refined them.\n* **Bezem & Coquand, *Automating Coherent Logic*** (ResearchGate HTTP 403) and **Fisher & Bezem, *Skolem Machines*** (Semantic Scholar, empty body) — the primary Geolog sources. Read via institutional access before citing Geolog's concrete syntax.\n* **LessWrong: *Davidad's Provably Safe AI Architecture*** — HTTP 429 rate-limited. Worth a retry for Q4.\n* **Alloy online tutorial** (HTML parser crash) and **alloytools day-course slides** (PDF) — Alloy detail rests on Wikipedia plus its citation of Jackson's *Software Abstractions*.\n* **TLAPS project site** (`lamport.azurewebsites.net/tla/tlaps.html`, 404); TLAPS facts are from Wikipedia and the INRIA mirror.\n* **Isabelle documentation** (fetch error) — Isabelle is covered only by analogy to Lean here.",
+          "url": "https://linear.app/hash/issue/FE-1375/formal-verification-canon-survey-archive",
+          "createdAt": "2026-08-11T15:35:16.933Z",
+          "updatedAt": "2026-08-19T16:20:27.379Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "fa06f304-4d60-457e-ba14-801664e34c49",
+          "identifier": "FE-1374",
+          "title": "Assemble the spec [archive]",
+          "description": "The destination of the whole planning effort: assembled the full specification from every resolved ticket — fourteen sections plus an appendix of adjudicated contradictions. The spec lives at `docs/planning/elicitation-kernel/spec.md` (brunch-lite repo), with a companion plain-language product description. Resolved 2026-08-10; this closed the parent map.\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/08-assemble-the-spec.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Assemble the spec\n\nType: task\nStatus: resolved\nResolved: 2026-08-10\nBlocked by: 04, 05, 06, 07, 09, 10, 11, 12, 13\n\n## Question\n\nAssemble the destination spec from the resolved decisions: architecture + contract decomposition + questioning-UX contract + shipping shape + first milestone against the confirmed dev-target portfolio. Non-goals (harness-agnosticism) and the elicitor→executor seam named explicitly. This is the map's terminal deliverable; resolving it ends the effort.\n\n## Answer\n\n> Resolved by spec assembly, 2026-08-10. Full read of the ~54K-token working set (map, glossary, tickets 01–13 in the pre-pass's amendment order, both inbox docs), one session, no digest subagents — as sized.\n\n**The spec is assembled: [spec.md](<../spec.md>)** — the map's terminal deliverable. Fourteen sections + an adjudications appendix: purpose · non-goals & the elicitor→executor seam · vocabulary · four shells + binding · the capture envelope (derived-status principle, three strata) · operations & validation strata · questioning-UX contract · capture mechanics · sessions/durability/storage port · the ten-item substrate-capability list · plugins & packs · shipping shape · dev targets & milestone one (gherkin + assurance argument, `Statement` contract) · acceptance material (five proof obligations, ten harness invariants restated in envelope vocabulary, gating tests, testing strategy, open verification items).\n\n**All seven pre-pass contradictions adjudicated** (spec Appendix A): C1 storage port binding-implemented, with the `db.ts`-vs-capture-store reconciliation stated; C2 the four operations stay pure — ticket 12's PluginContext-storage clause scoped to non-op code, milestone one defines no such methods; C3 status derived, never stored — retraction specified as an explicit user-cited event with no successor; C4 tap-ness made a transport fact via a harness-defined reserved reply encoding (else absences are inferred); C5 invariant 1 reconciled with the provenance rule — user-derived captures cite user entries, `defaulted`/`external-lookup` cite declared defaults/documented transformations; C6 the channel is a per-message current-affordance surface, durable identity on tool output parts, reject-second-interactive-affordance as mechanism; C7 picked together — no instruction interpolation (kills the wake wart's cause), pending question on the ask tool result + pending-affordance slot, reply binding harness-mechanical via the single-pending invariant, no echo token.\n\n**Notable assembler adjudications beyond the seven** (each flagged inline in the spec): retraction semantics; `not-mentioned` demoted to computed fact; absence-strip label mapping and the `not-yet-decided`/`deferred` distinction; advisories as computed-ephemeral vs. stored issues; issue namespacing; domain labels computed via `project` at read time; transport outcomes `answered | redirected | unanswered` (`unavailable` retired); session→target-document binding via `initialData`; milestone-one store format constrained by whole-sweep atomicity; **kernel card** kept as a term of art, **\"kernel invariants\" renamed harness invariants**.\n\n**Fold-ins completed alongside**: `CONTEXT.md` gained the envelope-vocabulary section (capture envelope, evidence span, epistemic status, absence state, supersession, resolution record, issue, advisory, pack, kernel card, PluginContext, storage port — pre-pass L11) and the kernel-compound ruling (L12); the `plugin-assurance` rename propagated as header notes on tickets 02 and 07; the 42-item obligation checklist verified covered (§ mapping held during drafting); the ten kernel invariants restated in current vocabulary (S14) so only one vocabulary exists in the acceptance criteria.\n\nResolving this ticket ends the effort: the map's frontier is empty. Remaining fog (dev-app probe view, remote deploy target, storage format, concurrent-session coordination, plugin-ecosystem machinery, the real name) is post-spec by construction and graduates with the build effort the spec now enables.\n\n## Comments\n\n**2026-08-10 (pre-assembly prep, HITL).** Three prep items completed ahead of this ticket:\n\n* **Second-target rename decided**: the target is the **assurance argument**, package `plugin-assurance` (recorded on the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>); ticket 09's category-error verdict discharged). Propagate over the historical `elicit-proof-obligations` occurrences in tickets 02 and 07.\n* **Cross-ticket consistency pre-pass**: [notes/consistency-prepass-2026-08-10.md](<../notes/consistency-prepass-2026-08-10.md>) — the assembler's working checklist. Contents: **seven contradictions** the spec must adjudicate, each with an authoritative-side recommendation (C1 storage-port implementer; C2 op purity vs PluginContext storage methods; C3 derived capture status changes 04's envelope schema; C4 `deferred (explicit)` lacks a transport mechanism; C5 provenance rule vs kernel invariant 1's declared defaults; C6 one-live-affordance slot vs multiplexed forms; C7 wake-wart remedy and reply binding must be picked together); **fourteen stale statements** (S1–S14) so nobody re-imports superseded material — notably 03's partly-overturned classification table and the requirement to restate the ten kernel invariants in current vocabulary; the **42-item \"the spec must…\" checklist** (§3b) collected from every ticket; and the **amendment-order reading guide** (§4) — read tickets in that order, treating 01/02/03 as lookup sources.\n* **Sizing corrected**: ~54K tokens total — map + glossary + tickets (~42K) **plus the two inbox docs** (`agentic-elicitation-challenges`, `agentic-elicitation-criteria`, ~13K), which ticket 04 adopts by reference and by count, so the spec cannot be assembled without reading them. Fits one session raw; no digest subagents needed.\n\n**New blocker added**: [Walking skeleton: sweep seam on Flue](<13-walking-skeleton-sweep-seam.md>) — the pre-pass found the sweep seam unproven on the committed substrate (no settlement-trigger lifecycle event exercised, no proven harness path to read a session entry range; items L1–L3). Decision (HITL, 2026-08-10): prove it before assembly. Its resolution also completes the substrate-capability list this spec must enumerate.\n\nAlso fold in when drafting: the glossary needs the envelope vocabulary added (pre-pass L11–L12) — capture envelope, evidence span, epistemic status, absence state, resolution record, supersession, pack, issue, kernel card, PluginContext, storage port — and a ruling on the \"kernel card\" / \"kernel invariants\" compounds vs the glossary's \"avoid: kernel\".\n\n**2026-08-10 (HITL review round 1, via tuicr).** Seven comments on the draft; five spec amendments: (1) **executor/handoff language removed entirely** — brunch adoption leakage; the spec now names *no privileged downstream consumer* (partially supersedes obligation 17's \"elicitor→executor seam\" clause); (2) absence-state enum marked a working set with expected extension pressure (the assumption vs. known-unknown lesson; naming-for-behavioral-activation as kernel-card-grade work); (3) structured taps pinned as optional ui capability, not a requirement; (4) `project` kept as canon op name with a stated prose preference for the noun (and the §9.4 \"signals project\" verb collision fixed); (5) **new §9.7 compaction vs. durable log** — compaction may shrink what the model re-reads, never what the store can resolve; durable-projection independence stated as a storage-contract constraint, binding absorbs otherwise; verification item added to §14.5; (6) Principle v2 ratified by acclaim, no change; (7) **binding packages take the role prefix**: `packages/binding-flue`, horizon `binding-*` (product name lives in the npm scope, not the basename).\n\n**2026-08-11 (HITL review round 2, from the plain-prose read-through).** Four observations, all folded in: (1) evidence pointers confirmed already stored — §5 sharpened so quote→entry resolution is stated as write-time-once, every later reader navigates by pointer, never text search; (2) `declined` ≠ `deferred` pinned in §5.1 — a decline is a boundary (closes only via explicit act), a deferral an invitation (completion evaluation chases it); (3) **conversations are documents too** — storage-port scope extended to capture store **plus session-log archive**, archive-on-read mechanism, session logs retained indefinitely with the target-document (§9.1/§9.6/§9.7 amended; the archive also becomes the compaction defense); (4) **generic strategy quiver written in as §11.5**, named-not-designed — guidance ownership follows vocabulary ownership; harness-shipped strategy cards over envelope vocabulary, plugin-composed; reference shapes `ln-grill`/`ln-disambiguate` and brunch's style trichotomy; the assurance technique decomposes into generic strategy + domain cards. `CONTEXT.md` (storage port, kernel card) and both companion docs updated to match. Note: round 2's changes were narrated in-session on 2026-08-10 but committed 2026-08-11 — the earlier narration preceded the actual edits.",
+          "url": "https://linear.app/hash/issue/FE-1374/assemble-the-spec-archive",
+          "createdAt": "2026-08-11T15:35:15.764Z",
+          "updatedAt": "2026-08-19T16:20:26.406Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "manual-task" }] }
+        },
+        {
+          "id": "4b48c94d-9bf0-4c40-beeb-7c5192117580",
+          "identifier": "FE-1373",
+          "title": "Dev-target portfolio confirmation [archive]",
+          "description": "Confirmed the two practice subjects the architecture is built against — Gherkin scenarios and assurance arguments (BPMN third) — because building two very different subjects at once forces the plugin model to stay genuinely general. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/07-dev-target-portfolio.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Dev-target portfolio confirmation\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 02\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). Also superseded here: the four-rung status ladder is demoted to a derived UI label with the assumption ledger as headline (pre-pass S8), and the Geolog/ARIA adjacency guess is refuted (pre-pass S9).\n\n## Question\n\nConfirm the first milestone's two live dev targets. The zil-lean survey resolved the shape of the second: full elicit-lean is **not** dev-sized (writing Lean statements from intent is the deep-expertise step), but the **elicit-proof-obligations** slice is — capture an assumption/lemma/theorem/guarantee dependency graph with criticality and evidence refs, validated by acyclicity + Datalog closure (no Lean statements, no proofs), per the ElicitationPack/ProjectionPack sketches in the survey answer. The survey judges it a *better* second target than BPMN on both pack axes; BPMN stays third.\n\nProposed portfolio to confirm: **elicit-gherkin** (tracer) + **elicit-proof-obligations** (second, forces the pack swap and the evidence-graded IR).\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06.\n\n**Portfolio confirmed**: `elicit-gherkin` + `elicit-proof-obligations` are the first milestone's two live dev targets; `elicit-BPMN/process-mining` is named third; full elicit-lean is deferred (writing Lean statements from intent is the deep-expertise step zil-lean itself never attempts).\n\n**Order — hybrid, addressing the real risk at the design layer**: the spec mandates that **both packs are authored before the pack interface freezes** (design against both simultaneously, on paper — the \"two targets on each axis from the beginning\" rule), while **elicit-gherkin wires end-to-end first** as the cheap mechanism proof, with elicit-proof-obligations immediately after. Rationale: the user's identified risk — brunch failed to find a scalable, modular way to specify an elicitation process plus guiding skill material without over-proceduralizing — lives in interface design, not wiring order. The trivial target must not freeze the pack contract before the hard target has stressed it.\n\n**Design principle surfaced (routed to Contract decomposition as a named input)**: agents do better with *behavioral* guidance than procedural, and with *clear shapes/patterns to fill* rather than schemas that require extensive parsing to build a model of the output shape. Packs are shapes-to-fill plus behavioral guidance — not procedural scripts, not parse-heavy schemas.\n\n**Proof-obligations output format**: steal the ideas, own the format. Adopt zil-lean's load-bearing vocabulary (evidence-graded assurance lattice with prohibited promotions; PROVED/CONDITIONAL/WEAK/BROKEN status ladder; acyclicity + Datalog-closure validation) in our own claim-DAG serialization, **hewing to whatever existing canon fits** — Dafny's `requires/ensures/invariant` contract vocabulary is the leading candidate; Geolog (ARIA program, axioms addressed via Datalog-like queries) is plausibly adjacent. Grounding this is the new **Formal-verification canon survey** ticket (09), which blocks Assemble-the-spec so the milestone lands canon-grounded. `.zc` export is someday-maybe; no dependency on the unproven zil-lean repo.\n\n**Gherkin validator depth (milestone one)**: parse validity + optional **pack-declared step-lexicon** binding check. The apparent codebase coupling dissolves: a step lexicon carried as pack policy needs no external project; only live-codebase step binding defers, named as the target's growth path.\n\nSub-questions:\n\n* Do the two chosen targets differ materially on *both* pack axes (semantic + representation)?\n* What is each target's smallest honest output contract for milestone one?\n* Which target is the tracer (built first) and which trails to force the second-pack swap?",
+          "url": "https://linear.app/hash/issue/FE-1373/dev-target-portfolio-confirmation-archive",
+          "createdAt": "2026-08-11T15:35:14.709Z",
+          "updatedAt": "2026-08-19T16:20:27.618Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "dc49b036-3e7f-4663-85c9-64fa741c64f8",
+          "identifier": "FE-1372",
+          "title": "Shipping shape: kernel library vs. Flue agent [archive]",
+          "description": "Decided what actually ships: a harness library inside a thin host-authored agent — not a standalone product — organized as a workspace monorepo with the plugin SDK as its public surface, and tested by generated, replayable interview fixtures rather than live model calls. Resolved 2026-08-08; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/06-shipping-shape.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Shipping shape: kernel library vs. Flue agent\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 01, 04\n\n## Question\n\nWhat does the carve-out physically ship as — a kernel library that a thin Flue agent (and later Petrinaut/web/brunch hosts) embeds, or a Flue agent as the product itself — and what is the viable/ideal package structure?\n\nSub-questions:\n\n* Given the Flue deep-read: is library-embedded-in-agent natural in Flue, or fighting the framework?\n* What does each option cost the Petrinaut-UI and web-UI futures?\n* Package topology: one package or kernel + packs as separate packages? Where do dev targets (elicit-gherkin, elicit-lean) live?\n* What is the local dev loop (run against both targets) vs. the remote deploy story?\n\nInput from Contract decomposition (issue 04): the plugin **SDK surface** is part of the shipping shape — standard machinery for evidence anchoring, claim identity, issue construction, schema validation, retries, idempotency, state-delta application, tracing, test fixtures, and a **local simulation harness** (fixture-driven pack testing: conversation in → expected claims/issues/projections out; \"debugging should not require reading an entire agent transcript\"). The black-box authoring test and change-surface metric are the acceptance bar.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-07 (two rounds + a testing-strategy revision pass grounded in `expert-property-based-testing`).\n\n### Root: harness library in a thin host-authored agent — ratified, with the second-binding test\n\nThe product is the **harness library** (core + packs/plugins); every host authors its own thin `'use agent'` module, `app.ts` mount, and storage adapter, and calls a hook shaped like `useElicitation(plugin)`. The Flue facts make the alternative structurally unavailable anyway (build-time `'use agent'` scan lives in the consuming project; a library cannot ship a pre-registered agent). A runnable reference app ships alongside as a dev/demo vehicle, not as the product.\n\n**Amendment — portability as a named pressure test, not a build target.** The deliverable decomposes into (1) pure runtime mechanism, (2) a tool surface, (3) prompt/skill material — and (3) is already portable for free (Open Agent Skills format is shared by Flue, Claude Code, and Pi-family harnesses). The substrate-agnostic-core non-goal stands as written (no ports for hypothetical consumers, no second maintained binding), but the decomposition must keep a second binding *demonstrably small*:\n\n* The spec **enumerates the substrate-facing surface as a short named capability list** the binding must supply: register a tool · contribute instructions · persist state · emit an affordance payload · suspend-for-reply · private model call. Porting = reimplementing that list; if it grows exotic Flue-shaped entries, that is an early smell signal.\n* **Second-binding test** (sibling to smallest-honest-plugin, adopted into spec acceptance material): every time mechanism wants to land in the binding rather than the core, ask \"is this genuinely substrate-specific, or is mechanism leaking into Flue's dialect?\"\n* Binding-size asymmetry is expected, not a failure: Flue's binding carries the turn-suspension compensation (ticket 10); a terminal binding gets ask-the-user nearly free but may only afford the questioning-UX markdown floor (which issue 05 already fixed as universal). Claude Code/Codex would be the awkward cousins (out-of-process: MCP server + skills dir). The core stays identical; each binding absorbs what its substrate lacks or forbids.\n* **Binding** entered the glossary (`CONTEXT.md`): the harness defines the capability list; a binding imports both harness and substrate; the harness imports no substrate.\n\n### Package topology\n\n* **Core and Flue binding as two workspace packages from day one.** The package boundary is the enforcement mechanism for the portability property; extracting a subpath later is visible churn. Acknowledged as mild ceremony now — accepted because the cost is low if kept clean.\n* **Monorepo in this repo** (brunch-lite becomes the workspace; rename is cheap once the real name resolves). Bun workspaces: `packages/core`, `packages/flue` (binding), `packages/plugin-gherkin`, `packages/plugin-proof-obligations`, `apps/dev`. The dev app owns the `'use agent'` module, `app.ts`, `db.ts`, and the Vite build Flue requires. Spec records the layout as intended structure; nothing is scaffolded during this map.\n* **Plugin packages are** `plugin-*`**, not** `elicit-*` — the prefix names what they are architecturally; \"elicit\" is the function, not the identity.\n* **Plugin SDK is core's public export surface** (authoring types + machinery; test/fixture machinery on a `core/testing` subpath so prod bundles stay clean). A separate SDK package would re-export core with no seam-value.\n* **Dependency rule, stated as a spec invariant: plugins depend on** `core` **only** — never on the binding, never on Flue. Every plugin is substrate-portable by construction, and the black-box authoring test stays honest (a plugin author's world is one package's exports).\n* **Envisioned horizon** (named, not built): per-substrate binding packages (`flue-<name>`, `pi-<name>`, `codex-<name>`), same harness inside each. The payoff *if the second-binding test keeps passing*, not a commitment.\n\n### Cross-cutting choices\n\n* **Valibot throughout** — Flue locks it at every boundary; Standard-Schema-at-the-waist would buy plugin-author comfort at the cost of a conversion seam that can silently drop constraints (named smell: silent coercion/loss).\n* **Tool namespacing: prefix derived from the product name**, provisionally `bl_*` — never `elicit_*` (function vs. identity again). Core names ops abstractly; the binding renders them as substrate tool names. All model-facing tools are harness-owned (plugins expose ops, not tools).\n* **Naming principle** (recurring, carried forward): architectural strings name *identity* (product, role), not *function*; the name-fog eventually resolves every one of these strings, so nothing bakes \"elicit\" or \"brunch\" into structure.\n* **Publishing posture: workspace-internal** — no npm publishing until the real name resolves and an external consumer exists. The spec describes the publishable shape; publishing waits.\n\n### Testing strategy: generation-first fixtures, deterministic replay\n\nThe scripted deterministic driver (ticket 11's headless-driver pattern) is the **execution/replay layer**: fixtures are data, replay is pure, everything runs in plain `bun test` — no model, no substrate. But hand-written fixtures demote to **seeds**; the corpus is generated, answering the two untruthfulness modes:\n\n1. **Circularity** (fixtures tailored to the plugin-as-written): properties come from the **kernel contract** — the ten kernel invariants (ticket 04) are literally properties (re-sweep idempotence, equivalent-state → equivalent-projection, corrections don't erase history, retries idempotent, …) — and generators come from the **plugin's declarations**, never its implementation. The SDK ships `arbitraryFromSchema` (Valibot → fast-check arbitraries) for generated capture populations, plus negative-space properties for plugin code (validators total: never throw, always typed issues; `project` never emits an undeclared loss category).\n2. **Unrealistic conversational dynamics**: (i) most invariants hold over capture/state space directly — no conversation needed; (ii) where dynamics are the subject (sweep/settlement, supersession, absences), **model-based command-sequence testing** (`fc.commands`) over a small command alphabet — utter · settle-range · sweep · correct · contradict · reply-with-absence · redirect — derived from the envelope vocabulary; the fuzzer explores interleavings no hand-scripted conversation contains; (iii) language realism via a **model as offline generator, never CI oracle**: a model plays the respondent against the plugin's own kernel cards (Detects/Questions = targeting spec), varied by persona/curveball, plus a **mutation library** generalizing the minimal-pairs test (epistemic-status flips, absence injections, supersession injections). Outputs freeze as replayable fixture files; **regenerate when declarations change** (the anti-drift mechanism).\n\nBonus adopted: shrunk counterexamples from broken invariants *are* minimal pathological conversations — pinned as regressions and read first as type-design feedback on envelope/payload types. SDK surface therefore includes: schema-driven arbitraries, the command alphabet, mutation operators, fixture freeze/replay format — alongside ticket 04's list (evidence anchoring, capture identity, issue construction, retries, tracing).\n\n### Dev loop, demo, deploy\n\n* **One agent per target** in one dev app (`ElicitGherkin`, `ElicitProofObligations`): static per-agent tool sets (Flue cache economics), and the shape Cloudflare forces later anyway (build-time agent set; plugin choice is conversation-lifetime-immutable via `initialData` regardless).\n* **The dev app is chartered with three roles, spec'd as roles not features**: (1) local dev loop against both plugins; (2) the colleague-facing **target-gallery demo** — parallel tabbed sessions: start a BDD-spec elicitation, open another tab for a proof obligation, another for a process model; (3) the diagnostic/probe surface — provisional affordance renderers now (the deferred UI package's exploratory material), exploded-view instrumented readout when it graduates. Demo-polish and probe-internals pull opposite ways, so they are different views/routes of one app.\n* **UI affordance package deferred**: spec names it as intended (React renderers + reply transport over `@flue/react`; non-React hosts build on `@flue/sdk`), milestone one keeps renderers in the dev app.\n* **Remote deploy: milestone one is local-only; the spec pins the remote-parity constraints** (one-agent-many-conversations, pinned `agentName`, host-owned storage port, no dynamic agent creation) so nothing local-only creeps in. CI smoke = `vite build` + the simulation suite (no model key, no flake); an optional secret-gated real-model `flue run` smoke once a provider key exists. Actual deploy-target choice waits on an infra conversation (user, 2026-08-07) and blocks nothing on this map.\n\n## Comments\n\n**2026-08-07 (context pointer, from issue 11's cleanup).** The prototype branches are the implementation seeds for this topology, kept as primary sources out of main: `prototype/11-capture-sweep` holds the pure capture-layer reducer (no DOM, envelope semantics only) whose behavior `packages/core`'s capture module lifts *as semantics, not code-by-copy*, plus a headless driver whose 32 checks seed the invariant-property suite described under Testing strategy (several are already kernel-invariant instances: re-sweep idempotence, atomic sweep application, corrections-don't-erase-history, single-hop supersession). Likewise `prototype/10-flue-roundtrip` is the sketch `packages/flue` starts from. Working-tree copies were deleted after HITL review; retrieve any file with e.g. `git show prototype/11-capture-sweep:.scratch/elicitation-kernel/prototypes/11-capture-sweep.html`.\n\n**2026-08-10 (amendment, from [Multi-session elicitation & durable target state](<12-multi-session-durable-target.md>)).** The charter's persistence hypothesis resolved: **flipped** — the storage port is harness-defined and binding-implemented, plugin-blind; plugin-addressable storage exists only as harness-defined methods passed through the injected PluginContext. This sharpens two things already in this ticket: the capability-list entry \"persist state\" and the remote-parity constraint \"host-owned storage port\". Additionally, evidence spans carry pointer + quoted excerpt, so capture provenance is self-contained regardless of how a deploy target exposes substrate session logs.\n\n**2026-08-10 (amendment, second-target rename).** Per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict, the second target is now the **assurance argument**; the topology's `packages/plugin-proof-obligations` reads `packages/plugin-assurance`.",
+          "url": "https://linear.app/hash/issue/FE-1372/shipping-shape-kernel-library-vs-flue-agent-archive",
+          "createdAt": "2026-08-11T15:35:12.893Z",
+          "updatedAt": "2026-08-19T16:20:27.583Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "4302b30b-db51-41f6-ab3c-8fbfa97fa1fb",
+          "identifier": "FE-1371",
+          "title": "Questioning-UX contract [archive]",
+          "description": "Decided how structured questions live inside a free-flowing conversation: the conversation stays primary, forms and choice strips are dropped into it as interactive elements, and captured knowledge is extracted afterwards in repeatable sweeps rather than question-by-question. Also fixed the system's four-layer naming (substrate / ui / harness / plugin). Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/05-questioning-ux-contract.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Questioning-UX contract\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-07\nBlocked by: 03\n\n## Question\n\nWhat is the kernel's generic questioning-UX contract — the successor to brunch's `ask` / `present_*` / `request_*` exchange family — critiqued rather than copied?\n\nSub-questions:\n\n* Which of brunch's exchange forms earn a place in the generic contract, which generalize with changes, which are brunch-specific and stay behind?\n* What does the \"one high-value question over several low-value questions\" dialogue policy need from the UX contract (question budgets, visible current interpretation, distinguish not-mentioned/no/unknown/N-A)?\n* How do typed issues (missing/ambiguous/conflicting/invalid/unsupported/unmapped/low-confidence) render as user-facing exchanges?\n* What must the contract leave to the host surface (TUI vs. web vs. chat channel) vs. fix in the kernel?\n\nInput from Contract decomposition (issue 04): the exchange contract must carry the envelope's conversation-level semantics — **absence states** (`unknown-to-user | declined | deferred | not-applicable`… as answer outcomes, not null), **alternatives** (letting more than one interpretation stay live through an exchange), and conflict-resolution exchanges (an explicit resolution event for a `conflicting` issue). Dialogue policy is behavioral guidance + factual issue queue — the UX contract renders issues to the agent, never scores them.\n\nNote from the Flue deep-read (issue 01): Flue has **no first-class ask-the-user primitive** — the kernel must own a turn-suspension protocol (`terminate: true` tool + pending question in persistent state + structured data part; the answer arrives as a fresh dispatch). The UX contract should be designed with that as the remote rendering path (`useDataWriter` / `dynamic-tool` output parts), alongside richer local surfaces.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (five rounds), with a live fact-finding pass over Flue's docs mid-session. All shape-level commitments are **working hypotheses** per the built-artifacts-as-proofs preference (ratified into the map's Notes during this session); delegated proof obligations live in tickets 10 (walking skeleton) and 11 (logic-prototype). Vocabulary hardened via `/domain-modeling` into repo `CONTEXT.md`.\n\n### The load-bearing reframe: no exchange-pair ontology\n\nBrunch's exchange machinery (offer→terminal pairs, pending-exchange state, recovery scans) was baggage from its older agent-initiated turn-by-turn model and is **not inherited**. The free-flowing conversation is primary. When the agent poses a structured question it emits an **affordance** — a rendered enhancement in the stream, not a state machine the harness maintains. There is no \"pending exchange\" concept, hence no cardinality rule, no recovery scan, no terminal union.\n\n* Ask invocations **do commit** structured question payloads to the session (design clue: Claude Code's `AskUserQuestion` — question set as `tool_use`, selections/interruption as adjacent `tool_result`; self-contained, replayable, no separate exchange store). The answer may follow as a structured response, or the ask may be cancelled/redirected — all of it is **session evidence**.\n* **Capture is decoupled from asking**: a **range-sweep** over session entries, run on **settlement** (agent-judged, range-level — a vein closing — never per-question, which would resurrect exchange-pairs through the back door). Harness owns sweep bookkeeping (high-water mark, idempotence); agent owns settlement judgment. → ticket 11.\n* Audit lessons demoted by the reframe: *declared continuations / non-forgeability* (the failure mode shifts from forgery to misinterpretation, which the envelope's `epistemic_status: inferred` already covers; whether a widget reply needs an echo token is empirical → ticket 10); *only-answered-closes recovery* and *self-contained terminals* (patterns at most, not structure).\n\n### Shells, vocabulary, and control (hardened)\n\n**substrate** (Pi family, Flue) → **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI) → **harness** (the generic capability layer — mechanism + orchestration; the effort's essence is *harness-engineering*; replaces \"kernel\" as shell name) → **plugin** (target policy). Control is IoC per the Hollywood principle: the plugin declares and registers; the harness discovers, orders, invokes; harness capabilities (the ask API, capture envelope, issue queue, sweep bookkeeping) reach the plugin as a **narrow injected context** — the questioning-UX contract is literally part of the PluginContext surface. Composition is the plugin's at authoring time; control flow is the harness's at runtime. Schema ownership follows capability ownership: *the shell that defines a capability owns its affordance schemas.*\n\n### What the harness fixes (the generic contract)\n\n1. **Baseline question forms**: free-text / single-choice / multi-choice, plus **questionnaire chaining** as first-class baseline (beyond brunch's `ask`). The harness owns the standard ask API and payload shapes; plugins add custom presentation/collection forms through the plugin API.\n2. **Absence**: interpret by default, afford when structured. Agent-interpreted absence from free conversation carries `epistemic_status: inferred`; structured affordances carry a one-tap absence strip (don't-know / not-applicable / decide-later — generalizing `allowNone`), keeping `unknown-to-user` vs `declined` vs `not-applicable` explicit. Transport outcome and epistemic absence never conflate.\n3. **One harness data channel** multiplexing all affordance forms (`form` tag + plugin-typed body + markdown baseline), because Flue channel names are static structural identity in a flat collision-prone namespace. Plugin widgets are progressive enhancement keyed on the form tag; hosts that know only the envelope render everything via markdown. → ticket 10.\n4. **Interpretation render** (\"visible current interpretation\"): the one affordance form that must be harness-owned, since it renders the harness's own envelope vocabulary — captures with epistemic status, absence states, live alternatives. The **plugin may supply a renderer/projector definition with typed arguments** (typed against its own payload shapes), which the harness uses to produce the ui-level view; **when it doesn't, the harness falls back to a default renderer (plain JSON view of payloads)** — keeping the renderer optional, consistent with the smallest-honest-plugin test. React vs. accept are two *capture semantics*, not exchange steps. Renderer-seam exercised once real packs exist (ticket 07's portfolio).\n5. **Issues → exchanges**: only `conflicting` / `possibly-equivalent` get forced treatment — a `conflicting` issue closes **only via an explicit resolution record** (capture-layer event citing the user's utterance as evidence); the guarantee moved from wire to store. Every other issue type renders however the agent judges best, guided by kernel cards — prescribing seven mappings would be judgment-as-procedure. → ticket 11.\n6. **No question-budget machinery**: economical interviewing is implemented through strategy and judgment guidance in pack kernel cards; with asks committed to session, anything countable is derivable — no stored counters, no ask-to-issue attribution model, no stored number for the agent to defer to.\n\n### What the ui owns\n\nRendering (zero built-in widgets in Flue — the embedding app branches on part types), reply transport, identity. Flue facts recorded for the spec: outbound is rich (Valibot-validated `data-*` parts, dynamic-tool outputs), **inbound is string-only** (`sendMessage(text, images)`; SDK signals are string-body too) — so answer typing/validation happens entirely harness-side on read-back; unknown part types are silently dropped (hence the markdown-baseline floor); one documented contradiction (data-part update-in-place vs append) needs the ticket-10 runtime check; turn suspension confirmed (`terminate: true`, answer as fresh dispatch; multi-tool batches terminate only when every result terminates).\n\n### Brunch disposition (sub-question 1)\n\n**Earns a place**: the three answer shapes as interaction vocabulary; questionnaire (promoted); absence affordances (generalized from `allowNone`); react≠accept (as capture semantics); no-stored-agenda (extended: no stored counters either). **Generalizes with changes**: named present tools → plugin-declared forms over one channel; approval-commits-atomically → the resolution-record store guarantee. **Stays behind**: the exchange-pair ontology and everything predicated on it (terminal unions, recovery scans, prev/curr/next chains, declared continuations as wire mechanism), plus everything the audit already classed brunch-specific (rubric schemas, review-set node/edge machinery, graph_refs). Audit lessons not touched by the reframe (comment-vs-message provenance, boundary-teaching schemas, hash-pinned prompt directives, private scratchpad) stand as pattern guidance for the spec.\n\n### Process decision (map-level)\n\n**Built artifacts as proofs** ratified into the map Notes: grilling tickets resolve decisions provisionally and name the proof obligations they delegate. Two prototype tickets created from this session: [Walking skeleton: Flue question round-trip](<10-walking-skeleton-flue-roundtrip.md>) and [Logic-prototype: capture sweep & settlement](<11-logic-prototype-capture-sweep.md>). Plugin lifecycle, fault containment, and contract versioning routed to [Shipping shape](<06-shipping-shape.md>).",
+          "url": "https://linear.app/hash/issue/FE-1371/questioning-ux-contract-archive",
+          "createdAt": "2026-08-11T15:35:11.332Z",
+          "updatedAt": "2026-08-19T16:20:27.539Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "9d7da48f-bd0d-4320-ab00-08e9060625f0",
+          "identifier": "FE-1370",
+          "title": "Contract decomposition: kernel / host / plugin / pack boundary [archive]",
+          "description": "Decided how responsibility splits between the generic interviewing engine and the pluggable subject-matter definitions. The engine owns a domain-free envelope around whatever a plugin stores — with evidence links, confidence, and explicit \"no answer\" states — and typed issues as its feedback channel; there is deliberately no universal data model. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/04-contract-decomposition.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Contract decomposition: kernel / host / plugin / pack boundary\n\nType: grilling\nStatus: resolved\nResolved: 2026-08-06\nBlocked by: 01, 03 (both resolved)\n\n## Question\n\nWhat exactly does the kernel own (mechanism + orchestration), what does the host supply (input shapes and pathways, deploy target), and what do plugins define (target policy) — and does the four-contract + pack decomposition (ElicitationPack: concept/observation/completion; ProjectionPack: projection) survive contact with the Flue facts and the brunch audit?\n\nSub-questions this grilling must close:\n\n* Are the A-axis (semantic target) and B-axis (representation target) genuinely separately swappable in our first milestone, or bundled per plugin?\n* Where does the evidence-preserving IR / claim graph live, and how thin is its common core?\n* Persistence: does the plugin-owned-persistence hypothesis hold, or does the host (deploy target) own it with plugins declaring shape? What state must the kernel externalize (session, transcript refs, artifact-in-progress, episteme ledger)?\n* Where is control inverted: typed issues as backpressure (projector → elicitation controller) — is that the only inversion, or do observation lenses invert too?\n* The policy-vs-mechanism rule: enumerate what would otherwise become the central `switch` and check each is on the plugin side.\n\nPrimary input: docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md\n\nNamed input from the portfolio decision (issue 07): **behavioral over procedural** — agents do better with behavioral guidance than procedural scripts, and with clear shapes/patterns to fill rather than schemas that require extensive parsing to build a model of the output shape. Brunch's unsolved problem — specifying how an elicitation process should work plus skill material to guide an agent through it, without over-proceduralizing — is a core stress test for the pack contract. The decomposition must say what a pack *feels like* to the agent consuming it, not only what it validates.\n\nConcrete test cases for every boundary claim (from issue 07): how would `elicit-gherkin` do this vs. `elicit-proof-obligations`? The spec mandates both packs are authored before the pack interface freezes.\n\n## Answer\n\n> Resolved by HITL grilling, 2026-08-06 (four rounds, including an evidence pass over `~/Clones/mattpocock/skills` + `../brunch/docs/design/BEHAVIORAL_KERNELS.md`, and integration of [agentic-elicitation-criteria](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>), the second inbox doc).\n\n### Ownership table\n\n|  | Owns |\n| -- | -- |\n| **Kernel** *(mechanism + orchestration)* | The conversation loop, agent-forward (agent judgment at the helm) · the questioning-UX contract (issue 05's subject) · the **capture envelope** (below) around opaque plugin payloads · the **typed issue queue** (vocabulary, storage, factual attributes; the only stored agenda-like state; also where conflict/equivalence live) · the private scratchpad · the **turn-suspension protocol** (Flue has no ask-primitive; the kernel owns one) · operation *signatures* (`observe/reconcile/project/validate`) with snapshot-in/deltas-out calling convention, validation, and application of returned deltas · completion evaluation (running plugin-declared criteria) · pack loading, progressive disclosure, kernel-card activation · capture-id minting · the **storage port** definition |\n| **Host** *(embedding + affordances)* | Input surfaces and pathways (TUI / web / chat channel / Petrinaut later) · verified respondent identity · deploy target · **storage port implementation** · artifact delivery (repo write, API, post) · model/provider via the Pi family |\n| **Plugin** *(target policy)* | Its **own IR payload structure** — graph, flat list, whatever fits; shared between its packs, never universal; namespaced concepts · **ElicitationPack**: kernel cards (Detects / Goal / contrastive Questions / Artifacts), completion contract, clarification hints · **ProjectionPack(s)**: `project` + `validate` (required), `reconcile` (optional), output contract, annotated shapes, **typed loss reports**, lossiness policy · artifact persistence *shape* · domain vocabulary |\n\n### The capture envelope (the hourglass waist)\n\nKernel-defined, domain-free — semantically rich, structurally minimal:\n\n* `id` (kernel-minted), evidence spans (utterance provenance, phrase-level where possible)\n* **Epistemic status** enum, distinct from confidence: `explicit | inferred | tentative | defaulted | external-lookup`\n* Confidence (qualitative), status: `active | superseded | retracted`, one `supersedes` link\n* **Absence states** as first-class capture values: `not-mentioned | unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred`\n* **Alternatives** grouping: >1 live interpretation of the same evidence may coexist until resolved\n* Opaque, plugin-typed payload. **No kernel edges, no graph, no kind taxonomy** — structure is payload business. Conflict (`conflicting`) and equivalence (`possibly-equivalent`) are **typed issues referencing capture ids**, not edges; resolution must be an explicit event (supersession or recorded decision) — \"no silent conflict resolution.\"\n\n### Operations\n\n* **Required**: `project` (captures → draft artifact **+ typed loss report**: `mapped-exactly / normalized / approximate / collapsed / omitted / defaulted / unrepresentable`) and `validate` (→ typed issues).\n* **Optional**: `reconcile` (dedup/merge over the plugin's own structure); kernel calls it when present.\n* **Agent-native**: `observe` — noticing is the agent's work guided by pack kernel cards; code-level extractors are an optimization, never the required path.\n* **Calling convention**: plugin ops receive an **immutable state snapshot**, return observations/issues/deltas; the kernel validates and applies. Buys atomic plugin failure, semantically idempotent retries (a retry never counts as a second user assertion), and tracing.\n* **Backpressure**: validators and projectors never address the user; they return typed issues the agent consumes.\n\n### Dialogue policy\n\nBehavioral guidance + factual issue queue. **Facts computed, weights judged**: the kernel computes issue facts (blocks-required-criterion, origin semantic|representational, can_default); the agent weighs them qualitatively. The inbox doc's priority formula is adopted as *prose the agent thinks with*, never as a computed score — computed-priority dimensions are judgments wearing metric costumes, and a stored ranking becomes an authority the agent defers to instead of reading the conversation (brunch's no-stored-agenda lesson).\n\n### Cross-cutting decisions\n\n1. **No universal IR** — the kernel's slice is the envelope; structure is plugin-unique. Typed-entity-graph maximalism explicitly not adopted; a graph remains any plugin's private choice (including a future brunch-target plugin).\n2. **Smallest-honest-plugin test** — a flat record list + one validator must suffice; every kernel-contract addition is checked against the bar it raises. Empirical form: the black-box authoring test.\n3. **Axes separated in contract, bundled in shipping** — one ElicitationPack + N ProjectionPacks per plugin sharing the plugin's IR; swappability proven by reprojection.\n4. **Principle v2 (ratified, replaces \"behavioral over procedural\")**: *procedure for mechanism, anchors for judgment, shapes for output*. Evidence: the mattpocock skills are full of procedure that works because it is short, carried by leading words (pretrained concepts recruited deliberately), ends on checkable completion criteria, and rides on shapes/templates with progressive disclosure. Failure modes to design against: sprawl, negation-steering, no-ops, judgment-encoded-as-procedure — not procedure itself. `writing-for-agents` is the cited pack-authoring standard.\n5. **Kernel cards** (from BEHAVIORAL_KERNELS.md) are the unit of ElicitationPack content: Detects (signal-phrase activation) / Goal / contrastive Question patterns / Artifacts (typed claims emitted) / validator hooks. The fifteen-kernel ontology itself stays brunch prior art; packs declare their own kernels. Contrastive classification over open-ended essays.\n6. **Pack physical form**: kernel cards + annotated shapes + deterministic validators + small wire schemas (boundary-teaching: shallow for model legibility, deep requiredness in validators) + completion contract as checkable bounds.\n\n### Acceptance material adopted into the spec (from the criteria doc)\n\n* The **five proof obligations** as contract acceptance criteria: independent variability, semantic conservation, explicit transformation, controlled elicitation, local implementation.\n* The **ten kernel invariants** (§9) as kernel-enforced test properties (no unsupported value without provenance; no silent conflict resolution; no silent projection loss; corrections don't erase history; retries idempotent; target issues namespaced; plugin failures atomic; equivalent state → equivalent projection; unknown ≠ false; explicit ≠ inferred/defaulted).\n* Gating tests: **reprojection/projector substitution**, **minimal pairs** (\"the budget is / might be €20,000\"), **black-box authoring test** (count concepts, boilerplate, escape hatches).\n* Named smells as review vocabulary: opaque payload waist, giant context bag, schema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden target leakage.\n\n### Deferred to fog (post-milestone)\n\nSimultaneous multi-plugin composition · plugin removal · full replay · capability negotiation · version/migration machinery (the spec names the five version axes — API contract / plugin impl / concept-schema / target-schema / persisted state — implements nothing).\n\n### Routed onward\n\n* §4 SDK-machinery list (evidence anchoring, issue construction, fixtures, **local simulation harness** — \"debugging should not require reading an entire agent transcript\") → issue 06 (Shipping shape).\n* Envelope + absence states + turn-suspension → issue 05 (Questioning-UX contract).\n\n## Comments\n\n**2026-08-07 (vocabulary clarification from issue 05's resolution).** The ownership table's \"Host (embedding + affordances)\" bundled two concerns that later split: the **ui** shell (interface: rendering, input, reply transport, identity) and the **substrate** (the embedding environment: deploy target, storage-port implementation, artifact delivery, model/provider). Under the hardened lexicon (`CONTEXT.md`), this table's \"Host\" row reads as substrate concerns plus ui concerns; \"kernel\" reads as **harness**. No substantive change to the decomposition.",
+          "url": "https://linear.app/hash/issue/FE-1370/contract-decomposition-kernel-host-plugin-pack-boundary-archive",
+          "createdAt": "2026-08-11T15:35:10.226Z",
+          "updatedAt": "2026-08-19T16:20:27.501Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "75228d43-47c4-4197-858c-433334016a59",
+          "identifier": "FE-1369",
+          "title": "Brunch exchange-schema audit [archive]",
+          "description": "Catalogued how the existing brunch app structures its question-and-answer exchanges, sorting every part into keep / adapt / leave behind for the new library. The generic asking machinery survives; brunch-specific vocabulary and review structures do not. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/03-brunch-exchange-schema-audit.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Brunch exchange-schema audit\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nCatalog brunch's structured-exchange vocabulary and classify each element as **generic to any elicitation** vs. **brunch-specific** (coupled to the spec-graph/product), so the questioning-UX and contract-decomposition tickets inherit a map of what to keep, generalize, or drop.\n\nSpecifically, in `../brunch` (read-only):\n\n* `src/exchanges/` — schemas (`ask`, `present_candidates`, `present_digest`, `present_review_set`, `request_choice`/`request_review`, capture/editor envelopes), projections, recovery\n* `src/agents/runtime/elicitor/` — prompt/context assembly, active-tool policy, the control-ownership table (spec posture / elicitation style / asking agenda)\n* `src/agents/skills/` — the activity-move routing table (analyze/elicit/ingest/propose/project/map/review) as candidate generic elicitation routines\n* Relevant `TOPOLOGY.md` files for boundary intent\n\nFor each element: what interaction problem it solves, where it hard-codes brunch's graph/spec shape, and any right-sizedness doubts visible in the code or docs (the abstractions \"were also just a guess\" — look for strain marks: legacy kept-for-reads projections, migration notes, loud failure modes).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Facts cited to file:line-range in `../brunch`; judgments marked **\\[J\\]**.\n\n# Brunch Structured-Exchange & Elicitor Audit\n\n## 1. Exchange catalog\n\n`ask` **(the only registered interactive terminal).** Solves: getting exactly one typed response from a human, in one of four shapes, without a separate collect tool per shape. Params (`src/exchanges/schemas/params.ts:~180-215`) carry markdown `body`, optional `options[]`, `multiple`, `allowOther`, `allowNone`, `commentPrompt`, `topLabel`/`bottomLabel`; no options ⇒ free text, options ⇒ single choice, options + `multiple` ⇒ multi-choice (`src/.pi/extensions/exchanges/TOPOLOGY.md`, \"Answer sources\"). Details (`src/exchanges/schemas/request.ts:~390-460`) echo the question *and* the answer in one result: `question` echo (body, options, `commentPrompt`, `otherPrompt`) plus exactly one of `answered | cancelled | unavailable` — a **property-presence union** rather than a status enum (`src/exchanges/schemas/TOPOLOGY.md:293-300`). Continuation: `ask({ continues: exchange_id })` reads the declared continuation off a prior present; model-authored payload fields on a continuing ask are rejected at the params boundary (`params.ts` `zAskParams.superRefine`, message `\"continuing ask payload is declared by the referenced offer\"`).\n\n`present_candidates`**.** Solves: fan-out comparison — let the user *recognize* a direction among alternatives instead of authoring one. Details (`src/exchanges/schemas/present.ts:185-235`): `display{heading, body?}` plus `candidates[]` of `{id, title, user_rubric, meta_rubric, graph_refs[]}`. `user_rubric` is six required nonblank markdown fields — `core_bet, best_fit, cost_complexity, covers_well, main_risks, lock_in_constraints` (+ optional `recommendation`); `meta_rubric` is four optional fields — `legibility_cost_of_knowing, failure_modes, coverage_range, commitment` (the D31-L four-axis meta-rubric, `memory/SPEC.md:262`). Continuation: `continuation: zOptionRequiredAskContinuationDeclaration` → `{tool: \"ask\", params: {body, options, ...}}`; the answer emits a `request_choice` detail discriminant with `tool_meta.prev = present_candidates`, and may lead to `capture_candidate`.\n\n`present_digest`**.** Solves: putting a large ingested source in front of the user as prose. Details (`present.ts:237-262`): `digest{abstract (required, nonblank), analysis?, recommendation?}`. Explicitly *not* a graph carrier — graph payload fields are rejected (`schemas/TOPOLOGY.md:289`). Continuation is the **free-text** variant (`zFreeTextAskContinuationDeclaration`, which `z.never()`s options/multiple/allowOther/allowNone/commentPrompt/labels — `shared.ts`), collecting conversational feedback only. Acceptance is deliberately *not* a review decision: a later standalone `ask({acceptsDigest, questions})` questionnaire or a `confirm|revise` single-select mints the accepted carrier, copying `accepted_abstract` from the runtime-resolved digest — caller-authored abstracts are rejected (`src/exchanges/TOPOLOGY.md:27`; `projections/ask.ts` `projectDigestQuestionnaire` / `projectDigestConfirmation`).\n\n`present_review_set`**.** Solves: batch approval of a structurally valid graph-mutation proposal. Details (`present.ts:60-180`): `review_set{nodes[], edges[]}` where each node is `{draft_id, proposed_code, settlement: advisory|settled, plane: intent|oracle|design|plan, kind, title, body?, detail?}` and each edge is a role-named discriminated union over nine categories (`dependency, witness, rationale, realization, refinement, exclusion, composition, cross_reference, supersession`) with `{draft_id}|{existing_code}` endpoint refs. Continuation is option-required. Approval is the commit: an approved continuation invokes shared settlement *before* `ask.execute` returns, so only a committed, `receipt`-bearing result is appended (`.pi/extensions/exchanges/TOPOLOGY.md`; `ask/continuation.ts:527` throws `'Review-set approval must route through shared settlement'`). `request_changes` requires a comment; `request_changes`/`reject` are terminal-only, no graph effect.\n\n**Legacy** `present_question`**.** A merged question/offer anchor (`response_kind: answer|choice|choices` + options inline). Unregistered; its Pi adapter is deleted; the projection survives only for old persisted reads (`schemas/TOPOLOGY.md:132-134`; `projections/present-question.ts`).\n\n`request_choice` **/** `request_review` **/** `request_answer` **/** `request_choices`**.** No longer registered tools — they are the *preserved wire vocabulary* for terminal details, so capture/sweep readers keep reading what they always read (`.pi/extensions/exchanges/TOPOLOGY.md:81-84`). `request_review` projection callers must pass a present-tool discriminator because review-set and digest close through the same detail kind but capture reads them differently (`projections/request-response/review.ts` `ReviewPresentTool`).\n\n**Capture envelopes.** `capture_answer|choice|choices|review|candidate` (`schemas/capture.ts`), each a `zCaptureDetailsHeader` + `tool_meta{prev, curr}`. Graph payloads intentionally undesigned in this pass (`schemas/TOPOLOGY.md:386-390`); `capture_candidate` consumes only the selected id.\n\n**Editor envelope.** `editor.ts` is a *wire* envelope, not transcript detail: a JSON blob prefilled into `ctx.ui.editor` for the one payload Pi built-ins can't carry over RPC (multi-choice). Its `status: 'answered'|'cancelled'` string never enters details, which carry outcome as key presence (`schemas/TOPOLOGY.md:36-38`).\n\n**Questionnaires.** `schemas/questionnaire.ts`: `{id, kind: free-text|single-select|multi-select, prompt, options[]}` questions and kind-matched answers, replayed on persisted completion so IDs/kinds/option-membership/completeness can't diverge.\n\n## 2. Classification\n\n| Element | Class | Change needed / coupling |\n| -- | -- | -- |\n| `ask` single-tool-four-shapes | **Generic** | The strongest abstraction here. **\\[J\\]** One terminal covering free-text/single/multi + a declared-continuation mode is the right primitive. |\n| Property-presence terminal union (`answered`/`cancelled`/`unavailable`) | **Generic** | Distinguishes \"user declined\" from \"no UI available\" — both are non-answers, and conflating them is the classic bug. |\n| `comment` (user-authored) vs `message` (system-authored) split | **Generic** | `schemas/TOPOLOGY.md:108-112`. Cheap, high-value provenance discipline. |\n| Question-echo-in-result (self-contained terminal) | **Generic** | Makes the transcript replayable without joining back to the present. |\n| Declared continuation (`present` names its own terminal; collector rejects model re-authoring) | **Generic** | **\\[J\\]** The single most transferable idea: the offer owns the answer vocabulary, so the model cannot drift the options between showing and collecting. |\n| `exchange_id` + `tool_meta{prev,curr,next}` chain | **Generalize-with-changes** | Currently a hand-maintained discriminated union of ~15 literal prev/curr/next triples (`shared.ts`). Replace with a generic `{exchangeId, parentId?}` link + one `form` tag; the pairwise enumeration is combinatorial and buys little. |\n| Recovery scan / pending-present resumption | **Generic** | `recovery.ts:78-81`: only an *answered* terminal closes an exchange; cancelled/unavailable stay resumable. Any interviewer needs this. |\n| Present-then-ask two-step (offer ≠ collection) | **Generalize-with-changes** | Generic as \"render surface separate from input surface\", but brunch pins the offer set at three named tools. A kernel wants one `present(form, payload)` with pluggable payload validators. |\n| `present_candidates` as an *interaction* | **Generic** | Fan-out/compare/recognize is plane-invariant (A31-L, `memory/SPEC.md:111`). |\n| Candidate `user_rubric` (six required fields) | **Brunch-specific** | Hard-codes brunch's product judgment about what makes specs comparable (`core_bet`, `lock_in_constraints`). A kernel should take a caller-declared rubric schema. |\n| Candidate `meta_rubric` (D31-L four axes) | **Generalize-with-changes** | SPEC calls it \"a soft heuristic… not architecturally enforced\" (`memory/SPEC.md:262`) yet it is a required schema key. Demote to optional caller-supplied axes. |\n| `graph_refs[]` on candidates | **Brunch-specific** | Node-id coupling to the spec graph. |\n| `present_digest` as an interaction | **Generic** | \"Here is my reading of your source; react to it\" is universal to ingestion-shaped interviewing. |\n| Digest accept-via-later-carrier (feedback ≠ acceptance) | **Generalize-with-changes** | **\\[J\\]** The *separation* is a real lesson; the specific `acceptsDigest`/`accepted_abstract` field names and the \"runtime resolves the final eligible digest\" recognizer (`recovery.ts:18`) are brunch plumbing. |\n| `present_review_set` as an interaction | **Generalize-with-changes** | \"Approve/request-changes/reject a proposed batch of writes, atomically\" is generic. Brunch's version hardwires the target. |\n| Review-set node/edge draft schema | **Brunch-specific** | `plane: intent\\|oracle\\|design\\|plan`, nine graph edge categories, `settlement: advisory\\|settled` (D27-L), `proposed_code`. Params import `zReviewSetProposalPayloadForBoundary` from `graph/review-set.ts` — the only inbound coupling `exchanges/` allows (`exchanges/TOPOLOGY.md`, dependency direction). |\n| \"Boundary-teaching\" schema (advertise nested shape so the model sees it before the deep validator runs) | **Generic** | `schemas/TOPOLOGY.md:47-52`. **\\[J\\]** A genuinely good pattern: shallow schema for model legibility, deep validator for correctness. |\n| Approval-commits-atomically + receipt | **Generalize-with-changes** | Generic as \"the approve branch runs the target's commit and the terminal carries the target's receipt\"; `MutateGraphSuccess` (`request.ts:1`) is the coupling. Kernel needs an opaque target-supplied receipt type. |\n| Capture layer | **Brunch-specific** | Exists as envelope only, graph payloads undesigned; `capture_candidate` semantics are graph-shaped. |\n| Editor envelope (`editor.ts`) | **Generalize-with-changes** | Real problem (host UI can't carry a payload over RPC), brunch-shaped solution. Kernel: name it a \"degraded-transport fallback\", don't bind it to multi-choice. |\n| Option-id regex `^[^>\\r\\n]+$` | **Generalize-with-changes** | The comment says ids round-trip through an HTML-comment marker recovered by a regex stopping at `>` (`params.ts`). **\\[J\\]** A rendering leak in a validation schema — a kernel should encode ids opaquely instead. |\n| `active-tools.ts` allowlist | **Generalize-with-changes** | Generic pattern (fixed tool policy per role), brunch-specific contents (`read_graph`, `mutate_graph`, `read_elicitation_scratchpad`). |\n| Elicitation scratchpad (private, non-authoritative obligations) | **Generic** | D101-L: session-local, last-snapshot-wins, \"durable truth stays in the graph; low-confidence noticings land here.\" Every interviewer needs a place for \"noticed, not yet asked.\" |\n| `elicitation_style: interrogate\\|disambiguate\\|propose` | **Generic** | `session/elicitation-style.ts`. Style ≠ authority ≠ capability. |\n| `warrant-before-commit` directive (hash-pinned, ablatable) | **Generic** | `compose-live-prompt.ts` validates exactly one directive block, hashes it, exposes it as `providerVisibleText`, and supports dev-only ablation. **\\[J\\]** Treating one prompt paragraph as a versioned, A/B-testable artifact is a pattern worth stealing outright. |\n| Skill moves `analyze / elicit / ingest / propose / project / review` | **Generic** | These six are the actual elicitation routine vocabulary. |\n| Skill move `map` | **Brunch-specific** | Graph vocabulary/routing/persistence. |\n| Skill move `tutorial` | **Brunch-specific** | Product walkthrough of Brunch itself. |\n| `elicit` topology-driven question ranking table | **Generalize-with-changes** | The *shape* — structural signal in the target ⇒ question shape — is generic; every row names graph kinds (`assumption`, `witness` path, `criterion`, `exclusion`). Kernel: targets supply their own signal→question-shape table. |\n| Readiness bands as \"concentric concern envelopes, not workflow stages\" | **Generalize-with-changes** | **\\[J\\]** Excellent dialogue policy (\"absence matters *later*, capture is never illegal earlier\"); the band vocabulary is brunch's. |\n| Prompt-injected skill manifest (`<brunch-skills>` with absolute paths, \"do not infer additional skills\") | **Generic** | `skills/registry.ts` `renderBrunchSkills`. |\n| `intent -> design -> verification -> scope -> build` handoff sequence, frontier/scope edge directions, `PROJECT_EXECUTION_HARNESS_TITLE` verify-recipe block | **Brunch-specific** | `prompts/elicitor.md`; `compose-live-prompt.ts` `renderProjectExecutionHarnessGuidance`. |\n\n## 3. Strain marks\n\n**Legacy-kept-for-reads.** `present-question.ts` and `request-response.ts` survive as projections with no registered tool (`exchanges/TOPOLOGY.md:22`; `.pi/.../TOPOLOGY.md:81-84`). `shared.ts` literally names the residue: `STRUCTURED_EXCHANGE_TERMINAL_NAMES = { current: 'ask', legacyRequestPrefix: 'request_' }`. The tool topology collapsed from `present_question → request_response` to `ask`, but the *detail* vocabulary could not follow because capture/sweep readers were written against it.\n\n**Same detail kind, two meanings.** `request_review` closes both review-set and digest, so `projectRequestReview` demands a `ReviewPresentTool` discriminator from callers (`projections/request-response/review.ts`). Receipts are required for review-set approval and *strictly rejected* on every digest branch (`schemas/TOPOLOGY.md:~325`). **\\[J\\]** Two different transactions wearing one name — a merge that shouldn't have happened.\n\n**A retracted merge.** Digest acceptance *was* a review decision and was pulled back out: \"digest acceptance is no longer a review decision\" (`exchanges/TOPOLOGY.md:27`), with `recovery.ts:31-36` retaining a `legacyReview` parse path for digests approved under the old model.\n\n**Doc/code drift on edge categories.** `schemas/TOPOLOGY.md:194` documents `dependency | proof | support | realization | boundary | composition | association | supersession`; the Zod in `present.ts:89-160` implements `dependency | witness | rationale | realization | refinement | exclusion | composition | cross_reference | supersession`. Four categories were renamed and the schema doc was not updated.\n\n**Retired axes.** D98-L retired strategy/lens/method as runtime or manifest state; A35-L records the retreat: the axis model \"may still be useful as prompt-resource organization, but it is no longer trusted as user-changeable or transcript-backed runtime state\" (`memory/SPEC.md:115`). The migration note in `skills/TOPOLOGY.md` maps seven old constructs onto activity homes and ends with a hard rule: *\"if a skill is live, it appears in the first-level registry; if guidance is not there, it is not switchable product state.\"* Retired axes also left dead vocabulary behind — `lens` is still advertised in the review-set boundary schema (`schemas/TOPOLOGY.md:50`) and the elicitor prompt still says \"plan-lens review set\".\n\n**Loud failure modes.** Only two `throw`s in the whole exchange surface, both about authority: `'Review-set approval must route through shared settlement'` (`ask/continuation.ts:527`) and `'parsed ask parameters do not describe a runtime variant'` (`ask.ts:748`). Everything user-facing degrades to an `unavailable` terminal with a message instead (`continuation.ts:222` — a missing continuation declaration is an error string, not a crash). Params failures return bounded `TOOL_INPUT_INVALID` tool results with no human-visible transcript line.\n\n**Where validation lives (revised once).** D105-L: validate at trust boundaries — LLM params, RPC input, editor replies, transcript read-back — *not* inside constructors, which \"do not parse objects [they] just built.\" D108-L consolidated the whole contract out of two prior homes (`src/.pi/extensions/exchanges/schemas/` and `src/projections/exchanges/`) into `src/exchanges/`.\n\n**Lessons \\[J\\].** (a) Wire vocabulary outlives tool names — version the *detail* schema independently of the tool registry from day one, or every tool rename leaves a fossil. (b) Do not merge two interaction forms because their outcomes look alike; brunch merged digest into review and had to un-merge it while keeping a legacy read path. (c) An enumerated `prev/curr/next` chain across N forms is O(N²) maintenance for a link that could be one parent pointer. (d) The `settlement: advisory|settled` retrofit (D27-L, FE-1187) shows that *strength of assertion* is a first-class field, not a later annotation.\n\n## 4. Elicitor control model\n\nThree controls, three owners, three lifetimes (`runtime/elicitor/TOPOLOGY.md`, \"Control ownership\"):\n\n* **Spec posture** (`kind`/`origin`/`relatesToSpecId`) — owned by the persisted product row, spec lifetime. Session establishment decides *whether to ask*, not what the fact is; the live context renderer \"cannot establish or overwrite it.\" Enforced in code: `context.ts:14-19` comments that `workspace.posture` is a *workspace* stub, \"not D118-L spec posture.\"\n* **Elicitation style** (`interrogate|disambiguate|propose`) — last valid `brunch.elicitation_style` entry on the active branch, session lifetime across kicks. The prompt adapter \"projects it into the live elicitor control block without changing capability or authority.\"\n* **Asking agenda** — *has no state field at all*. Turn lifetime, \"reconsidered from current conversation and on-demand reads.\" Origination supplies neutral graph facts once; the prompt directs `establish orientation` then `focus a vein`.\n\nThe closing rule is the sharp part: **\"Formatting is not authority: shared text helpers may render facts, but spec posture cannot satisfy style, style cannot persist or gate an agenda, and the prompt cannot establish product posture.\"**\n\nThe conduct itself lives in `prompts/elicitor.md`: a new session \"starts from graph facts and an empty or inherited elicitation scratchpad, **never a scored or ranked agenda**\"; establish orientation, then \"pick one concrete thread worth pursuing this session and let the scratchpad track obligations you notice along the way, rather than trying to cover every absence at once.\" Scratchpad obligations are private working state — \"do not disclose even a summary… unless the user explicitly asks.\"\n\n**Judgment \\[J\\].** *Generic dialogue policy:* the three-way separation of persisted-fact / session-style / turn-agenda; the refusal to persist an agenda (D101-L retired the persisted spec-scoped register in favour of a session scratchpad — `memory/SPEC.md:180`); \"one vein, not full coverage\"; private-by-default working state; the three style values; \"formatting is not authority.\" *Product policy:* that spec posture is the persisted axis at all; the specific graph facts constituting orientation; the `intent→design→verification→scope→build` sequence and execution-harness verify-recipe block; the `mutate_graph`/`read_graph` tool allowlist. **\\[J\\]** The most under-appreciated design move is the *negative* one — an agenda deliberately has no storage, so it cannot go stale, cannot be gamed, and cannot become a scoring engine the prompt defers to instead of reading the conversation.\n\n## 5. Design lessons for a greenfield questioning-UX contract\n\n**Inherit**\n\n 1. **Declared continuations.** The offer names its own terminal in its result; the collector fills body/options from that declaration and rejects model-authored payload on a continuing call. This is the mechanism that makes offer→answer non-forgeable.\n 2. **Property-presence outcome union with three arms** — answered / cancelled / unavailable — plus the recovery rule that *only answered closes an exchange* (`recovery.ts:78-81`). Cancel must leave the offer resumable, and the user-facing hint must stay honest after a cancel.\n 3. **One terminal tool, several shapes.** Not one collect-tool per question type. Params-level cross-field refinement decides the shape; the runtime asserts the parsed params \"describe a runtime variant\" and throws if not.\n 4. **Self-contained terminals.** Echo the question, the options, and the sub-prompts into the answer detail so a transcript reader never needs the present.\n 5. `comment` **vs** `message` — never let user text and system text share a field.\n 6. **Boundary-teaching schemas.** Advertise the nested shape shallowly for model legibility; keep the deep requiredness contract in one validator the target owns.\n 7. **Agenda as derived state, not stored state**, with a private, non-authoritative scratchpad for \"noticed but not asked.\"\n 8. **Version and hash load-bearing prompt paragraphs.** `LIVE_ELICITOR_DIRECTIVES` pins one directive by sha256, validates its stable opening sentence, and supports dev-only ablation — prompt text as a testable artifact.\n 9. **Separate \"react to this\" from \"accept this.\"** Digest feedback and digest acceptance are different exchanges for a reason brunch learned by reverting the merge.\n10. **Approval-commits, with the target's receipt in the terminal.** Never leave \"approved\" and \"committed\" as two states the model can straddle — the settlement runs before the terminal is appended.\n\n**Avoid**\n\n11. **Enumerated** `prev/curr/next` **tool-meta unions.** Use one parent link and one form tag.\n12. **Product judgment baked into required schema fields** — the six-field `user_rubric` and the four-axis `meta_rubric` (documented as \"a soft heuristic… not architecturally enforced\" yet schema-required). Rubrics belong to the target, declared per call.\n13. **Rendering constraints leaking into validation** — the option-id regex exists because ids round-trip through an HTML comment. Encode ids opaquely.\n14. **One detail kind for two transactions.** `request_review` forces every caller to hand-carry a discriminator and forks receipt rules downstream.\n15. **Tool names as the versioning unit.** Brunch's wire vocabulary froze independently of its tool registry; plan for that from the start rather than maintaining `legacyRequestPrefix` and a parallel unregistered projection tree.\n\n**Key paths:** `../brunch/src/exchanges/{TOPOLOGY.md,recovery.ts,editor-envelope.ts,text.ts}`, `../brunch/src/exchanges/schemas/{TOPOLOGY.md,shared.ts,present.ts,request.ts,params.ts,questionnaire.ts,capture.ts,editor.ts}`, `../brunch/src/exchanges/projections/`, `../brunch/src/.pi/extensions/exchanges/{TOPOLOGY.md,ask.ts,ask/continuation.ts,index.ts}`, `../brunch/src/agents/runtime/elicitor/{TOPOLOGY.md,active-tools.ts,compose-live-prompt.ts,context.ts}`, `../brunch/src/agents/prompts/elicitor.md`, `../brunch/src/agents/skills/{TOPOLOGY.md,registry.ts,elicit/SKILL.md,propose/SKILL.md}`, `../brunch/src/session/elicitation-style.ts`, `../brunch/memory/SPEC.md`.",
+          "url": "https://linear.app/hash/issue/FE-1369/brunch-exchange-schema-audit-archive",
+          "createdAt": "2026-08-11T15:35:09.107Z",
+          "updatedAt": "2026-08-19T16:20:27.340Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "d3e3d8b2-170a-4fa9-8ea8-26d396caa0b6",
+          "identifier": "FE-1368",
+          "title": "zil-lean survey [archive]",
+          "description": "Examined zil-lean, a prototype claim-graph system, as a candidate second practice subject for the interviewing architecture. Conclusion: it contains no interviewing itself, but it is a working proof of the claim-graph idea; a smaller \"assurance argument\" slice was chosen as the second subject instead of the full system. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/02-zil-lean-survey.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# zil-lean survey\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n> **Rename note (2026-08-10, spec assembly):** occurrences of `elicit-proof-obligations` below are the historical name; the second target is the **assurance argument**, package `plugin-assurance` (per the [Formal-verification canon survey](<09-formal-verification-canon-survey.md>)'s category-error verdict). This ticket's ElicitationPack sketch is superseded by ticket 09's `Statement` contract (pre-pass S10); the surviving contributions are the existence proof, the assurance lattice with prohibited promotions, derivation provenance, and the derived-status idea.\n\n## Question\n\nWhat elicitation-for-formal-verification insights does [https://github.com/jagg-ix/zil-lean](<https://github.com/jagg-ix/zil-lean>) hold, and is a lean/formal-flavored elicitation target *dev-sized* — small enough to develop the kernel against without wading into a massively complex target?\n\nSpecifically:\n\n* What is the repo: purpose, structure, how it relates natural-language intent to Lean formalization\n* What would an **ElicitationPack** for a lean-flavored target need: concept contract (what counts as a proposition/invariant/assumption), observation lenses, completion criteria\n* What would its **ProjectionPack** need: output contract/shape, validators (does Lean itself act as the deterministic validator?), lossiness\n* Verdict: dev-sized or too heavy? If too heavy, what is the smallest formal-flavored slice that still exercises both pack axes differently from elicit-gherkin? (Fallback second target is BPMN/process-mining.)\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06. Local clone for follow-up: scratchpad `zil-lean/` (session-temporary).\n\n# zil-lean survey\n\n## 1. What it is\n\n**Documented facts.**\n\n* `jagg-ix/zil-lean` — \"ZIL: a relational knowledge language implemented in Lean 4 with a Clojure runtime and toolchain.\" Primary language Clojure; no license file; 31 stars, 1 fork, 0 subscribers, 1 open issue, no topics.\n* **Provenance/activity**: repo created 2026-07-27T06:10, last push 2026-07-29T02:26. Entire history is **27 commits over \\~2 days**. First commit is \"Initial public snapshot\" by `github-actions[bot]`; all six PRs are branches named `agent/modularize-*`, `agent/complete-engine-governance-modules`. There is also a `PUBLIC-CONTENT-POLICY.md` and commits titled \"Isolate validated source publication.\" **Inference (high confidence)**: this is an agent-authored code dump published from a private working repo — ~140k tracked lines landed in one snapshot, then mechanically split into modules. Not an organically evolved project, and not battle-tested.\n* **Size/structure**: 532 files. `Zil/` (106 files, 14.2k lines Lean 4 — the native library), `src/zil/` (75 files, 17.5k lines Clojure — runtime/CLI/bridges), `spec/` (44 markdown specs, 5.3k lines), `examples/` (133 files, 85k lines — dominated by generated data), `lib/` + `libsets/` (`.zc` macro libraries), `test/` (57 files, 6.1k). Lean pinned to `leanprover/lean4:v4.31.0`.\n* **What \"ZIL\" is**: a **relation-tuple + Horn-rule (Datalog) knowledge language**, explicitly modeled on Google's Zanzibar `object#relation@user` tuple syntax, extended from authorization into general project knowledge: `declaration ─implements→ requirement`, `theorem ─validates→ component`, `claim ─supportedBy→ document`. Four primitives: nodes, relations, rules, queries. Two surface syntaxes (`.zc` tuple text; native Lean macros `zil_fact` / `zil_theorem_rule`) plus a canonical IR, snapshot format `ZILX/1`, delta format `ZILD/1`, revision log `ZILR/1`, and exporters to Soufflé and Prolog.\n* **Relation to Lean**: Lean is (a) the implementation host of the engine and (b) a **certification backend for a narrow slice**. `Zil.Trust` has three levels — `asserted` (registered fact), `graphDerived` (rule-inferred), `certified` (a rule paired with a Lean proposition + proof term, kernel-checked). Everything else about proofs is *bookkeeping*: `spec/proof-obligation-governance-v1.md` governs declared obligations across `z3 | tlaps | lean4 | acl2 | manual` and validates *presence of evidence references*, not their content (\"Lean kernel validation remain[s] the responsibility of [its] producing system\").\n\n**It is not**: a benchmark, a proof-automation system, an autoformalization pipeline, or anything with an LLM in it. `grep -ril 'openai|anthropic|llm|prompt|natural.language|gpt-'` across the repo hits **two files, both false positives** (a Terraform API schema, a config macro lib). \"assistant\" appears only as node names in examples (`assistant.formalization`, `assistant.codegen`) — agents are *modeled as nodes in the graph*, never as interviewers. **There is no elicitation, no question-asking, and no natural-language front-end anywhere in this repo.**\n\n## 2. Elicitation-relevant insights\n\nThe bookmark intuition is wrong about the surface but partly right about the substrate. zil-lean contains **no informal→formal capture**, but it is an unusually well-worked-out example of **the layer the kernel calls the claim graph** — and it is worth reading precisely for that.\n\nTransferable, documented:\n\n* **Evidence-graded claim graph as a first-class artifact.** `spec/assurance-levels-v1.md` defines five orthogonal labels — `exploratory`, `validated`, `kernel-backed`, `externally-attested`, `byte-attested` — with an explicit **prohibited-promotion lattice** (`validated ↛ kernel-backed`, `externally-attested ↛ kernel-backed`, `byte-attested ↛ validated`). Crucially: \"Assurance labels state what checked a result… must not be inferred from a successful exit code alone.\" Directly reusable as the kernel's IR annotation on captured claims, and the sharpest thing in the repo.\n* **Full derivation provenance.** `spec/derivation-provenance-v1.md`: every fact node carries `id / fact / origin / stratum`, where origin is `base` or `rule(ruleName, premiseFactIds, negativeChecks, binding)`. Query answers emit witnesses with premise fact IDs and bindings. Reports are deterministic and **timestamp-free** so they hash stably. This is the evidence-preserving IR the kernel wants, worked out concretely — including the honest caveat: \"The trace is graph-derived evidence. It is not a Lean kernel proof term.\"\n* **A concept vocabulary for formal-flavored capture that already distinguishes the kernel's hard cases.** `examples/formalization-arc-demo.zc` + `lib/theorem-dsl-macros.zc` separate **assumption** (with class + `ASSUME_HOLDS(source)` / `ASSUME_BROKEN(source, reason)`), **lemma**, **theorem**, **guarantee** (`THEOREM_ENSURES`), **evidence** (engine + token), **component**, **signal**, and **incident** (which can *break* an assumption and propagate). Derived statuses: `PROVED` (deps satisfied + witness), `CONDITIONAL` (witness but assumption under review), `WEAK` (no witness), `BROKEN` (required assumption broken). That is a completion-criteria ladder, expressed as Datalog, that the kernel could adopt nearly verbatim.\n* **Two forms of \"enough.\"** `spec/formalization-plan-v1.md` schedules `FORMALIZATION_TARGET` declarations (`module, file, declaration, status, priority, dependencies?`) over a validated acyclic dependency graph, defining *readiness* as `status ∈ {ready, in_progress} ∧ ∀dep. dep.status ∈ {verified, reviewed, proved}`, with structured blocking reasons (`status:<s>`, `missing:<t>`, `dependency:<t>:<s>`). `spec/agent-context-v1.md` defines a **context bundle** for handing a task to an agent — changed nodes → reverse impact → relevant facts → originating rules → auto-selected queries and targets — with explicit incompleteness issues (`unknown-changed-node`, `missing-query`, `missing-formalization-target`) and `context_bundle_id = sha256(report bytes)`.\n* **Drift detection on formal statements.** `spec/theorem-statement-locks-v1.md` locks `(token_id, declaration, module, kind, type_fingerprint)` and reports ordered check states (`fingerprint_changed`, `declaration_changed`, `missing_token`, `current_unresolved`, `unexpected_token`…). Answers \"did the formalization silently stop meaning what the user said?\" — a re-elicitation trigger.\n* **A request-elicitation schema that already exists.** `spec/request-form-core-v0.1.md` (draft) formalizes \"a requester asks for `<something>`\" as `Data | Action | Compound | Recursive`, with `mode ∈ {dry_run, apply}`, explicit `Effect` entities, and `Criterion` acceptance predicates, lowered to canonical tuples with derived judgments (`has_side_effect`, `is_recursive`, `execution_contract plan_only`). **Inference**: this is the closest thing in the repo to an elicitation target schema, and it is *not* Lean-flavored at all — it is intent-flavored. It may be more useful to the kernel than the theorem DSL.\n\nWhat zil-lean does **not** show, and the kernel must supply: how anyone *arrives* at these declarations. Every `.zc` file is hand-authored. There is no question generation, no ambiguity detection, no candidate extraction from prose, no clarification loop. The Lean checker is used as an oracle over *already-formal* artifacts, never as a feedback signal into a conversation.\n\n## 3. ElicitationPack sketch (elicit-lean/formal)\n\nGrounded in the vocabulary zil-lean shows is actually load-bearing.\n\n**Concept contract** — five kinds, distinguished by their *evidential obligations*, not their grammar:\n\n| Kind | Test | Obligation on capture |\n| -- | -- | -- |\n| `assumption` | Taken as given; not to be discharged here | must name a holder/source and a review status |\n| `invariant` | Must hold at all times over a named state/scope | must name scope + the state it constrains |\n| `proposition/theorem` | A claim asserted to follow from others | must name required assumptions + lemmas |\n| `guarantee` (ensures) | An outcome promised to a consumer | must attach to a producing component |\n| `constraint` | A restriction on inputs/config, not a claim about behavior | must name what it restricts |\n\nNon-negotiable per-item fields (from `THM_*` + proof-obligation governance): `id`, `criticality`, `depends_on: [assumption|lemma]`, `evidence?: (engine, token)`, `status`, and — added by the kernel, absent in zil-lean — `source_span` (the utterance it came from) and `paraphrase_confirmed: bool`.\n\n**Observation lenses** (what to notice in conversation):\n\n1. **Modal/quantifier lens** — \"always\", \"never\", \"must\", \"for every\", \"at most one\" → invariant candidate.\n2. **Hedge lens** — \"assuming\", \"as long as\", \"we can take for granted\", \"in practice X is well-formed\" → assumption candidate, and a *required* follow-up on who guarantees it. `a_input_well_formed` in the demo is exactly this shape.\n3. **Consequence lens** — \"so then\", \"which means\", \"that guarantees\" → proposition with an implicit dependency edge to name.\n4. **Break lens** — \"except when\", \"unless\", \"this fell over once when…\" → either a missing precondition on an existing item, or an incident that breaks an assumption (`INCIDENT_BREAK_ASSUMPTION`).\n5. **Undefined-term lens** — a noun used in a claim that has no node yet → must be introduced before the claim can be normalized.\n\n**Completion criteria** (ladder taken from the demo's status computation, plus dependency-closure from the plan spec):\n\n* *Structurally complete*: every claim's `depends_on` targets exist; dependency graph acyclic; every term referenced has a node. (Directly = the plan spec's set-validation rules.)\n* *Epistemically complete*: no claim is `WEAK` without the user having explicitly deferred it; every `CONDITIONAL` names the assumption under review and its owner; every `critical` item has either evidence or an explicit, reasoned waiver (governance spec forbids waiving critical items).\n* *Faithfulness*: every captured item has a user-confirmed paraphrase. This is the one criterion zil-lean cannot inform — there is no user in it.\n\n## 4. ProjectionPack sketch\n\n**Output contract**: the claim graph projects to a `.zc`-shaped tuple set plus derived-status queries — the `formalization-arc-demo.zc` shape is a working, concrete target. Textual, diffable, deterministic, machine-checkable *without Lean*.\n\n**Deterministic validators, in ascending cost** — and this is the important structural finding: **zil-lean demonstrates that Lean is the wrong first validator.** Three cheaper tiers exist and catch most errors:\n\n1. **Schema/graph validation** (free): unique IDs, nonnegative priorities, existing dependency targets, acyclicity, stratification safety, relation declared in some base fact or rule head (`unknown-relation` verdict).\n2. **Datalog closure** (cheap, deterministic, bounded — default fuel 64/stratum): derives `PROVED / CONDITIONAL / WEAK / BROKEN`, impact sets, break roots. The real workhorse oracle, and it runs on the *informal* graph.\n3. **Obligation governance** (cheap): checks that declared statuses are supported by evidence references — `proved-status-requires-evidence`, `obligation-not-discharged`, `waiver-reason-missing`, `critical-obligation-cannot-be-waived`.\n4. **Lean elaboration** (expensive, narrow): only for items actually written as Lean declarations. `spec/lean-verification-report-v1.md` runs `lake env lean <file>` per module + SHA-256 manifest match; `Zil.Trust.CertifiedRule` kernel-checks a proposition/proof pair.\n\nSo: **Lean serves as the deterministic validator only for the** `kernel-backed` **tier, and zil-lean's own architecture says you must not let success at tiers 1–3 masquerade as tier 4.** The prohibited-promotion table is the lossiness policy, pre-written.\n\n**What's lossy**: the natural-language statement itself (`statement` is a free-text field in the obligation schema, unvalidated); the *reason* an assumption is believed (only `source` is kept); alternative derivations (v1 provenance retains only the first witness); and — the deep one — the gap between \"Lean accepted this declaration\" and \"this declaration means what the user said.\" `theorem-statement-locks` spells it out: \"The lock does not claim that unchanged type fingerprints imply unchanged proof terms, source text, or external scientific meaning.\" The kernel must keep the utterance→claim→declaration chain because nothing downstream can reconstruct it.\n\n## 5. VERDICT — dev-sized?\n\n**A full elicit-lean/formal target is not dev-sized. A slice of it is, and it's a good one — but it is not the slice with Lean in it.**\n\nReasoning:\n\n* **The heavy part is real.** Getting from a user's claim to a Lean *statement* (not proof) requires committing to a type-theoretic encoding of the domain — the step autoformalization research finds hardest. That is deep-Lean-expertise work, and the contract is not definable without it. zil-lean quietly concedes this: it never writes theorem statements from intent. It stores `proof:Normalize.idempotent` as an opaque **token naming a declaration a human already wrote**. The demo file says so outright: \"Proof status here is bookkeeping only. The proof assistant remains the sole proof authority; proof tokens name checked declarations but do not assert them.\"\n* **The light part is genuinely there, and zil-lean is a working existence proof of it.** Eliciting an **assumption/lemma/theorem dependency graph with criticality and evidence pointers** — no Lean statements, no proofs — is weeks-scale. Every validator you need is graph-level and already specified in this repo.\n\n**Smallest formal-flavored slice: \"elicit-proof-obligations\" / the verification arc.** Interview a user about a system they believe is correct; capture assumptions (with owners and review status), lemmas, theorems, guarantees, and the dependency edges among them; attach evidence references where they exist; project to a `.zc`-style graph; validate by acyclicity + stratified Datalog closure yielding `PROVED/CONDITIONAL/WEAK/BROKEN` + break-root and impact queries.\n\n**Does it differ from elicit-gherkin on both pack axes? Yes, cleanly:**\n\n* *ElicitationPack*: Gherkin's concept contract is **scenario-shaped and example-driven** (Given/When/Then, concrete instances, no cross-item structure); completion is per-scenario coverage. This target's contract is **claim-shaped and dependency-structured** — the unit is a proposition with edges to other propositions, the hedge lens is central (Gherkin has no notion of an assumption), and completion is *graph closure plus evidence adequacy*, not enumeration. Different lenses, genuinely different \"enough.\"\n* *ProjectionPack*: Gherkin projects to a flat, independently-executable list; validation is parse + step-binding. This projects to a **DAG with derived statuses**, validated by fixpoint computation and an evidence-promotion lattice. The lossiness policy is substantive (assurance levels, first-witness-only) rather than near-absent.\n\n**Fallback comparison.** Take this slice **over** elicit-BPMN/process-mining as second target. Both differ from Gherkin, but the proof-obligation slice stresses the kernel harder on the axes the design cares about: it forces the claim-graph IR to carry *evidence grades and derivation provenance* (BPMN mostly forces sequencing and gateway structure, which Gherkin partly covers), and it gives you a deterministic non-trivial validator — a Datalog fixpoint — without any external tooling or domain SME. Keep BPMN as third; it's the better *breadth* target once the IR is stable, and it has an easier user-recruitment story. **Inference**, based on pack-axis distance, not on any BPMN sources reviewed here.\n\nOne caveat worth carrying: nothing in this repo has been validated by use. Treat the specs as well-reasoned design documents by an agent-assisted author, not as field-tested contracts — the `assurance-levels` lattice and the `THM_*` status ladder are worth stealing on their merits, not on their track record.\n\n## 6. Unreached sources\n\n* Did not build or run anything (`lake build`, `lake exe zilLeanTests`, `clojure -M:test`) — no Lean toolchain here; **all correctness claims are from specs and source, not execution.**\n* Did not read: the 129 Lean files in `Zil/` beyond filenames; `spec/zil-formal-core-v0.1.md` (427 lines, the core semantics); `spec/canonical-relational-ir-v0.1.md`; `spec/evidence-envelope-v1.md`; `spec/query-governance-v1.md`; `spec/recovery-audit-v1.md`; `spec/dmetavm-core-v0.1.md`; `formal/` (TLA+/SMT); the 17 `libsets/` domain packs; the 133 example files beyond three.\n* Repo wiki is enabled (`has_wiki: true`) — not checked. 1 open issue — not read. No discussions, no releases checked.\n* Author `jagg-ix` (Jorge A. Garcia) — no external profile or publication search performed, so no independent read on provenance beyond commit metadata.",
+          "url": "https://linear.app/hash/issue/FE-1368/zil-lean-survey-archive",
+          "createdAt": "2026-08-11T15:35:07.948Z",
+          "updatedAt": "2026-08-19T16:20:27.450Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "4f506cd8-070b-41ad-b208-0b625f987418",
+          "identifier": "FE-1367",
+          "title": "Flue architecture deep-read [archive]",
+          "description": "Read Flue — the web/agent framework the interviewing library runs on — closely enough to know how the library should ship on it. Conclusion: embed as a library inside a host-authored app, which is Flue's natural grain; Flue has no built-in \"pause and ask the user\" facility, so the library owns its own turn-taking mechanism. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).\n\n---\n\n> **Archive migration (2026-08-11).** Resolved ticket from the local-markdown wayfinder effort `elicitation-kernel` (`brunch-lite:.scratch/elicitation-kernel/issues/01-flue-architecture-deep-read.md`), mirrored to Linear for team visibility. Full original content below, including the resolution.\n\n---\n\n# Flue architecture deep-read\n\nType: research\nStatus: resolved\nResolved: 2026-08-06\n\n## Question\n\nWhat does Flue's architecture offer — and constrain — for embedding an elicitation kernel, such that the shipping-shape and contract-decomposition tickets can decide on facts rather than the marketing page?\n\nSpecifically:\n\n* The agent programming model (React-like hooks API): what is \"an agent\" as a unit of code, state, and deployment?\n* How skills, tools, subagents, persistent state, sandboxes, and channels are defined and composed\n* How Pi is exposed through Flue — can an embedded library reach Pi primitives directly, or only through Flue's abstractions?\n* Local vs. remote parity: what changes between a Node local run and a Cloudflare/CI deploy? What state survives where?\n* Is a \"kernel library embedded in a thin Flue agent\" a natural pattern, or does Flue push toward the agent *being* the program?\n* Channels (Slack/Teams/Discord/GitHub) as host input pathways — what does a host surface look like in Flue terms?\n\nSources: [https://flueframework.com/docs/guide/](<https://flueframework.com/docs/guide/>) (pages are fetchable as markdown at `/docs/guide/<topic>/index.md`).\n\n## Answer\n\n> Resolved by `/research` subagent, 2026-08-06.\n\n# Flue Architecture — Findings for an Embedded \"Elicitation Kernel\"\n\nVersion context: `@flue/runtime` **2.0.3** (npm, published 2026-08-05; package created 2026-05-14, 48 versions). Siblings `@flue/cli`, `@flue/sdk`, `@flue/react`, `@flue/vite` all at 2.0.3. Docs pages carry \"Last updated Jul 21–23, 2026\". Repo: `github.com/withastro/flue`.\n\n## 1. Agent as a unit\n\n**Code.** An agent is a plain exported, capitalized JS function that returns its system-prompt string. Capabilities come from `use*` hooks called in its body. A module marked `'use agent'` is scanned at build time by the Vite plugin (`flue()` from `@flue/vite`); every exported capitalized function in it becomes a registered agent. One file may export several.\n\n**Lifecycle.** The function **re-renders before every model call** and rebuilds instructions and its declared resource set from scratch. Unlike React, resource hooks *may* be called conditionally — this is the framework's central design bet (\"an agent is a program to write, not an object to configure\"). Between renders the runtime diffs the declared set against a \"last-narrated snapshot\" and appends a framework-authored `resources` signal at the next turn boundary (\"New tool available: …\"). Skill/subagent catalogs are frozen on a durable baseline so flips don't bust the prompt cache; custom-tool changes rewrite the native tools array and *do* invalidate cache (documented exception: a tool unlocked by a completed tool call, on non-Haiku Anthropic models).\n\n**State.** Durable identity is the function name (or the `Fn.agentName` static) — it keys conversation storage, so renaming without pinning `agentName` is a DB migration. Each conversation is addressed by a caller-chosen `id`. `Fn.initialData` (a Valibot schema static) validates creation-time data exactly once.\n\n**Deployment.** Registration ≠ mounting. `createAgentRouter(agent)` returns a Hono sub-app you mount yourself in `src/app.ts`; agents reached only via `dispatch(...)` need no mount at all. Entry points: `flue run <module>` (CLI, no server), HTTP `POST /:id` (202 fire-and-forget), `dispatch(agent, {id, message, initialData, uid})`, and `start()` + `init()` for standalone Node processes.\n\n## 2. Primitive inventory (what a library could register/own)\n\n* **Tools.** `defineTool({name, description, input?, output?, harness?, durable?, run})` — Valibot schemas, frozen at module load, importable from a light `@flue/runtime/tool` entry \"for tool-only modules\". Mounted per render via `useTool(def)`. `run` receives `{data, signal, log, toolCallId}`; `harness: true` adds `harness`, `durable: true` adds `step`. Reserved names: `task`, `activate_skill`, `read_skill_resource`, plus sandbox built-ins (`read/write/edit/bash/grep/glob`). **This is the primary registration surface an embedded kernel would own.**\n* **Harness tools** (worth calling out separately). `harness.sandbox` (direct file/exec verbs, *never recorded in the conversation*) and `harness.prompt(text, {result: Schema, tools, model, thinkingLevel, images})` — runs a model operation in a private scratch conversation invisible to clients, with Valibot-validated structured output enforced via a framework-injected `finish` tool. Repeated calls continue that scratch conversation. **This is the closest thing Flue has to a sub-LLM call primitive, and it is a strong fit for a kernel's internal extraction/normalization steps.** Also `harness.compact()`.\n* **Skills.** Open Agent Skills format (`SKILL.md` + supporting files), or `defineSkill({name, description, instructions, files})` for generated/assembled content. Progressive disclosure: one catalog line always present; full instructions arrive as an `activate_skill` tool *result*, so activation never mutates the system prompt and the cached prefix survives. Supporting files are served read-only from the app bundle at virtual paths — **not** copied into the sandbox. Also auto-discovered from `<cwd>/.agents/skills/` when a sandbox exists.\n* **Subagents.** `defineSubagent({name, description, agent})` + `useSubagent()`. Model-driven via the always-present `task` tool. Child inherits *environment* (sandbox, workspace context, parent model) but **nothing conversational** — no history, instructions, tools, skills, persistent state, or initialData. Only the final message returns. Explicitly *not* a second addressable agent: \"no conversation id, no persistent state, and no address.\" `GeneralSubagent` ships as a blank delegate under `flue-general`.\n* **Persistent state.** `usePersistentState(name, initial)` — React-shaped, JSON-serializable, keyed by name, durable for the life of the conversation. Writes commit **atomically with the unit of work that made them** (tool batch, or event-hook seam checkpoint), which is what makes it the correct guard for at-least-once callbacks. Prefer updater functions; the render value is a snapshot.\n* **Sandboxes.** `useSandbox(factory, {cwd})`. `local()` from `@flue/runtime/node`, or adapters (Daytona, E2B, Modal, Cloudflare Sandbox/Computer) built against the Sandbox Adapter API. Attaching one adds the six built-in file/shell tools; an adapter may replace that set entirely. Sandbox filesystems are **ephemeral by default** and independent of conversation durability.\n* **Channels.** Inbound-only verified HTTP ingress (Slack, Discord, Teams, GitHub, Stripe, …), shipped as **blueprints** (`flue add channel slack`) that generate project source rather than as opaque packages. A channel is \"an object with declarative routes\"; `createChannelRouter(routes)` builds one by hand. Handlers call `dispatch(...)` themselves. **Outbound is explicitly not Flue's job** — no send-message abstraction; you use the provider SDK and expose narrow tools with the destination bound in trusted code.\n* **Event hooks / data writers.** `useAgentStart` (async — the load-data seam), `useAgentFinish`, `useResponseStart/Finish` (return values merge onto response *metadata*). `useDataWriter(name, {schema})` streams typed structured data parts to clients (`{type: 'data-orderCard', data}`), strictly one-way out of the agent — **the model never sees data parts**, and a write never re-renders the agent.\n* **Custom hooks.** Plain `use*` functions composing the built-ins, returning instruction fragments to the caller. Docs explicitly frame this as the reuse/packaging unit.\n\n## 3. Pi exposure\n\nPartial and deliberate, concentrated at the **model-provider layer**. Documented facts:\n\n* `@flue/runtime`'s npm dependencies include `@earendil-works/pi-agent-core` and `@earendil-works/pi-ai` directly.\n* Models guide: \"Providers are Pi's own objects, and Flue accepts them directly: build one with Pi's `createProvider()` … and hand it to `setProvider()` at module top level in `app.ts`.\" Examples import from `@earendil-works/pi-ai`, `.../api/anthropic-messages.lazy`, `.../providers/anthropic`, `.../api/openai-completions.lazy`.\n* `start({providers})` registers \"the Pi providers this runtime registers, replacing the default set.\"\n* `PromptImage` \"re-exports pi-ai's `ImageContent`.\"\n* Why-Flue: \"Flue builds on Pi, the open agent harness behind OpenClaw, and integrates it deeply into every agent you build.\"\n\nEverything else — conversation loop, tool dispatch, skills, subagents, durability — sits behind Flue's own abstractions. **Inference:** there is no documented path to Pi's agent loop, message list, or Pi extension/package system from inside a Flue agent. A kernel that currently assumes Pi-level tool registration, transcript control, or `renderResult`-style TUI hooks would have to be re-expressed entirely in Flue's `defineTool` + render model. Flue also uses Durable Streams (`@durable-streams/client`) as its client transport protocol.\n\n## 4. Local vs. remote parity\n\nDurable *records and recovery decisions are identical* across targets; ownership and wake mechanics differ.\n\n|  | Node | Cloudflare |\n| -- | -- | -- |\n| Unit | one server process, coordinator with **lease-based** ownership | one **Durable Object per agent conversation**, own SQLite; ownership structural |\n| Recovery | startup reconciliation + periodic lease scans | wake-on-start + self-renewing durable wake schedule, bounded supervision pass |\n| Storage | `db.ts` adapter required (sqlite, Postgres, MySQL, Mongo, Redis, libSQL, Turso, Supabase, Valkey); **without one, conversations are process-local memory and a restart loses them** | built in |\n| Constraint | must route each conversation to exactly one owner; active-active / round-robin for the same conversation is unsafe | every deployed agent needs an append-only DO migration tag in your hand-authored `wrangler.jsonc`; renames/deletes are storage migrations (`renamed_classes` / `deleted_classes`) |\n\nCore contract: \"Every accepted submission reaches exactly one durable terminal outcome — completed, failed, or aborted — no matter how many crashes happen in between.\" Submissions are recorded durably *before* any model work; that is what the 202 and the `DispatchReceipt` attest to. There is a retry budget plus a wall-clock timeout, enforced preemptively via the attempt's abort signal.\n\n**Deliberately not durable:** sandbox files (rebuilt fresh on each initialization unless the adapter keys a provider workspace on the instance id — \"a durable database does not make a sandbox durable\"); in-flight local promises (persist the `DispatchReceipt` and `read(receipt)` re-attaches from any process); and **code outside the agent** — Flue explicitly does not checkpoint arbitrary TypeScript. For that, docs point to Cloudflare Workflows / Inngest / Temporal calling Flue \"like any other service.\" External side effects are never recorded, only that a tool ran and what it returned.\n\nAlso: there is **no GitHub Actions or GitLab *target***. CI is just `flue run` in a shell step (`--new` + deterministic `--id` gives exactly-once conversation creation). GHA/GitLab appear only in the ecosystem catalog. Builds are Vite (`vite build` → `dist/server.mjs` + `dist/app.mjs`, or the Cloudflare plugin's output). Node deps are externalized, not bundled; the built server does not load `.env`.\n\n## 5. Library-in-agent vs. agent-as-product\n\n**Embedding is a natural pattern, and the docs endorse it explicitly.** Evidence:\n\n* `defineTool` / `defineSkill` / `defineSubagent` all exist specifically as *exportable, frozen, module-load-validated* units — described as \"the natural shape for tools shared across agents\" and \"the exportable unit — define a delegate once, mount it from any agent.\"\n* **Custom hooks are the documented composition unit:** \"a `useGitHub()` hook that bundles the right tools, skills, and instructions can be written once and dropped into every agent that works with GitHub.\" That is precisely a kernel-in-a-hook.\n* `@flue/runtime/tool` is a lighter entry point for tool-only modules — a library can depend on Flue without pulling in the server runtime.\n* Source-dir resolution order puts `.flue/` **first**, described as \"a self-contained Flue source area inside a larger application,\" with authored modules free to \"import ordinary supporting code from elsewhere in the project.\"\n* Per-mount overrides \"spread cleanly\": `useSubagent({ ...issueClassifier, model: 'anthropic/claude-haiku-4-5' })`.\n\nCounter-pressure: Flue insists the *agent itself* be a program, not config, and the `'use agent'` build-time scan means a library **cannot ship a pre-registered agent** — the agent module must be authored in the consuming project.\n\n**Recommendation (inference):** ship the kernel as a published custom hook — `useElicitationKernel(targetPlugin)` — that internally calls `useTool` / `useSkill` / `usePersistentState` / `useDataWriter` and returns instruction fragments, plus raw `defineTool` exports for hosts that want selective mounting. The host owns a ~10-line `'use agent'` module, the `app.ts` mount, and `db.ts`. This is library-in-a-thin-agent, and Flue's grain supports it. One real constraint: tool names are globally unique per render and collide with reserved names, so the kernel needs a namespacing convention.\n\n## 6. Channels as host surfaces\n\nA \"host input pathway\" in Flue is: verified ingress → `dispatch(agent, {id, message, initialData})`. Three distinct payload lanes:\n\n* `initialData` — recorded once at conversation creation, validated against the agent's schema static, read with `useInitialData()`, immutable thereafter. This is where an elicitation *target descriptor* belongs.\n* `kind: 'signal'` **messages** — `{type, body, attributes}` where `attributes` is a string→string map of facts *trusted code* attached. Read with `useDelivery()`. Docs push this hard as the authorization pattern: \"the model may choose an order ID to look up, but it cannot choose the customer.\" For a kernel, this is the channel for host-verified respondent identity. Channel deliveries are signals rather than `user` messages precisely because a Slack thread is multi-participant.\n* `kind: 'user'` — direct human turns.\n\n**Interviewing-UX rendering surfaces, ranked by fit:**\n\n1. `useDataWriter` **+** `@flue/react`**.** Named, schema-validated structured data parts arriving alongside text on the same message; a tool can write several times mid-run to drive live progress. `useFlueAgent({url})` gives `messages`, `parts`, `status`, `historyReady`, `sendMessage()`, `refresh()`. Message parts are `text | reasoning | dynamic-tool | file`, and **validated structured tool output is preserved on the** `dynamic-tool` **part's** `output` — the React docs say this exists \"so applications can render custom tool interfaces without a separate data-event channel.\" Direct fit for question cards, choice sets, and review panes.\n2. **Chat channels** (Slack/Teams/Discord/GitHub) for text-shaped interviewing only. There is **no outbound abstraction** — every reply is a tool you write against the provider SDK with the destination bound in trusted code (the `replyInThread(data)` pattern). Rich Slack Block Kit interviewing is entirely your code.\n\n**Gap worth flagging loudly: Flue documents no first-class human-in-the-loop / elicitation / interrupt primitive.** There is no \"ask the user and suspend\" hook. `terminate: true` on a tool result ends the turn once the current batch settles; the documented pattern for waiting on a human is state-gated tools (`record_approval` unlocks `publish_release`) plus a new inbound submission. **Inference:** the kernel must implement its own turn-suspension protocol — a `terminate: true` tool that writes the pending question into `usePersistentState` and emits a data part, with the host's answer arriving as a fresh `dispatch`. That is exactly the kind of thing a kernel *should* own, but Flue provides no scaffolding for it, so it is net-new work either way.\n\n## 7. Constraints & risks\n\n* **Maturity.** 2.0.3, with 2.0 a full API rewrite around hooks announced this cycle; a Migration Guide exists. `@flue/vite` first published 2026-07-10 (19 versions). Fast-moving — expect churn.\n* **Build-time magic is load-bearing.** `'use agent'` scanning, `SKILL.md` module imports, and agent-identity stamping all happen in the Vite plugin. **This effectively requires Vite.** A kernel published as a library must not depend on that transform internally — keep to `defineTool`/`defineSkill` (plain runtime calls) and let the host own the scanned module.\n* **Durable-identity coupling.** Conversation storage is keyed by agent function name. Always pin `agentName`.\n* **Cloudflare migration ceremony.** Adding an agent is always agent + mount + new DO migration tag. If the design ever wants *dynamic* agent creation per elicitation target, Cloudflare forbids it — agents are a build-time set. Use one agent + many conversation ids instead.\n* **Prompt-cache economics constrain dynamism.** \"Gate tools on state that changes rarely.\" An interviewing kernel that swaps tools per question would thrash the cache. Prefer one stable tool set + state-driven instructions, or skill activation (cache-safe by design).\n* **Valibot lock-in** at every schema boundary (`input`, `output`, `initialData`, `useDataWriter`, `harness.prompt({result})`). A kernel with Zod-based plugin contracts needs a conversion layer or a dual-schema strategy.\n* **Node multi-replica.** No active-active per conversation; you must own routing.\n* **Subagents are conversationally sterile** — no id, no state, no address. If elicitation-target plugins need their own durable memory, they cannot be subagents; they must be state + tools inside the parent, or separately registered agents.\n* **Petrinaut / non-React web-UI host risk:** the rich path (`useFlueAgent`) is React-specific. `@flue/sdk` (`createFlueClient` → `send/read/wait/observe/history`, built on `@durable-streams/client`) is framework-neutral and is what `@flue/react` sits on, so a non-React host is viable — but it must reimplement the materialized-snapshot / reconnect / canonical-reset layer that `useFlueAgent` provides. **Inference:** budget for that, or wrap `createFlueClient` directly and accept a thinner UI contract.\n* `skills` **frontmatter** `allowed-tools` **is accepted but not enforced** — Flue does not restrict the session toolset from a skill. Any kernel-level tool gating must be done with conditional `useTool`.\n\n## 8. Unreached sources\n\n**HTTP 404 (do not exist at those paths):** `/docs/guide/deployment/`, `/docs/guide/state/`, `/docs/guide/cloudflare/`, `/docs/guide/cli/`, `/docs/guide/github-actions-target/`, `/docs/reference/index.md`, `/llms.txt`. (Real equivalents: `/docs/guide/deploy/`, state is a section of `agent-hooks`, `/docs/guide/cloudflare-target/`.)\n\n**Exist but not fetched** (nav-confirmed; would sharpen specific answers): `/docs/guide/database/`, `/docs/guide/schedules/`, `/docs/guide/evals/`, `/docs/guide/observability/`, `/docs/guide/configuration/`, `/docs/guide/migration/`, `/docs/guide/agent-behavior/`, `/docs/reference/sandbox-api/`, `/docs/reference/provider-api/`, the full `/docs/reference/agent-hooks-api/` (indexed, read only via search), the CLI and Agent SDK reference sections, all `/docs/ecosystem/*` sub-pages, the `@flue/react` package README, and `examples/react-chat`. The GitHub repo (`withastro/flue`) source and Pi's own docs (`pi.dev/docs/latest`) were not read.",
+          "url": "https://linear.app/hash/issue/FE-1367/flue-architecture-deep-read-archive",
+          "createdAt": "2026-08-11T15:35:05.561Z",
+          "updatedAt": "2026-08-19T16:20:27.414Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+            "identifier": "FE-1366",
+            "title": "Spec the elicitation harness architecture (archived wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "a5053b51-937d-453f-9c4e-fe8e49e912ad",
+          "identifier": "FE-1366",
+          "title": "Spec the elicitation harness architecture (archived wayfinder map)",
+          "description": "This is the completed planning map for the **elicitation harness**: the architecture that generalizes brunch's AI interviewer into a reusable library, able to interview people about different kinds of subject matter through pluggable target definitions — so the same interviewing machinery can produce, say, software specs in one setting and process models in another. Planning finished on 2026-08-10; the outcome is a reviewable specification, in the brunch-lite repo at `docs/planning/elicitation-kernel/spec.md`, alongside a plain-language product description. The build, and the September demo that motivates it, are planned on the successor map FE-1357.\n\nEverything below the divider is a verbatim mirror of the map as it was worked in repo markdown, kept for team visibility.\n\n---\n\n> **Archive migration (2026-08-11).** This wayfinder map was worked and completed in local markdown (repo `brunch-lite`, `docs/planning/elicitation-kernel/`) before this repo's tracker moved to Linear; it is mirrored here retroactively for team visibility. **Destination reached 2026-08-10** — the assembled spec lives at `docs/planning/elicitation-kernel/spec.md`. Repo-relative links below refer to files in `brunch-lite`. Successor effort: FE-1357 (process-model elicitation).\n\n---\n\n# Map: Elicitation Kernel — carve-out spec\n\nLabel: wayfinder:map\nStatus: closed — destination reached 2026-08-10 (the spec is assembled: [spec.md](<spec.md>))\nCreated: 2026-08-06\n\n## Destination\n\nA reviewable **spec** for a standalone architecture (working name **elicitation kernel**) that generalizes brunch's elicitor into agentic interviewing against pluggable elicitation targets, on the Pi-family substrate, deployable local and remote (Flue-shaped). The spec fixes: the shipping shape (kernel library vs. Flue agent); the kernel / host / plugin contract decomposition (leading hypothesis: the four-contract + pack model from the agentic-elicitation-challenges doc, with persistence plugin-owned in accord with deploy target); the questioning-UX contract (successor to brunch's structured exchanges, critiqued not copied); and a first milestone against two live dev targets (elicit-gherkin + elicit-lean/formal, BPMN named third).\n\n## Notes\n\n* Tracker: local markdown (`docs/agents/issue-tracker.md`); this map and `issues/` are canonical. Ticket `Status:` values: `open` / `claimed` / `resolved`.\n* HITL tickets consult `/grilling` + `/domain-modeling`; research tickets resolve via `/research` subagents, AFK.\n* Plan, don't do: tickets resolve decisions. The spec (ticket 08) is the map's only deliverable.\n* Lexicon (hardened via `/domain-modeling` 2026-08-06, during the Questioning-UX grilling; canonical home: repo `CONTEXT.md`): **substrate** (the agent framework beneath: Pi family, Flue — the charter's \"harness-agnostic core\" non-goal reads \"substrate-agnostic\"), **ui** (the user-interface shell: whatever affords interaction — rendering, input, reply transport; not bound to GUI/TUI; replaces \"host\"/\"host-interface\"), **harness** (the generic capability layer: mechanism + orchestration — the effort's essence is harness-engineering; replaces \"kernel\" as shell name), **plugin** (target-defining policy; composes packs, receives harness capabilities via a narrow injected context), **pack** (unchanged: ElicitationPack = concept/observation/completion contracts; ProjectionPack = projection contract; \"kernel card\" survives only as the pack-content unit), **target** (split 2026-08-10 by the multi-session resolution: **target-domain** = the artifact family a plugin defines; **target-document** = the durable unit sessions attach to; bare \"target\" legal where context disambiguates), **issue** (typed backpressure to the elicitation controller; two producers since the capture-sweep resolution — plugin ops at the payload level, the harness itself at the envelope level).\n* **Built artifacts as proofs** (ratified 2026-08-06, from the Questioning-UX grilling): prototypes, walking skeletons, and logic-prototypes are the proof path — grilling tickets resolve decisions *provisionally* and name the proof obligations they delegate to prototype tickets, rather than pinning everything through precedent + conversation alone.\n* Primary references: [docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md](<../../docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md>) (turn 1: four contracts, packs, IR) and [docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md](<../../docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md>) (turn 2: hourglass, proof obligations, invariants, smells, test matrix)\n* Reference codebase (read-only): `../brunch` — esp. `src/agents/runtime/elicitor/`, `src/exchanges/`, `src/agents/skills/`\n* External: [Flue docs](<https://flueframework.com/docs/guide/why-flue/>), [zil-lean](<https://github.com/jagg-ix/zil-lean>)\n\n### Charter decisions (pre-map grilling, 2026-08-06)\n\n* Destination artifact = a spec (not a decision-set alone, not a build)\n* Elicitor-first: the elicitor is this map's spine\n* Greenfield reimplementation; brunch is reference architecture, not shared code\n* Fully decoupled from brunch's September MVP\n* Pi-family substrate committed; harness-agnostic core is a named non-goal\n* Brunch's exchange vocabulary is prior art to critique, not an incumbent to preserve\n* Persistence plugin-owned (in accord with deploy target) is a hypothesis to test, not a decision — **resolved 2026-08-10, flipped** by [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>): storage port harness-defined, binding-implemented, plugin-blind\n* Two live dev targets from day one (forces generalization on both pack axes); BPMN/process-mining named third\n* \"brunch-lite\" is a temporary label; real name is fog\n* **Principle v2** (ratified 2026-08-06, replaces \"behavioral over procedural\" after an evidence pass over `~/Clones/mattpocock/skills` and `../brunch/docs/design/BEHAVIORAL_KERNELS.md`): *procedure for mechanism, anchors for judgment, shapes for output*. Short step sequences with checkable completion criteria where order matters; leading words wherever judgment is required; annotated shapes for everything produced; reference disclosed progressively. Design against sprawl, negation-steering, no-ops, judgment-as-procedure — not against procedure itself. `writing-for-agents` is the pack-authoring standard; kernel cards (BEHAVIORAL_KERNELS.md) are the unit of elicitation guidance.\n\n## Decisions so far\n\n<!-- one line per closed ticket: gist + link -->\n\n* [Assemble the spec](<issues/08-assemble-the-spec.md>) — **the destination: [spec.md](<spec.md>) assembled** (fourteen sections + adjudications appendix) from the full working set in amendment order; all seven pre-pass contradictions adjudicated (storage port binding-implemented with the `db.ts` reconciliation; ops stay pure; status derived never stored, retraction specified; tap-ness as a transport fact via a reserved reply encoding; invariant 1 reconciled with the provenance rule; per-message current-affordance surface with identity on tool output parts; no instruction interpolation + harness-mechanical reply binding, no echo token); ten harness invariants restated in envelope vocabulary; `CONTEXT.md` gained the envelope vocabulary and the kernel-compound ruling (kernel card kept, \"kernel invariants\" → harness invariants); rename propagated over tickets 02/07. **The frontier is empty — this map is complete.** Remaining fog is post-spec and graduates with the build effort.\n* [Walking skeleton: sweep seam on Flue](<issues/13-walking-skeleton-sweep-seam.md>) — **all four capabilities hold on Flue** (two native, two binding-absorbed, none forbidden), closing pre-pass L1–L3: settlement trigger = `useAgentFinish` would-stop seam with same-response signal steering (fires on `terminate:true` suspensions too — the pending guard is load-bearing; needs a re-nudge loop guard); session-entry read = binding-absorbed via the public durable-history projection (no in-process API; `purpose` discriminates provenance) with the load-bearing HITL amendment that **evidence anchoring is harness-resolved — the model cites verbatim user quotes, never entry numbers** (sharpens issue 12's span shape: excerpt primary, pointer derived); on-behalf injection = `kind:'signal'` append/dispatch, projecting structurally non-user so the citable-evidence rule is mechanically enforced (live: unscripted conversational conflict-surfacing off the re-entry briefing; a fact recovered from a *superseded* capture, honestly marked inferred); transactional store = binding-owned entirely (content-keyed idempotence is load-bearing under Flue's at-least-once re-execution). **Amends Shipping shape's capability list to ten entries** (adds would-stop seam, entry-projection read, signal injection, transactional store). New payload-stratum spec examples: absence smuggled as payload; compound payloads make supersession lossy. Prototype on branch `prototype/13-sweep-seam`.\n* [Multi-session elicitation & durable target state](<issues/12-multi-session-durable-target.md>) — **durable target-document, transient sessions, sweep as the only bridge**: \"target\" splits into **target-domain** (family a plugin defines) / **target-document** (durable unit sessions attach to — capture store **plus all session logs** as truth, renders strictly derived); session = one substrate conversation (per-session state: log + swept high-water mark + pending-affordance slot), never formally closes; **interleaved-only** concurrency — serialized store, whole-sweep-atomic refusals, the single-hop refusal doubling as the stale-session guard (true concurrency + per-item application → fog); re-entry briefing = injected on-behalf-of-user state messages (Pi convention), advisory-only, with the sharpened provenance rule that **only true user entries are citable evidence**; completion = derived status, never a write gate; **persistence hypothesis flipped** — storage port harness-defined, binding-implemented, plugin-blind (plugin-addressable only via PluginContext-passed methods); evidence spans = pointer + quoted excerpt.\n* [Shipping shape: kernel library vs. Flue agent](<issues/06-shipping-shape.md>) — **harness library in a thin host-authored agent, ratified with the second-binding test**: the spec enumerates a six-item substrate-capability list as the core/binding seam (portability = pressure test, not build target; **binding** entered the glossary); topology = Bun-workspace monorepo in this repo — `packages/core` (plugin SDK is its export surface; `core/testing` subpath), `packages/flue` (binding), `packages/plugin-gherkin` + `packages/plugin-assurance` (renamed from `plugin-proof-obligations` 2026-08-10, per the Formal-verification canon survey's category-error verdict; plugins depend on core *only* — stated spec invariant), `apps/dev`; Valibot throughout; tool prefix from product name (provisionally `bl_*`, never `elicit_*` — strings name identity, not function); workspace-internal, no publishing; testing = **generation-first fixtures over a deterministic replay driver** (kernel invariants as properties, `arbitraryFromSchema`, `fc.commands` conversation fuzzing from the envelope vocabulary, model as offline generator never CI oracle, regenerate-on-declaration-change); dev app chartered with three roles (dev loop / target-gallery demo / diagnostic probe views); one agent per target; milestone one local-only with remote-parity constraints pinned in spec; CI smoke = build + simulation suite.\n* [Walking skeleton: Flue question round-trip](<issues/10-walking-skeleton-flue-roundtrip.md>) — **transport proven, one amendment**: the one-channel multiplex works end-to-end (three forms, markdown floor, string-only replies, absence strip, redirect), but the fixed data channel is a *one-live-affordance slot per message* (update-in-place at every layer — stream, history, reply read-back), so per-ask identity/payload must ride the ask tool's **output part** and the kernel must **reject a second ask per batch** as mechanism; echo token not needed (adjacency + persistent pending state bound every bare-string reply); turn suspension (`terminate: true` + persistent state + fresh dispatch) sufficient, with a wake wart — instruction-interpolated pending state triggers an extra \"instructions updated\" model turn per ask; cancelled/redirected questions read back cleanly via `record_interpretation` evidence. Flue facts: `@flue/vite` needs vite ^8; dev server gives `app.ts` the whole request space (ui is app-served). Prototype on branch `prototype/10-flue-roundtrip`.\n* [Logic-prototype: capture sweep & settlement](<issues/11-logic-prototype-capture-sweep.md>) — **all five capture hypotheses hold** in a working prototype (branch `prototype/11-capture-sweep`; double-clickable demo + headless driver), each sharpened: settlement splits into **trigger vs judgment** (lifecycle-event wiring *not* proven in ticket 10 — misattribution caught by the 2026-08-10 consistency pre-pass; delegated to the sweep-seam walking skeleton, ticket 13); idempotence splits into **mechanical (harness, evidence-anchored capture identity) vs semantic (plugin reconcile)** and is content-based, so re-sweeps repair omissions; absences are **evidence, not agenda** (re-ask runs through plugin validate → issues); single-hop supersession over active heads = the lost-update guard; **two supersession channels** (sweep-time link / issue-time resolution record) with read-time *derived* status suggested (cf. issue 09). Amendments: **two validation strata** (envelope-level harness-owned refusals + advisories / payload-level plugin ops — strengthens smallest-honest-plugin), op cadence = pure orchestration policy (snapshot-purity), **resume-time sweep reconciliation** (unswept tail as computed re-entry fact). Graduated the multi-session fog → ticket 12.\n* [Questioning-UX contract](<issues/05-questioning-ux-contract.md>) — the reframe: **no exchange-pair ontology** — conversation is primary, structured questions are **affordance emissions** committed to session as evidence, capture via idempotent **range-sweeps** on agent-judged, range-level **settlement**; shells renamed **substrate / ui / harness / plugin** (the effort's essence is *harness-engineering*; IoC via narrow injected PluginContext — the ask API is part of it); harness fixes: three baseline shapes + questionnaire chaining, absence interpret-by-default/afford-when-structured, **one multiplexed data channel** with markdown floor (Flue: outbound rich / inbound string-only), interpretation render harness-owned with plugin-optional typed renderer (JSON default), conflicts close only via explicit **resolution records**, no question-budget machinery (economical interviewing = judgment guidance); all shape-level commitments are working hypotheses with proof obligations delegated to the two prototype tickets created here (10, 11); **built-artifacts-as-proofs** ratified into Notes.\n* [Contract decomposition](<issues/04-contract-decomposition.md>) — the load-bearing resolution: **agent-forward hybrid** (agent judgment owns the loop; deterministic mechanism as tools; typed-issue backpressure); **no universal IR** — the kernel owns only a domain-free **capture envelope** (evidence spans, epistemic-status enum, absence states, alternatives, one `supersedes` link) around opaque plugin payloads, no kernel edges or graph (conflicts/equivalence are typed issues, resolved only explicitly); operations tiered `project`+`validate` required / `reconcile` optional / `observe` agent-native, all snapshot-in/deltas-out with typed loss reports; **facts computed, weights judged** dialogue policy (no scoring engine); packs = kernel cards + shapes + validators + shallow schemas + completion contract; smallest-honest-plugin test; five proof obligations + ten kernel invariants + gating tests (reprojection, minimal pairs, black-box authoring) adopted as spec acceptance material; multi-plugin composition, removal, replay, capability negotiation, versioning deferred to fog. Full ownership table in the ticket.\n* [Flue architecture deep-read](<issues/01-flue-architecture-deep-read.md>) — embedding is Flue's grain: ship the kernel as a custom hook (`useElicitation(plugin)` — final name per Shipping shape) + exportable `defineTool`s over a thin host-authored `'use agent'` module; Pi is exposed only at the provider layer (no path to Pi's loop/extensions — brunch-style Pi assumptions don't transfer); durability contract identical local/remote but storage/ownership differ; **no first-class ask-the-user primitive — the kernel must own its turn-suspension protocol** (`terminate: true` tool + persistent state + data part, answer arrives as fresh dispatch); constraints: Valibot at every schema boundary, stable-tool-set cache economics, subagents conversationally sterile, non-React hosts must build on `@flue/sdk`.\n* [Formal-verification canon survey](<issues/09-formal-verification-canon-survey.md>) — align the second target to a **GSN skeleton** (Goal/Strategy/Solution/Assumption/Justification; the one canon built for argued claims about a system) with **Dafny nouns** (`requires`/`ensures`/`invariant`/`lemma`/`assume` transfer; `modifies`/ghost don't) and **Lean sorry-taint semantics**; the headline artifact is a `dafny audit`-style **assumption ledger** (per-claim status becomes a derived label); acyclicity kept as a deliberate restriction with `decreases` as future escape hatch; sell the Datalog closure as taint-propagation, never as an assurance verdict; **\"proof obligations\" is a category error to verification readers — rename the target** (resolved 2026-08-10: the second target is the **assurance argument**, package `plugin-assurance`); Geolog is *not* an ARIA artifact (negative result) but coherent-logic saturation is the validator's genuinely canonical lineage; concrete milestone-one contract sketch (one `Statement` record, four edge kinds, five-stratum status rules) is in the ticket.\n* [Dev-target portfolio confirmation](<issues/07-dev-target-portfolio.md>) — confirmed `elicit-gherkin` + `elicit-proof-obligations` live (BPMN third, full elicit-lean deferred); **hybrid order**: both packs authored before the pack interface freezes, gherkin wires end-to-end first; proof-obligations format = zil-lean's ideas in our own claim-DAG serialization, hewing to existing canon (Dafny leading candidate — grounded by new ticket 09); gherkin milestone-one validation = parse validity + pack-declared step lexicon; surfaced the **behavioral-over-procedural** design principle (routed to Contract decomposition).\n* [Brunch exchange-schema audit](<issues/03-brunch-exchange-schema-audit.md>) — full catalog + three-way classification: **generic** (the `ask` one-terminal-four-shapes primitive, declared continuations that make offer→answer non-forgeable, answered/cancelled/unavailable property-presence union, self-contained terminals, boundary-teaching schemas, no-storage asking agenda + private scratchpad, hash-pinned prompt directives); **generalize-with-changes** (present-then-ask two-step → one `present(form, payload)` with pluggable validators, parent-link instead of enumerated prev/curr/next unions, opaque target-supplied receipts, rubrics declared by the target); **brunch-specific** (review-set node/edge schema, plane vocabulary, `graph_refs`, `map`/`tutorial` skills). Strain marks confirm the \"just a guess\" caution: wire vocabulary outlived tool names, a digest-into-review merge was retracted, doc/code drift on edge categories. 15 inherit/avoid lessons feed tickets 04 and 05.\n* [zil-lean survey](<issues/02-zil-lean-survey.md>) — zil-lean contains **no elicitation** (agent-authored 2-day snapshot; Datalog/Zanzibar-style claim graph in Lean 4 + Clojure) but is a strong existence proof of the kernel's claim-graph layer: evidence-graded assurance lattice with prohibited promotions, full derivation provenance, assumption/lemma/theorem/guarantee vocabulary with derived PROVED/CONDITIONAL/WEAK/BROKEN statuses. **Verdict: full elicit-lean is not dev-sized; the \"elicit-proof-obligations\" slice is** (claim DAG + criticality + evidence refs, validated by acyclicity + Datalog closure — no Lean statements) and beats BPMN as second target on both pack axes; BPMN stays third.\n\n## Not yet specified\n\n* Diagnostic \"exploded view\" harness for HITL prototype sessions — an instrumented walking-skeleton UI with parallel state readout and labeled moving parts (persistent state, pending affordance slot, tool traffic, terminate boundaries, advisory wakes, activation timing) so the human can react to internals, not just the chat surface; surfaced by the user after the ticket-10 walking skeleton, wanted \"at some point\" — **host identified** by the Shipping-shape resolution: the dev app's probe view (role 3 of its charter); graduates with the dev app, post-spec\n* Remote deploy target choice & provisioning — pending an infra-colleagues conversation (2026-08-07); blocks nothing on this map (the spec pins remote-parity constraints without naming the target)\n* Unstructured-ingest crossover at scale — the IR inside the contract-decomposition ticket absorbs the parsing/mapping core; what remains foggy is bulk/brownfield ingest as a first-class mode\n* elicit-to-petri-net as a future plugin — abstract questions (what fits a net; what IR precedes a net) wait until the pack model exists\n* JSONL-vs-YAML storage-format comparison — persistence resolved harness-defined / binding-implemented (multi-session resolution, 2026-08-10), so the format is a binding-internal choice; graduates with the local binding implementation, post-spec\n* Concurrent-session coordination beyond interleaving — simultaneous sweeps against one target-document, per-item partial sweep application, merge machinery; the spec's stance (serialized store + single-hop refusal + re-entry advisory) covers interleaving, and this graduates only if a real concurrent consumer appears\n* The real product name\n* Deferred plugin-ecosystem machinery (from Contract decomposition): simultaneous multi-plugin composition, plugin removal, full replay, capability negotiation, version/migration (spec names the five version axes only)\n\n## Out of scope\n\n* **Executor-standalone** — a different kind of project; the spec only names the elicitor→executor handoff seam\n* **Harness-agnostic core** — every named consumer is Pi-family; revisit only if a non-Pi consumer materializes (would be a fresh effort under a redrawn destination)",
+          "url": "https://linear.app/hash/issue/FE-1366/spec-the-elicitation-harness-architecture-archived-wayfinder-map",
+          "createdAt": "2026-08-11T15:34:45.686Z",
+          "updatedAt": "2026-08-19T16:26:24.440Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": null,
+          "labels": { "nodes": [{ "name": "map" }] }
+        },
+        {
+          "id": "6493c839-b368-4d62-b86f-68ef7b3220fd",
+          "identifier": "FE-1364",
+          "title": "Define the intermediate representation for process-model elicitation",
+          "description": "The interviewer doesn't write straight into the model file. It accumulates what it learns in an intermediate representation — the knowledge store the final model is generated from — because much of what an expert says (reasons, unwritten rules, references, policies) has no place in the diagram itself but must not be lost. This ticket decides what that representation is. Blocked until the reference use case (FE-1363) is chosen, since the use case stresses what the representation must hold.\n\n---\n\n## Question\n\n**What is the intermediate representation for process-model elicitation?** The net is one projection of the elicited description — what must the capture/plugin-payload schema hold, at minimum, for the September use case?\n\nKnown content with no canonical net home (corpus + Yannis, 2026-08-11): decision policies at conflict points, objective functions and penalty weights, goals and rationale, regulatory/business constraints, conservation laws, theoretical-vs-actual process (manuals vs event logs), data-feed bindings, validation criteria. Decide: how this maps onto the elicitation-kernel capture envelope (harness-owned) vs plugin payload structure (domain-owned); what the plugin's projection to Petrinaut's net format emits as its typed loss report; and what the open-questions doc's §7 answers add when they land.\n\nThis is the seam where this map feeds the plugin spec (the destination's second half).",
+          "url": "https://linear.app/hash/issue/FE-1364/define-the-intermediate-representation-for-process-model-elicitation",
+          "createdAt": "2026-08-11T14:18:13.076Z",
+          "updatedAt": "2026-08-19T16:26:27.321Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "5b14224b-a39f-4eaa-8398-54f5af224514",
+          "identifier": "FE-1363",
+          "title": "Choose the reference use case; settle the SDCPN-showcase criterion",
+          "description": "Which real-world operation should the September demo model — a truck fleet, a cold chain, a scheduling problem? The choice needs a story a live audience can follow in minutes, a willing expert to interview, and enough substance to show off what makes the approach special (timing, quantities, and randomness where the model genuinely earns them). Needs input from Dora and Yannis. This is the next open decision on the map, and it unblocks the data-representation question (FE-1364).\n\n---\n\n## Question\n\n**Which reference use case carries the demo, and what does \"showcase SDCPN features\" actually require?** (= the engineering half of PRO-99.)\n\nThe tension to settle: PRO-99 wants the net to showcase SDCPN features (\"stochasticity, dynamics not just bare PN\"), but the use-case pool is thin on systems that genuinely earn dynamic colouring. Candidates: **Truck Fleet Predictive Maintenance** (earns the full ladder incl. dynamic colouring; Idea-stage, no reference net), **pharma cold chain** (implicitly dynamically coloured — evolving temperature history; anchored by the SAILS Predictive Temperature Management case), **Production Process Scheduling** (mature, spec'd, attached reference net — but statically coloured). Either pick a case that earns the showcase, or explicitly soften the showcase criterion with the team.\n\nDone when: use case agreed with team (incl. Dora/Yannis), showcase criterion stated honestly, and PRO-99's \"written list of all facts necessary to make the net\" is scoped for that case.",
+          "url": "https://linear.app/hash/issue/FE-1363/choose-the-reference-use-case-settle-the-sdcpn-showcase-criterion",
+          "createdAt": "2026-08-11T14:18:11.980Z",
+          "updatedAt": "2026-08-19T16:20:28.274Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready to merge", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "591fc53b-1b86-413c-b617-176b86e9f460",
+          "identifier": "FE-1362",
+          "title": "Decide the September demo vehicle",
+          "description": "This ticket decided what the September demo actually is (resolved 2026-08-12): a purpose-built, throwaway demo app that uses a new interviewing library and Petrinaut's existing libraries side by side, passing a runnable model file between them — rather than building the interviewer into Petrinaut itself. The decision also set what must be visible on stage (traceable statements, the interviewer knowing what it hasn't asked, a live results panel, the model file opening and running) and demoted voice to a conditional extra. Reasons and evidence: `docs/planning/process-model-elicitation/recommendation-demo-vehicle.md` (brunch-lite repo); full record in the resolution comment.\n\n---\n\n## Question\n\n**What is the September demo vehicle?** The demo as outlined in the September Plan rides on something with so many new parts that it is effectively *entirely new* (grilling round 1). Decide what it is assembled from: the elicitation-kernel architecture (greenfield, Flue), parts of the existing brunch codebase, Petrinaut surfaces — and settle the **integration posture** (artifact boundary: a net file that loads in Petrinaut; vs library coupling per FE-1328/FE-1331 framing).\n\nMust reconcile with the in-flight framing of FE-1328 (\"extract the elicitation core\"), FE-1329 (\"make the brunch elicitor generic\"), FE-1333 (integration decision, blocks FE-1328), and FE-1331 (launch from create-new-net) — each is a claim this decision validates, redefines, or contradicts; verdicts recorded here and referenced from those issues, which this map never closes.\n\nConstraints: 17–18 Sept demo; Kostandin back ~18 Aug; decoupling preference unless evidence forces coupling; demo-legibility test.",
+          "url": "https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle",
+          "createdAt": "2026-08-11T14:18:10.840Z",
+          "updatedAt": "2026-08-19T16:26:28.338Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "grilling" }] }
+        },
+        {
+          "id": "9ab369b7-6637-42c1-af27-31e9505e53ee",
+          "identifier": "FE-1361",
+          "title": "Baseline control — what does one-shot AI elicitation already achieve?",
+          "description": "Before claiming the new interviewer beats a plain AI chat, we need to measure what a plain AI chat already achieves. This prototype runs a one-shot \"interview me and generate a model\" baseline and catalogues the mistakes it makes. The result is both the demo's honest comparison point and a check that our design fixes the failures it claims to fix. Not yet started; the experiment design is below.\n\n---\n\n## Question\n\n**Baseline control run** (Dora's proposal, 2026-08-11): what does one-shot / lightly-prompted AI elicitation *already* achieve, so we fill gaps rather than build from scratch?\n\nRun vanilla Claude on an elicitation-shaped task for a candidate demo use case (and the current Petrinaut assistant, once the survey ticket documents how to drive it): \"interview me, then produce the model.\" Capture: what it asks unprompted, what it never asks (couplings, taxonomies, penalty weights, unwritten constraints), whether its output net is structurally sane, and what assumptions it silently makes (store them, per Dora, as an explicit list). The artifact is something to react to — it calibrates every viability verdict and sharpens the positioning claim (\"the incumbent asks for a net; the elicitor works upstream\").",
+          "url": "https://linear.app/hash/issue/FE-1361/baseline-control-what-does-one-shot-ai-elicitation-already-achieve",
+          "createdAt": "2026-08-11T14:18:09.692Z",
+          "updatedAt": "2026-08-19T16:20:28.021Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Ready for review", "type": "started" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "prototype" }] }
+        },
+        {
+          "id": "ab1ae78d-2c9c-4d93-a9d4-d880805cdd0e",
+          "identifier": "FE-1360",
+          "title": "Ground elicitation strategy in the literature",
+          "description": "What does the research literature on interviewing experts — from simulation modelling, knowledge acquisition, and requirements engineering — say about how an AI interviewer should work? The strongest findings: start by eliciting the questions the model must answer, because they define both scope and \"done\"; structured interviews vastly outperform unstructured ones; ask for quantities as \"how many out of 100…\" rather than typical/fastest/slowest, which is measurably biased; and several published question catalogues can be imported wholesale. These findings shape the interviewer's design and back most of our recommendations on the PM checklist (PRO-98). Full findings: `docs/planning/process-model-elicitation/research/elicitation-strategy-literature.md`; conclusions in the resolution comment.\n\n---\n\n## Question\n\nWith no in-house expert-interviewing practice to draw on (established 2026-08-11 — modelling practice here is literature- and tool-based), what does the **literature** say for each section of the [open-questions doc](<https://www.notion.so/hashintel/3b93c81fe024801b89b3cf63a9a6ff20>)?\n\nFields to mine: knowledge acquisition / expert-knowledge elicitation (incl. classic expert-systems KA literature), requirements engineering interviewing, simulation **conceptual modelling** (e.g. Robinson), process mining & conformance, and cognitive task analysis. For each open-questions section (how modelling starts; reaching the unwritten; motif catalogues; completeness criteria; cross-examination; formalism-earning; what lives outside the model): the best-grounded answer, with sources, and a note on how it would become **pack content** (kernel cards / strategies) for the elicitor.\n\nFindings → `.scratch/process-model-elicitation/research/elicitation-strategy-literature.md`.",
+          "url": "https://linear.app/hash/issue/FE-1360/ground-elicitation-strategy-in-the-literature",
+          "createdAt": "2026-08-11T14:18:08.709Z",
+          "updatedAt": "2026-08-19T16:20:27.656Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "ab537b5e-fc6e-4e2c-be49-c5c5c7d4d6ab",
+          "identifier": "FE-1359",
+          "title": "Voice interviewing — bolt-on adapter or architectural rewrite?",
+          "description": "Could the September demo be voice-driven — the expert speaking rather than typing — without rebuilding the interviewer's architecture? Answer: yes, as a bolt-on. Buy speech-to-text and text-to-speech as separate services and attach them where the app takes turns with the user; an all-in-one \"voice conversation\" provider would take over parts of the system we need to own. Three tiers were scoped, from push-to-talk (days of work) to hands-free with a live results panel (weeks). Voice was later demoted to a conditional nice-to-have for September (FE-1362). Full findings: `docs/planning/process-model-elicitation/research/voice-feasibility.md`; conclusions in the resolution comment.\n\n---\n\n## Question\n\nIs voice interviewing a **bolt-on edge adapter** to a text/event-driven elicitation agent, or does it force a different agent architecture (writing and prompting agents entirely differently)?\n\nInputs: `docs/reference/voice-implementation-recommendation-pplx.md` (recommends ElevenLabs Speech Engine as an adapter around an existing agent: ASR → agent → TTS, barge-in via AbortSignal, authoritative state backend-side, push-to-talk fallback) and the elicitation-kernel spec's transport contract (`.scratch/elicitation-kernel/spec.md` §7: turn suspension, one-live-affordance, string-only inbound replies, markdown floor).\n\nResolve: (a) where the adapter pattern collides with our suspension/affordance model (live transcription, interruption mid-turn, structured affordances with no voice rendering); (b) what the *live entity extraction while speaking* demo beat requires beyond the adapter; (c) a risk-ranked verdict: bolt-on / bolt-on-with-constraints / architectural. Findings → `.scratch/process-model-elicitation/research/voice-feasibility.md`.",
+          "url": "https://linear.app/hash/issue/FE-1359/voice-interviewing-bolt-on-adapter-or-architectural-rewrite",
+          "createdAt": "2026-08-11T14:18:07.572Z",
+          "updatedAt": "2026-08-19T16:20:27.307Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "e423cf48-75e4-4b26-9047-00d3f34525cb",
+          "identifier": "FE-1358",
+          "title": "Survey Petrinaut — architecture, dependencies, assistant implementation",
+          "description": "Before deciding how the September demo would be built, we needed a clear picture of Petrinaut — HASH's process-modelling tool — and of the AI assistant it already ships. The survey found that Petrinaut is published as two reusable libraries; that it already has a production-ready way to import a model from a file (currently hidden in HASH's embedding of it); and that its existing assistant can interview a user but keeps no record of who said what, cannot run outside the browser, and produces models that need a separate \"scenario\" before they can run. These facts became the backbone of the demo-vehicle decision (FE-1362). Full findings: `docs/planning/process-model-elicitation/research/petrinaut-survey.md` (brunch-lite repo); conclusions in the resolution comment.\n\n---\n\n## Question\n\nWhat is Petrinaut's actual architecture, dependency surface, and current \"assistant\" implementation — and which integration posture is plausible for the September demo?\n\nSurvey the monorepo at `../hash/` (relative to brunch-lite) and produce:\n\n1. **Comparative audit, for the sake of argument, of both couplings**: *brunch-in-Petrinaut* (elicitor library consumed by Petrinaut, per FE-1328/FE-1331 framing) vs *Petrinaut-in-brunch* (net rendering/editing consumed by an elicitation app). For each: what would have to be true, what breaks, dependency/build-cycle risk against a 17–18 Sept deadline.\n2. **Current assistant implementation**: prompting, tool-use, model/provider wiring.\n3. **IR & persistence architecture of assistant output**, if any (what does it store, in what schema, where).\n4. **Task/job/subagent architectures** in or around the assistant.\n5. The **net file format** Petrinaut loads (the artifact boundary a decoupled elicitor would project into).\n\nFindings land as markdown in `.scratch/process-model-elicitation/research/petrinaut-survey.md`; resolution comment here gists the verdict-relevant facts.",
+          "url": "https://linear.app/hash/issue/FE-1358/survey-petrinaut-architecture-dependencies-assistant-implementation",
+          "createdAt": "2026-08-11T14:18:06.239Z",
+          "updatedAt": "2026-08-19T16:20:27.268Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "Done", "type": "completed" },
+          "parent": {
+            "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+            "identifier": "FE-1357",
+            "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)"
+          },
+          "labels": { "nodes": [{ "name": "research" }] }
+        },
+        {
+          "id": "9f81a2e1-da8a-4f1b-b9e4-eda62b2b837e",
+          "identifier": "FE-1357",
+          "title": "Plan the September elicitation demo and the plugin spec behind it (wayfinder map)",
+          "description": "In mid-September HASH demos to the ARIA research community. On stage, an AI interviewer holds a conversation with someone who knows how a real-world operation works — a truck fleet, a cold chain, a schedule — and turns what they say into a process model: a diagram of the operation that can be opened, inspected, and *run* in Petrinaut, HASH's process-modelling tool. Along the way the interviewer keeps a record of exactly who said what (so every part of the model can be traced back to a statement), knows what it still hasn't asked about, and produces a model file anyone can open — three things no current tool in the stack does.\n\nThis issue is the planning map for that demo: each decision that must be made before serious building starts is a sub-issue below, and the sections after the divider index what's decided and what's still open. Status: the groundwork research is done, and three big decisions have landed — the demo will be a purpose-built demo app that uses a new interviewing library and Petrinaut's existing libraries side by side, passing a model file between them, rather than building the interviewer into Petrinaut itself (2026-08-12); the demo's reference use case is truck-fleet predictive maintenance (recommended to the team, ratification expected ~18 August), with the interviewee played from a prepared briefing rather than requiring a live domain expert (2026-08-12); and the form interview knowledge is stored in is settled (2026-08-13) — the store is the set of recorded, source-traceable statements the expert made, and the runnable diagram is one view generated from it, so everything an expert says that has no place in a diagram (reasons, policies, unwritten rules) is kept rather than lost. Next: pressure-test that storage definition against more plugin kinds, then write the plugin spec once the team ratifies the use case. Planning documents live in the brunch-lite repo under `docs/planning/process-model-elicitation/`.\n\n---\n\n## Destination\n\nAn end-of-September roadmap of settled, viable commitments for the 17–18 September demo and its immediate aftermath — every product claim sorted (demo-critical / demo-visible / invisible-in-demo / post-September) with a commit/defer/reject verdict — followed immediately by the spec for the **process-model elicitation plugin** those commitments authorize. Long-form artifacts live in the repo at `docs/planning/process-model-elicitation/`.\n\n## Notes\n\n* Domain: elicitation of process models of cyber-physical systems. **SDCPN is a candidate projection target, treated as hypothesis, not premise** (stance shared on record by Dora and Lu, 2026-08-11).\n* Standing preferences: viability over declared wishes; decoupling from Petrinaut's architecture and release cycle unless evidence forces coupling; the demo-legibility test (effort concentrates on what is visible on stage); PM-stubbed product issues are *referenced and validated*, never absorbed or closed by this map.\n* The demo as outlined in [Brunch — September Plan](<https://www.notion.so/hashintel/Brunch-September-Plan-3b33c81fe02480a5af6bf3089c3ee640>) rides on something **entirely new** — settled by [Decide the September demo vehicle](<https://linear.app/hash/issue/FE-1362>): a one-off demo shell consuming the greenfield elicitation library and Petrinaut's libs over the artifact boundary.\n* Skills per ticket type: HITL tickets use /grilling + /domain-modeling; AFK tickets use /research subagents. Issue prose follows `docs/agents/issue-writing.md`.\n* Team facts: demo 17–18 September, audience = ARIA crowd, setting/format TBD (format claims are themselves feasibility-validation targets); Kostandin back ~18 August; integration discussion (Dei, Chris, Lu) Tuesday 18 August.\n* Prior inputs: [elicitation-kernel spec](<https://github.com/hashintel/brunch-lite>) at `docs/planning/elicitation-kernel/spec.md`; September Plan (above); [Petri Net business use cases DB](<https://www.notion.so/hashintel/3893c81fe0248064baa9c13fed48e016>); `docs/reference/` (settled from the inbox): SDCPN Library ideas, SAILS public report, voice implementation recommendation, Yannis/Dora/Lu transcript 2026-08-11; findings + prep notes at `docs/planning/process-model-elicitation/notes/`; [open-questions doc](<https://www.notion.so/hashintel/3b93c81fe024801b89b3cf63a9a6ff20>) (async, awaiting comments).\n\n## Decisions so far\n\n* [Ground elicitation strategy in the literature](<https://linear.app/hash/issue/FE-1360>) — objectives-first ordering (model content is *derived* from the questions the model must answer — the questions table is scope + completion + validation criterion at once); four probe catalogues imported verbatim (CDM, ACTA, 35-type typology, premortem) as ready pack content; structured beats unstructured ~10× → two-phase interview architecture; quantities via quantiles/IDEA four-step, never min/mode/max (triangular habit overstated a measured mean ~69%); motif catalogue = small quiver with variant selectors (Börger), strong as scaffold, weak as generator; colour is a folding, stochasticity has a quantitative earning test (VUT) — a principled showcase criterion for the use-case decision; logs-vs-interview boundary precisely mapped (rationale, off-system behaviour, resource reality, case notion are interview-only).\n* [Voice interviewing — bolt-on adapter or architectural rewrite?](<https://linear.app/hash/issue/FE-1359>) — **Bolt-on with constraints**, attached at the ui/turn shell: buy standalone ASR+TTS primitives (never a provider-owned conversation — the inbox note's Speech Engine shape is disqualified on its own docs); endpointing becomes a one-way-valve \"turn shell\"; tiered demo shape T0 push-to-talk voice-in (2–4 days) → T2 live-extraction panel (1.5–2 wks) → T3 open-mic/agent-interruption (stretch; \"no seam\" exists for agent interrupts). T0–T2 delivers the narrative, T3 the adjectives. Top risk is evidential: ASR scored 0/35 on \"Petrinaut\" in our own transcript — lexicon biasing + marked voice captures required.\n* [Survey Petrinaut — architecture, dependencies, assistant implementation](<https://linear.app/hash/issue/FE-1358>) — Petrinaut is two published npm libs (React UI + headless `petrinaut-core`); the artifact boundary (versioned file format + pure parser + import-with-autolayout) already exists in production, though Import is hidden in HASH's embed; a brunch SSE integration (\"Actual mode\") already ships; the incumbent assistant already interviews (\"Interview first, build second\") but is browser-resident with no headless path, no queue, no provenance capture anywhere; nets carry no initial marking or timing — a generator must emit a `scenario`, and guards/rates are JS code strings. Evidence favours the artifact boundary; the hard question is differentiation.\n* [Decide the September demo vehicle](<https://linear.app/hash/issue/FE-1362>) — a **one-off demo shell** consuming two libraries: the greenfield elicitation library (kernel-spec harness + CPS plugin + Flue binding; brunch app is *not* the base, \"extraction\" is figurative) and Petrinaut's published libs, meeting at the **artifact boundary** (net file + scenario through the production parser; in-process handoff on stage plus an \"it's just a file\" beat; the net *runs*). Demo-critical: provenance, completion accounting, live interpretation panel, handoff-and-run; voice strictly conditional. Verdicts: FE-1328/FE-1329 redefined, [FE-1331](https://linear.app/hash/issue/FE-1331/start-elicitation-from-petrinauts-create-new-net-flow) + Dora's [PRO-98](https://linear.app/hash/issue/PRO-98/write-a-brunch-elicitation-checklist-for-process-modelling) #5 contradicted-for-September/deferred, [FE-1333](https://linear.app/hash/issue/FE-1333/define-how-brunch-and-petrinaut-will-integrate) answered pending 18 Aug ratification. Recommendation doc: `docs/planning/process-model-elicitation/recommendation-demo-vehicle.md`.\n* [Choose the reference use case; settle the SDCPN-showcase criterion](<https://linear.app/hash/issue/FE-1363>) — **Truck Fleet Predictive Maintenance** (pending team ratification ~18 Aug; cold chain runner-up pending SAILS-shareability check; scheduling retained as flat-baseline testbed, not showcase; data centre rejected on feasibility). Showcase criterion re-grounded as the **earning test** — every formalism feature earned by a question the model answers; truck fleet passes both halves (per-truck wear gating maintenance = the dynamic-colouring archetype). Interviewee = **simulated expert** from a **situation pack** (persona + situation + scenario, private to the user-side; *never* IR-shaped — pack and IR sit across an information wall; glossary in CONTEXT.md, with **answer key** as the separate modeller-side eval rubric). Demo spine working hypothesis, recommended upward: the **revision story** (sped-up recorded elicitation + bounded live segment forcing a structural revision, before/after run). Sourcing fired as [Source dossier: published fleet-maintenance models + operational data](<https://linear.app/hash/issue/FE-1382>). Recommendation delivered to the team via [PRO-99](https://linear.app/hash/issue/PRO-99/agree-reference-petri-net-use-case-for-september-demo) comment + [Brunch September Demo: Reference use-case Recommendations](<https://app.notion.com/p/hashintel/3ba3c81fe024814c9ebee7767fbffa9e>) (2026-08-12).\n* [Source dossier: published fleet-maintenance models + operational data](<https://linear.app/hash/issue/FE-1382>) — dossier on branch `research/truck-fleet-dossier` (`docs/planning/process-model-elicitation/research/truck-fleet-source-dossier.md`). Headlines: **no prior art for the continuous-degradation archetype** (literature discretises into bands; SDCPN published only in air-traffic safety) and **no published road-truck fleet maintenance PN at all** — the demo net is a synthesis with clean whitespace; best structural templates are aircraft-fleet CPNs (Sheng & Prescott) + rail/wind maintenance nets. Best dataset: SCANIA Component X (CC BY); nothing public joins truck telemetry to workshop reality — the workshop half exists only as a municipal CMMS analogue (Cincinnati). Domain texture source-grade (49 CFR 396, OEM PM intervals, ATRI costs) incl. three found authenticity traps for the situation pack.\n* [Define the intermediate representation for process-model elicitation](<https://linear.app/hash/issue/FE-1364>) — the IR is **the set of active captures read through the plugin's declared payload type system**; no second store — every consolidated view (entity graph, net, completion table) is a read-time projection, the net being one of them. Architecture-level property list (statement granularity + projection-independence are the new MUSTs) **conditionally ratified**: validation via worked payload designs fired as [Validate the generic IR definition against worked payload designs](<https://linear.app/hash/issue/FE-1397>); sublimation pressure named as the expected finding. CPS payload: **ten assertion kinds** — incl. new **boundary-condition**, the mandatory scenario's supply line — kinds 1–6 net-bearing, 7–10 partly/wholly IR-only (the demo story; Dora's Maps-to column corroborates); quantity / rationale / `prescribed|practiced` as cross-kind attributes; Dora's claim #2 validated as a *projection* rule (no timing field exists — factoring is `project`'s job, never the interviewer's); question-relative completion anchored on objectives; projection emits net + scenario + metrics + parameters (optimization format excluded — Yannis's ontology in flight); practiced-wins regime rule; expert names verbatim in IR, PascalCase mapping owned by projection. Design doc: `docs/planning/process-model-elicitation/ir-design.md`; answers open-questions doc §7 (posted back).\n\n<!-- one line per closed ticket: gist + link -->\n\n* [Baseline control — what does one-shot AI elicitation already achieve?](<https://linear.app/hash/issue/FE-1361>) — the bare frontier model already interviews objectives-first, probes unwritten rules, and keeps an unprompted assumptions register: the \"incumbent asks for a net; elicitor works upstream\" positioning is dead on evidence, and differentiation must rest on machinery. Neither condition could end the engagement (a novel deliverable-deferral failure alongside the literature's budget-exhaustion). The v0 seven-category prompt bought interaction shape, quantile elicitation, live category accounting, conflict-point depth, and penalty-weight co-construction; its residual gaps are the evidence-derived plugin requirements (completion adjudication, durable idempotent capture, enforced epistemic status, provenance spans, computed coverage, validate+project, absence as first-class). Full experiment: `docs/planning/process-model-elicitation/baseline/`.\n\n## Not yet specified\n\n* **Plugin spec authoring** — the destination's second half; vehicle decided ([FE-1362](https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle)), IR decided ([FE-1364](https://linear.app/hash/issue/FE-1364/define-the-intermediate-representation-for-process-model-elicitation), 2026-08-13); graduates once the team ratifies the use case ([FE-1363](https://linear.app/hash/issue/FE-1363/choose-the-reference-use-case-settle-the-sdcpn-showcase-criterion), ~18 Aug) and the worked-examples validation ([FE-1397](https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-definition-against-worked-payload-designs)) lands. Two items now scoped into it: the destination-trend question (generic elicitation-plugin spec + CPS instantiation vs. CPS-only — would amend this map's destination wording) and motif-quiver *content* design (FE-1364 settled its home: ElicitationPack question-guidance, scaffold-yes/generator-no, no payload vocabulary).\n* **Demo script & format** — PM's call, but engineering now has a working hypothesis recommended upward ([FE-1363](https://linear.app/hash/issue/FE-1363/choose-the-reference-use-case-settle-the-sdcpn-showcase-criterion)): the **revision story** — recorded sped-up elicitation + bounded live segment where 2–3 turns force a structural net revision, before/after run in Petrinaut. Feasibility claims ours to validate: live re-projection, before/after run. A real human interviewee (vs. role-played from the situation pack) is an upgrade option if Ciaran/Dei identify one by ~19 Aug — never a dependency.\n* **Situation-pack authoring for the truck-fleet case** — deliberately held (we're out on a limb with the simulation angle): the [source dossier](<https://linear.app/hash/issue/FE-1382>) has landed (2026-08-12); graduates once the team has reacted on [PRO-99](https://linear.app/hash/issue/PRO-99/agree-reference-petri-net-use-case-for-september-demo). Wall invariant in CONTEXT.md; the dossier's three authenticity traps are ready pack-design input.\n* **Answer key + reference \"before\" net for the truck-fleet case** — flagged on [PRO-99](https://linear.app/hash/issue/PRO-99/agree-reference-petri-net-use-case-for-september-demo), not ticketed here: who builds nets is the open Dora/Yannis thread on that issue.\n* **Voice integration design** — feasibility resolved ([FE-1359](https://linear.app/hash/issue/FE-1359/voice-interviewing-bolt-on-adapter-or-architectural-rewrite)), but demoted to *conditional* by FE-1362: revisit only if the four demo-critical capabilities are very solid with significant time to spare (then T0 floor → T2 target).\n* **Package naming** — `brunch-lite` / `brunch-core` interim candidates for the elicitation library; possible post-September fold into a `brunch` monorepo with sub-path packages ([FE-1362](https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle) fog).\n* **Demo-shell deployment & storage specifics** — remote/sandbox story for the demo; runtime/persistence *shape* decided in [FE-1362](https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle) (elicitor server-side on Flue, capture store behind the storage port in the shell), specifics judged low-difficulty.\n* **Evaluation proxy** for iterating on elicitation quality (honest elicitations are slow, generative, non-repeatable — meeting finding 2026-08-11); kernel spec's replay-fixture strategy is the candidate answer.\n* **Low-effort elicitation and demo pacing** — design is owned by [FE-1406](https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies). The 2026-08-19 decision is to optimize for low user effort to reach an acceptably grounded model, not raw turn count. Kickoff infers objective, context, scope, time, intended use, and tolerance for suggested assumptions within the first turn or two; constrained sessions shift toward proposal-and-correction while preserving provenance and visible gaps. Question batching / staleness (the horizon problem) and live extracted-entity display UX remain open implementation questions.\n* Answers arriving on the open-questions Notion doc — fold in as they land. §7 is now answered by [FE-1364](https://linear.app/hash/issue/FE-1364/define-the-intermediate-representation-for-process-model-elicitation) (answer posted back to the doc); §1–§6 remain open.\n* **Session carryover 2026-08-12 — read before any HITL ticket**: `docs/planning/process-model-elicitation/notes/grilling-inputs-2026-08-12.md` (destination trend toward a general elicitation-plugin spec; facets/motions schema; Dora-checklist adopt/validate split; standing tensions). [Dora's PRO-98 checklist](<https://www.notion.so/hashintel/3b93c81fe0248019a7beda9bb31df2c8>) is a new prior input — treat its claims per that note's validate table; feedback on items 1–5 was delivered as a comment on [PRO-98](https://linear.app/hash/issue/PRO-98/write-a-brunch-elicitation-checklist-for-process-modelling) (2026-08-12).\n\n## Out of scope\n\n* **SemType/HASH-graph entity storage for September** — ruled out by Dei on [FE-1327](https://linear.app/hash/issue/FE-1327/decide-whether-to-use-hash-graph-for-september) (captured as [FE-1342](https://linear.app/hash/issue/FE-1342/store-elicited-entities-eg-requirements-inferred-from-brunch-qanda-in), post-Sep).\n* **Petrinaut-side analysis features** (optimisation, structural analysis, NL description of node groups) — the Petrinaut team's half of the demo.\n* **Post-September roadmap items** ([H-6758](https://linear.app/hash/issue/H-6758/unstructured-ingest-of-documents), [FE-1338](https://linear.app/hash/issue/FE-1338/unstructured-ingest-of-entities-from-interviews), [PRO-104](https://linear.app/hash/issue/PRO-104/benchmark-elicitation-accuracy-and-completeness) benchmarks as deliverables) — this map's roadmap horizon ends end-of-September; these return as a future effort.",
+          "url": "https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it",
+          "createdAt": "2026-08-11T14:16:57.836Z",
+          "updatedAt": "2026-08-19T16:26:28.291Z",
+          "creator": {
+            "id": "d06f9361-b221-4f40-a352-f8de83712df9",
+            "name": "Lu Nelson",
+            "email": "ln@hash.ai"
+          },
+          "state": { "name": "In progress", "type": "started" },
+          "parent": null,
+          "labels": { "nodes": [{ "name": "map" }] }
+        },
+        {
+          "id": "73816456-08dd-4eb4-b54c-700b157816ab",
+          "identifier": "FE-1334",
+          "title": "Offer user a surprising scenario of their model",
+          "description": "Show the user a surprising scenario that fits everything they said during the elicitation and the model that's been built, to confirm they are indeed correct / highlight any points to clarify",
+          "url": "https://linear.app/hash/issue/FE-1334/offer-user-a-surprising-scenario-of-their-model",
+          "createdAt": "2026-08-07T15:16:08.229Z",
+          "updatedAt": "2026-08-19T16:26:29.176Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "2efc4b91-faf6-46da-a6b2-ef8379ab6913",
+          "identifier": "FE-1333",
+          "title": "Define how brunch and Petrinaut will integrate",
+          "description": "We have agreed brunch is a library Petrinaut consumes rather than a separate application, but exactly where the boundaries are and what the archiecture is is TBC - we need to have this discussion\n\nReference: [**Brunch — September Plan**](<https://www.notion.so/hashintel/Brunch-September-Plan-3b33c81fe02480a5af6bf3089c3ee640>)\n\nDone when:\n\n* Integration boundary chosen and recorded in a doc\n* Decision covers where sessions are persisted and where the elicitor runs\n* Decision states whether net generation is part of the same package or a separate one etc",
+          "url": "https://linear.app/hash/issue/FE-1333/define-how-brunch-and-petrinaut-will-integrate",
+          "createdAt": "2026-08-07T14:59:46.015Z",
+          "updatedAt": "2026-08-19T16:26:28.423Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Duplicate", "type": "duplicate" },
+          "parent": null,
+          "labels": { "nodes": [{ "name": "blocks" }] }
+        },
+        {
+          "id": "0be7b6c0-a59f-49c2-b8dc-cea0d47727a0",
+          "identifier": "FE-1331",
+          "title": "Start elicitation from Petrinaut's create-new-net flow",
+          "description": "There is no longer a separate brunch application. brunch will be a library Petrinaut consumes: creating a new net should start the user in the elicitation flow, effectively the existing AI assistance in Petrinaut which is adequate in generating Petri nets but do not have an elicitation process. \n\nDone when:\n\n* Creating a new net in Petrinaut starts an elicitation session\n* The user has the option to exit the elicitation process or generate the Petri net without completing the process",
+          "url": "https://linear.app/hash/issue/FE-1331/start-elicitation-from-petrinauts-create-new-net-flow",
+          "createdAt": "2026-08-07T13:11:08.345Z",
+          "updatedAt": "2026-08-19T16:26:28.828Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Todo", "type": "unstarted" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "742f5f8a-92ce-4479-9d66-a2f9dfb36557",
+          "identifier": "FE-1330",
+          "title": "Generate a Petri net in Petrinaut from an elicitation session",
+          "description": "The output of the \"cyber-physical\" domain elicitation process should be a Petri net, whether it is describe a process or a plan\n\nDone when:\n\n* An elicitation session using the demo use case produces a Petri net that loads in Petrinaut\n* The net is recognisably the same process as the reference net\n* The net should utilize all SDCPN features as appropriate",
+          "url": "https://linear.app/hash/issue/FE-1330/generate-a-petri-net-in-petrinaut-from-an-elicitation-session",
+          "createdAt": "2026-08-07T12:44:02.158Z",
+          "updatedAt": "2026-08-19T16:26:27.012Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Duplicate", "type": "duplicate" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "1debf025-1bf8-4825-a972-6cc3bf987404",
+          "identifier": "FE-1329",
+          "title": "Make the brunch elicitor generic for cyber-physical domains",
+          "description": "The existing brunch elicitor is tied to software-dev / AI R&D spec elicitation. Make the elicitation more general to cyber-physical applications, namely for modelling processes or time plans which will then both be represented as Petri nets (later potentially extended to formal specification but TBC)\n\nReference: [**Brunch — September Plan**](<https://www.notion.so/hashintel/Brunch-September-Plan-3b33c81fe02480a5af6bf3089c3ee640>)\n\nDone when:\n\n* General elicitation logic carries no AI R&D specifics\n* brunch can elicit cyber-physical process modelling and schedules\n* The elicitor tracks what it still needs and judges when it has enough to build a Petri net\n* A second domain can be added without changing the core\n  \n",
+          "url": "https://linear.app/hash/issue/FE-1329/make-the-brunch-elicitor-generic-for-cyber-physical-domains",
+          "createdAt": "2026-08-07T12:39:08.601Z",
+          "updatedAt": "2026-08-19T16:26:25.558Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Duplicate", "type": "duplicate" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        },
+        {
+          "id": "c6198dfc-9fd1-4b78-89e1-0369297e2fcc",
+          "identifier": "FE-1328",
+          "title": "Extract the elicitation core into an importable package",
+          "description": "The elicitation logic is currently coupled in its own application shell - which Petrinaut cannot consume in that shape. Extract the elicitation core behind a public API with no assumptions about storage, transport or UI, and leave the existing brunch app as one consumer of it.\n\n(Perhaps similar to how Petrinaut did the split with its own core library and published package)\n\nDone when:\n\n* Elicitation core is importable with a documented public API\n* Core carries no server, database or UI dependencies\n* The brunch app consumes the core rather than containing it\n* Petrinaut can run a session through the API without vendoring brunch source",
+          "url": "https://linear.app/hash/issue/FE-1328/extract-the-elicitation-core-into-an-importable-package",
+          "createdAt": "2026-08-07T12:04:09.727Z",
+          "updatedAt": "2026-08-19T16:26:24.521Z",
+          "creator": {
+            "id": "a21d7e26-df21-4aaa-bf88-2a2297a28fa6",
+            "name": "Dora Ma",
+            "email": "dm@hash.ai"
+          },
+          "state": { "name": "Duplicate", "type": "duplicate" },
+          "parent": null,
+          "labels": { "nodes": [] }
+        }
+      ],
+      "pageInfo": {
+        "hasNextPage": false,
+        "endCursor": "c6198dfc-9fd1-4b78-89e1-0369297e2fcc"
+      }
+    }
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/source-record-hashes.json b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/source-record-hashes.json
new file mode 100644
index 00000000000..083efaad635
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/data/source-record-hashes.json
@@ -0,0 +1,696 @@
+{
+  "generatedFrom": {
+    "linearSourceSha256": "1a7200ac6a8fe466615c8d963ee29922e9e9d258e07411ce9edcdd400d10a808",
+    "githubSourceSha256": "2d00d591a91c349b81a645907825aab8640831e4682be164eb905900698ae6f5"
+  },
+  "linear": [
+    {
+      "identifier": "FE-1328",
+      "url": "https://linear.app/hash/issue/FE-1328/extract-the-elicitation-core-into-an-importable-package",
+      "updatedAt": "2026-08-19T16:26:24.521Z",
+      "titleSha256": "ae56ea6d4965234e46182510962e1d62da8a046dcc5837d7f0791f6ced557d6b",
+      "bodySha256": "4acfcc5b15e313b84921fc6396e6fd9c52b2765dfff81025a125325b733e6cb3"
+    },
+    {
+      "identifier": "FE-1329",
+      "url": "https://linear.app/hash/issue/FE-1329/make-the-brunch-elicitor-generic-for-cyber-physical-domains",
+      "updatedAt": "2026-08-19T16:26:25.558Z",
+      "titleSha256": "1e3899052502bfe561049a9091e4c52aded916dc7b8115b7139eef12f356a695",
+      "bodySha256": "408094b6d63b760d7fdf3780d197b31b5167d20fc099083f61d67466e6299879"
+    },
+    {
+      "identifier": "FE-1330",
+      "url": "https://linear.app/hash/issue/FE-1330/generate-a-petri-net-in-petrinaut-from-an-elicitation-session",
+      "updatedAt": "2026-08-19T16:26:27.012Z",
+      "titleSha256": "3850227fe63e0cd77cdae1b68ee783d17ef0a8798d9c55f9def6349270ed2d41",
+      "bodySha256": "7150e58a2762fd9a02cfd7aae88c9e06edee2af01ddfb4830850c282a2126521"
+    },
+    {
+      "identifier": "FE-1331",
+      "url": "https://linear.app/hash/issue/FE-1331/start-elicitation-from-petrinauts-create-new-net-flow",
+      "updatedAt": "2026-08-19T16:26:28.828Z",
+      "titleSha256": "3b62c2c8fc45fdb1e67b716d61f7a2f2a1de593bd3246b2a46587276da7e003c",
+      "bodySha256": "8958060e3a87c73e7bda3a0de82c7c44d27c5b47b9c113fd76fe194e0c63d8ee"
+    },
+    {
+      "identifier": "FE-1333",
+      "url": "https://linear.app/hash/issue/FE-1333/define-how-brunch-and-petrinaut-will-integrate",
+      "updatedAt": "2026-08-19T16:26:28.423Z",
+      "titleSha256": "aaccf73ec7dd40ce962ee4cd10a2ffe90a49b71c3d8d1a623668a5b1ce9beb6b",
+      "bodySha256": "6a11bc30e736307cd61277080042f0198000de588d2443a220c69a4252bb7567"
+    },
+    {
+      "identifier": "FE-1334",
+      "url": "https://linear.app/hash/issue/FE-1334/offer-user-a-surprising-scenario-of-their-model",
+      "updatedAt": "2026-08-19T16:26:29.176Z",
+      "titleSha256": "df1dc72aacf44420caf1ede7a463d613e15084a1f0d56670119722a8d85b543a",
+      "bodySha256": "2cfce75eed19d8bfd9a0fe4efc27fa6788f650d4c3ab5fb96c27042af8de6a01"
+    },
+    {
+      "identifier": "FE-1357",
+      "url": "https://linear.app/hash/issue/FE-1357/plan-the-september-elicitation-demo-and-the-plugin-spec-behind-it",
+      "updatedAt": "2026-08-19T16:26:28.291Z",
+      "titleSha256": "83601abba5441bd6090bce3ea1dcf9568ec80844a9bb19dcdbb1284df7608a84",
+      "bodySha256": "70c31f029f6aa53ce7fa10701436754ed06140024841d6f451db9e7e5771a525"
+    },
+    {
+      "identifier": "FE-1358",
+      "url": "https://linear.app/hash/issue/FE-1358/survey-petrinaut-architecture-dependencies-assistant-implementation",
+      "updatedAt": "2026-08-19T16:20:27.268Z",
+      "titleSha256": "f0ba585b8182ae752cbf2efffaabe8e3e805dedd6e0c9fe4712c01dda18c2366",
+      "bodySha256": "db2735d101439db145bdceb1a38b8e290487853806a91464677bfb650d4d4b5d"
+    },
+    {
+      "identifier": "FE-1359",
+      "url": "https://linear.app/hash/issue/FE-1359/voice-interviewing-bolt-on-adapter-or-architectural-rewrite",
+      "updatedAt": "2026-08-19T16:20:27.307Z",
+      "titleSha256": "90f6a9c3c8a4623f3635441de84273aab1c8639d9630ecef4b98d16d0623ffcd",
+      "bodySha256": "2bfe24356304af451f85f6518453b9b202a67d301b76f9c42fc50fead0b7776b"
+    },
+    {
+      "identifier": "FE-1360",
+      "url": "https://linear.app/hash/issue/FE-1360/ground-elicitation-strategy-in-the-literature",
+      "updatedAt": "2026-08-19T16:20:27.656Z",
+      "titleSha256": "f9b6d463b4fbd91c31446559b1cb91cb27a2f6080e416c5758e20c81040ea6f9",
+      "bodySha256": "25c76c4fe5da56fbfd6fbd123e84e8c544fcb09e3e455ae0924f3924aadebca9"
+    },
+    {
+      "identifier": "FE-1361",
+      "url": "https://linear.app/hash/issue/FE-1361/baseline-control-what-does-one-shot-ai-elicitation-already-achieve",
+      "updatedAt": "2026-08-19T16:20:28.021Z",
+      "titleSha256": "89252bf7368aae36924c6a2fb34ace7477a76199a34255b373bda2440a4e9010",
+      "bodySha256": "95f7163a475614b062c16230b0ef576e624ead0280d702b97dcac9deb8d575f0"
+    },
+    {
+      "identifier": "FE-1362",
+      "url": "https://linear.app/hash/issue/FE-1362/decide-the-september-demo-vehicle",
+      "updatedAt": "2026-08-19T16:26:28.338Z",
+      "titleSha256": "cdb93df46f8071efeb92a153b4eadcae8d65a4c301e9ab8c5985a2da0576886a",
+      "bodySha256": "b7a1b6eea883a9151ce69a93149934c588deeb33fcaf97f19bdc97957d45c230"
+    },
+    {
+      "identifier": "FE-1363",
+      "url": "https://linear.app/hash/issue/FE-1363/choose-the-reference-use-case-settle-the-sdcpn-showcase-criterion",
+      "updatedAt": "2026-08-19T16:20:28.274Z",
+      "titleSha256": "5a20ee169ead5fc437c962db1ff0db13adc0d1c46776cb8862b5f3a25830c0a7",
+      "bodySha256": "ffa0d06dc4022dd33a5921e8c3e2e741f8f9599b632bc6734e051256a5140509"
+    },
+    {
+      "identifier": "FE-1364",
+      "url": "https://linear.app/hash/issue/FE-1364/define-the-intermediate-representation-for-process-model-elicitation",
+      "updatedAt": "2026-08-19T16:26:27.321Z",
+      "titleSha256": "aa12482b696cc600940045a86c3fdfc36df84ff3e463c29bc2184fbefde75d1e",
+      "bodySha256": "a468c2c80f6e27f387ae7cb76493f6cba7f974099060b2617a105535244de04b"
+    },
+    {
+      "identifier": "FE-1366",
+      "url": "https://linear.app/hash/issue/FE-1366/spec-the-elicitation-harness-architecture-archived-wayfinder-map",
+      "updatedAt": "2026-08-19T16:26:24.440Z",
+      "titleSha256": "3cd9b3e42040c5bd4f19c7ccb505e838266683b4098bb7d02934b03c8df8f6b5",
+      "bodySha256": "991af4e8570535aa208f829fd81107ebcf5163186d25837f78746cee7ed77015"
+    },
+    {
+      "identifier": "FE-1367",
+      "url": "https://linear.app/hash/issue/FE-1367/flue-architecture-deep-read-archive",
+      "updatedAt": "2026-08-19T16:20:27.414Z",
+      "titleSha256": "d56adb14bff1dbfe03cac1c1c2a312d5fc3ac3693b36a8324c59c080ef5aea2a",
+      "bodySha256": "5f6506ff45d1964c8545e824d2c5b8f989410ac176bfa5fef6b9cfe150109239"
+    },
+    {
+      "identifier": "FE-1368",
+      "url": "https://linear.app/hash/issue/FE-1368/zil-lean-survey-archive",
+      "updatedAt": "2026-08-19T16:20:27.450Z",
+      "titleSha256": "aa2bdea3725452e09651b2a77e90deef72ab518995b82968d256935035bf1dad",
+      "bodySha256": "a34174377a2da0548781191d7cbb33e606fb329065a5f14afe4d22454917596f"
+    },
+    {
+      "identifier": "FE-1369",
+      "url": "https://linear.app/hash/issue/FE-1369/brunch-exchange-schema-audit-archive",
+      "updatedAt": "2026-08-19T16:20:27.340Z",
+      "titleSha256": "dfdef0d5ba4e9548fd25e728e40fb8685c0bd6e0daa4432d3793d8d5d6cb85e6",
+      "bodySha256": "1fd94e7b433040097a806d169e9cd702bb67db2dcbf906a5e197e678ed4249c2"
+    },
+    {
+      "identifier": "FE-1370",
+      "url": "https://linear.app/hash/issue/FE-1370/contract-decomposition-kernel-host-plugin-pack-boundary-archive",
+      "updatedAt": "2026-08-19T16:20:27.501Z",
+      "titleSha256": "e26e5d7d5c992fae3d3148ce48e892d0f0246c65aace5cb2f76f686181b778a8",
+      "bodySha256": "2234383db65ad51aafd0ef50877851b0449988ebd0e1c57173120549a6f95c11"
+    },
+    {
+      "identifier": "FE-1371",
+      "url": "https://linear.app/hash/issue/FE-1371/questioning-ux-contract-archive",
+      "updatedAt": "2026-08-19T16:20:27.539Z",
+      "titleSha256": "9c5bb4c0020f39dc129390162dbb882bf463fa6e089c5000047f64924d49f497",
+      "bodySha256": "7ec025083f39f180878790e096ec19c369a7d4120c839730dacc7fe7980cc9fb"
+    },
+    {
+      "identifier": "FE-1372",
+      "url": "https://linear.app/hash/issue/FE-1372/shipping-shape-kernel-library-vs-flue-agent-archive",
+      "updatedAt": "2026-08-19T16:20:27.583Z",
+      "titleSha256": "1dab9baee26c9752955fa86d601f08aed2a362b5cf4c721084b6f2259ab68b68",
+      "bodySha256": "b0f7c959583b663416d505a36c08f6db34f037d1bf8842b950cddce5797462c5"
+    },
+    {
+      "identifier": "FE-1373",
+      "url": "https://linear.app/hash/issue/FE-1373/dev-target-portfolio-confirmation-archive",
+      "updatedAt": "2026-08-19T16:20:27.618Z",
+      "titleSha256": "f716acc84bd7e8b18c26d9f5020804c103bd5a28cd5f957f643d47885903a973",
+      "bodySha256": "a1a499c06b23735a1b16cabcc6c787f35c1e3fda3af30f09c87927173b54f426"
+    },
+    {
+      "identifier": "FE-1374",
+      "url": "https://linear.app/hash/issue/FE-1374/assemble-the-spec-archive",
+      "updatedAt": "2026-08-19T16:20:26.406Z",
+      "titleSha256": "e0ef68909d31cd8e17da3910dd6beb59c3fd02068b82f7a8179a35a498f40f44",
+      "bodySha256": "a61865e7695eb3e3170612f0101ffd8bf4dd97c8322fc08c4bd129d2ea0828c1"
+    },
+    {
+      "identifier": "FE-1375",
+      "url": "https://linear.app/hash/issue/FE-1375/formal-verification-canon-survey-archive",
+      "updatedAt": "2026-08-19T16:20:27.379Z",
+      "titleSha256": "686845995b96dbb4605c51d32a3db23e65fe13afab1b3d29fb71ac0f3aa751f5",
+      "bodySha256": "da21a9ce028674fd3a68be0b7b6401585fa9af23cd013781a53c1d1a8a1a787c"
+    },
+    {
+      "identifier": "FE-1376",
+      "url": "https://linear.app/hash/issue/FE-1376/walking-skeleton-flue-question-round-trip-archive",
+      "updatedAt": "2026-08-19T16:20:26.447Z",
+      "titleSha256": "b44606046ef4f88db1c99ea98b64ca1c22da4d2dbe757268232851b775131f77",
+      "bodySha256": "ed9a8f3a2277d2bbb6122af8c449793c65672faa235173b5d51d657f8e5dc3c6"
+    },
+    {
+      "identifier": "FE-1377",
+      "url": "https://linear.app/hash/issue/FE-1377/logic-prototype-capture-sweep-and-settlement-archive",
+      "updatedAt": "2026-08-19T16:20:26.491Z",
+      "titleSha256": "37acb34d281af002054f9c0cecaececb353463f7bd3f37b592c050efcb5076f7",
+      "bodySha256": "1f7efed2a48a98b6b9ddb02cce3aef6afedb49aeb7ba33415ca5a32dfc38b908"
+    },
+    {
+      "identifier": "FE-1378",
+      "url": "https://linear.app/hash/issue/FE-1378/multi-session-elicitation-and-durable-target-state-archive",
+      "updatedAt": "2026-08-19T16:20:26.948Z",
+      "titleSha256": "a0a6d108d755c05072d5afcc84ed4ebddb1d01b3b55c339dbfb22662c6bad90a",
+      "bodySha256": "4a2e6fa5bc9e664bf7fed660d561ed2a843aa2f99509734de0773e29b169c8ca"
+    },
+    {
+      "identifier": "FE-1379",
+      "url": "https://linear.app/hash/issue/FE-1379/walking-skeleton-sweep-seam-on-flue-archive",
+      "updatedAt": "2026-08-19T16:20:26.560Z",
+      "titleSha256": "4508ec17020f4110e54e4fd9bb6409653fa6051f503485280387d982b90eae6f",
+      "bodySha256": "77ba77f249d1d1e88dda09de03554a2672f52d91e2e75261cfdbe0520f3c4cb7"
+    },
+    {
+      "identifier": "FE-1382",
+      "url": "https://linear.app/hash/issue/FE-1382/source-dossier-published-fleet-maintenance-models-operational-data-for",
+      "updatedAt": "2026-08-19T16:20:26.109Z",
+      "titleSha256": "8789e5d3309cda42c6acf9fc2fb9ed8f3fd7f223fd4c9a5b31475a5f39510bca",
+      "bodySha256": "98a2f626e1fc039a1f81b0d0fa6ecdf6a39c1fa525a4494097e78c3fb3688c34"
+    },
+    {
+      "identifier": "FE-1383",
+      "url": "https://linear.app/hash/issue/FE-1383/build-the-elicitation-harness-to-milestone-one-an-interview-that",
+      "updatedAt": "2026-08-19T16:26:28.251Z",
+      "titleSha256": "d5fbe781b6392a20e99ebbcd938e2556a3591b1eec6b089aa46e450fc54abd2b",
+      "bodySha256": "6ffa6c3bd7e56e39402e2b9b3c4a6dca3a3d926202fcfa19b6d41feecdadf78d"
+    },
+    {
+      "identifier": "FE-1384",
+      "url": "https://linear.app/hash/issue/FE-1384/generative-test-corpus-over-the-replay-driver",
+      "updatedAt": "2026-08-19T16:20:26.528Z",
+      "titleSha256": "34fd893cbe8f38105a28d034e986b36d093d2bb616f11fd3705d9a89ca11a606",
+      "bodySha256": "dc23151710c724730fd5e28460cf1e18ad96ee9b6faf63acf4c4385c7b963ab8"
+    },
+    {
+      "identifier": "FE-1385",
+      "url": "https://linear.app/hash/issue/FE-1385/dev-app-target-gallery-and-diagnostic-probe-surface",
+      "updatedAt": "2026-08-19T16:20:26.147Z",
+      "titleSha256": "7e4a538631309c52c61b4d6d4e1d405aa54ba435c20f18e8684b3f2a020ceedb",
+      "bodySha256": "1bd36079855c694a19c2c16781b8fe79cb03ea9ed3cd3bbce9b31f3ba0993cb4"
+    },
+    {
+      "identifier": "FE-1386",
+      "url": "https://linear.app/hash/issue/FE-1386/verify-compaction-leaves-the-durable-entry-projection-intact",
+      "updatedAt": "2026-08-19T16:20:26.302Z",
+      "titleSha256": "e290d7dbfc6823fb2391b9835c7851aac4dcfd7266cbcca1076a83916a843bc0",
+      "bodySha256": "b032d11e90f77e094632a0437a00a3b19ba43f3b74d851fda5f9983d7059a675"
+    },
+    {
+      "identifier": "FE-1387",
+      "url": "https://linear.app/hash/issue/FE-1387/author-the-second-pack-and-freeze-the-plugin-contract",
+      "updatedAt": "2026-08-19T16:20:26.344Z",
+      "titleSha256": "1e34347c94852da08269de757dd7c58086a76b740fcff0e69c8104de4853eff7",
+      "bodySha256": "0e246edd61bf61e1ca4ca67103d4f396f0d7b1d11611474727197431788ca94b"
+    },
+    {
+      "identifier": "FE-1388",
+      "url": "https://linear.app/hash/issue/FE-1388/scaffold-the-bun-workspace-and-prove-the-ci-smoke",
+      "updatedAt": "2026-08-19T16:20:27.054Z",
+      "titleSha256": "1f553d53fd1c4493bf1808505a85c8275a908f377cc646c3d822d7ee9cc4a4b7",
+      "bodySha256": "5b79a1a15bf83d384bc11b114188db2252eeec734c0299f196f56f83c59a4d94"
+    },
+    {
+      "identifier": "FE-1389",
+      "url": "https://linear.app/hash/issue/FE-1389/walking-skeleton-the-harness-asks-a-free-text-question-and-binds-the",
+      "updatedAt": "2026-08-19T16:20:28.046Z",
+      "titleSha256": "02a0530dca8c589424e2bc9a4813afe1a1cf33887212424ba50fdeba8cb20a49",
+      "bodySha256": "3623852992eec05f9567c745d0d253773713feb486dbef929fc28db16f7a317c"
+    },
+    {
+      "identifier": "FE-1390",
+      "url": "https://linear.app/hash/issue/FE-1390/capture-envelope-storage-port-and-the-local-capture-store",
+      "updatedAt": "2026-08-19T16:20:27.947Z",
+      "titleSha256": "79014f58a3fcbcbe710117e024203f408d2c85b31178827f4e2a1f2f7c50d74b",
+      "bodySha256": "dce103e6c13f999a39d866e51e61826185cc97f34dd221baa2a8b8f55bf77826"
+    },
+    {
+      "identifier": "FE-1391",
+      "url": "https://linear.app/hash/issue/FE-1391/durable-entry-projection-harness-resolved-anchoring-and-the-session",
+      "updatedAt": "2026-08-20T08:02:56.636Z",
+      "titleSha256": "64ec7826e8f32ec6ab84c8a8b36879fb5b9b6c7153d9f5ff3fca2616a42ff230",
+      "bodySha256": "464a7faf1c52aa7bbc16b542aee5d1085fff78cd671575e61dd832e2ec6295d0"
+    },
+    {
+      "identifier": "FE-1392",
+      "url": "https://linear.app/hash/issue/FE-1392/settlement-trigger-and-sweep-the-first-captured-statement",
+      "updatedAt": "2026-08-20T08:02:56.825Z",
+      "titleSha256": "dc560fe9d1bf4ae882310eb8563baa90c49375e0ab8009a2069bddb5877fe98f",
+      "bodySha256": "7a58e8a4d7e8960c3b41b0b0a91396e7c14f002f3fbf68ec63aa3dfdc8e46b3b"
+    },
+    {
+      "identifier": "FE-1393",
+      "url": "https://linear.app/hash/issue/FE-1393/plugin-sdk-and-the-gherkin-plugin-the-first-projected-artifact",
+      "updatedAt": "2026-08-19T16:20:25.951Z",
+      "titleSha256": "c19a8e89dc13b6eb7cf8b1e023e20a8f82ef1d254ab865caf2fdea5e2a463a3a",
+      "bodySha256": "eb4be2fba6a05bdbcdace930230c21ca24be097e2d707bcbf8441cebeb1367c8"
+    },
+    {
+      "identifier": "FE-1394",
+      "url": "https://linear.app/hash/issue/FE-1394/conflict-supersession-and-the-interpretation-render",
+      "updatedAt": "2026-08-19T16:20:26.378Z",
+      "titleSha256": "300684bbdff69dcc7f9ee11eb17102a826a7e24bfd5cc9b47d7c2cc6fa5c6693",
+      "bodySha256": "59342c6a55a213c528d8566c757ac6a85af9a08819e19af57664798e93b8d2ef"
+    },
+    {
+      "identifier": "FE-1395",
+      "url": "https://linear.app/hash/issue/FE-1395/the-full-affordance-set-choices-questionnaire-chaining-and-the-absence",
+      "updatedAt": "2026-08-19T16:20:26.675Z",
+      "titleSha256": "3c8ed19b489983343fae2ea6dcbced4c87330e476f984fb75fa9937fb1974f67",
+      "bodySha256": "2a5426c3cda4bfd5d3b5e7451880acfb2000efd8f906ae9512651fa23aa94d01"
+    },
+    {
+      "identifier": "FE-1396",
+      "url": "https://linear.app/hash/issue/FE-1396/re-entry-briefing-resume-reconciliation-and-restart-durability",
+      "updatedAt": "2026-08-19T16:20:25.918Z",
+      "titleSha256": "81da9d71280d7fa1fd21ba19d101e1cd02d113fd2e626f425d50ea302efe93f8",
+      "bodySha256": "a107fcbcc646a6054c66bd208141252bda7298308546c689e1fcf9d0ff79d797"
+    },
+    {
+      "identifier": "FE-1397",
+      "url": "https://linear.app/hash/issue/FE-1397/validate-the-generic-ir-definition-against-worked-payload-designs",
+      "updatedAt": "2026-08-19T16:19:46.091Z",
+      "titleSha256": "57101af27a029ed36c454595d43f1a63d722dc7fecde14313f61c122f3ff195b",
+      "bodySha256": "676e3faa8b8d4801db351f8c82bdf8899036df30c8a5b2789d9a3f3e2b2ca534"
+    },
+    {
+      "identifier": "FE-1399",
+      "url": "https://linear.app/hash/issue/FE-1399/make-the-ci-gates-and-dev-app-fail-loudly-where-review-found-they-fail",
+      "updatedAt": "2026-08-19T16:20:26.590Z",
+      "titleSha256": "2dccdd3bedc0bb7b28b086c4a1c0c8da6c68a894767abe0713ba8b3550a581d7",
+      "bodySha256": "6b0a691af9b858b532b0ac30b62f352fcf19afc87071534e5f6ea25b13cc6379"
+    },
+    {
+      "identifier": "FE-1400",
+      "url": "https://linear.app/hash/issue/FE-1400/close-the-review-found-gaps-where-the-gates-dev-app-and-baseline",
+      "updatedAt": "2026-08-19T16:20:26.709Z",
+      "titleSha256": "4e4a7a42972cd87205b806f4c89d7ba44e0ab2ddb6efa1abbab18de34022ed39",
+      "bodySha256": "ea04928499443681cda2c797a268fe7c62b970dacb49d787ada0a84d2e516257"
+    },
+    {
+      "identifier": "FE-1401",
+      "url": "https://linear.app/hash/issue/FE-1401/resolve-the-follow-ups-from-the-stack-legibility-session",
+      "updatedAt": "2026-08-19T16:20:28.561Z",
+      "titleSha256": "3eb163af50263452be68f66950600c587100fa854645791d88be95fddb53e306",
+      "bodySha256": "add5a3da06b366dbc9fe4cdc44b9ce161d2775c8b43fb18af380b2fe2c9c9d5e"
+    },
+    {
+      "identifier": "FE-1402",
+      "url": "https://linear.app/hash/issue/FE-1402/decide-when-an-elicitation-is-complete-or-should-stop",
+      "updatedAt": "2026-08-19T16:19:47.912Z",
+      "titleSha256": "518f7d5cf52ba2195138f03237f8cebbff16622631fd34f3d96e68e9066fc5db",
+      "bodySha256": "0443796ebe3de81af985a3621799610618b8f020b26ee7e4558e237ea1752df1"
+    },
+    {
+      "identifier": "FE-1403",
+      "url": "https://linear.app/hash/issue/FE-1403/assemble-the-cps-packs-interviewing-guidance-and-desk-test-it-where",
+      "updatedAt": "2026-08-19T16:19:48.641Z",
+      "titleSha256": "76a2a8c3c3f4070aa4979a9414bd2d22eca8e87303966a2377bf17fc8a417196",
+      "bodySha256": "0f8b52a00cb0756e5a5175f053ee2911bca209347466334d61f9f7607f78ccdc"
+    },
+    {
+      "identifier": "FE-1404",
+      "url": "https://linear.app/hash/issue/FE-1404/run-the-armed-baseline-condition-3-completion-contract-and-pack",
+      "updatedAt": "2026-08-19T16:19:48.957Z",
+      "titleSha256": "dc85e7886b6e6ba00a4848394abc5de81f7592f16cfdd8db8291d6586675e22f",
+      "bodySha256": "f88abfbaa37d65613194b26c3c52b12356af84b1bd39e5b8b062b86d03fefd85"
+    },
+    {
+      "identifier": "FE-1405",
+      "url": "https://linear.app/hash/issue/FE-1405/draft-the-cps-payload-interiors-annotated-shapes-for-the-ten-kinds",
+      "updatedAt": "2026-08-20T08:02:56.864Z",
+      "titleSha256": "6684fe28ff26349efddef701756334dbc89e05ad594c401f49a8b0f575f0845a",
+      "bodySha256": "42b2be3331cc53b8d4f319769fc410edee6afe23b96111e1f79cc3adf9c59785"
+    },
+    {
+      "identifier": "FE-1406",
+      "url": "https://linear.app/hash/issue/FE-1406/design-reusable-elicitation-strategies",
+      "updatedAt": "2026-08-19T16:20:27.749Z",
+      "titleSha256": "9e9eb8ab449ad16c522398efabb98d5eff616e2e1e7cd8c81b99ff2b54d86ba2",
+      "bodySha256": "c5698449d7a48b8b4f4f1b3f9dead3407ae1a737b26c62c6034528c809b993f9"
+    },
+    {
+      "identifier": "FE-1407",
+      "url": "https://linear.app/hash/issue/FE-1407/catalogue-the-frontier-elicitor-failure-modes-the-published",
+      "updatedAt": "2026-08-19T16:19:49.974Z",
+      "titleSha256": "20bc9b033919f9de69d2601587094279f30a7542246f0b91a234fc77247e5500",
+      "bodySha256": "147f3f51d5bb84c4d365fcbeb62793a602f48218bcfa36358fb2179f38e737cd"
+    },
+    {
+      "identifier": "FE-1419",
+      "url": "https://linear.app/hash/issue/FE-1419/close-the-seams-where-the-capture-store-and-verification-gates-claim",
+      "updatedAt": "2026-08-19T16:20:27.978Z",
+      "titleSha256": "c7839e241c62f56c68fa6c425f55035423c76bda7a42bdbb9916214a3d0ffdca",
+      "bodySha256": "8943da27bdc24725789f0721adc47978caad9bc3dc841c5086d8bd7860c07b59"
+    },
+    {
+      "identifier": "FE-1420",
+      "url": "https://linear.app/hash/issue/FE-1420/the-affordance-protocol-survives-retries-unknown-forms-and-abandoned",
+      "updatedAt": "2026-08-19T16:20:26.642Z",
+      "titleSha256": "3bfff13eaf86dd08b581c3c256de11384d3a0322712bec45e72909d23488c045",
+      "bodySha256": "81b2a078103ec981c418c6d8583f31e301dd47b5025e06e967b13f9143b7123c"
+    },
+    {
+      "identifier": "FE-1422",
+      "url": "https://linear.app/hash/issue/FE-1422/the-ask-protocol-is-substrate-portable-mechanism-moves-from-the-flue",
+      "updatedAt": "2026-08-20T08:02:56.900Z",
+      "titleSha256": "2f1e7a4a1dc36d322f689117372148fc36b8b32010e7c5a83ad8b5164882edd3",
+      "bodySha256": "896c07b62ab8f586a5b0a3e91d47dd2227e5e69ab4b76c60e2ee33afea3de43d"
+    },
+    {
+      "identifier": "FE-1423",
+      "url": "https://linear.app/hash/issue/FE-1423/the-demo-shell-is-safe-to-expose-beyond-localhost",
+      "updatedAt": "2026-08-19T16:20:27.185Z",
+      "titleSha256": "20bfcf5adb6266e8a21935a7059acb2f2b3a72b6a45328d5a666febdbd322a07",
+      "bodySha256": "5a59b5eb9a3ef99c1232b3833764309a3a4523371cc3d50f17b733daf28e9cde"
+    },
+    {
+      "identifier": "FE-1424",
+      "url": "https://linear.app/hash/issue/FE-1424/the-documentation-protocol-runs-end-to-end-inbox-settled-planning",
+      "updatedAt": "2026-08-20T08:02:56.935Z",
+      "titleSha256": "4ba41dff52f65d73eb3a91251a5f2f5593dd20f33ee17b935bd4f4fa0a53f03c",
+      "bodySha256": "25338da8862bddb99fe1703004fd71da6f90c544df8a3026c5ac2db39bdc8451"
+    },
+    {
+      "identifier": "FE-1431",
+      "url": "https://linear.app/hash/issue/FE-1431/plugin-authoring-becomes-declarative-a-domain-is-two-schemas-and-two",
+      "updatedAt": "2026-08-19T16:20:27.703Z",
+      "titleSha256": "9a7bf9004f09c283ea30033b983064c6ad1e6bf7b90b688aacce0a9b641271f6",
+      "bodySha256": "5d4914829c96abbd9cb90a8868e87372ae837b5ac05404f6824b4c7d97e6c381"
+    },
+    {
+      "identifier": "FE-1432",
+      "url": "https://linear.app/hash/issue/FE-1432/the-stacks-open-review-threads-are-adjudicated-fixed-owned-or-refused",
+      "updatedAt": "2026-08-20T08:02:56.984Z",
+      "titleSha256": "87232791cdfbe95bb69b3bcb846ca1a9b0057306d8b5c372fcd11b3336da9a43",
+      "bodySha256": "4280899d06e4ac85fef832eaaaa5f9bb08c388105125b5369808b5c7354d0688"
+    },
+    {
+      "identifier": "FE-1433",
+      "url": "https://linear.app/hash/issue/FE-1433/the-elicitor-serves-demopetrinautorgs-chat-panel-from-a-remote-brunch",
+      "updatedAt": "2026-08-20T08:02:57.029Z",
+      "titleSha256": "281967069fd5f9b5bfe6d27dabf982004c1f5b8286312ca546001f8466c87c7e",
+      "bodySha256": "327f6f24386c6636bd8b52e557f1164e6483a8bd4804355cdca32d1f612d1b1d"
+    },
+    {
+      "identifier": "FE-1434",
+      "url": "https://linear.app/hash/issue/FE-1434/spike-does-flue-turn-suspension-carry-batched-client-tool-round-trips",
+      "updatedAt": "2026-08-20T08:02:57.068Z",
+      "titleSha256": "c10af0cac7faccaeac3f161ec242d94fc92549f164b8e885a6305159115d58c8",
+      "bodySha256": "fac188333116b05f6764814ccb6ed97bd003e182bc45132c2d39c932440b5bb2"
+    },
+    {
+      "identifier": "FE-1435",
+      "url": "https://linear.app/hash/issue/FE-1435/spike-does-a-harness-driven-stream-drive-petrinauts-real-chat-panel",
+      "updatedAt": "2026-08-20T08:02:57.126Z",
+      "titleSha256": "2c301f3965071e2bfb773497b119bfe4e616ef41902a611005f2061854523f84",
+      "bodySha256": "a157fa152e18f4783339cc49e56ac61a608e57ce097cac34502e7a3acec17698"
+    },
+    {
+      "identifier": "FE-1436",
+      "url": "https://linear.app/hash/issue/FE-1436/the-elicitor-answers-conversation-turns-in-petrinauts-real-chat-panel",
+      "updatedAt": "2026-08-20T08:02:57.380Z",
+      "titleSha256": "a5958e22310b6c5fa71520b3c9e0c5e27b41bf557cbcf54c0d423297a0a9a6b4",
+      "bodySha256": "b07965244f137a1844adffb0b30dce5130cd4e8555f2e139579a6bc8456d0e69"
+    },
+    {
+      "identifier": "FE-1437",
+      "url": "https://linear.app/hash/issue/FE-1437/hashintelbrunch-agent-lives-in-hashintelhash-with-its-history",
+      "updatedAt": "2026-08-19T16:20:27.220Z",
+      "titleSha256": "75970ac9d4456f223830b137b2f74eab7999fb8e35f2216057966b99c9bc03ce",
+      "bodySha256": "cbe7b6d050e3486f8e1649848516b240c282e85f601a56f693f095059902a476"
+    },
+    {
+      "identifier": "FE-1438",
+      "url": "https://linear.app/hash/issue/FE-1438/the-elicitor-builds-and-repairs-the-net-through-petrinauts-client",
+      "updatedAt": "2026-08-19T16:26:26.410Z",
+      "titleSha256": "fab2a16c55c83622257f80bc3c8d2bafe38e778c7618766f473a51fbbdbfde5c",
+      "bodySha256": "4b1de406e41f3b22fd6fa75888723caa04bceb2fd97bf01d359a4f52cb9a8c0f"
+    },
+    {
+      "identifier": "FE-1439",
+      "url": "https://linear.app/hash/issue/FE-1439/elicitation-sessions-are-private-per-browser-and-survive-a-reload",
+      "updatedAt": "2026-08-19T16:20:26.834Z",
+      "titleSha256": "a52fa9f76201b88dac7f36951eb5cf70a0fbe75b77812e21ebc5ef0f904747bc",
+      "bodySha256": "c98a5d0620887f1d30a07eb63f16d2d76d7dace03784a3b3d11e63f3874a8d5f"
+    },
+    {
+      "identifier": "FE-1440",
+      "url": "https://linear.app/hash/issue/FE-1440/demopetrinautorg-ships-the-elicitor-behind-its-chat-panel",
+      "updatedAt": "2026-08-19T16:20:26.864Z",
+      "titleSha256": "c963a4b6c2fd98029b5e8c57e30e341a983769da62cec64af0236ba081293204",
+      "bodySha256": "697595134f5edfbfb98ca3046f039abca72047f4bf214916d4abcff9d41f04e5"
+    },
+    {
+      "identifier": "FE-1441",
+      "url": "https://linear.app/hash/issue/FE-1441/the-elicitor-server-runs-on-hash-infrastructure-behind-the-pre-remote",
+      "updatedAt": "2026-08-19T16:20:26.907Z",
+      "titleSha256": "7857490e95bf278812b8552e2ed55d21146842212873364d9369fb83a55afeb2",
+      "bodySha256": "2ddc691ac9f44ccc31fab6071cefa9c67942c94a358e3f4805da80d61fc19eb0"
+    },
+    {
+      "identifier": "FE-1442",
+      "url": "https://linear.app/hash/issue/FE-1442/captures-and-completion-accounting-render-live-in-the-demo-site",
+      "updatedAt": "2026-08-19T16:20:27.003Z",
+      "titleSha256": "aed7b19ffd731679630103fc8bee5d7cc962a5e2a54f6fb0d7336651c883bc1a",
+      "bodySha256": "864ae481d518556b75611b62baf28fb2de7df4d8db340d87de86942ccea9130f"
+    },
+    {
+      "identifier": "FE-1448",
+      "url": "https://linear.app/hash/issue/FE-1448/petrinaut-hosts-render-their-own-interactive-chat-tools",
+      "updatedAt": "2026-08-19T16:20:27.813Z",
+      "titleSha256": "675c39fa590ebda855c128a3837f13a98d557cce9fda8da734e5e4efe36d9b18",
+      "bodySha256": "d3722991fd835760a4d8a24c5822e68439a3860fb2308a354812cfafea0bf73e"
+    },
+    {
+      "identifier": "FE-1449",
+      "url": "https://linear.app/hash/issue/FE-1449/a-structured-brunch-question-suspends-and-resumes-visibly-in-petrinaut",
+      "updatedAt": "2026-08-19T16:20:28.606Z",
+      "titleSha256": "2b666da1c16c40eefa3542811dce3f24da1d9e005261fba747aace65a9fdb67c",
+      "bodySha256": "acd7ce7b5b6bf664d57404bd478ac63a98039fa232ad5832d2706f11a3a4dbd0"
+    },
+    {
+      "identifier": "FE-1451",
+      "url": "https://linear.app/hash/issue/FE-1451/keep-issues-comments-and-prs-easy-to-scan",
+      "updatedAt": "2026-08-19T16:20:28.510Z",
+      "titleSha256": "37219df7e036b6c5e63477976107b2c2a704596cc7fe084757fa42d906e26c5c",
+      "bodySha256": "91b3b7773b3f664b22ace816a7d85d631020f9bf80348966cc6294c461dc8bcb"
+    }
+  ],
+  "github": [
+    {
+      "number": 1,
+      "url": "https://github.com/hashintel/brunch-lite/pull/1",
+      "updatedAt": "2026-08-19T13:59:58Z",
+      "titleSha256": "2349400d04eb80fe6d4f1253ea64eecc37cc01df5cc71141a92dbc1839396dbc",
+      "bodySha256": "b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51"
+    },
+    {
+      "number": 2,
+      "url": "https://github.com/hashintel/brunch-lite/pull/2",
+      "updatedAt": "2026-08-19T14:00:01Z",
+      "titleSha256": "213035e657b4ee4135ccdf4f4781e3b7a94d4a42d404ced75c5f821df9c4b371",
+      "bodySha256": "def66364b5c84aaf3357de5f03701eea169d84972dceb6f35284fa16e281f6ce"
+    },
+    {
+      "number": 3,
+      "url": "https://github.com/hashintel/brunch-lite/pull/3",
+      "updatedAt": "2026-08-19T14:00:02Z",
+      "titleSha256": "479fc988f738df20272d535d4cdec59affba9e2c782f716ba8b2c1077966ece0",
+      "bodySha256": "c11ea0f55f34cf925c4c4dd02834521dc97c1f1b2575c18b5b48e087b027fb00"
+    },
+    {
+      "number": 4,
+      "url": "https://github.com/hashintel/brunch-lite/pull/4",
+      "updatedAt": "2026-08-19T14:00:04Z",
+      "titleSha256": "d1e15580b5ebf90f1be401019c3b33876f59f9aabe23a0424ee5b0688b15a628",
+      "bodySha256": "b14b6372d8340e427843903ecd013bdf356c3adc8d00a4cec6f664672b67817d"
+    },
+    {
+      "number": 5,
+      "url": "https://github.com/hashintel/brunch-lite/pull/5",
+      "updatedAt": "2026-08-19T14:00:05Z",
+      "titleSha256": "229ac27a91eab0e70254f9a283f3ef6a9f8d375bbf17fffdb8f7d04d2ac59603",
+      "bodySha256": "e6f28eca8b261bb837c955a6a243db8b74fbb2b31d4033a230b131ffef570cbc"
+    },
+    {
+      "number": 6,
+      "url": "https://github.com/hashintel/brunch-lite/pull/6",
+      "updatedAt": "2026-08-19T14:00:06Z",
+      "titleSha256": "49a7e617a4276a193a7ac78578d95fb09586d2fd660232472afb83eaa2c81739",
+      "bodySha256": "a504f8f2a3ac48ec0599e2f1bf0a8d9968e94dbbd04eb6d8b23d200966e8bbb6"
+    },
+    {
+      "number": 7,
+      "url": "https://github.com/hashintel/brunch-lite/pull/7",
+      "updatedAt": "2026-08-19T14:00:08Z",
+      "titleSha256": "09929e03f4a76113a051454c63fd0fdad8466e536a83e0e3f13e4a817672c64c",
+      "bodySha256": "23f9bc92607a7d5be6b55ee742f4669bf684245ce7a5c126d92f5fd65807c119"
+    },
+    {
+      "number": 8,
+      "url": "https://github.com/hashintel/brunch-lite/pull/8",
+      "updatedAt": "2026-08-19T14:00:10Z",
+      "titleSha256": "bb81d98a6ecb4ad55e7dddaf963f52da31c86a14e7cb652ee63e46396ee2867e",
+      "bodySha256": "e8ed6d96887037c79160976cbc45078edc4c452c456ef50783cead160602a7f0"
+    },
+    {
+      "number": 9,
+      "url": "https://github.com/hashintel/brunch-lite/pull/9",
+      "updatedAt": "2026-08-19T14:00:12Z",
+      "titleSha256": "438c3f68d2d61c5975585c864f38610d5e0899e9f6d1aea28d3091b82f63bb71",
+      "bodySha256": "3e7d50eae5e60d3152d16e1ecefb3de27934ea2f73e2e9f26d995921a67cc869"
+    },
+    {
+      "number": 10,
+      "url": "https://github.com/hashintel/brunch-lite/pull/10",
+      "updatedAt": "2026-08-19T14:00:14Z",
+      "titleSha256": "9aa634521196bc66ad8a36254eb995aee3b484177468d0bb0e007fb358ffb8b7",
+      "bodySha256": "f5249295ba3564783719e2d9e870e7659b074482d3c86d20803c118308d26a69"
+    },
+    {
+      "number": 11,
+      "url": "https://github.com/hashintel/brunch-lite/pull/11",
+      "updatedAt": "2026-08-19T14:00:15Z",
+      "titleSha256": "710989fa7a8870a91ba1e36447c52327068378fbb13bc879314f367363dc3f6c",
+      "bodySha256": "a58c82980be648e3b01142e3c0d0087a3c49b893c9547055bde27b98bf0bc5e0"
+    },
+    {
+      "number": 12,
+      "url": "https://github.com/hashintel/brunch-lite/pull/12",
+      "updatedAt": "2026-08-19T14:00:17Z",
+      "titleSha256": "0451f66a36602e806df9c2112c1121521b94245613ec8efffb621bb83695c9d0",
+      "bodySha256": "cca722394c59d6fc2431b1d6619f0991782d6d1969121d2d9193b4bbe84af0c3"
+    },
+    {
+      "number": 13,
+      "url": "https://github.com/hashintel/brunch-lite/pull/13",
+      "updatedAt": "2026-08-19T14:00:18Z",
+      "titleSha256": "fb7a8ac27ea24f41a79d749ca20733e2c25c4b1cee170719bc02ce0d241ad260",
+      "bodySha256": "f9ab772a065145e23ed733c85c63888b8319ec31e8b04db7b281917372d796d4"
+    },
+    {
+      "number": 14,
+      "url": "https://github.com/hashintel/brunch-lite/pull/14",
+      "updatedAt": "2026-08-19T14:00:20Z",
+      "titleSha256": "23fbf383a72d5bb528910b8067ebd01c3aef2aad088e7404b1c19f5a196b894e",
+      "bodySha256": "c3cec4fdb4fe1de796714e121acf420b6d2da0d14d743c2e9b147d705f2ac8a1"
+    },
+    {
+      "number": 15,
+      "url": "https://github.com/hashintel/brunch-lite/pull/15",
+      "updatedAt": "2026-08-19T14:00:22Z",
+      "titleSha256": "9b957cd8c760d786142e94469da03e59648c0835a5a54a7ec59204f86372f2dd",
+      "bodySha256": "105a9f8da172e7bd653130a30dcbe55ae828672de2469449a8c3e8e2d99901fa"
+    },
+    {
+      "number": 16,
+      "url": "https://github.com/hashintel/brunch-lite/pull/16",
+      "updatedAt": "2026-08-19T14:00:24Z",
+      "titleSha256": "57533df404cf90eb95676d0223056011c73aa2ab89bacfeb6ebc12e5e91d1703",
+      "bodySha256": "1fc9f55dcaded9b23be43b01e2fe6961b26a0bf5556f802ddfc7d1066846c05d"
+    },
+    {
+      "number": 17,
+      "url": "https://github.com/hashintel/brunch-lite/pull/17",
+      "updatedAt": "2026-08-19T14:00:26Z",
+      "titleSha256": "8df88b0ce1d3b89975c44cc7efb9d680d2cbda6518cf08c0af135ab15e663dae",
+      "bodySha256": "08e75c781979efa46ebd3537f207e71dc89e95cd002bf534696690d6eea06a84"
+    },
+    {
+      "number": 18,
+      "url": "https://github.com/hashintel/brunch-lite/pull/18",
+      "updatedAt": "2026-08-19T14:00:27Z",
+      "titleSha256": "e2af4a86d0444c15a7135f477591b390b36fff479e0915de853efc36b4e36ec9",
+      "bodySha256": "74deff20a1a55625cb86f64d8a867194c23f04df9057556314683a9420c14062"
+    },
+    {
+      "number": 19,
+      "url": "https://github.com/hashintel/brunch-lite/pull/19",
+      "updatedAt": "2026-08-19T14:00:29Z",
+      "titleSha256": "8baa3f7952c774fe17d2c91f5700063fa8e11047b193813df55b11766fee8eab",
+      "bodySha256": "ae7d1b251d8e1f3547dc5b55930a4e1372bd97f9af952c7e8d3e2319d46c0172"
+    },
+    {
+      "number": 20,
+      "url": "https://github.com/hashintel/brunch-lite/pull/20",
+      "updatedAt": "2026-08-19T14:00:30Z",
+      "titleSha256": "f994067680a1d677c1289baa403f1b2db4452f64845198006fd1c337648d7e81",
+      "bodySha256": "c3efa637340c6fb14916825e3303b27da6733d7a9528c5bc10cdf065722c9b64"
+    },
+    {
+      "number": 21,
+      "url": "https://github.com/hashintel/brunch-lite/pull/21",
+      "updatedAt": "2026-08-19T14:00:32Z",
+      "titleSha256": "c47a125d640ac02cb20d9907f82c7d3612121c3ba6b574f4fa7560dc2d4e30d7",
+      "bodySha256": "037a322196d9f97ed586af85f637e9ea51eb4f9a2e19911b5285b5ea7dddfac4"
+    },
+    {
+      "number": 22,
+      "url": "https://github.com/hashintel/brunch-lite/pull/22",
+      "updatedAt": "2026-08-19T14:00:35Z",
+      "titleSha256": "ea8d78aaeef51c451235b2dcd2e5aef2459dfa218dae80928968f5499c0408ea",
+      "bodySha256": "985fc49182ce7429b93462cb72bd5124b6f77a2c66a3f554e63ebd1c5a3a44b5"
+    },
+    {
+      "number": 23,
+      "url": "https://github.com/hashintel/brunch-lite/pull/23",
+      "updatedAt": "2026-08-19T14:00:37Z",
+      "titleSha256": "51da4c3d51152014c2866fb0114f20a4ae2f32653b7a64a20149ee0cd63fa59e",
+      "bodySha256": "c0634fcf88f0fb7c9428da627183b68b53d13023a55153fb1649230f5717ede3"
+    },
+    {
+      "number": 24,
+      "url": "https://github.com/hashintel/brunch-lite/pull/24",
+      "updatedAt": "2026-08-19T14:00:38Z",
+      "titleSha256": "bd9e156289c48be8bc090b55ed791baa949ca60fa375428e1ce44cefdee10367",
+      "bodySha256": "e1027892dd6c1a87afc8f7922fc51a997066da09baf710a15c05aa24a9c5c283"
+    },
+    {
+      "number": 25,
+      "url": "https://github.com/hashintel/brunch-lite/pull/25",
+      "updatedAt": "2026-08-20T08:46:31Z",
+      "titleSha256": "92298a4ff0ba866ac7de95fa5ae22a2be4d911f4e3ef9db4a562987660d684bb",
+      "bodySha256": "37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851"
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github-editorial-review.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github-editorial-review.md
new file mode 100644
index 00000000000..bb8b0b9a234
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github-editorial-review.md
@@ -0,0 +1,36 @@
+# GitHub migration editorial review
+
+## Summary
+
+- Reviewed: 25 of 25 linked `brunch-lite` pull requests.
+- Current result: 25 pass, 0 fail.
+- Proposed changes: 24 titles and 8 bodies.
+- No current editorial, fidelity, or mechanical defect remains.
+
+## Findings
+
+None.
+
+## Resolved from prior pass
+
+- **PR #25 — STATUS_DRIFT:** Resolved. The outer now limits the completed behavior to the AI SDK wire and committed application route, records that the matching answer resumes the same Flue conversation, and states that Petrinaut component registration through FE-1448 remains required for full acceptance.
+
+## Explicit archival and normalization verdicts
+
+- **PR #1:** Pass. Its outer accurately summarizes the merged record and does not turn historical uncertainty into a present commitment. The complete source body remains byte-for-byte inside the canonical wrapper.
+- **PR #23:** Pass. Normalization removes only the accidentally nested standalone Agent-notes opener and closer. All other source bytes remain unchanged and in source order, and the proposed body contains one canonical wrapper.
+
+## Mechanical validation
+
+All checks passed:
+
+- All 25 source PRs appear exactly once.
+- Every proposed title is exactly `{ISSUE-ID}: {proposed linked issue title}`.
+- Source title, source body, source inner, normalized inner, and proposed body hashes recompute correctly.
+- All 24 ordinary inner records remain byte-for-byte identical to their source inner records.
+- PR #23 differs from its source inner only by removal of the nested standalone wrapper tags.
+- Every proposed body contains exactly one canonical Agent-notes opener and one closer, with the normalized inner record appearing exactly once.
+- The title-change and body-change flags match the source comparisons.
+- Proposed titles and outers contain no banned-word matches.
+
+The editorial pass reviewed changed and unchanged outers for unsupported claims, material omissions, status drift, title commitment errors, and house-style defects. No current finding resulted.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github.md
new file mode 100644
index 00000000000..72c05740c77
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/github.md
@@ -0,0 +1,450 @@
+# GitHub migration review
+
+This manifest records the proposed GitHub PR title and body changes. It does not call GitHub or Linear.
+
+## Validation
+
+- All 25 source PRs appear exactly once, and every linked issue resolves to one proposed issue title.
+- Source title, source body, source inner, normalized inner, and proposed body SHA-256 hashes were recomputed and matched.
+- Every proposed title exactly matches `{ISSUE-ID}: {proposed Linear issue title}`.
+- Every proposed body has one standalone Agent-notes details opener and one standalone closer.
+- Every nonempty normalized inner record appears byte-for-byte exactly once in its proposed body.
+- PR #23 equals its raw source inner after removing only the nested standalone details-tag lines. All remaining bytes stay ordered.
+- Proposed titles and outers have no avoidable banned-word matches. Fixed matches: “actually” in #6 and #13, “surfaces” in #16, “slice” in #22, and “seams” in #24.
+
+## Summary
+
+- Title changes: 24
+- Body changes: 8
+- Ambiguities: 0
+- Extraction methods:
+  - 1 — outer canonical wrapper extracted; nested standalone wrapper tags removed from source inner
+  - 22 — single canonical wrapper extracted
+  - 2 — whole source body treated as authoritative inner record and wrapped once
+
+## PRs
+
+### [#1](https://github.com/hashintel/brunch-lite/pull/1) — FE-1374
+
+- Title: `FE-1374: Assemble the spec` → `FE-1374: Assemble the elicitation harness specification`
+- Body changed: `true`
+- Extraction: whole source body treated as authoritative inner record and wrapped once
+- Inner: 994 chars; source `b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51`; normalized `b034992e70ad0e9a8ab26ba321aaa87f91365d563c4bb4a021dd8c5cee3aed51`
+- Normalization: Added one canonical Agent-notes wrapper around the unchanged source body.
+- Concerns: None.
+
+**Old outer**
+
+_(none)_
+
+**Proposed outer**
+
+This branch assembles the elicitation harness specification and its companion product descriptions. It also records the second review round and the resulting changes to conversation history, absence states, evidence navigation, and reusable strategies.
+
+### [#2](https://github.com/hashintel/brunch-lite/pull/2) — FE-1362
+
+- Title: `FE-1362: Decide the September demo vehicle` → `FE-1362: Decide the September demo architecture`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 537 chars; source `9ea766c6ed1b481260e6cdfa69d077f14aa6f9044c104f1625f69be708cf525d`; normalized `9ea766c6ed1b481260e6cdfa69d077f14aa6f9044c104f1625f69be708cf525d`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.
+
+**Proposed outer**
+
+This branch records the decision that guided the September demonstration and organizes the supporting planning material. It gives later work one documented starting point instead of leaving the demo shape implicit.
+
+### [#3](https://github.com/hashintel/brunch-lite/pull/3) — FE-1363
+
+- Title: `FE-1363: Choose the reference use case; settle the SDCPN-showcase criterion` → `FE-1363: Choose the demo use case and modelling criteria`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 160 chars; source `61d4a1544d743147646d62c9ae8c4bfb0d70cfa15585c6348c8025e2ef892f27`; normalized `61d4a1544d743147646d62c9ae8c4bfb0d70cfa15585c6348c8025e2ef892f27`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.
+
+**Proposed outer**
+
+This branch defines the reference case used to judge the demonstration work. It makes the selection criteria clear enough for later planning and review.
+
+### [#4](https://github.com/hashintel/brunch-lite/pull/4) — FE-1388
+
+- Title: `FE-1388: Scaffold the Bun workspace and prove the CI smoke` → `FE-1388: Create the Bun workspace and enforce dependency boundaries`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 3407 chars; source `a64a1d8ff07ec6eb8ddff05773cfae355166251c53888725f2272d729eccd4ab`; normalized `a64a1d8ff07ec6eb8ddff05773cfae355166251c53888725f2272d729eccd4ab`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.
+
+**Proposed outer**
+
+The repository needed a runnable workspace before feature work could be trusted. This branch establishes the initial package layout and checks that catch boundary and build failures early.
+
+### [#5](https://github.com/hashintel/brunch-lite/pull/5) — FE-1364
+
+- Title: `FE-1364: Define the intermediate representation for process-model elicitation` → `FE-1364: Define the process-model elicitation representation`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 471 chars; source `5855717a5f072802db5ab6383077122e4599d0435709ea2222b1da1006ba5d89`; normalized `5855717a5f072802db5ab6383077122e4599d0435709ea2222b1da1006ba5d89`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.
+
+**Proposed outer**
+
+This branch defines the shared representation used to turn elicited evidence into a model. The definition gives future plugins and projections a common basis without introducing another source of stored truth.
+
+### [#6](https://github.com/hashintel/brunch-lite/pull/6) — FE-1361
+
+- Title: `FE-1361: Baseline control — what does one-shot AI elicitation already achieve?` → `FE-1361: Measure the one-shot AI elicitation baseline`
+- Body changed: `true`
+- Extraction: single canonical wrapper extracted
+- Inner: 1662 chars; source `fb6a119b6a835d5db47ffc75c42aa42213d0e7dc5b224fbccffeb462fb126408`; normalized `fb6a119b6a835d5db47ffc75c42aa42213d0e7dc5b224fbccffeb462fb126408`
+- Normalization: The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.
+- Concerns: None.
+
+**Old outer**
+
+This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is actually needed.
+
+**Proposed outer**
+
+This branch records what a lightly guided model can already do in the reference case. The findings set a factual baseline for deciding which product machinery is needed.
+
+### [#7](https://github.com/hashintel/brunch-lite/pull/7) — FE-1399
+
+- Title: `FE-1399: Make the CI gates and dev app fail loudly where review found they fail silently` → `FE-1399: Fix verified silent failures in CI and the dev app`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1487 chars; source `4fb763857dc7d92796d5c5100d3a1569bbe3e42455521a70c011b9fecfeafb2e`; normalized `4fb763857dc7d92796d5c5100d3a1569bbe3e42455521a70c011b9fecfeafb2e`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.
+
+**Proposed outer**
+
+Review found checks that could pass while failing to protect the behavior they claimed to cover. This branch makes those checks and the development app report those failures instead of quietly accepting them.
+
+### [#8](https://github.com/hashintel/brunch-lite/pull/8) — FE-1397
+
+- Title: `FE-1397: Validate the generic IR definition against worked payload designs (Gherkin, CPS, +1)` → `FE-1397: Validate the generic IR against worked plugin payloads`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1490 chars; source `bf06af3e6f96d849b4c1be53c8a5d9a6d3d750d4f8fdd6ddd6cac5444ec17d8a`; normalized `bf06af3e6f96d849b4c1be53c8a5d9a6d3d750d4f8fdd6ddd6cac5444ec17d8a`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.
+
+**Proposed outer**
+
+The generic representation still needed evidence that it held across more than one domain shape. This branch tests it against worked payload designs and records which parts of the definition remain sound.
+
+### [#9](https://github.com/hashintel/brunch-lite/pull/9) — FE-1400
+
+- Title: `FE-1400: Close the review-found gaps where the gates, dev app, and baseline runner still fail silently` → `FE-1400: Strengthen verification, dev storage, and the baseline runner`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 3141 chars; source `417c1c5f7a1e36797056a57c4926ece639a5b1194698472254dc2bb5269d8de9`; normalized `417c1c5f7a1e36797056a57c4926ece639a5b1194698472254dc2bb5269d8de9`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.
+
+**Proposed outer**
+
+This branch resolves the remaining review findings where checks or local tools could report success without proving the intended behavior. The result makes those failure paths visible and testable.
+
+### [#10](https://github.com/hashintel/brunch-lite/pull/10) — FE-1389
+
+- Title: `FE-1389: Walking skeleton — the harness asks a free-text question and binds the reply` → `FE-1389: Implement the first suspended free-text question`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1238 chars; source `f5792d146c557204d975fa7c7b4cacc298cced709faec5fe5cd951c46b0e7ea4`; normalized `f5792d146c557204d975fa7c7b4cacc298cced709faec5fe5cd951c46b0e7ea4`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.
+
+**Proposed outer**
+
+This branch proves the first end-to-end question-and-reply path through the real application harness. It establishes that a question can pause a turn, persist, and bind the later answer correctly.
+
+### [#11](https://github.com/hashintel/brunch-lite/pull/11) — FE-1390
+
+- Title: `FE-1390: Capture envelope, storage port, and the local capture store` → `FE-1390: Implement capture history and local persistence`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1138 chars; source `dd6b285545fcc139792afefef315c9c22acc0e2f1b1d08a9a80b9198b98a46ba`; normalized `dd6b285545fcc139792afefef315c9c22acc0e2f1b1d08a9a80b9198b98a46ba`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.
+
+**Proposed outer**
+
+This branch gives captured evidence a durable local home with an explicit write path. It establishes reliable history for later model work while leaving consumption work to subsequent branches.
+
+### [#12](https://github.com/hashintel/brunch-lite/pull/12) — FE-1401
+
+- Title: `FE-1401: Resolve the follow-ups from the stack legibility session` → `FE-1401: Resolve the stack legibility follow-ups`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1429 chars; source `deb834741c2f9b93ca8d47f6032007240f2aeafb09d79b6e6593f4d11f61226a`; normalized `deb834741c2f9b93ca8d47f6032007240f2aeafb09d79b6e6593f4d11f61226a`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.
+
+**Proposed outer**
+
+The legibility review produced findings that needed durable documentation and follow-up ownership. This branch records those findings, repairs the affected planning material, and makes the remaining work visible.
+
+### [#13](https://github.com/hashintel/brunch-lite/pull/13) — FE-1419
+
+- Title: `FE-1419: Close the seams where the capture store and verification gates claim more than they enforce` → `FE-1419: Align capture-store rules and verification claims`
+- Body changed: `true`
+- Extraction: single canonical wrapper extracted
+- Inner: 2201 chars; source `03aaf220ef749b0fcb9a0b8a846cc9670fd135f285e682acaf84c04dc77759a0`; normalized `03aaf220ef749b0fcb9a0b8a846cc9670fd135f285e682acaf84c04dc77759a0`
+- Normalization: The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.
+- Concerns: None.
+
+**Old outer**
+
+This branch closes places where the capture store and verification checks promised stronger guarantees than they actually enforced. It aligns the implementation and the checks with the properties the stack relies on.
+
+**Proposed outer**
+
+This branch closes places where the capture store and verification checks promised stronger guarantees than they enforced. It aligns the implementation and the checks with the properties the stack relies on.
+
+### [#14](https://github.com/hashintel/brunch-lite/pull/14) — FE-1424
+
+- Title: `FE-1424: The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable` → `FE-1424: Complete the documentation protocol`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 2328 chars; source `901600f53a27bda06c361821ab502ea6e0e30a5c279c9503fd5f0ea6ca13c050`; normalized `901600f53a27bda06c361821ab502ea6e0e30a5c279c9503fd5f0ea6ca13c050`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.
+
+**Proposed outer**
+
+The documentation protocol described a complete lifecycle but had not yet been exercised as one. This branch runs that lifecycle, gives each document a clear home, and adds a check that keeps the index honest.
+
+### [#15](https://github.com/hashintel/brunch-lite/pull/15) — FE-1405
+
+- Title: `FE-1405: Draft the CPS payload interiors: annotated shapes for the ten kinds, worked from baseline utterances` → `FE-1405: Draft and test the CPS payload schemas`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 2226 chars; source `c9864945e962b46747bac5d78ecf91947d3ed95f4ae9cd3f7e7e22fecf363083`; normalized `c9864945e962b46747bac5d78ecf91947d3ed95f4ae9cd3f7e7e22fecf363083`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.
+
+**Proposed outer**
+
+The CPS plugin needed concrete payload shapes grounded in the baseline evidence. This branch drafts those shapes and records the open pressures that later work must resolve.
+
+### [#16](https://github.com/hashintel/brunch-lite/pull/16) — FE-1422
+
+- Title: `FE-1422: The ask protocol is substrate-portable: mechanism moves from the Flue binding into core` → `FE-1422: Move the portable ask protocol into core`
+- Body changed: `true`
+- Extraction: single canonical wrapper extracted
+- Inner: 566 chars; source `59fdea11ba00ea9f408a7936f5f48176856261837a2957afbd506aa653c88008`; normalized `59fdea11ba00ea9f408a7936f5f48176856261837a2957afbd506aa653c88008`
+- Normalization: The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.
+- Concerns: None.
+
+**Old outer**
+
+The question-and-reply behavior was tied too closely to one runtime binding. This branch moves the portable part into the core so other application surfaces can use the same protocol.
+
+**Proposed outer**
+
+The question-and-reply behavior was tied too closely to the Flue runtime binding. This branch moves the portable part into core so other applications can use the same protocol.
+
+### [#17](https://github.com/hashintel/brunch-lite/pull/17) — FE-1391
+
+- Title: `FE-1391: Durable entry projection, harness-resolved anchoring, and the session-log archive` → `FE-1391: Resolve evidence quotes to durable conversation entries`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1167 chars; source `aa0dc9d30893dc7c516127e3e33517a0cee1493d257d73d835e9ec3ad0840d23`; normalized `aa0dc9d30893dc7c516127e3e33517a0cee1493d257d73d835e9ec3ad0840d23`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.
+
+**Proposed outer**
+
+Later capture work needed a durable way to locate and anchor prior conversation entries. This branch establishes that path and retains enough history for those anchors to be resolved reliably.
+
+### [#18](https://github.com/hashintel/brunch-lite/pull/18) — FE-1392
+
+- Title: `FE-1392: Settlement trigger and sweep — the first captured statement` → `FE-1392: Capture settled conversation statements safely`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 220 chars; source `df3111e4b7761fa8032c600be382986205f9317ed03564010aa4b5e8172b2986`; normalized `df3111e4b7761fa8032c600be382986205f9317ed03564010aa4b5e8172b2986`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.
+
+**Proposed outer**
+
+This branch connects completed conversation work to the first captured statement. It makes settlement occur at the appropriate lifecycle point and keeps the resulting evidence current.
+
+### [#19](https://github.com/hashintel/brunch-lite/pull/19) — FE-1432
+
+- Title: `FE-1432: The stack's open review threads are adjudicated: fixed, owned, or refused on the record` → `FE-1432: Resolve the stack's open review threads`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 1559 chars; source `19f5f98e93e5519ab3b1bc2ece5499a459022157087eec5015c58a9c56d17d6b`; normalized `19f5f98e93e5519ab3b1bc2ece5499a459022157087eec5015c58a9c56d17d6b`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.
+
+**Proposed outer**
+
+The stack had review findings without a clear final disposition. This branch resolves them by fixing the actionable cases and recording ownership or a supported refusal for the rest.
+
+### [#20](https://github.com/hashintel/brunch-lite/pull/20) — FE-1433
+
+- Title: `FE-1433: The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server` → `FE-1433: Deliver the remote Petrinaut elicitor integration`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 2365 chars; source `9ca3adac2b7d307ec1440ef7d27bd38111d069641c9c688cd9a931f3e2af7ce9`; normalized `9ca3adac2b7d307ec1440ef7d27bd38111d069641c9c688cd9a931f3e2af7ce9`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.
+
+**Proposed outer**
+
+The demo needed a settled integration direction before implementation could proceed. This branch records the decision to serve the existing chat panel from a remote brunch-agent server and defines the delivery work that follows.
+
+### [#21](https://github.com/hashintel/brunch-lite/pull/21) — FE-1434
+
+- Title: `FE-1434: Spike: does Flue turn suspension carry batched client-tool round-trips?` → `FE-1434: Test whether Flue resumes batched client-tool results`
+- Body changed: `false`
+- Extraction: single canonical wrapper extracted
+- Inner: 747 chars; source `75374819449c6180ad66bdbce8100715a814735ed9812ee909cbe7de36831b0a`; normalized `75374819449c6180ad66bdbce8100715a814735ed9812ee909cbe7de36831b0a`
+- Normalization: None; the canonical body and inner record are preserved byte-for-byte.
+- Concerns: None.
+
+**Old outer**
+
+The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.
+
+**Proposed outer**
+
+The planned integration depends on whether suspended turns can resume with several client-tool results together. This spike answers that question with recorded evidence and identifies the remaining obligations.
+
+### [#22](https://github.com/hashintel/brunch-lite/pull/22) — FE-1435
+
+- Title: `FE-1435: Spike: does a harness-driven stream drive Petrinaut's real chat panel?` → `FE-1435: Test whether the elicitor stream drives Petrinaut’s chat panel`
+- Body changed: `true`
+- Extraction: single canonical wrapper extracted
+- Inner: 783 chars; source `9e78b931b4c73c4fa061c49db1121b77958f68707520b3ba33ffeffba819e3fe`; normalized `9e78b931b4c73c4fa061c49db1121b77958f68707520b3ba33ffeffba819e3fe`
+- Normalization: The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.
+- Concerns: None.
+
+**Old outer**
+
+The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production slice builds on it.
+
+**Proposed outer**
+
+The integration needed proof that the real chat panel accepts the stream produced by the harness. This spike exercises that path and records the resulting wire evidence before the production integration builds on it.
+
+### [#23](https://github.com/hashintel/brunch-lite/pull/23) — FE-1451
+
+- Title: `FE-1451: Keep issues, comments, and PRs easy to scan` → `FE-1451: Keep issues, comments, and PRs easy to scan`
+- Body changed: `true`
+- Extraction: outer canonical wrapper extracted; nested standalone wrapper tags removed from source inner
+- Inner: 2380 chars; source `7d0c7197002a2bd29907e73de006782e60a3104da9f54a8082d12c3d88fc3899`; normalized `14c689899a8f5687c0f26293949b64974adc409de4379339d847a0356991b723`
+- Normalization: Removed the nested standalone details opener and closer only. All non-structural bytes remain in source order; the final body has one canonical wrapper.
+- Concerns: None.
+
+**Old outer**
+
+Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.
+
+**Proposed outer**
+
+Agent-written issues, comments, and PR descriptions had become hard to scan. This branch sets a compact title format and a plain-language summary above collapsed agent working detail, then applies the rules to the issue that introduced them.
+
+### [#24](https://github.com/hashintel/brunch-lite/pull/24) — FE-1436
+
+- Title: `FE-1436: The elicitor answers conversation turns in Petrinaut's real chat panel` → `FE-1436: Connect the elicitor to Petrinaut’s real chat panel`
+- Body changed: `true`
+- Extraction: single canonical wrapper extracted
+- Inner: 1147 chars; source `10e4f1c874197ab56e237d4d4ffbe11ff3b8a286a3b0a7f3036cdbc4a23ff8aa`; normalized `10e4f1c874197ab56e237d4d4ffbe11ff3b8a286a3b0a7f3036cdbc4a23ff8aa`
+- Normalization: The inner record is unchanged; the outer was revised to remove an avoidable banned-word use.
+- Concerns: None.
+
+**Old outer**
+
+The spikes proved the required seams separately, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.
+
+**Proposed outer**
+
+Separate spikes proved Flue suspension and AI SDK panel streaming, but the elicitor still needed to answer real chat turns in the target panel. This branch connects that path and preserves the evidence needed to verify completed, failed, and cancelled turns.
+
+### [#25](https://github.com/hashintel/brunch-lite/pull/25) — FE-1449
+
+- Title: `FE-1449: A structured brunch question suspends and resumes visibly in Petrinaut` → `FE-1449: Prove a structured brunch question suspends and resumes in Petrinaut`
+- Body changed: `true`
+- Extraction: whole source body treated as authoritative inner record and wrapped once
+- Inner: 2146 chars; source `37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851`; normalized `37dedf722f51fb6dd12e5e690a1f843040a5c84edf5d8ed8187ee386980d3851`
+- Normalization: Added one canonical Agent-notes wrapper around the unchanged source body.
+- Concerns: None.
+
+**Old outer**
+
+_(none)_
+
+**Proposed outer**
+
+This branch keeps a structured brunch question open on the AI SDK wire and resumes the same Flue conversation when the matching human answer arrives through the committed application route. It validates the reply against durable conversation history and rejects stale, duplicate, forged, malformed, and machine-only submissions before dispatch. Petrinaut component registration through FE-1448 remains required for full acceptance.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1357.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1357.md
new file mode 100644
index 00000000000..93e5c3dab47
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1357.md
@@ -0,0 +1,508 @@
+# Linear migration review: FE-1357
+
+Generated `2026-08-20T09:04:00.141915Z` from `data/linear-source.json`. Selected 29 Lu Nelson-authored issues whose ultimate ancestor is FE-1357.
+
+## FE-1357
+
+**Title:** Plan the September elicitation demo and the plugin spec behind it (wayfinder map) → **Plan the September elicitation demo and plugin specification**
+
+**Current outer**
+
+In mid-September HASH demos to the ARIA research community. On stage, an AI interviewer holds a conversation with someone who knows how a real-world operation works — a truck fleet, a cold chain, a schedule — and turns what they say into a process model: a diagram of the operation that can be opened, inspected, and _run_ in Petrinaut, HASH's process-modelling tool. Along the way the interviewer keeps a record of exactly who said what (so every part of the model can be traced back to a statement), knows what it still hasn't asked about, and produces a model file anyone can open — three things no current tool in the stack does.
+
+This issue is the planning map for that demo: each decision that must be made before serious building starts is a sub-issue below, and the sections after the divider index what's decided and what's still open. Status: the groundwork research is done, and three big decisions have landed — the demo will be a purpose-built demo app that uses a new interviewing library and Petrinaut's existing libraries side by side, passing a model file between them, rather than building the interviewer into Petrinaut itself (2026-08-12); the demo's reference use case is truck-fleet predictive maintenance (recommended to the team, ratification expected ~18 August), with the interviewee played from a prepared briefing rather than requiring a live domain expert (2026-08-12); and the form interview knowledge is stored in is settled (2026-08-13) — the store is the set of recorded, source-traceable statements the expert made, and the runnable diagram is one view generated from it, so everything an expert says that has no place in a diagram (reasons, policies, unwritten rules) is kept rather than lost. Next: pressure-test that storage definition against more plugin kinds, then write the plugin spec once the team ratifies the use case. Planning documents live in the brunch-lite repo under `docs/planning/process-model-elicitation/`.
+
+**Proposed outer**
+
+This map coordinates the decisions and evidence required for the 17–18 September demo and the process-model elicitation plugin behind it. Research, baseline work, the intermediate representation, and the original demo architecture have been decided, while later records replace the separate demo application with a remote elicitor inside Petrinaut’s chat panel. The current work is to validate plugin payloads, complete the plugin specification, and deliver the revised integration graph without losing source traceability or completion accounting.
+
+**Extraction:** `standalone-divider`
+**Inner:** 16644 characters; `aae3d23e453ffdad8853d49f9a56a927fb65e66950beaf0edbeb949cab26a33f`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1358
+
+**Title:** Survey Petrinaut — architecture, dependencies, assistant implementation → **Survey Petrinaut for the September integration**
+
+**Current outer**
+
+Before deciding how the September demo would be built, we needed a clear picture of Petrinaut — HASH's process-modelling tool — and of the AI assistant it already ships. The survey found that Petrinaut is published as two reusable libraries; that it already has a production-ready way to import a model from a file (currently hidden in HASH's embedding of it); and that its existing assistant can interview a user but keeps no record of who said what, cannot run outside the browser, and produces models that need a separate "scenario" before they can run. These facts became the backbone of the demo-vehicle decision (FE-1362). Full findings: `docs/planning/process-model-elicitation/research/petrinaut-survey.md` (brunch-lite repo); conclusions in the resolution comment.
+
+**Proposed outer**
+
+Document Petrinaut’s architecture, dependencies, assistant, persistence, and model-file boundary so the demo can choose between embedding brunch in Petrinaut and embedding Petrinaut in a separate elicitation application. The completed survey found reusable libraries and a production model import path, but no provenance, headless execution, or directly runnable assistant output. Those findings informed FE-1362’s original demo choice and the later integration decision.
+
+**Extraction:** `standalone-divider`
+**Inner:** 1135 characters; `84fd8a05e509600d08ac36ed506cf7a1c3c6b278690717ed45ea64ef658faac2`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1359
+
+**Title:** Voice interviewing — bolt-on adapter or architectural rewrite? → **Decide whether voice changes the elicitor architecture**
+
+**Current outer**
+
+Could the September demo be voice-driven — the expert speaking rather than typing — without rebuilding the interviewer's architecture? Answer: yes, as a bolt-on. Buy speech-to-text and text-to-speech as separate services and attach them where the app takes turns with the user; an all-in-one "voice conversation" provider would take over parts of the system we need to own. Three tiers were scoped, from push-to-talk (days of work) to hands-free with a live results panel (weeks). Voice was later demoted to a conditional nice-to-have for September (FE-1362). Full findings: `docs/planning/process-model-elicitation/research/voice-feasibility.md`; conclusions in the resolution comment.
+
+**Proposed outer**
+
+Determine whether voice can attach to the text-and-event elicitor as speech recognition and synthesis, or whether interruption, live transcription, and structured questions require architectural changes. The completed research found a constrained add-on approach viable and scoped three levels from push-to-talk to hands-free interaction. FE-1362 later made voice a conditional September addition.
+
+**Extraction:** `standalone-divider`
+**Inner:** 1062 characters; `4cb05fb2319afdb541a245bdc4d881b63b460c287135d9826c09266e3bc14432`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1360
+
+**Title:** Ground elicitation strategy in the literature → **Derive elicitation guidance from published research**
+
+**Current outer**
+
+What does the research literature on interviewing experts — from simulation modelling, knowledge acquisition, and requirements engineering — say about how an AI interviewer should work? The strongest findings: start by eliciting the questions the model must answer, because they define both scope and "done"; structured interviews vastly outperform unstructured ones; ask for quantities as "how many out of 100…" rather than typical/fastest/slowest, which is measurably biased; and several published question catalogues can be imported wholesale. These findings shape the interviewer's design and back most of our recommendations on the PM checklist (PRO-98). Full findings: `docs/planning/process-model-elicitation/research/elicitation-strategy-literature.md`; conclusions in the resolution comment.
+
+**Proposed outer**
+
+Review expert interviewing, knowledge acquisition, requirements engineering, simulation modeling, and related literature for guidance that can become elicitor pack content. The completed research supports objectives-first interviews, structured question sets, less biased quantity prompts, and several reusable question catalogues. Its findings inform the interviewer design and recommendations on PRO-98.
+
+**Extraction:** `standalone-divider`
+**Inner:** 985 characters; `875e27ee8fcb11c912719fd097bab2cd09845c692b04b5f0e7f5cb23ce098a96`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1361
+
+**Title:** Baseline control — what does one-shot AI elicitation already achieve? → **Measure the one-shot AI elicitation baseline**
+
+**Current outer**
+
+Before claiming the new interviewer beats a plain AI chat, we need to measure what a plain AI chat already achieves. This prototype runs a one-shot "interview me and generate a model" baseline and catalogues the mistakes it makes. The result is both the demo's honest comparison point and a check that our design fixes the failures it claims to fix. Not yet started; the experiment design is below.
+
+**Proposed outer**
+
+The completed baseline measured what one-shot and lightly prompted AI elicitation already achieve before adding new interviewer machinery. A plain model already asked about objectives, probed unwritten rules, and kept an assumptions register, but neither tested condition could end the engagement: one deferred the deliverable and the other exhausted its budget. The transcripts and scored results now provide the comparison baseline and identify the remaining requirements for completion, durable capture, evidence status, provenance, coverage, projection, and explicit absence.
+
+**Extraction:** `standalone-divider`
+**Inner:** 820 characters; `9f35d242e30ca2005412e9e7a4e17828a9bdd9fc53a8c83774ba0e09895ab0a5`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1362
+
+**Title:** Decide the September demo vehicle → **Decide the September demo architecture**
+
+**Current outer**
+
+This ticket decided what the September demo actually is (resolved 2026-08-12): a purpose-built, throwaway demo app that uses a new interviewing library and Petrinaut's existing libraries side by side, passing a runnable model file between them — rather than building the interviewer into Petrinaut itself. The decision also set what must be visible on stage (traceable statements, the interviewer knowing what it hasn't asked, a live results panel, the model file opening and running) and demoted voice to a conditional extra. Reasons and evidence: `docs/planning/process-model-elicitation/recommendation-demo-vehicle.md` (brunch-lite repo); full record in the resolution comment.
+
+**Proposed outer**
+
+This issue originally chose a separate throwaway demo application that combined a new interviewing library with Petrinaut libraries through a runnable model file. It also set the required stage-visible behavior and made voice conditional. ADR-0004 and FE-1433 later replaced that staging choice with integration inside Petrinaut’s existing chat panel, so the historical decision remains authoritative only as the earlier record.
+
+**Extraction:** `standalone-divider`
+**Inner:** 1001 characters; `43811604f679479aa4fb89ac0155eaf6c6a0c6a4f15c57b709090574523a8aa2`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1363
+
+**Title:** Choose the reference use case; settle the SDCPN-showcase criterion → **Choose the demo use case and modelling criteria**
+
+**Current outer**
+
+Which real-world operation should the September demo model — a truck fleet, a cold chain, a scheduling problem? The choice needs a story a live audience can follow in minutes, a willing expert to interview, and enough substance to show off what makes the approach special (timing, quantities, and randomness where the model genuinely earns them). Needs input from Dora and Yannis. This is the next open decision on the map, and it unblocks the data-representation question (FE-1364).
+
+**Proposed outer**
+
+Truck Fleet Predictive Maintenance is the engineering recommendation for the September demo because it supports timing, quantities, randomness, and dynamic colouring in a story the audience can follow. The selection criterion now requires each formal feature to answer a real modelling question. Pharmaceutical cold chain is the runner-up pending a source-sharing check, while production scheduling remains a baseline rather than the showcase. Team agreement from Dora and Yannis remains the final condition.
+
+**Extraction:** `standalone-divider`
+**Inner:** 1023 characters; `27839c0e9cfe911dcc85bf70997c89f7405812e2679eb1ce25812227e90177b1`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1364
+
+**Title:** Define the intermediate representation for process-model elicitation → **Define the process-model elicitation representation**
+
+**Current outer**
+
+The interviewer doesn't write straight into the model file. It accumulates what it learns in an intermediate representation — the knowledge store the final model is generated from — because much of what an expert says (reasons, unwritten rules, references, policies) has no place in the diagram itself but must not be lost. This ticket decides what that representation is. Blocked until the reference use case (FE-1363) is chosen, since the use case stresses what the representation must hold.
+
+**Proposed outer**
+
+The representation is conditionally defined as the active captures interpreted through each plugin's declared payload types. Consolidated views, including the Petrinaut net, are projections rather than a second store, so source-traceable statements, reasons, policies, and unwritten rules remain available even when the diagram cannot hold them. The definition covers ten process-model assertion kinds and keeps quantities, rationale, and prescribed-versus-practiced distinctions with the evidence. FE-1397 now owns validation against worked payloads before ratification.
+
+**Extraction:** `standalone-divider`
+**Inner:** 921 characters; `173130b0bec025f2e42d4f80764355fedea1872503d21afec834a0ea2738d585`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1382
+
+**Title:** Source dossier: published fleet-maintenance models + operational data for the truck-fleet case → **Compile the truck-fleet source dossier**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Find published fleet-maintenance models, public operational data, and practitioner evidence sufficient to author the truck-fleet situation pack, reference net, and answer key without a live expert. Record licenses and granularity, and pay particular attention to models of per-vehicle degradation. The dossier resolves the sourcing part of FE-1363; situation-pack authoring waits for team feedback on PRO-99.
+
+**Extraction:** `heading-first`
+**Inner:** 1777 characters; `98a2f626e1fc039a1f81b0d0fa6ecdf6a39c1fa525a4494097e78c3fb3688c34`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1397
+
+**Title:** Validate the generic IR definition against worked payload designs (Gherkin, CPS, +1) → **Validate the generic IR against worked plugin payloads**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Test the generic intermediate-representation properties against payload designs for Gherkin, CPS, and a third plugin target. Record which properties survive, require amendment, or belong in guidance, including cases where domain content should move into the harness. Apply the resulting changes to `ir-design.md`; working-harness validation remains later September work.
+
+**Extraction:** `heading-first`
+**Inner:** 1397 characters; `676e3faa8b8d4801db351f8c82bdf8899036df30c8a5b2789d9a3f3e2b2ca534`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1402
+
+**Title:** Decide when an elicitation is complete or should stop → **Define and rehearse the elicitation completion contract**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+The baseline could report coverage but could neither decide that an engagement was complete nor stop when progress stalled. Draft the completion computation, then replay it exchange by exchange over both baseline transcripts to test whether it catches the observed deferral loop, open-ended continuation, and missing coverage. Keep model completion distinct from a user choosing the best useful partial result within the available session.
+
+**Extraction:** `heading-first`
+**Inner:** 2620 characters; `0443796ebe3de81af985a3621799610618b8f020b26ee7e4558e237ea1752df1`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1403
+
+**Title:** Assemble the CPS pack's interviewing guidance and desk-test it where the baseline was weak → **Assemble and test the CPS interview guidance**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Turn the imported interviewing research into CPS question guidance and clarification hints that target the payload fields from FE-1405. Compare every item with the baseline transcripts and retain guidance that addresses observed weaknesses rather than repeating behavior the model already performs. Tag domain-specific and envelope-wide guidance separately so FE-1406 can later adopt reusable items.
+
+**Extraction:** `heading-first`
+**Inner:** 2864 characters; `0f8b52a00cb0756e5a5175f053ee2911bca209347466334d61f9f7607f78ccdc`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1404
+
+**Title:** Run the armed baseline (condition 3): completion contract and pack guidance against the simulated expert → **Run the third baseline with completion and interview guidance**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Run a third simulated-expert baseline using the drafted completion contract, the surviving interview guidance, and the three corrections identified by the earlier readout. Score it against the same measures as conditions one and two to test whether the interviewer ends, reprioritizes, and refuses unproductive deferral before the harness exists. Durable capture, enforced epistemic status, and provenance remain expected implementation work outside this experiment.
+
+**Extraction:** `heading-first`
+**Inner:** 1958 characters; `f88abfbaa37d65613194b26c3c52b12356af84b1bd39e5b8b062b86d03fefd85`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1405
+
+**Title:** Draft the CPS payload interiors: annotated shapes for the ten kinds, worked from baseline utterances → **Draft and test the CPS payload schemas**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+The generic intermediate-representation work names ten CPS capture kinds but does not define their fields or worked instances. Draft annotated payload schemas for all ten kinds and test them against real baseline utterances, including absence values, quantity ranges, operating-regime distinctions, and multiple captures from one utterance. Fields must match answers an expert can give rather than Petrinaut’s model format, because FE-1402 and FE-1403 depend on field-level gaps.
+
+**Extraction:** `heading-first`
+**Inner:** 2708 characters; `42b2be3331cc53b8d4f319769fc410edee6afe23b96111e1f79cc3adf9c59785`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1407
+
+**Title:** Catalogue the frontier-elicitor failure modes the published instruments cannot see → **Catalogue elicitor failures that published measures miss**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Published measures built around human novice errors scored the baseline almost clean while missing the failures the frontier-model elicitor produced. Build a typed catalogue from both baseline transcripts and relevant literature, with each failure’s mechanism, detection signature, accountable layer, and prevention claim. Distinguish useful deferral that deposits durable state from evasive deferral that loses work, so later scoring does not punish correct multi-session behavior.
+
+**Extraction:** `heading-first`
+**Inner:** 3707 characters; `147f3f51d5bb84c4d365fcbeb62793a602f48218bcfa36358fb2179f38e737cd`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1423
+
+**Title:** The demo shell is safe to expose beyond localhost → **Require safe remote access to the elicitor server**
+
+**Current outer**
+
+The mounted Flue agent route is public today: anyone who can reach the server can open or continue conversations under any conversation id. That is fine on localhost and disqualifying the moment the URL leaves the machine. This ticket carries the gates that must hold before the demo shell is exposed beyond localhost. It blocks remote exposure, not the demo itself.
+
+Origin: the Flue-vs-tilde analysis's recommended course (`docs/reference/amp-analysis-flue-vs-tilde.md`), carried through the architecture cheatsheet's reconciliation section (`docs/planning/_shared/flue-architecture-cheatsheet.md`) and the routing table's pre-remote row (`docs/agents/flue-routing.md`), and tracked as Ledger A10 in `docs/planning/legibility-sweep/remediation-plan-2026-08-17.md`. On 2026-08-17 Lu ratified these as **requirements**, not recommendations — a demo deployment conversation with infra is already underway, so the gates are schedule-relevant now.
+
+**Proposed outer**
+
+The mounted Flue agent route currently lets any caller open or continue any conversation ID, which is acceptable only on localhost. Before remote exposure, require authentication and conversation authorization, runtime telemetry, persisted-state versioning and backup expectations, and restart durability. Lu ratified these requirements on 2026-08-17, and the deployment discussion makes them schedule-relevant.
+
+**Extraction:** `manual-summary-before-heading`
+**Inner:** 1378 characters; `079839429dcfb3258dbbfe9fea16433185391f7444d7cd2b14a58dd720e5c06b`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1431
+
+**Title:** Plugin authoring becomes declarative: a domain is two schemas and two tables → **Define declarative plugin authoring**
+
+**Current outer**
+
+Today every new elicitation domain looks like an engineering project: the capture store says how evidence is kept, but nothing says what a domain author must write down to make the machinery elicit _their_ domain, and nothing turns a pile of typed captures into the thing the user wants — a model of their plant, their feature, their system. Completion questions ("is this model good enough to answer my objective?") have no model to be asked of, and semantic judgments risk hiding inside read paths where nobody can audit them.
+
+The FE-1405 shapes work settled an answer, now written up as a provisional spec: a plugin is **two schemas and two small tables** — declare your domain's node kinds and slots, declare the typed proposals that fill them (annotated with how to elicit each), and say what your completion anchors demand; fold rules mostly derive. The elicited model is derived from captures by a pure fold (ADR-0003), all interpretation happens at write time as contestable captures, and model gaps mechanically cue grounded follow-up candidates. Interviewing strategy decides whether to ask, propose a likely structure for correction, or leave a visible gap. The spec is desk-validated on the baseline transcripts and cross-plugin thumbnails (Gherkin, formal verification, CPS); its ratification condition is a full worked pass across three plugin targets, and its open questions are carried as first-class sections with owning tickets rather than folded into the design.
+
+**Proposed outer**
+
+New elicitation domains currently require bespoke engineering, and the system lacks a declared path from source-traceable captures to a useful domain model and completion judgment. The provisional plugin contract reduces authoring to two schemas and two small tables, with interpretation recorded when captures are written and model views derived later. Ratification still requires a full worked pass across three plugin targets, and named tickets own the remaining questions.
+
+**Extraction:** `standalone-divider`
+**Inner:** 1766 characters; `b083c6e46567b897ac8923940a7badd8c37ffd70b3c8fde9b8bfde724ac54432`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1433
+
+**Title:** The elicitor serves demo.petrinaut.org's chat panel from a remote brunch-agent server → **Deliver the remote Petrinaut elicitor integration**
+
+**Current outer**
+
+The 2026-08-18 integration meeting settled the September demo's staging: the elicitor is presented inside [demo.petrinaut.org](http://demo.petrinaut.org)'s existing chat panel, not in a separate demo application. The brunch elicitor therefore runs as a remote server that Petrinaut's chat UI talks to through its host-pluggable transport, with the elicitor's sessions, captures, and IRs persisted server-side and keyed to the visitor's browser. The library is renamed `@hashintel/brunch-agent` and will be imported (with git history) into the `hashintel/hash` monorepo as a sibling of `@hashintel/petrinaut` once the currently open PRs merge.
+
+This issue carries the integration spec for that architecture. The decision itself is recorded in ADR-0004 (`docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md`), which supersedes the demo-shell recommendation (`docs/planning/process-model-elicitation/recommendation-demo-vehicle.md`). The spec document is at `docs/planning/process-model-elicitation/petrinaut-integration-spec.md` — seams, user stories, implementation and testing decisions, and the spike-gated questions.
+
+The two original spikes have now reported. Flue carries batched suspension through a non-user signal (FE-1434), and the AI SDK v6 wire shape drives Petrinaut's real panel (FE-1435). A third seam surfaced before implementation: Petrinaut's internal interactive-tool registry is not host-extensible, and a human answer returned through an AI SDK tool-output-shaped message must not be confused with a machine tool result. FE-1448 adds the generic host component mechanism; FE-1449 is the durable, visibly inspectable prototype that proves the actual brunch ask suspends and resumes without laundering provenance.
+
+Related: FE-1333 (the integration-definition ticket this spec answers; closes on the ADR), FE-1357 (parent map).
+
+**Proposed outer**
+
+The September demo will present the elicitor inside demo.petrinaut.org’s existing chat panel, with a remote brunch-agent server holding browser-keyed sessions, captures, and intermediate representations. ADR-0004 records this decision and replaces the earlier separate demo application recommendation. The two original feasibility tests passed, while FE-1448 and FE-1449 now own the newly discovered host-component and human-answer provenance work.
+
+**Extraction:** `standalone-divider`
+**Inner:** 2951 characters; `efbb2e84cf944b655703e32a9805677f250dee50e840d19aaa6c199300bc07fc`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1434
+
+**Title:** Spike: does Flue turn suspension carry batched client-tool round-trips? → **Test whether Flue resumes batched client-tool results**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Determine whether Flue can end a turn with pending client tools and later resume the same session with batched outputs recorded as non-user entries. The verdict will shape both the external-tool protocol and FE-1395’s questionnaire chaining. If Flue cannot carry this form, select the document-handle fallback for the demo and record evidence for a second binding.
+
+**Extraction:** `heading-first`
+**Inner:** 1855 characters; `fac188333116b05f6764814ccb6ed97bd003e182bc45132c2d39c932440b5bb2`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1435
+
+**Title:** Spike: does a harness-driven stream drive Petrinaut's real chat panel? → **Test whether the elicitor stream drives Petrinaut’s chat panel**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Test whether a server that translates harness output into the AI SDK v6 stream protocol can drive Petrinaut’s real panel, including text, reasoning, tool summaries, client tool calls, and diagnostics. This is a throwaway integration test against a local hash checkout, with no commits there. Preserve the full request and stream transcript as fixtures for later contract tests.
+
+**Extraction:** `heading-first`
+**Inner:** 1561 characters; `a157fa152e18f4783339cc49e56ac61a608e57ce097cac34502e7a3acec17698`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1436
+
+**Title:** The elicitor answers conversation turns in Petrinaut's real chat panel → **Connect the elicitor to Petrinaut’s real chat panel**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Build the first durable integration in which a local Petrinaut panel holds a text-and-reasoning conversation with the actual elicitor. Commit the server route, launch path, AI SDK transport, contract fixtures, and runtime diagnostics as production-intent code that later question and editor-tool work can reuse. Diagnostics must expose request and turn boundaries, part kinds, stable IDs, and completion state without becoming user evidence.
+
+**Extraction:** `heading-first`
+**Inner:** 2438 characters; `b07965244f137a1844adffb0b30dce5130cd4e8555f2e139579a6bc8456d0e69`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1437
+
+**Title:** @hashintel/brunch-agent lives in hashintel/hash with its history preserved → **Move brunch-agent into hashintel/hash with its history**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Rename the library to `@hashintel/brunch-agent` and import it into `hashintel/hash` with history preserved, as a sibling of `@hashintel/petrinaut`. The move waits for FE-1434 and FE-1435 to report and for the open FE-1388/89/90/99 review stack to merge. The imported package must adopt the hash toolchain while preserving the boundary between brunch-agent, Petrinaut, and their host applications.
+
+**Extraction:** `heading-first`
+**Inner:** 1493 characters; `cbe7b6d050e3486f8e1649848516b240c282e85f601a56f693f095059902a476`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1438
+
+**Title:** The elicitor builds and repairs the net through Petrinaut's client-executed tools → **Build and repair Petrinaut nets through client tools**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Answers in the elicitor must create and change the net on Petrinaut’s canvas through Petrinaut’s existing client-executed tools. Add an external-tool round-trip protocol beside the question protocol, generate tool definitions from Petrinaut’s exported schemas, and keep returned outputs mechanically excluded from user evidence. FE-1434 determines the batching shape, and this work must coordinate with FE-1395 because both change the same pending-response rules.
+
+**Extraction:** `heading-first`
+**Inner:** 2252 characters; `4b1de406e41f3b22fd6fa75888723caa04bceb2fd97bf01d359a4f52cb9a8c0f`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1439
+
+**Title:** Elicitation sessions are private per browser and survive a reload → **Keep elicitation sessions private and durable per browser**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+An elicitation must survive a reload while remaining inaccessible to another browser. The demo site will send a random browser identifier, the server will resolve it to sessions, and storage will enforce an opaque owner key without adding principals to the harness core. This identification is sufficient for the accepted demo threat model, while deployment separately owns rate limits and the origin allowlist.
+
+**Extraction:** `heading-first`
+**Inner:** 1644 characters; `c98a5d0620887f1d30a07eb63f16d2d76d7dace03784a3b3d11e63f3874a8d5f`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1440
+
+**Title:** demo.petrinaut.org ships the elicitor behind its chat panel → **Ship the elicitor in demo.petrinaut.org’s chat panel**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Add a real elicitor mode to demo.petrinaut.org by committing the local integration wiring, browser identifier setup, and remote transport to hashintel/hash. Keep brunch-specific code at application level and leave the stock assistant unchanged when the mode is off. The process-model plugin supplies later demo content, but this wiring can be completed and verified independently.
+
+**Extraction:** `heading-first`
+**Inner:** 1646 characters; `697595134f5edfbfb98ca3046f039abca72047f4bf214916d4abcff9d41f04e5`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1441
+
+**Title:** The elicitor server runs on HASH infrastructure behind the pre-remote gates → **Deploy the elicitor server behind the remote-release checks**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Run the elicitor server on HASH infrastructure with Postgres storage, per-principal and per-IP rate limits, and an origin allowlist. Infrastructure has confirmed that Postgres is available, but the server must remain private until FE-1423’s authentication, durability, telemetry, state-versioning, and backup requirements hold. Record the deployment host, CI, and backup expectations with the infrastructure work.
+
+**Extraction:** `heading-first`
+**Inner:** 1601 characters; `2ddc691ac9f44ccc31fab6071cefa9c67942c94a358e3f4805da80d61fc19eb0`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1442
+
+**Title:** Captures and completion accounting render live in the demo site → **Show live captures and completion accounting in the demo**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+The demo must show the elicitor’s source-traceable captures and completion accounting while an interview runs, because the existing prompt-in-a-panel experience cannot show either claim. Decide whether this UI belongs beside the panel or in a generic Petrinaut extension once the wiring exists. The process-model plugin will deepen the accounting later, but harness captures and derived completion already support this task.
+
+**Extraction:** `heading-first`
+**Inner:** 1355 characters; `864ae481d518556b75611b62baf28fb2de7df4d8db340d87de86942ccea9130f`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1448
+
+**Title:** Petrinaut hosts render their own interactive chat tools → **Let Petrinaut hosts render interactive chat tools**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+Petrinaut’s chat panel can render its own interactive tool, but hosts cannot register equivalent tools because the registry is private and fixed. Add a typed public extension for host-provided parsers, components, and submitted outputs, and prove it with tests and a runnable example. Existing tools must retain their behavior, unknown tools must still fail loudly, and the product code must remain free of brunch-specific details.
+
+**Extraction:** `heading-first`
+**Inner:** 1998 characters; `d3722991fd835760a4d8a24c5822e68439a3860fb2308a354812cfafea0bf73e`
+**Ambiguity:** None
+**Banned-word matches:** None
+
+## FE-1449
+
+**Title:** A structured brunch question suspends and resumes visibly in Petrinaut → **Prove a structured brunch question suspends and resumes in Petrinaut**
+
+**Current outer**
+
+_None; the source body is retained as the inner record._
+
+**Proposed outer**
+
+The next working prototype must connect the actual brunch agent to Petrinaut’s chat panel through the existing structured question flow. A correlated human answer must resume the same Flue conversation, while stale, forged, duplicate, unrelated, and machine-generated outputs remain excluded from user evidence. The committed prototype must also make question state, correlation IDs, suspension, return, and resumption visible without feeding diagnostics into evidence.
+
+**Extraction:** `heading-first`
+**Inner:** 2980 characters; `acd7ce7b5b6bf664d57404bd478ac63a98039fa232ad5832d2706f11a3a4dbd0`
+**Ambiguity:** None
+**Banned-word matches:** None
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1366.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1366.md
new file mode 100644
index 00000000000..865e040b24f
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1366.md
@@ -0,0 +1,231 @@
+# Linear migration review: FE-1366
+
+Generated: 2026-08-20T09:03:27.215678Z
+Issues: 14
+Banned-word scan: no exact matches in any proposed title or outer section.
+
+## FE-1366
+
+**Title:** Spec the elicitation harness architecture (archived wayfinder map) → Document the elicitation harness architecture
+
+**Current outer**
+
+This is the completed planning map for the **elicitation harness**: the architecture that generalizes brunch's AI interviewer into a reusable library, able to interview people about different kinds of subject matter through pluggable target definitions — so the same interviewing machinery can produce, say, software specs in one setting and process models in another. Planning finished on 2026-08-10; the outcome is a reviewable specification, in the brunch-lite repo at `docs/planning/elicitation-kernel/spec.md`, alongside a plain-language product description. The build, and the September demo that motivates it, are planned on the successor map FE-1357.
+
+Everything below the divider is a verbatim mirror of the map as it was worked in repo markdown, kept for team visibility.
+
+**Proposed outer**
+
+This completed planning map defines an elicitation harness that turns the existing AI interviewer into a reusable library for different subject areas. Planning finished on 2026-08-10 and produced `docs/planning/elicitation-kernel/spec.md` plus a plain-language product description. FE-1357 plans the build and the September demo that depends on it.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 21791 characters; SHA-256 `5dc0886da2a1b3b2373a1e3f0e172b2adb805003a15aa782200015be298fbd56`
+**Ambiguity:** None
+
+## FE-1367
+
+**Title:** Flue architecture deep-read [archive] → Define how the elicitation harness uses Flue
+
+**Current outer**
+
+Read Flue — the web/agent framework the interviewing library runs on — closely enough to know how the library should ship on it. Conclusion: embed as a library inside a host-authored app, which is Flue's natural grain; Flue has no built-in "pause and ask the user" facility, so the library owns its own turn-taking mechanism. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This research determined how the interviewing library should run on Flue. The library belongs inside a host-authored app, and it must manage conversational turn-taking because Flue does not provide a built-in way to pause and ask the user. The research was resolved on 2026-08-06 as part of the completed elicitation-harness plan.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 19780 characters; SHA-256 `6d565c7365ebc78f76a053a624703acd07ac03cb40a6c8cb3c127bc0de30a087`
+**Ambiguity:** None
+
+## FE-1368
+
+**Title:** zil-lean survey [archive] → Assess zil-lean as an elicitation subject
+
+**Current outer**
+
+Examined zil-lean, a prototype claim-graph system, as a candidate second practice subject for the interviewing architecture. Conclusion: it contains no interviewing itself, but it is a working proof of the claim-graph idea; a smaller "assurance argument" slice was chosen as the second subject instead of the full system. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This research assessed zil-lean, a prototype claim-graph system, as the second subject for testing the interviewing architecture. zil-lean does not include interviewing, but it demonstrates the claim-graph model. The plan therefore chose a smaller assurance-argument subject instead of the full system and resolved the research on 2026-08-06.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 18905 characters; SHA-256 `ae5914e467433c3a0002f56350c81322249cc6eb04ab971cf4371f994ab35d26`
+**Ambiguity:** None
+
+## FE-1369
+
+**Title:** Brunch exchange-schema audit [archive] → Classify Brunch exchange structures for reuse
+
+**Current outer**
+
+Catalogued how the existing brunch app structures its question-and-answer exchanges, sorting every part into keep / adapt / leave behind for the new library. The generic asking machinery survives; brunch-specific vocabulary and review structures do not. Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This audit classified each part of the existing Brunch question-and-answer exchanges by whether the new library should keep, adapt, or leave it behind. The generic asking machinery remains useful, while Brunch-specific vocabulary and review structures do not carry forward. The audit was resolved on 2026-08-06.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 24404 characters; SHA-256 `09086b43d756206ba140c9019b0a1b0d89cb74d9783bfede2317e047e884e130`
+**Ambiguity:** None
+
+## FE-1370
+
+**Title:** Contract decomposition: kernel / host / plugin / pack boundary [archive] → Define the harness and plugin responsibilities
+
+**Current outer**
+
+Decided how responsibility splits between the generic interviewing engine and the pluggable subject-matter definitions. The engine owns a domain-free envelope around whatever a plugin stores — with evidence links, confidence, and explicit "no answer" states — and typed issues as its feedback channel; there is deliberately no universal data model. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This decision assigns responsibilities between the generic interviewing engine and the subject-matter plugins. The engine owns a domain-free envelope for plugin data, including evidence links, confidence, explicit absence states, and typed issues for feedback. The design does not impose one universal data model and was resolved on 2026-08-07.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 10944 characters; SHA-256 `a8617883eff469f2b9a5dce712067f072907d7ca666141998a19d46323477384`
+**Ambiguity:** None
+
+## FE-1371
+
+**Title:** Questioning-UX contract [archive] → Define structured questions within conversation
+
+**Current outer**
+
+Decided how structured questions live inside a free-flowing conversation: the conversation stays primary, forms and choice strips are dropped into it as interactive elements, and captured knowledge is extracted afterwards in repeatable sweeps rather than question-by-question. Also fixed the system's four-layer naming (substrate / ui / harness / plugin). Resolved 2026-08-06; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This decision keeps free-flowing conversation primary while placing forms and choices within it as interactive elements. The system extracts captured knowledge through repeatable range sweeps after the conversation rather than after each question. It also establishes the four component names: platform, UI, harness, and plugin. The decision was resolved on 2026-08-06.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 9887 characters; SHA-256 `6abd613018b32d1ce53af2ef93b056e10c3c89ad68f43950a792f102edfb5db3`
+**Ambiguity:** None
+
+## FE-1372
+
+**Title:** Shipping shape: kernel library vs. Flue agent [archive] → Choose how the elicitation harness ships
+
+**Current outer**
+
+Decided what actually ships: a harness library inside a thin host-authored agent — not a standalone product — organized as a workspace monorepo with the plugin SDK as its public surface, and tested by generated, replayable interview fixtures rather than live model calls. Resolved 2026-08-08; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This decision makes the deliverable a harness library inside a thin host-authored agent rather than a standalone product. A workspace monorepo exposes the plugin SDK, and generated replayable interview fixtures test the system without live model calls. The decision was resolved on 2026-08-08.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 12470 characters; SHA-256 `92eed4355aa2a82a0ba5d4e65d53ac27de767087bbce2f98c387b70f0d9e3478`
+**Ambiguity:** None
+
+## FE-1373
+
+**Title:** Dev-target portfolio confirmation [archive] → Choose the initial elicitation subjects
+
+**Current outer**
+
+Confirmed the two practice subjects the architecture is built against — Gherkin scenarios and assurance arguments (BPMN third) — because building two very different subjects at once forces the plugin model to stay genuinely general. Resolved 2026-08-07; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This decision selects Gherkin scenarios and assurance arguments as the two initial subjects, with BPMN third. Developing two different subjects together tests whether the plugin model remains general. The decision was resolved on 2026-08-07.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 4404 characters; SHA-256 `af4bb40e8c7c41c4f1c03c942e33f45a93b4934d3850af95029ff474e268a702`
+**Ambiguity:** None
+
+## FE-1374
+
+**Title:** Assemble the spec [archive] → Assemble the elicitation harness specification
+
+**Current outer**
+
+The destination of the whole planning effort: assembled the full specification from every resolved ticket — fourteen sections plus an appendix of adjudicated contradictions. The spec lives at `docs/planning/elicitation-kernel/spec.md` (brunch-lite repo), with a companion plain-language product description. Resolved 2026-08-10; this closed the parent map.
+
+**Proposed outer**
+
+This task assembled the completed planning decisions into a fourteen-section specification with an appendix that resolves prior contradictions. The specification is at `docs/planning/elicitation-kernel/spec.md`, with a companion plain-language product description. It was completed on 2026-08-10 and closed the parent map.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 9377 characters; SHA-256 `4f36c5012d06ba284886145fb9fec5c92aa650338986366b9c619ef383874030`
+**Ambiguity:** None
+
+## FE-1375
+
+**Title:** Formal-verification canon survey [archive] → Align the assurance subject with verification practice
+
+**Current outer**
+
+Checked the second practice subject against the formal-verification literature. Verdict: "proof obligations" was the wrong name — a category error to verification readers — so the subject was renamed to the assurance argument, aligned to the GSN standard with vocabulary borrowed from Dafny. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This research compared the second practice subject with formal-verification literature. It found that “proof obligations” named the wrong concept for verification readers, so the plan renamed the subject “assurance argument” and aligned it with GSN and Dafny vocabulary. The research was resolved on 2026-08-10.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 19571 characters; SHA-256 `b3522ac5372aa5e91bac588fead9e7603c59d5fd669f256d1bc627d68a7e4b7a`
+**Ambiguity:** None
+
+## FE-1376
+
+**Title:** Walking skeleton: Flue question round-trip [archive] → Prove a Flue question round trip
+
+**Current outer**
+
+Built a working skeleton on real Flue proving a structured question can travel from the agent to the user and the answer back — with the discovered constraint that only one live question can be pending at a time, which became a rule in the spec. Code on branch `prototype/10-flue-roundtrip` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This prototype demonstrated that a structured question can travel from the agent to the user and return with an answer on Flue. It also found that only one live question can remain pending, which became a specification rule. The code is on branch `prototype/10-flue-roundtrip`, and the task was resolved on 2026-08-09.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 7972 characters; SHA-256 `c211016d13a5e46835dddd71c1c611027dc47df950221d50117a51e06622b450`
+**Ambiguity:** None
+
+## FE-1377
+
+**Title:** Logic-prototype: capture sweep & settlement [archive] → Prove repeatable conversation capture
+
+**Current outer**
+
+Built an isolated prototype proving the knowledge-capture mechanics: deciding when a stretch of conversation is ready to harvest, harvesting it repeatably without double-counting, recording "no answer" as real information, and correcting earlier captures without erasing history. Code on branch `prototype/11-capture-sweep` (brunch-lite repo). Resolved 2026-08-09; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This prototype demonstrated the knowledge-capture mechanics: deciding when conversation is ready to collect, collecting it repeatedly without duplicate records, treating an absent answer as information, and correcting prior captures without deleting history. The code is on branch `prototype/11-capture-sweep`, and the task was resolved on 2026-08-09.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 11032 characters; SHA-256 `98d7b96fd075a96786c314905d3c2fe3bcf5661d0f18ee234b167f21a7c02dbc`
+**Ambiguity:** None
+
+## FE-1378
+
+**Title:** Multi-session elicitation & durable target state [archive] → Define durable state across elicitation sessions
+
+**Current outer**
+
+Decided how work survives across conversations: a durable target-document holds all captured knowledge and the full session logs; individual chat sessions are transient, never formally close, and can always resume against the current state. Storage went to the platform adapter, not the plugin — flipping an earlier hypothesis. Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This decision makes the target document durable, including captured knowledge and complete session logs, while individual chat sessions remain temporary and resumable. It assigns storage to the platform adapter rather than the plugin, reversing the earlier hypothesis. The decision was resolved on 2026-08-10.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 7774 characters; SHA-256 `9c8b6e6bcc99322400c0c25629d1f0e4939e8496ba3dfb43cafe064b8144a4a2`
+**Ambiguity:** None
+
+## FE-1379
+
+**Title:** Walking skeleton: sweep seam on Flue [archive] → Prove the remaining Flue capabilities
+
+**Current outer**
+
+Built the second walking skeleton on Flue, proving the four remaining platform capabilities the spec depends on (knowing when to harvest, reading conversation history, injecting system notes, and safe storage under retries) — completing the evidence base for the spec. Code on branch `prototype/13-sweep-seam` (brunch-lite repo). Resolved 2026-08-10; part of the completed elicitation-harness planning (see parent map).
+
+**Proposed outer**
+
+This prototype demonstrated the four remaining Flue capabilities required by the specification: detecting when to collect knowledge, reading conversation history, injecting system notes, and storing data safely during retries. This completed the specification’s evidence base. The code is on branch `prototype/13-sweep-seam`, and the task was resolved on 2026-08-10.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 16760 characters; SHA-256 `6a1ed589c55484beda4a01d588643c6d5835b60653166b164c6a2cd13dc2f728`
+**Ambiguity:** None
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1383.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1383.md
new file mode 100644
index 00000000000..e42a427b76d
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1383.md
@@ -0,0 +1,363 @@
+# Linear migration review: FE-1383
+
+Generated: 2026-08-20T09:04:03.710797Z
+Issues: 19
+
+## FE-1383
+
+**Title:** Build the elicitation harness to milestone one — an interview that produces a validated artifact with per-value provenance → **Build the first complete elicitation interview**
+
+**Current outer**
+
+The [elicitation kernel spec](https://github.com/hashintel/brunch-lite/blob/main/docs/planning/elicitation-kernel/spec.md) is finished and reviewed, but nothing has been built — the repo holds planning documents and no code at all. Until that changes, the September demo has no library to consume: FE-1362 committed the demo to a purpose-built shell driving a new interviewing library, and this is that library.
+
+Milestone one is the walking version of the whole architecture. A person is interviewed in ordinary conversation; the agent captures what they said as evidence-anchored structured meaning; a plugin turns those captures into a real artifact — a Gherkin feature file for the first target — in which every value traces back to a verbatim quote, corrections never erase history, and anything that could not be represented is reported rather than dropped. The sub-issues below are vertical slices of that path, each one demoable or verifiable on its own.
+
+One capability is deliberately absent. The spec requires a second, harder target to stress the plugin contract before that contract is declared stable, and which target that should be depends on decisions still being resolved on FE-1357 — so the plugin interface stays explicitly unfrozen through this batch, and the last four tickets are a working plan rather than a settled one.
+
+**Proposed outer**
+
+The elicitation kernel is specified and reviewed, but the repository has no implementation. The September demo depends on this library to interview a person, preserve evidence and corrections, and produce a Gherkin artifact whose values trace to verbatim quotes.
+
+This milestone builds that complete path through independently verifiable sub-issues. The plugin interface remains unstable until FE-1357 resolves the harder second target, so the final four sub-issues remain a working plan.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 1289 characters; `dc692280cc915bda482146be207015d0dcdd034d4ad8fbd09d37c40b2b4897ee`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1384
+
+**Title:** Generative test corpus over the replay driver → **Generate replay tests for the harness rules**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+Earlier work has accumulated hand-written replay tests, while the ten harness rules are stated as properties. This task will derive generated conversations and values from plugin declarations, run the rules against those sequences without a model or runtime dependency, and retain reduced failures as regression cases.
+
+The amount of generation needed for milestone one, the role of offline model-generated fixtures, and the fixture refresh process still need decisions.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1849 characters; `dc23151710c724730fd5e28460cf1e18ad96ee9b6faf63acf4c4385c7b963ab8`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1385
+
+**Title:** Dev app — target gallery and diagnostic probe surface → **Expand the dev app into a target gallery and diagnostic view**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The dev app currently serves as a test UI. This task will make it support local development, side-by-side target demonstrations, and a diagnostic view of session state, tool traffic, suspensions, and injected signals.
+
+The required diagnostic depth, the timing of a gallery before a second target exists, and the actions a colleague must perform without help remain unsettled.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1674 characters; `1bd36079855c694a19c2c16781b8fe79cb03ea9ed3cd3bbce9b31f3ba0993cb4`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1386
+
+**Title:** Verify compaction leaves the durable entry projection intact → **Test durable history across transcript compaction**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The specification says transcript compaction may reduce model context without removing entries that evidence references resolve, but no test has crossed a real compaction boundary. This investigation will determine whether old evidence pointers and session state survive, then record either confirmation or the exact archive work the binding must perform.
+
+The test design depends in part on whether Flue provides a compaction definition.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1525 characters; `b032d11e90f77e094632a0437a00a3b19ba43f3b74d851fda5f9983d7059a675`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1387
+
+**Title:** Author the second pack and freeze the plugin contract → **Choose a second target and stabilize the plugin interface**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+Gherkin alone cannot establish a stable plugin interface because it does not exercise evidence grading, graph-shaped payloads, or derived domain labels. This task will build a harder second target through the same harness, record the interface changes it requires, and then judge the interface against the specified proof obligations.
+
+FE-1364 must first choose between the specified assurance-argument target and the demo's process-model target; that choice also determines whether this work is demo-critical.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 2091 characters; `0e246edd61bf61e1ca4ca67103d4f396f0d7b1d11611474727197431788ca94b`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1388
+
+**Title:** Scaffold the Bun workspace and prove the CI smoke → **Create the Bun workspace and enforce dependency boundaries**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The repository needs a Bun workspace that builds and tests from a clean checkout before feature work begins. This task will create the specified core, Flue binding, Gherkin plugin, and dev-app boundaries, then enforce their dependency direction in CI without model credentials or network access.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1419 characters; `5b79a1a15bf83d384bc11b114188db2252eeec734c0299f196f56f83c59a4d94`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1389
+
+**Title:** Walking skeleton — the harness asks a free-text question and binds the reply → **Implement the first suspended free-text question**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The harness needs to ask a free-text question, suspend the turn, receive a typed answer, and continue a real dev-app conversation. This task will move the proven prototype mechanism into the main workspace while keeping the question out of instructions and binding replies mechanically to the single pending affordance.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1681 characters; `3623852992eec05f9567c745d0d253773713feb486dbef929fc28db16f7a317c`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1390
+
+**Title:** Capture envelope, storage port, and the local capture store → **Implement capture history and local persistence**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The harness needs a local store for captures, corrections, contradictions, retractions, and resolution records that never overwrites history. This task will define the capture envelope and persistence port, derive status when reading, reject invalid lifecycle changes, and apply each sweep atomically without requiring a model or runtime.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1859 characters; `dce103e6c13f999a39d866e51e61826185cc97f34dd221baa2a8b8f55bf77826`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1391
+
+**Title:** Durable entry projection, harness-resolved anchoring, and the session-log archive → **Resolve evidence quotes to durable conversation entries**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+Captures must cite durable user entries, but the model is reliable with verbatim quotes rather than entry numbers. This task will resolve each quote against true user entries, reject missing or invalid evidence, retain every read entry in the archive, and keep cited entries retrievable independently of runtime history retention.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1778 characters; `464a7faf1c52aa7bbc16b542aee5d1085fff78cd671575e61dd832e2ec6295d0`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1392
+
+**Title:** Settlement trigger and sweep — the first captured statement → **Capture settled conversation statements safely**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The harness can ask questions but cannot yet turn a completed topic into stored meaning. This task will detect an unswept conversation range, let the agent judge whether it has settled, and store quote-anchored captures through an atomic operation that is safe to repeat. It will also preserve the high-water mark and report unanswered asks without blocking capture.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1623 characters; `7a58e8a4d7e8960c3b41b0b0a91396e7c14f002f3fbf68ec63aa3dfdc8e46b3b`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1393
+
+**Title:** Plugin SDK and the gherkin plugin — the first projected artifact → **Produce the first Gherkin artifact through the plugin SDK**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The first complete artifact should turn an interview about a feature into a valid Gherkin file and a typed report of information Gherkin cannot represent. This task will implement the pure plugin operations, injected harness context, authoring packs, validation, and failure atomicity needed for that path.
+
+The SDK remains unstable until a harder second target tests the interface.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 2214 characters; `eb4be2fba6a05bdbcdace930230c21ca24be097e2d707bcbf8441cebeb1367c8`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1394
+
+**Title:** Conflict, supersession, and the interpretation render → **Preserve conflicts until the user resolves them**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+When a person contradicts an earlier statement, both interpretations must remain visible until the person resolves the conflict. This task will store the alternatives and resolution evidence, distinguish correction paths, and render the harness's interpretation with uncertainty intact. It will also keep interactive questions separate from informational renders and distinguish answered, redirected, and unanswered outcomes.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 1847 characters; `59342c6a55a213c528d8566c757ac6a85af9a08819e19af57664798e93b8d2ef`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1395
+
+**Title:** The full affordance set — choices, questionnaire chaining, and the absence strip → **Add choices, questionnaires, and explicit absence replies**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+The harness currently has only free-text questions. This task will add single-choice, multi-choice, and locally chained questionnaires, plus explicit replies for unknown, inapplicable, and deferred answers.
+
+Because inbound replies are strings, the transport must distinguish a UI action from identical typed prose; clients that only render markdown will continue to produce honestly inferred absences.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 2031 characters; `2a5426c3cda4bfd5d3b5e7451880acfb2000efd8f906ae9512651fa23aa94d01`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1396
+
+**Title:** Re-entry briefing, resume reconciliation, and restart durability → **Restore interview context after resume and restart**
+
+**Current outer**
+
+_None; the source body starts with a heading and is preserved as the inner record._
+
+**Proposed outer**
+
+A returning interview must reflect captures, conflicts, unswept conversation, and a pending question that changed while the agent was away. This task will compute and inject that briefing, preserve all session state through restart, and prevent injected system facts from being cited as user evidence. Completion remains derived when reading, so a later correction follows the normal path.
+
+**Extraction:** `heading-first-whole-body-as-inner`
+**Inner record:** 2123 characters; `a107fcbcc646a6054c66bd208141252bda7298308546c689e1fcf9d0ff79d797`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1399
+
+**Title:** Make the CI gates and dev app fail loudly where review found they fail silently → **Fix verified silent failures in CI and the dev app**
+
+**Current outer**
+
+The FE-1361 code review swept the whole repo and verified five findings that fall outside that ticket's scope. Three sit in the merge gates themselves: the checks that are supposed to keep workspace boundaries honest can currently go red on an innocent comment-only edit, silently skip any newly added workspace group, and let a misspelled tool operation name compile — so the gates either cry wolf or pass vacuously, which matters most in a repo whose gates are its main safety net. The other two are silent-failure seams in the dev app: a route path duplicates the one identifier the codebase pins as never-drifting, and the production asset route serves a narrower set of files than the client build can emit, so the first added font or image would break production only. All five have verified failure scenarios; each fix is small and none blocks current work.
+
+**Proposed outer**
+
+The FE-1361 review confirmed five small failures outside that issue's scope. Three CI checks can reject harmless text, omit new workspace groups, or accept misspelled tool operations; two dev-app routes duplicate a pinned identifier or fail on asset types the client build may emit.
+
+This task will make those checks and routes report the verified failures without changing unrelated behavior; none currently blocks other work.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 1969 characters; `e7bbd746c9bcb2d4c9922968d638266edff9b833de4e22b655d8ac0ee22f3456`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1400
+
+**Title:** Close the review-found gaps where the gates, dev app, and baseline runner still fail silently → **Strengthen verification, dev storage, and the baseline runner**
+
+**Current outer**
+
+During the FE-1397 tie-off, a full adversarially-verified review of the branch stack's diff against main surfaced ten confirmed correctness findings plus a handful of cleanups — none in the FE-1397 docs themselves, all in earlier branches' work. The common thread is uncomfortable: several of the checks FE-1399 added _to make silent failures loud_ can themselves pass vacuously (a build-artifact witness matched by bootstrap code regardless of what got bundled, nested `test/` directories escaping every boundary invariant, a CI-gate check satisfied by commented-out gates, known-gap predicates that an empty stub file flips). Alongside those: the dev app's durable conversation store resolves its default path against the launch directory — the exact restart-durability failure the file's own comment says it exists to prevent — and the baseline runner can silently drop or truncate its main deliverable and dies on a single network blip hours into a paid run. The always-loaded agent instructions also still describe the triage roles as five verbatim labels, contradicting the rewritten triage doc's state/label mapping.
+
+This ticket bundles all fixes as one refactor, executed as small always-green commits: documentation truth first, then the test-integrity fixes (each proven by temporarily breaking the guarded property and watching the gate go red), then the one behavioral dev-app fix, then baseline-runner robustness, then the cleanup tail. Filed from the FE-1397 thread's review output; to be claimed and run in a follow-up session.
+
+**Proposed outer**
+
+The FE-1397 review confirmed ten correctness problems and several smaller cleanups in earlier branches. Verification checks can pass without testing the claimed property, the dev store can appear empty after launch from another directory, and the baseline runner can omit or truncate its artifact or stop after a transient network failure. The always-loaded triage guidance also contradicts the current state-and-label mapping.
+
+This task will fix those areas through small green commits, proving each strengthened check by making the guarded property fail temporarily. The official Anthropic SDK is preferred for runner retries and usage accounting, but a local retry implementation remains an acceptable fallback if the dependency is rejected.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 8174 characters; `aa47cdaca48abf4436fbda2ab03d226e6c93c97f1dc3d4ee6bf0e1ad66e92f29`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1419
+
+**Title:** Close the seams where the capture store and verification gates claim more than they enforce → **Align capture-store rules and verification claims**
+
+**Current outer**
+
+An inductive review of the open PR comments (2026-08-14) found two seams that still claim more than their implementations support. The capture store applies different rule sets at command time, persisted-parse time, and lifecycle-transition time — so a command can return success for a snapshot the next read rejects, and an open conflict can end up with no legal way to close. And the verification layer still infers runtime facts from source text: substring and regex proxies stand in for "the gap closed", "CI ran this gate", "this test is hermetic". Until these close, green gates and successful commands overstate what is actually guaranteed — the same silent-failure family the FE-1399/FE-1400 sweeps addressed, one level deeper (two of the queue's commits replace countermeasures FE-1400 itself introduced).
+
+The plan is a nine-commit queue that gives each contract one owner and makes negative results precise; it is authored and ready to execute.
+
+**Proposed outer**
+
+A review of open PR comments found that the capture store applies different rules when accepting commands, parsing persisted data, and changing lifecycle state. A successful command can therefore create data that the next read rejects or leave a conflict with no legal resolution. Verification checks also infer runtime behavior from source text, so green checks can overstate what ran.
+
+The prepared nine-commit plan assigns each rule one owner and replaces these proxies with precise negative results after FE-1390 and FE-1400 land.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 609 characters; `d5eac9c8540f56560f6533189b2bc55fd99ee58d3e3b9babb0cf7a1407f917d3`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1420
+
+**Title:** The affordance protocol survives retries, unknown forms, and abandoned asks → **Make affordance handling safe under retries and abandonment**
+
+**Current outer**
+
+The FE-1389 deep-read (notes/deep-read-fe-1389.md, from the FE-1401 remediation sweep) found three places where the new ask/affordance protocol fails unsafely rather than safely. Flue re-executes tools at-least-once, and a re-executed ask mints the identical affordance — but the pending-slot guard checks only that the slot is occupied, so a benign retry is refused as if the model had asked a second question. The dev UI validates the whole concrete free-text form and renders nothing on a parse failure, so the first affordance of any other form will blank instead of falling back to the markdown floor the spec requires (§7.2/§7.7 — the envelope needs its own schema with the payload opaque). And an ask whose reply never arrives occupies the slot forever: nothing records an `unanswered` outcome (§7.5) and no advisory reports the stuck state (§8.6), so every later ask is refused silently.
+
+None of these blocks the walking skeleton — they are the hardening it deliberately deferred — but the retry refusal will start firing as soon as anything (like the settlement trigger) makes re-execution common, and the markdown floor breaks the moment a second affordance form lands.
+
+**Proposed outer**
+
+The FE-1389 review found three unsafe cases in the ask protocol. A retry of the same ask is rejected as a second question, an unknown form can blank the UI instead of showing markdown, and an abandoned ask can occupy the pending position forever.
+
+These defects do not block the first free-text flow, but retries will become common with settlement and new forms will require the fallback. This task will make identical retries idempotent, parse the envelope separately from its opaque payload, and record unanswered outcomes so later asks can proceed.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 985 characters; `8d0fad5ee0201cf6c7e62778cd97d219beee824653bbfd520bdae507714c5392`
+**Ambiguity:** None
+**Banned-word concerns:** None
+
+## FE-1422
+
+**Title:** The ask protocol is substrate-portable: mechanism moves from the Flue binding into core → **Move the portable ask protocol into core**
+
+**Current outer**
+
+The walking skeleton put the whole ask/suspension protocol inside the Flue binding: the affordance id scheme, the one-live-affordance rule, the reply-binding signal payload, and the elicitation instruction text all live interleaved with hook wiring in binding-flue/src/index.ts, while packages/core exports only schemas and naming. That is the spec's second-binding test failing in spirit (§14.2): a second binding would have to re-implement the protocol rather than reuse it, and every slice that adds mechanism the same way deepens the debt — the sweep work (FE-1392) is the next one that would.
+
+The fix is an extraction, not a redesign: a pure ask-protocol module in core (mint an affordance from question + call id, the one-live guard as a pure decision, the signal payload builder, the instruction fragments), with useElicitation reduced to hook wiring — hooks in, protocol calls out. Scheduled ahead of FE-1392 so sweep mechanism can start in core the same way (sweep-protocol) from day one.
+
+**Proposed outer**
+
+The walking skeleton placed reusable ask behavior inside the Flue binding, including identity, the one-live rule, reply signals, and instruction text. A second runtime binding would have to reproduce that behavior, and settlement work would deepen the duplication.
+
+This task will extract pure ask decisions and builders into core while leaving only Flue hook translation in the binding. It is scheduled before FE-1392 so new settlement behavior begins in the portable module.
+
+**Extraction:** `first-standalone-divider`
+**Inner record:** 663 characters; `301dbadb8c2872e43533c31fcfa09671e4f425b015f1407526a856406f701fcb`
+**Ambiguity:** None
+**Banned-word concerns:** None
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1401.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1401.md
new file mode 100644
index 00000000000..fb76321664a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1401.md
@@ -0,0 +1,88 @@
+# Linear migration review: FE-1401
+
+Generated: 2026-08-20T09:03:34Z
+Issues: 4
+
+## FE-1401
+
+**Title:** Resolve the follow-ups from the stack legibility session → Resolve the stack legibility follow-ups
+
+**Current outer**
+
+I'm running a read-through of the open stack (FE-1374 up to FE-1390), aimed at regaining legibility over the top four branches before they land. The read-through is already surfacing more than branch understanding: process insights, a doc drift, and a couple of tooling ideas worth carrying forward. This issue is the resolution sweep for that session — everything we uncover, solve, design, or decide gets captured here and driven to a resolution, so the session's yield doesn't evaporate when the context does.
+
+The session is in progress; items accrue below as they surface. Anything that grows real work graduates to its own sub-issue.
+
+**Proposed outer**
+
+A read-through of the open stack from FE-1374 through FE-1390 is restoring a shared understanding of the top four branches before they land. It is also identifying process lessons, documentation drift, and tooling ideas that need a durable resolution. This issue records and resolves each finding so that the session's results remain available after the working context ends.
+
+The session is still in progress. Findings accumulate in the execution record, and any finding that requires substantial work becomes a sub-issue.
+
+**Extraction:** `standalone-divider`
+
+**Inner record:** 3285 characters; SHA-256 `f99c1280b8f7c73cd932a953bf8a8df0651f655b393f773cc88d46d0e49da113`
+
+**Ambiguity:** None.
+
+## FE-1424
+
+**Title:** The documentation protocol runs end to end: inbox settled, planning reshaped, index gated, arc-close triggerable → Complete the documentation protocol
+
+**Current outer**
+
+None. The unheaded numbered source body is the execution record.
+
+**Proposed outer**
+
+The repository's documentation rules defined where files belong and how each work arc closes, but the project had not applied them end to end. This issue carries out the rules and incorporates the amendments Lu approved on 2026-08-17.
+
+The work settles all seven inbox documents, reorganizes shared and effort-specific planning files, and adds a test for complete index coverage and directory structure. It also combines the three arc-close procedures and establishes how living documents reference issues and repair stale status language. Freshness remains a procedural review because a mechanical check could report success without proving that the text is current.
+
+**Extraction:** `whole-body-as-inner`
+
+**Inner record:** 1573 characters; SHA-256 `25338da8862bddb99fe1703004fd71da6f90c544df8a3026c5ac2db39bdc8451`
+
+**Ambiguity:** None. The unheaded numbered body is the issue's execution record, so the migration preserves the complete source body inside Agent notes.
+
+## FE-1432
+
+**Title:** The stack's open review threads are adjudicated: fixed, owned, or refused on the record → Resolve the stack's open review threads
+
+**Current outer**
+
+A cross-stack review of the unresolved inline PR threads ran 2026-08-18: 24 threads across 10 PRs, of which 9 were resolved with evidence-backed upstack replies and 15 remain open. The review also induced five reusable lenses, and the findings that survived under them are concrete: two capture-store closure gaps (overlapping conflicts can strand one another, and the persisted parser accepts a duplicate `issue-closed` event the command API refuses to produce), two completion-metadata drops (expert truncation is discarded, and a non-final interviewer response can stay truncated past the continuation cap without being marked incomplete), a boundary-honesty gap (`plugin-gherkin` declares `valibot` without importing it, and the boundary test checks the dependency relation in one direction only), and two test-setup holes (the capture-store test ignores setup results and leans on non-null assertions; the walking-skeleton integration test can throw while inspecting an absent reply context).
+
+FWIW several of these are not new discoveries — they are FE-1419's deliberate out-of-scope list coming due (unused-dependency cleanup, expert-truncation handling, advisory-loop tuning were all named there and deferred). This ticket is the FE-1401-style consolidation point: done means every row in the queue document lands in a commit, moves to a named owner, or is refused with a reply on its PR thread — and the 15 still-open threads each get the same adjudication.
+
+**Proposed outer**
+
+A review on 2026-08-18 covered 24 unresolved inline threads across 10 PRs. Nine threads now have evidence-backed replies, while 15 remain open. The review found two capture-store closure problems, two cases where completion metadata is lost, one dependency-check problem, and two unsafe test setups.
+
+Several findings repeat work that FE-1419 explicitly deferred. This issue is complete when every queue entry and each remaining thread is fixed in a commit, assigned to a named owner, or declined with a reply on the PR thread.
+
+**Extraction:** `standalone-divider`
+
+**Inner record:** 552 characters; SHA-256 `0fbd1bee2c01279349d7153444b398ce50eed5c2b1858847aa457ba5eff62a02`
+
+**Ambiguity:** None.
+
+## FE-1451
+
+**Title:** Keep issues, comments, and PRs easy to scan → Keep issues, comments, and PRs easy to scan
+
+**Current outer**
+
+Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](https://github.com/hashintel/internal-agents/pull/20). The change is ready for review in [brunch-lite PR #23](https://github.com/hashintel/brunch-lite/pull/23).
+
+**Proposed outer**
+
+Teammates have said that agent-written issues, comments, and PR descriptions are too long and too jargon-heavy to scan. This issue changes the writing rules: every issue and PR keeps a short plain-language summary first, and the agent's working detail moves into a section that Linear and GitHub render collapsed. Comments use one or two sentences to say what changed or was decided, with longer details in `🏗️ Agent notes`. The wording rules align with the house technical-writing guidance drafted in [hashintel/internal-agents PR #20](https://github.com/hashintel/internal-agents/pull/20). The change is ready for review in [brunch-lite PR #23](https://github.com/hashintel/brunch-lite/pull/23).
+
+**Extraction:** `existing-agent-notes`
+
+**Inner record:** 2952 characters; SHA-256 `5f7e7ccafc96dae7ca37a344d1196404fc760e3443ad6370e4e05ddb530062b2`
+
+**Ambiguity:** None.
+
+**Notes:** The source opener contains a space after +++; the proposed body normalizes only that structural opener.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1406.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1406.md
new file mode 100644
index 00000000000..0238c745559
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-FE-1406.md
@@ -0,0 +1,28 @@
+# Linear migration review: FE-1406
+
+Generated: 2026-08-20T09:03:34Z
+Issues: 1
+
+## FE-1406
+
+**Title:** Design reusable elicitation strategies → Design reusable elicitation strategies
+
+**Current outer**
+
+An elicitation should adapt to what the user is trying to achieve and how much effort they can give, instead of running through a fixed list of questions. The harness already names reusable interview situations, but it has no shared guidance for beginning an interview, proposing likely answers for correction, or deciding which uncertainties still warrant questions.
+
+This issue will design reusable, domain-independent interviewing guidance. It includes an opening strategy that establishes the objective, its context and scope, and the user's available time, intended use, and tolerance for suggested assumptions within the first turn or two. It also covers proposing a broad draft for correction when time is short, while keeping confirmed statements, declared defaults, and unresolved suggestions visibly distinct.
+
+**Proposed outer**
+
+An elicitation should adapt to the user's objective and available effort. The harness names reusable interview situations but lacks shared guidance for opening an interview, proposing likely answers for correction, and choosing which uncertainties warrant questions.
+
+This issue designs that guidance. The opening establishes objective, context, scope, time, intended use, and tolerance for assumptions; proposal and correction keep confirmed statements, defaults, and suggestions distinct. The scope settled on 2026-08-19, while three mechanics remain unresolved: use model-gap cues without walking the schema, distinguish session stopping from model completion, and decide whether inferred interaction preferences require stored state.
+
+**Extraction:** `existing-agent-notes`
+
+**Inner record:** 3590 characters; SHA-256 `3441bc967c62c4084377fe1de062ec618d820c501c81d50743337fb2ac673094`
+
+**Ambiguity:** None.
+
+**Notes:** The source opener contains a space after +++; the proposed body normalizes only that structural opener.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-editorial-review.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-editorial-review.md
new file mode 100644
index 00000000000..a9be3d4ce17
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/review/linear-editorial-review.md
@@ -0,0 +1,51 @@
+# Linear migration editorial review
+
+## Summary
+
+- Reviewed: 67 of 67 in-scope Lu-authored issues.
+- Issue result: 67 pass, 0 fail.
+- Editorial findings: 0 blocker, 0 major, 0 minor.
+- Apply-time platform formatting was incorporated without changing any inner record.
+
+## Findings
+
+None.
+
+## Apply-time platform correction
+
+The frozen review bodies used `+++🏗️ Agent notes` without the whitespace Linear stores around a
+fold. The first migration write proved that both the issue CLI and raw GraphQL canonicalize this
+to `+++ 🏗️ Agent notes` with blank separator lines. FE-1451's existing body has the same stored
+shape.
+
+The stored targets now derive deterministically from each approved `proposedOuter` and exact
+`innerRecord`. The correction adds one to three wrapper-whitespace bytes per body. Linear also
+expands the only bare domain in two approved outers, FE-1433 and FE-1440, into its stored
+Markdown-link syntax; the manifest declares those exact replacements. All 67 inner records
+remain byte-identical, and `linear-canonical-target-hashes.json` freezes the resulting body
+hashes. The original proposal files and their review hashes remain unchanged as the approval
+artifact.
+
+## Resolved from prior pass
+
+- **FE-1424 — RECORD_LOSS:** Resolved. The complete unheaded numbered source body is now the `innerRecord`, appears byte-for-byte once inside `🏗️ Agent notes`, and has matching inner and proposed-body hashes.
+- **FE-1361 — STATUS_DRIFT:** Resolved. The outer now describes the completed baseline, its two termination failures, the comparison evidence, and the remaining machinery requirements.
+- **FE-1363 — STATUS_DRIFT:** Resolved. The outer identifies truck-fleet predictive maintenance as the engineering recommendation pending team agreement, cold chain as the runner-up, and production scheduling as the baseline.
+- **FE-1364 — STATUS_DRIFT:** Resolved. The outer describes the representation as conditionally defined and assigns worked-payload validation before ratification to FE-1397.
+- **FE-1406 — MATERIAL_OMISSION:** Resolved. The outer records the 2026-08-19 scope decision and the three unresolved mechanics: model-gap cues without a schema walk, session stopping versus model completion, and whether inferred interaction preferences require stored state.
+
+## Mechanical validation
+
+All checks passed:
+
+- The candidate set contains all 67 Lu-authored source issues exactly once.
+- No duplicate candidate and no Dora-authored issue appears.
+- All 67 source titles match the source data, and all 67 source title and source body hashes recompute correctly.
+- All 67 `innerSha256` values recompute correctly.
+- Every nonempty `innerRecord` appears byte-for-byte exactly once in its `proposedBody`.
+- Every reviewed body contains exactly one standalone `+++🏗️ Agent notes` opener and exactly one standalone `+++` closer. Inline backticked mentions were not counted.
+- All 67 `proposedBodySha256` values recompute correctly.
+- All 67 stored targets contain the canonical `+++ 🏗️ Agent notes` wrapper, preserve the exact
+  `innerRecord`, and match `linear-canonical-target-hashes.json`.
+
+The proposed titles and outers were also re-scanned for unsupported claims, material omissions, status drift, title commitment errors, register defects, and banned words. No current finding resulted.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/validate.ts b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/validate.ts
new file mode 100644
index 00000000000..12907be7d08
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/issue-pr-migration-2026-08-20/validate.ts
@@ -0,0 +1,850 @@
+import { createHash } from "node:crypto";
+import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const PACKAGE_ROOT = dirname(fileURLToPath(import.meta.url));
+const DATA_ROOT = join(PACKAGE_ROOT, "data");
+const HASH_MANIFEST_PATH = join(DATA_ROOT, "source-record-hashes.json");
+const EXPECTED_HASH_MANIFEST_SHA256 =
+  "15ff2f72cd7e49a6d3d20f3a71ebbf6f583573f384700a68775f1a4390c31717";
+
+const EXPECTED_FILE_HASHES = {
+  "github-proposals.json":
+    "5c77c007537c15357a2d482c51bc933bc61b7727a6982e8324851d007e55adcc",
+  // The two raw source snapshots were captured minified; the hashintel/hash
+  // assimilation ran the monorepo formatter over them, so their frozen hashes
+  // are pinned to the pretty-printed bytes. Parse-identical to the originals,
+  // and every record-level hash below still checks the content itself.
+  "github-source.json":
+    "ff209f957d17fb3c3049a3c19845b2c3f2310c88cda88d01712a2a3ab67c5113",
+  "linear-canonical-target-hashes.json":
+    "2368d1d7a6d63193b981757e713148f8c155fb29e3ae68c1c805a03b1e338b25",
+  "linear-proposals-FE-1366.json":
+    "2473f32ebe5a4ef59f11d910e1ccf57f9eb22df60a9de40440652509e61bc327",
+  "linear-proposals-FE-1383.json":
+    "80146357d942c89602a3bbe74a31efa2f2c47556988c10c37c291d2778ae9ea7",
+  "linear-proposals-FE-1401.json":
+    "acdc70da63e7d8d74bff8aa736aa903978c695134e9f828e23419d7f4fa3a3d8",
+  "linear-proposals-FE-1406.json":
+    "87324f17f294996c8dcf0fc9ba92c76c51554ee0f7c48082f404e966e7275fbf",
+  "linear-source.json":
+    "863ba1deb87718cf3ba3c2accf70ac11cbe7b51a479aff9d9f1bf2719f26f152",
+} as const;
+
+/**
+ * The two snapshots' hashes at capture time, before the formatter ran.
+ * `source-record-hashes.json` is frozen with these in its `generatedFrom`
+ * block, so the manifest is rebuilt against them, not the current file bytes.
+ */
+const ORIGINAL_SOURCE_SNAPSHOT_HASHES = {
+  "linear-source.json":
+    "1a7200ac6a8fe466615c8d963ee29922e9e9d258e07411ce9edcdd400d10a808",
+  "github-source.json":
+    "2d00d591a91c349b81a645907825aab8640831e4682be164eb905900698ae6f5",
+} as const;
+
+const LINEAR_PROPOSAL_FILES = {
+  "FE-1366": "linear-proposals-FE-1366.json",
+  "FE-1383": "linear-proposals-FE-1383.json",
+  "FE-1401": "linear-proposals-FE-1401.json",
+  "FE-1406": "linear-proposals-FE-1406.json",
+} as const;
+
+const EXPECTED_LINEAR_COUNTS: Readonly<
+  Record<keyof typeof LINEAR_PROPOSAL_FILES, number>
+> = {
+  "FE-1366": 14,
+  "FE-1383": 19,
+  "FE-1401": 4,
+  "FE-1406": 1,
+};
+
+const EXCLUDED_LINEAR_ISSUES = [
+  "FE-1328",
+  "FE-1329",
+  "FE-1330",
+  "FE-1331",
+  "FE-1333",
+  "FE-1334",
+] as const;
+
+/**
+ * The FE-1357 subtree's proposals were reviewed and applied like every other
+ * subtree's, but their frozen snapshot (`linear-proposals-FE-1357.json`) was
+ * removed from the repository after the migration: its issue-URL-adjacent
+ * prose tripped the preflight scan that blocks merging any pull request
+ * whose title names a ticket still referenced beside a task marker, for
+ * every ticket from FE-1437 through FE-1441. The bytes remain in
+ * git history and the canonical target hashes remain complete. What survives
+ * here is each removed proposal's identifier and applied title, so coverage
+ * and the GitHub title checks still account for the whole subtree. All 29
+ * changed both title and body when applied.
+ */
+const REMOVED_LINEAR_PROPOSAL_TITLES: ReadonlyMap<string, string> = new Map([
+  ["FE-1357", "Plan the September elicitation demo and plugin specification"],
+  ["FE-1358", "Survey Petrinaut for the September integration"],
+  ["FE-1359", "Decide whether voice changes the elicitor architecture"],
+  ["FE-1360", "Derive elicitation guidance from published research"],
+  ["FE-1361", "Measure the one-shot AI elicitation baseline"],
+  ["FE-1362", "Decide the September demo architecture"],
+  ["FE-1363", "Choose the demo use case and modelling criteria"],
+  ["FE-1364", "Define the process-model elicitation representation"],
+  ["FE-1382", "Compile the truck-fleet source dossier"],
+  ["FE-1397", "Validate the generic IR against worked plugin payloads"],
+  ["FE-1402", "Define and rehearse the elicitation completion contract"],
+  ["FE-1403", "Assemble and test the CPS interview guidance"],
+  ["FE-1404", "Run the third baseline with completion and interview guidance"],
+  ["FE-1405", "Draft and test the CPS payload schemas"],
+  ["FE-1407", "Catalogue elicitor failures that published measures miss"],
+  ["FE-1423", "Require safe remote access to the elicitor server"],
+  ["FE-1431", "Define declarative plugin authoring"],
+  ["FE-1433", "Deliver the remote Petrinaut elicitor integration"],
+  ["FE-1434", "Test whether Flue resumes batched client-tool results"],
+  ["FE-1435", "Test whether the elicitor stream drives Petrinaut’s chat panel"],
+  ["FE-1436", "Connect the elicitor to Petrinaut’s real chat panel"],
+  ["FE-1437", "Move brunch-agent into hashintel/hash with its history"],
+  ["FE-1438", "Build and repair Petrinaut nets through client tools"],
+  ["FE-1439", "Keep elicitation sessions private and durable per browser"],
+  ["FE-1440", "Ship the elicitor in demo.petrinaut.org’s chat panel"],
+  ["FE-1441", "Deploy the elicitor server behind the remote-release checks"],
+  ["FE-1442", "Show live captures and completion accounting in the demo"],
+  ["FE-1448", "Let Petrinaut hosts render interactive chat tools"],
+  [
+    "FE-1449",
+    "Prove a structured brunch question suspends and resumes in Petrinaut",
+  ],
+]);
+
+const LINEAR_REVIEW_AGENT_NOTES_OPEN = "+++🏗️ Agent notes";
+const LINEAR_CANONICAL_AGENT_NOTES_OPEN = "+++ 🏗️ Agent notes";
+const LINEAR_AGENT_NOTES_CLOSE = "+++";
+const GITHUB_AGENT_NOTES_OPEN = "<details><summary>🏗️ Agent notes</summary>";
+const GITHUB_AGENT_NOTES_CLOSE = "</details>";
+
+interface LinearIssue {
+  readonly id: string;
+  readonly identifier: string;
+  readonly title: string;
+  readonly description: string | null;
+  readonly url: string;
+  readonly updatedAt: string;
+  readonly creator: {
+    readonly name: string;
+    readonly email: string;
+  };
+}
+
+interface LinearSource {
+  readonly data: {
+    readonly issues: {
+      readonly nodes: readonly LinearIssue[];
+    };
+  };
+}
+
+interface LinearProposal {
+  readonly id: string;
+  readonly identifier: string;
+  readonly url: string;
+  readonly sourceUpdatedAt: string;
+  readonly sourceTitle: string;
+  readonly sourceTitleSha256: string;
+  readonly sourceDescriptionSha256: string;
+  readonly proposedTitle: string;
+  readonly proposedOuter: string;
+  readonly innerRecord: string;
+  readonly innerSha256: string;
+  readonly proposedBody: string;
+  readonly proposedBodySha256: string;
+}
+
+interface LinearProposalFile {
+  readonly root:
+    | string
+    | {
+        readonly identifier: string;
+      };
+  readonly issueCount: number;
+  readonly issues: readonly LinearProposal[];
+}
+
+interface LinearCanonicalTarget {
+  readonly identifier: string;
+  readonly bodySha256: string;
+  readonly outerReplacement?: {
+    readonly from: string;
+    readonly to: string;
+  };
+}
+
+interface LinearCanonicalTargetFile {
+  readonly format: "linear-canonical-fold-v1";
+  readonly issues: readonly LinearCanonicalTarget[];
+}
+
+interface GithubPullRequest {
+  readonly number: number;
+  readonly title: string;
+  readonly body: string;
+  readonly url: string;
+  readonly updatedAt: string;
+  readonly author: {
+    readonly login: string;
+  };
+}
+
+interface GithubProposal {
+  readonly number: number;
+  readonly url: string;
+  readonly linkedIssue: string;
+  readonly sourceUpdatedAt: string;
+  readonly sourceTitle: string;
+  readonly sourceTitleSha256: string;
+  readonly sourceBodySha256: string;
+  readonly proposedTitle: string;
+  readonly proposedOuter: string;
+  readonly sourceInnerRecord: string;
+  readonly sourceInnerSha256: string;
+  readonly innerRecord: string;
+  readonly innerSha256: string;
+  readonly proposedBody: string;
+  readonly proposedBodySha256: string;
+  readonly bodyChanged: boolean;
+  readonly titleChanged: boolean;
+}
+
+interface GithubProposalFile {
+  readonly prCount: number;
+  readonly prs: readonly GithubProposal[];
+}
+
+interface SourceRecordHashes {
+  readonly generatedFrom: {
+    readonly linearSourceSha256: string;
+    readonly githubSourceSha256: string;
+  };
+  readonly linear: readonly {
+    readonly identifier: string;
+    readonly url: string;
+    readonly updatedAt: string;
+    readonly titleSha256: string;
+    readonly bodySha256: string;
+  }[];
+  readonly github: readonly {
+    readonly number: number;
+    readonly url: string;
+    readonly updatedAt: string;
+    readonly titleSha256: string;
+    readonly bodySha256: string;
+  }[];
+}
+
+function check(condition: unknown, message: string): asserts condition {
+  if (!condition) throw new Error(message);
+}
+
+function readJson<T>(path: string): T {
+  return JSON.parse(readFileSync(path, "utf8")) as T;
+}
+
+function sha256(value: string | Uint8Array): string {
+  return createHash("sha256").update(value).digest("hex");
+}
+
+function fileSha256(name: keyof typeof EXPECTED_FILE_HASHES): string {
+  return sha256(readFileSync(join(DATA_ROOT, name)));
+}
+
+function bodyOf(issue: LinearIssue): string {
+  return issue.description ?? "";
+}
+
+function linearCanonicalOuter(
+  proposal: LinearProposal,
+  target: LinearCanonicalTarget,
+): string {
+  const replacement = target.outerReplacement;
+  if (!replacement) return proposal.proposedOuter;
+  check(
+    replacement.from !== replacement.to,
+    `${proposal.identifier} has a no-op replacement`,
+  );
+  check(
+    countOccurrences(proposal.proposedOuter, replacement.from) === 1,
+    `${proposal.identifier} outer replacement source must occur exactly once`,
+  );
+  check(
+    !proposal.proposedOuter.includes(replacement.to),
+    `${proposal.identifier} outer replacement target is already present`,
+  );
+  return proposal.proposedOuter.replace(replacement.from, replacement.to);
+}
+
+function linearCanonicalBody(
+  proposal: LinearProposal,
+  target: LinearCanonicalTarget,
+): string {
+  const canonicalOuter = linearCanonicalOuter(proposal, target);
+  const openSeparator = proposal.innerRecord.startsWith("\n") ? "" : "\n";
+  const trailingNewlines = proposal.innerRecord.match(/\n*$/)?.[0].length ?? 0;
+  const closeSeparator = "\n".repeat(Math.max(0, 2 - trailingNewlines));
+  return `${canonicalOuter}\n\n${LINEAR_CANONICAL_AGENT_NOTES_OPEN}\n${openSeparator}${proposal.innerRecord}${closeSeparator}${LINEAR_AGENT_NOTES_CLOSE}`;
+}
+
+function countOccurrences(haystack: string, needle: string): number {
+  check(needle.length > 0, "Cannot count an empty value");
+  let count = 0;
+  let offset = 0;
+  while (true) {
+    const found = haystack.indexOf(needle, offset);
+    if (found === -1) return count;
+    count += 1;
+    offset = found + needle.length;
+  }
+}
+
+function countStandaloneLine(body: string, line: string): number {
+  return body.split("\n").filter((candidate) => candidate === line).length;
+}
+
+function checkUnique<T>(values: readonly T[], label: string): void {
+  check(
+    new Set(values).size === values.length,
+    `${label} contains a duplicate`,
+  );
+}
+
+function sorted(values: Iterable<string>): string[] {
+  return [...values].sort((left, right) =>
+    left.localeCompare(right, "en", { numeric: true }),
+  );
+}
+
+function buildHashManifest(
+  linearIssues: readonly LinearIssue[],
+  githubPullRequests: readonly GithubPullRequest[],
+): SourceRecordHashes {
+  return {
+    generatedFrom: {
+      linearSourceSha256: ORIGINAL_SOURCE_SNAPSHOT_HASHES["linear-source.json"],
+      githubSourceSha256: ORIGINAL_SOURCE_SNAPSHOT_HASHES["github-source.json"],
+    },
+    linear: [...linearIssues]
+      .sort((left, right) =>
+        left.identifier.localeCompare(right.identifier, "en", {
+          numeric: true,
+        }),
+      )
+      .map((issue) => ({
+        identifier: issue.identifier,
+        url: issue.url,
+        updatedAt: issue.updatedAt,
+        titleSha256: sha256(issue.title),
+        bodySha256: sha256(bodyOf(issue)),
+      })),
+    github: [...githubPullRequests]
+      .sort((left, right) => left.number - right.number)
+      .map((pullRequest) => ({
+        number: pullRequest.number,
+        url: pullRequest.url,
+        updatedAt: pullRequest.updatedAt,
+        titleSha256: sha256(pullRequest.title),
+        bodySha256: sha256(pullRequest.body),
+      })),
+  };
+}
+
+function serializeHashManifest(manifest: SourceRecordHashes): string {
+  return `${JSON.stringify(manifest, null, 2)}\n`;
+}
+
+function checkFrozenFiles(): void {
+  for (const [name, expectedHash] of Object.entries(EXPECTED_FILE_HASHES) as [
+    keyof typeof EXPECTED_FILE_HASHES,
+    string,
+  ][]) {
+    check(
+      fileSha256(name) === expectedHash,
+      `${name} no longer matches its frozen SHA-256`,
+    );
+  }
+}
+
+function checkLinear(
+  sourceIssues: readonly LinearIssue[],
+  proposals: readonly LinearProposal[],
+  canonicalTargetByIdentifier: ReadonlyMap<string, LinearCanonicalTarget>,
+): Map<string, LinearProposal> {
+  check(
+    sourceIssues.length === 73,
+    `Expected 73 Linear source issues, found ${sourceIssues.length}`,
+  );
+  check(
+    proposals.length === 38,
+    `Expected 38 live Linear proposals, found ${proposals.length}`,
+  );
+  checkUnique(
+    sourceIssues.map((issue) => issue.identifier),
+    "Linear source",
+  );
+  checkUnique(
+    proposals.map((proposal) => proposal.identifier),
+    "Linear proposals",
+  );
+  check(
+    canonicalTargetByIdentifier.size === 67,
+    `Expected 67 Linear canonical targets, found ${canonicalTargetByIdentifier.size}`,
+  );
+  check(
+    JSON.stringify(
+      sorted(
+        [...canonicalTargetByIdentifier.values()]
+          .filter((target) => target.outerReplacement)
+          .map((target) => target.identifier),
+      ),
+    ) === JSON.stringify(["FE-1433", "FE-1440"]),
+    "Linear outer replacements must be limited to the two bare-domain canonicalizations",
+  );
+
+  const sourceByIdentifier = new Map(
+    sourceIssues.map((issue) => [issue.identifier, issue]),
+  );
+  const proposalByIdentifier = new Map(
+    proposals.map((proposal) => [proposal.identifier, proposal]),
+  );
+  const excluded = new Set<string>(EXCLUDED_LINEAR_ISSUES);
+
+  for (const identifier of excluded) {
+    const issue = sourceByIdentifier.get(identifier);
+    check(
+      issue,
+      `Excluded issue ${identifier} is absent from the source snapshot`,
+    );
+    check(
+      issue.creator.email === "dm@hash.ai",
+      `${identifier} is not authored by Dora Ma`,
+    );
+    check(
+      !proposalByIdentifier.has(identifier),
+      `${identifier} must not have a proposal`,
+    );
+  }
+
+  for (const identifier of REMOVED_LINEAR_PROPOSAL_TITLES.keys()) {
+    check(
+      !proposalByIdentifier.has(identifier),
+      `${identifier} has both a live proposal and a removed-snapshot record`,
+    );
+  }
+  const expectedCandidates = sourceIssues
+    .filter((issue) => !excluded.has(issue.identifier))
+    .map((issue) => issue.identifier);
+  check(
+    JSON.stringify(
+      sorted([
+        ...proposalByIdentifier.keys(),
+        ...REMOVED_LINEAR_PROPOSAL_TITLES.keys(),
+      ]),
+    ) === JSON.stringify(sorted(expectedCandidates)),
+    "Live and removed Linear proposals do not exactly cover the non-Dora source issues",
+  );
+  for (const identifier of canonicalTargetByIdentifier.keys()) {
+    check(
+      proposalByIdentifier.has(identifier) ||
+        REMOVED_LINEAR_PROPOSAL_TITLES.has(identifier),
+      `Canonical target ${identifier} matches neither a live proposal nor a removed-snapshot record`,
+    );
+  }
+
+  let titleChanges = 0;
+  let bodyChanges = 0;
+  for (const proposal of proposals) {
+    const source = sourceByIdentifier.get(proposal.identifier);
+    check(
+      source,
+      `${proposal.identifier} is absent from the Linear source snapshot`,
+    );
+    check(
+      source.id === proposal.id,
+      `${proposal.identifier} has a different Linear id`,
+    );
+    check(
+      source.url === proposal.url,
+      `${proposal.identifier} has a different Linear URL`,
+    );
+    check(
+      source.creator.email === "ln@hash.ai",
+      `${proposal.identifier} is not Lu-authored`,
+    );
+    check(
+      source.updatedAt === proposal.sourceUpdatedAt,
+      `${proposal.identifier} updatedAt drifted`,
+    );
+    check(
+      source.title === proposal.sourceTitle,
+      `${proposal.identifier} source title drifted`,
+    );
+    check(
+      sha256(source.title) === proposal.sourceTitleSha256,
+      `${proposal.identifier} source title hash is invalid`,
+    );
+    check(
+      sha256(bodyOf(source)) === proposal.sourceDescriptionSha256,
+      `${proposal.identifier} source body hash is invalid`,
+    );
+    check(
+      sha256(proposal.innerRecord) === proposal.innerSha256,
+      `${proposal.identifier} inner-record hash is invalid`,
+    );
+    check(
+      countOccurrences(bodyOf(source), proposal.innerRecord) === 1,
+      `${proposal.identifier} inner record is not preserved exactly once in its source body`,
+    );
+    check(
+      countOccurrences(proposal.proposedBody, proposal.innerRecord) === 1,
+      `${proposal.identifier} inner record is not preserved exactly once in its proposed body`,
+    );
+    check(
+      sha256(proposal.proposedBody) === proposal.proposedBodySha256,
+      `${proposal.identifier} proposed-body hash is invalid`,
+    );
+    check(
+      countStandaloneLine(
+        proposal.proposedBody,
+        LINEAR_REVIEW_AGENT_NOTES_OPEN,
+      ) === 1,
+      `${proposal.identifier} must have one reviewed Agent notes opener`,
+    );
+    check(
+      countStandaloneLine(proposal.proposedBody, LINEAR_AGENT_NOTES_CLOSE) ===
+        1,
+      `${proposal.identifier} must have one canonical Agent notes closer`,
+    );
+    check(
+      proposal.proposedBody.startsWith(
+        `${proposal.proposedOuter}\n\n${LINEAR_REVIEW_AGENT_NOTES_OPEN}\n`,
+      ),
+      `${proposal.identifier} proposed body does not reconstruct from its proposed outer`,
+    );
+
+    const canonicalTarget = canonicalTargetByIdentifier.get(
+      proposal.identifier,
+    );
+    check(canonicalTarget, `${proposal.identifier} lacks a canonical target`);
+    const canonicalOuter = linearCanonicalOuter(proposal, canonicalTarget);
+    const canonicalBody = linearCanonicalBody(proposal, canonicalTarget);
+    check(
+      countOccurrences(canonicalBody, proposal.innerRecord) === 1,
+      `${proposal.identifier} inner record is not preserved exactly once in its canonical body`,
+    );
+    check(
+      countStandaloneLine(canonicalBody, LINEAR_CANONICAL_AGENT_NOTES_OPEN) ===
+        1,
+      `${proposal.identifier} canonical body must have one stored Agent notes opener`,
+    );
+    check(
+      canonicalBody.startsWith(
+        `${canonicalOuter}\n\n${LINEAR_CANONICAL_AGENT_NOTES_OPEN}\n\n`,
+      ),
+      `${proposal.identifier} canonical body does not reconstruct from its proposed outer`,
+    );
+    check(
+      canonicalBody.endsWith(`\n\n${LINEAR_AGENT_NOTES_CLOSE}`),
+      `${proposal.identifier} canonical body lacks the required closing separator`,
+    );
+    check(
+      sha256(canonicalBody) === canonicalTarget.bodySha256,
+      `${proposal.identifier} canonical target hash is invalid`,
+    );
+    if (source.title !== proposal.proposedTitle) titleChanges += 1;
+    if (bodyOf(source) !== canonicalBody) bodyChanges += 1;
+  }
+  // 65 and 66 across all 67 proposals; the 29 removed-snapshot proposals all
+  // changed both, leaving 36 and 37 among the live ones.
+  check(
+    titleChanges === 36,
+    `Expected 36 live Linear title changes, found ${titleChanges}`,
+  );
+  check(
+    bodyChanges === 37,
+    `Expected 37 live Linear body changes, found ${bodyChanges}`,
+  );
+
+  return proposalByIdentifier;
+}
+
+function removeStandaloneGithubWrapper(sourceInner: string): string {
+  return sourceInner
+    .replace(`${GITHUB_AGENT_NOTES_OPEN}\n`, "")
+    .replace(GITHUB_AGENT_NOTES_CLOSE, "");
+}
+
+function checkGithub(
+  sourcePullRequests: readonly GithubPullRequest[],
+  proposals: readonly GithubProposal[],
+  linearProposals: ReadonlyMap<string, LinearProposal>,
+): void {
+  check(
+    sourcePullRequests.length === 25,
+    `Expected 25 GitHub source pull requests, found ${sourcePullRequests.length}`,
+  );
+  check(
+    proposals.length === 25,
+    `Expected 25 GitHub proposals, found ${proposals.length}`,
+  );
+  checkUnique(
+    sourcePullRequests.map((pullRequest) => pullRequest.number),
+    "GitHub source",
+  );
+  checkUnique(
+    proposals.map((proposal) => proposal.number),
+    "GitHub proposals",
+  );
+
+  const sourceByNumber = new Map(
+    sourcePullRequests.map((pullRequest) => [pullRequest.number, pullRequest]),
+  );
+  let titleChanges = 0;
+  let bodyChanges = 0;
+
+  for (const proposal of proposals) {
+    const source = sourceByNumber.get(proposal.number);
+    check(
+      source,
+      `PR #${proposal.number} is absent from the GitHub source snapshot`,
+    );
+    check(
+      source.url === proposal.url,
+      `PR #${proposal.number} has a different GitHub URL`,
+    );
+    check(
+      source.author.login === "lunelson",
+      `PR #${proposal.number} is not Lu-authored`,
+    );
+    check(
+      source.updatedAt === proposal.sourceUpdatedAt,
+      `PR #${proposal.number} updatedAt drifted`,
+    );
+    check(
+      source.title === proposal.sourceTitle,
+      `PR #${proposal.number} source title drifted`,
+    );
+    check(
+      sha256(source.title) === proposal.sourceTitleSha256,
+      `PR #${proposal.number} source title hash is invalid`,
+    );
+    check(
+      sha256(source.body) === proposal.sourceBodySha256,
+      `PR #${proposal.number} source body hash is invalid`,
+    );
+    check(
+      sha256(proposal.sourceInnerRecord) === proposal.sourceInnerSha256,
+      `PR #${proposal.number} source inner-record hash is invalid`,
+    );
+    check(
+      countOccurrences(source.body, proposal.sourceInnerRecord) === 1,
+      `PR #${proposal.number} source inner record is not preserved in its source body`,
+    );
+    check(
+      sha256(proposal.innerRecord) === proposal.innerSha256,
+      `PR #${proposal.number} normalized inner-record hash is invalid`,
+    );
+
+    if (proposal.number === 23) {
+      check(
+        removeStandaloneGithubWrapper(proposal.sourceInnerRecord) ===
+          proposal.innerRecord,
+        "PR #23 normalization changed more than the nested standalone wrapper lines",
+      );
+    } else {
+      check(
+        proposal.sourceInnerRecord === proposal.innerRecord,
+        `PR #${proposal.number} changed its authoritative inner record`,
+      );
+    }
+
+    check(
+      countOccurrences(proposal.proposedBody, proposal.innerRecord) === 1,
+      `PR #${proposal.number} inner record is not preserved exactly once in its proposed body`,
+    );
+    check(
+      sha256(proposal.proposedBody) === proposal.proposedBodySha256,
+      `PR #${proposal.number} proposed-body hash is invalid`,
+    );
+    check(
+      countStandaloneLine(proposal.proposedBody, GITHUB_AGENT_NOTES_OPEN) === 1,
+      `PR #${proposal.number} must have one canonical Agent notes opener`,
+    );
+    check(
+      countStandaloneLine(proposal.proposedBody, GITHUB_AGENT_NOTES_CLOSE) ===
+        1,
+      `PR #${proposal.number} must have one canonical Agent notes closer`,
+    );
+    check(
+      proposal.proposedBody.startsWith(
+        `${proposal.proposedOuter}\n\n${GITHUB_AGENT_NOTES_OPEN}\n`,
+      ),
+      `PR #${proposal.number} proposed body does not reconstruct from its proposed outer`,
+    );
+
+    const linkedTitle =
+      linearProposals.get(proposal.linkedIssue)?.proposedTitle ??
+      REMOVED_LINEAR_PROPOSAL_TITLES.get(proposal.linkedIssue);
+    check(
+      linkedTitle !== undefined,
+      `PR #${proposal.number} links to missing proposal ${proposal.linkedIssue}`,
+    );
+    check(
+      proposal.proposedTitle === `${proposal.linkedIssue}: ${linkedTitle}`,
+      `PR #${proposal.number} title does not match its proposed Linear issue title`,
+    );
+    check(
+      proposal.titleChanged ===
+        (proposal.sourceTitle !== proposal.proposedTitle),
+      `PR #${proposal.number} titleChanged is invalid`,
+    );
+    check(
+      proposal.bodyChanged === (source.body !== proposal.proposedBody),
+      `PR #${proposal.number} bodyChanged is invalid`,
+    );
+    if (proposal.titleChanged) titleChanges += 1;
+    if (proposal.bodyChanged) bodyChanges += 1;
+  }
+
+  check(
+    titleChanges === 24,
+    `Expected 24 GitHub title changes, found ${titleChanges}`,
+  );
+  check(
+    bodyChanges === 8,
+    `Expected 8 GitHub body changes, found ${bodyChanges}`,
+  );
+}
+
+function emitOriginals(
+  destination: string,
+  linearIssues: readonly LinearIssue[],
+  githubPullRequests: readonly GithubPullRequest[],
+): void {
+  const writeExact = (path: string, content: string): void => {
+    mkdirSync(dirname(path), { recursive: true });
+    writeFileSync(path, content, { flag: "wx" });
+    check(
+      readFileSync(path, "utf8") === content,
+      `Rollback emission changed ${path}`,
+    );
+  };
+
+  for (const issue of linearIssues) {
+    const recordRoot = join(destination, "linear", issue.identifier);
+    writeExact(join(recordRoot, "title.txt"), issue.title);
+    writeExact(join(recordRoot, "body.md"), bodyOf(issue));
+  }
+  for (const pullRequest of githubPullRequests) {
+    const recordRoot = join(destination, "github", String(pullRequest.number));
+    writeExact(join(recordRoot, "title.txt"), pullRequest.title);
+    writeExact(join(recordRoot, "body.md"), pullRequest.body);
+  }
+}
+
+function main(): void {
+  checkFrozenFiles();
+
+  const linearSource = readJson<LinearSource>(
+    join(DATA_ROOT, "linear-source.json"),
+  );
+  const githubSource = readJson<readonly GithubPullRequest[]>(
+    join(DATA_ROOT, "github-source.json"),
+  );
+  const linearIssues = linearSource.data.issues.nodes;
+  const linearCanonicalTargetFile = readJson<LinearCanonicalTargetFile>(
+    join(DATA_ROOT, "linear-canonical-target-hashes.json"),
+  );
+  check(
+    linearCanonicalTargetFile.format === "linear-canonical-fold-v1",
+    "Linear canonical target manifest has an unknown format",
+  );
+  checkUnique(
+    linearCanonicalTargetFile.issues.map((issue) => issue.identifier),
+    "Linear canonical targets",
+  );
+  const linearCanonicalTargetByIdentifier = new Map(
+    linearCanonicalTargetFile.issues.map((issue) => [issue.identifier, issue]),
+  );
+
+  const linearProposals: LinearProposal[] = [];
+  for (const [root, name] of Object.entries(LINEAR_PROPOSAL_FILES) as [
+    keyof typeof LINEAR_PROPOSAL_FILES,
+    string,
+  ][]) {
+    const proposalFile = readJson<LinearProposalFile>(join(DATA_ROOT, name));
+    const proposalRoot =
+      typeof proposalFile.root === "string"
+        ? proposalFile.root
+        : proposalFile.root.identifier;
+    check(
+      proposalRoot === root,
+      `${name} identifies root ${proposalRoot}, not ${root}`,
+    );
+    check(
+      proposalFile.issueCount === EXPECTED_LINEAR_COUNTS[root],
+      `${name} has an unexpected issueCount`,
+    );
+    check(
+      proposalFile.issues.length === EXPECTED_LINEAR_COUNTS[root],
+      `${name} has an unexpected number of proposals`,
+    );
+    linearProposals.push(...proposalFile.issues);
+  }
+
+  const linearProposalByIdentifier = checkLinear(
+    linearIssues,
+    linearProposals,
+    linearCanonicalTargetByIdentifier,
+  );
+  const githubProposalFile = readJson<GithubProposalFile>(
+    join(DATA_ROOT, "github-proposals.json"),
+  );
+  check(
+    githubProposalFile.prCount === 25,
+    "github-proposals.json has an unexpected prCount",
+  );
+  checkGithub(githubSource, githubProposalFile.prs, linearProposalByIdentifier);
+
+  const expectedHashManifest = serializeHashManifest(
+    buildHashManifest(linearIssues, githubSource),
+  );
+  const hashManifest = readFileSync(HASH_MANIFEST_PATH, "utf8");
+  check(
+    sha256(hashManifest) === EXPECTED_HASH_MANIFEST_SHA256,
+    "source-record-hashes.json no longer matches its frozen SHA-256",
+  );
+  check(
+    hashManifest === expectedHashManifest,
+    "source-record-hashes.json does not match the frozen source snapshots",
+  );
+
+  if (process.argv[2] === "--emit-originals") {
+    const destination = process.argv[3];
+    check(
+      destination && process.argv.length === 4,
+      "Usage: node --experimental-strip-types validate.ts --emit-originals <dir>",
+    );
+    emitOriginals(destination, linearIssues, githubSource);
+    console.log(
+      `Emitted 73 Linear and 25 GitHub originals under ${destination}`,
+    );
+    return;
+  }
+
+  check(
+    process.argv.length === 2,
+    "Usage: node --experimental-strip-types validate.ts [--emit-originals <dir>]",
+  );
+  console.log(
+    "Validated 73 Linear originals, 38 live + 29 removed-snapshot Linear proposals across 67 canonical targets, and 25 GitHub originals/proposals.",
+  );
+}
+
+main();
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/refactor-queue-2026-08-14.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/refactor-queue-2026-08-14.md
new file mode 100644
index 00000000000..98ee543cd0c
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/refactor-queue-2026-08-14.md
@@ -0,0 +1,82 @@
+# Capture-store contract closure and verification-oracle integrity
+
+## Problem Statement
+
+Two seams currently make stronger claims than their implementations support.
+
+The capture store has separate rule sets at command application, persisted parsing, and lifecycle transition time. A command can therefore return success for a snapshot the next read rejects, accept list-shaped data that is later treated as a set, or create an open conflict that no legal command can close.
+
+The verification layer similarly infers executable facts from source text. Substrings and regular expressions claim that a gap closed, CI ran a gate, a substrate test is hermetic, or a path is a valid build output. These proxies can pass while the behavior they stand for is absent.
+
+```text
+current
+
+command branches ──> partial validators ──> snapshot ──> persistence
+                                      parser ──> different validators
+open conflict ──> supersession/retraction ──> no legal close
+
+source text ──> substring/regex proxy ──> claimed runtime fact
+asset path ──> invented filename grammar ──> 200 or broad-catch 404
+```
+
+## Solution
+
+Give each contract one owner and make negative results precise.
+
+Capture-store commands and persisted snapshots will share evidence and issue invariants. Conflict references will be unique, active sets; a conflicting issue must begin resolvable. While it remains open, supersession and retraction of its referenced captures will fail loudly, preserving the selected lifecycle rule that the conflict must be resolved first.
+
+Known-gap closure will become explicit rather than inferred: the proof commit deletes the gap entry. CI checks will match the actual declared commands, substrate imports will use an explicit reviewed inventory, and asset serving will validate only safety properties while accepting the producer's legal filename space. Expected absence errors become 404 or “not resolvable”; unexpected errors propagate.
+
+```text
+desired
+
+                 ┌─ command boundaries
+shared invariants├─ persisted parser
+                 └─ lifecycle guards ──> always-readable, reachable snapshot
+
+explicit gap ledger ──> proof commit deletes entry
+workflow structure ──> exact gate command
+reviewed integration inventory ──> permitted substrate entry points
+safe path segments + real filesystem result ──> precise HTTP status
+```
+
+## Commits
+
+1. Replace inferred known-gap closure with an explicit open-gap ledger whose entries are deleted in the same commit as their behavioral proof.
+2. Make CI-gate checks match exact active commands and replace the faux-provider marker comment with an explicit reviewed inventory of permitted substrate integration entry points.
+3. Make negative verification precise: only module-not-found means physically unresolvable; every other resolver failure remains loud.
+4. Align production asset serving with the build producer: accept every safe extension-bearing path, return existing bytes directly, and translate only expected missing-path errors to 404.
+5. Move evidence-range ordering into the shared evidence contract so capture proposals, event commands, and persisted snapshots enforce the same rule.
+6. Route issue creation through the canonical issue contract, require unique references, and compare conflict resolutions by exact set equality.
+7. Require every newly opened conflicting issue to reference at least two unique active captures.
+8. Add the explicit open-conflict transition guard: supersession and retraction refuse captures referenced by an unresolved conflict, returning the blocking issue identities.
+9. Lock the closure property with public-boundary tests: every successful command result round-trips through persisted parsing, and refused local-store commands leave the prior readable snapshot intact.
+
+## Decisions
+
+- **Modules modified:** capture-store domain model, local capture-store persistence tests, known-gap ledger, workspace boundary gates, production asset handler.
+- **Interface change:** the capture-store refusal union gains a refusal for captures blocked by unresolved conflicts.
+- **Schema contract:** issue references are non-empty unique sets; conflicting issues additionally require two or more active captures.
+- **Lifecycle contract:** open conflicts pin their referenced captures until a user-cited resolution closes the issue. No compatibility bridge is retained under the prototype/free-rewrite posture.
+- **Verification contract:** known-gap closure is an explicit repository action, not a source-text inference.
+- **Dependency decision:** no new dependency is needed.
+- **Topology files:** none exist in the affected directories.
+
+## Testing Decisions
+
+- Drive capture-store behavior through its public command function, then parse every successful snapshot through the public persisted-state parser.
+- Add table-driven refusal cases for malformed issues, duplicate references, reversed evidence spans, under-populated conflicts, inactive references, and capture changes blocked by an open conflict.
+- Keep one local-store round-trip proving an invalid command cannot corrupt the previously readable file.
+- Drive asset behavior through the real Hono route over real temporary files, including producer-valid punctuation and an unexpected filesystem failure.
+- Test workflow and substrate inventories as exact declared data, not nearby prose tokens.
+- Existing capture-store, local persistence, asset-route, and boundary suites provide the prior art; no paid model run or network oracle is required.
+
+## Out of Scope
+
+- Unused dependency cleanup in package manifests.
+- Baseline-runner expert truncation handling.
+- Documentation spelling, stale comments, and the stale Gherkin worked-example phrase.
+- Bun minimum-release-age policy.
+- Advisory-scan performance tuning and the redundant asset-byte copy except where the asset-boundary commit naturally removes it.
+- Alternative conflict semantics such as historical resolution, dynamic head-following, or a new “moot” event.
+- Replacing every regular expression or static architecture sentinel; only the review-confirmed proxies are included.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/remediation-plan-2026-08-17.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/remediation-plan-2026-08-17.md
new file mode 100644
index 00000000000..acca05f1eec
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/remediation-plan-2026-08-17.md
@@ -0,0 +1,49 @@
+# Remediation & resolution plan — 2026-08-17
+
+The consolidated read of everything the remediation sweep produced: the FE-1419 queue (executed),
+the deep-reads, the capture-store rendering, the patterns audit (as corrected), the architecture
+cheatsheet (+ tilde reconciliation), and the routing table. Two ledgers: **A** — what is still
+wrong or fragile in the implementation, with owners and plan corrections; **B** — what we don't
+know, with the cheapest honest way to find out. Rows leave this document by landing in a commit,
+a ticket, or a decision — per the legibility protocol, this file is a consolidation target, not
+a terminus.
+
+## Ledger A — wrong-or-fragile, still open
+
+| #   | What                                                                                                                                                                                                                                                                                                 | Evidence                                                                | Owner                                                                                         | Fix shape                                                                                                                                   | Plan correction needed                                                                                                                                                                                                            |
+| --- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
+| A1  | **Core was a schema bag; the suspension protocol lived in the binding.** The second-binding test (spec §14.2) failed in spirit: the affordance id scheme, one-live-affordance rule, reply-binding narration, and instruction assembly were portable harness mechanism in `binding-flue/src/index.ts` | deep-read FE-1389; SPEC-LEDGER §12.2; topology.md N1                    | **Discharged by FE-1422** (`ln/fe-1422-ask-protocol`, 2026-08-18)                             | `packages/core/src/ask-protocol.ts` now owns minting, guard, signal payload, and instructions; the binding is hook wiring                   | Done — landed before FE-1391/FE-1392, preserving the accepted spine                                                                                                                                                               |
+| A2  | FE-1420 findings 1+3: benign tool retry refused as duplicate ask; no relief for an abandoned pending slot (§7.5 `unanswered`)                                                                                                                                                                        | deep-read FE-1389; FE-1420                                              | FE-1420                                                                                       | One-line id-tolerant guard + outcome recording                                                                                              | FE-1392 separately delivered §8.6's derived affordance-bound accounting advisory; retry tolerance, free-text accounting, and abandoned-slot relief remain here. Finding 2 (markdown floor) rides `@flue/react` parts with FE-1385 |
+| A3  | **Evidence pointers were caller-supplied; §5/§8.2 require harness derivation.**                                                                                                                                                                                                                      | SPEC-LEDGER §5 contradicted row; deep-read FE-1390                      | **Discharged by FE-1391** (`ln/fe-1391-entry-projection`, 2026-08-18)                         | Caller inputs now carry verbatim quotes only; the store resolves them once against the archive and persists harness-owned ordinals          | Done — range/source assertions are refused at every evidence-bearing command surface                                                                                                                                              |
+| A4  | `resolve-conflict` rejects structured-tap evidence (§8.5 strict reading vs §5.1/C4) — a user who resolves by tapping cannot close the conflict                                                                                                                                                       | SPEC-LEDGER §8.5-adjacent contradicted row                              | **DECISION** — FE-1395 × FE-1390 seam (cross-comments posted)                                 | Adjudicate when FE-1395 picks the reply encoding; store rule follows the decision                                                           | None further; both tickets carry the seam note                                                                                                                                                                                    |
+| A5  | Confidence accepts scalar strings (`"0.93"`); spec: qualitative, never a scalar                                                                                                                                                                                                                      | deep-read FE-1390; SPEC-LEDGER §5 partial row                           | **Design discharged by FE-1405; store rule unowned**                                          | FE-1405 settled `firm                                                                                                                       | hedged                                                                                                                                                                                                                            | speculative` without changing the envelope; the remaining change is one store rule refusing numeric-parsing confidence strings | Keep the store refusal explicit as residual work; FE-1392 consumes the settled vocabulary but does not widen into that envelope change |
+| A6  | Issue `origin` is self-declared; producer unauthenticated (invariant 6 partial)                                                                                                                                                                                                                      | deep-read FE-1390; SPEC-LEDGER §6.3 row                                 | **UNOWNED** (FE-1393-adjacent)                                                                | Producer identity needs a caller concept that first exists when plugin ops arrive; bind origin to the executing op, not a command parameter | Note for FE-1393's SDK design: the op context should mint the origin                                                                                                                                                              |
+| A7  | Near-identical advisory fires for string payloads only; §6.2 promises flat-record plugins duplicate detection free                                                                                                                                                                                   | deep-read FE-1390                                                       | **UNOWNED** (FE-1393-adjacent)                                                                | Extend `normalizedPayloadText` to flat records (sorted key=value join) when the first flat-record payloads arrive with the gherkin plugin   | Note for FE-1393; test with its real payloads, not synthetic ones                                                                                                                                                                 |
+| A8  | Many-sessions-one-target-document unreachable: `chat.tsx` mints a fresh document id per page load (§9.1)                                                                                                                                                                                             | deep-read FE-1389; SPEC-LEDGER §9.1 row                                 | FE-1396 (+FE-1385 UI half)                                                                    | Stable target-document identity in the UI (route param), sessions attach to it                                                              | Recommend comment on FE-1396: the UI half is prerequisite to proving resume — coordinate with FE-1385                                                                                                                             |
+| A9  | `plugin.targetDomain` raw slug interpolated into the prompt ("elicit gherkin")                                                                                                                                                                                                                       | deep-read FE-1389                                                       | FE-1393 (§11.1 plugin ownership)                                                              | Plugin declares a human phrase (`displayName` or prompt fragment)                                                                           | Note for FE-1393                                                                                                                                                                                                                  |
+| A10 | **Pre-remote gates**: auth + per-conversation authorization (mounted route is public), runtime telemetry, persisted-state versioning/backup, restart durability                                                                                                                                      | cheatsheet reconciliation; tilde analysis; routing table pre-remote row | **FE-1423** (filed 2026-08-17 under FE-1357; FE-1396 blocks it, covering the durability gate) | The ticket carries all four gates as its checklist; blocks remote exposure, not the demo                                                    | Done — Lu ratified the gates as **requirements** (2026-08-17); the telemetry gate carries the dual charter (floor: visibility; ceiling: traces feed our feedback/oracles)                                                         |
+| A11 | Kickoff message is a machine-authored `user` entry (authored non-utterance)                                                                                                                                                                                                                          | deep-read FE-1389; trace §9.4                                           | FE-1420 (comment posted) + FE-1385 (`useInitialData` route)                                   | Carry kickoff via `useInitialData`/signal                                                                                                   | Done — comments posted on both                                                                                                                                                                                                    |
+
+Tracked-but-fine (no action beyond their rows): flat agent file → folders at FE-1385 (audit item 6).
+FE-1392 supplied the intended `useInitialData` caller for immutable session-to-target binding
+(audit item 13).
+
+## Ledger B — information gaps, by cheapest honest resolution
+
+| #   | Question                                                                                                                                                            | Why it matters                                                                                   | Mode                                                                                                                                                                                                                                                                                                                                                                                                                           | Owner                                                                                                                                    |
+| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| B1  | Capability 8's contract: what exactly does the durable entry projection's GET surface guarantee (paging, entry kinds, offsets) when read self-HTTP from in-process? | The binding's biggest docs-unsupported bet; FE-1391's archive and anchoring both stand on it     | **Resolved and implemented (2026-08-18):** `history()` is one unpaged materialized-message snapshot; updates page at 100 durable batches and the SDK drains them, but chunks are UI-only protocol; 1,000 is an internal store cap, not a wire entry limit. The binding consumes `history()` through a host-injected full URL resolver and transport. See [source-read record](flue-entry-projection-source-read-2026-08-18.md) | **FE-1391 implemented:** archive-owned ordinals, identity-keyed versions, and actual injected-transport read are pinned in binding tests |
+| B2  | Does compaction preserve the durable entry projection (history retention through compaction)?                                                                       | Every long interview; evidence pointers bind to the projection                                   | **Source-settled for Flue 2.0.3 (2026-08-18):** canonical storage is append-only; compaction appends a record and rewrites model context only; public history and persistent state survive. Reshape FE-1386 to one behavioral upgrade pin rather than an open-ended spike. See [source-read record](flue-entry-projection-source-read-2026-08-18.md)                                                                           | **FE-1386:** separate narrow behavioral pin; deliberately not folded into FE-1391/FE-1392                                                |
+| B3  | Exact private model-call surface for sweep extraction — previously paraphrased as direct `useSubagent` invocation                                                   | FE-1392 needs private structured extraction without granting pointer authority                   | **Resolved and implemented (2026-08-18):** installed 2.0.3 types and official docs show `useSubagent` is declarative/model-driven through `task`; `harness.prompt(..., { result })` is the direct private structured call inside a harness tool. FE-1392 uses it inside a durable tool with `step.do` boundaries                                                                                                               | **FE-1392 implemented**                                                                                                                  |
+| B4  | Can a skill-bearing agent run under `start()` in our node child process (Vite-graph resolution outside `vite build`)?                                               | Decides whether FE-1403/06 card content is testable in our harness or needs fixture-grade copies | **Local probe**, hour-scale, when cards first compile                                                                                                                                                                                                                                                                                                                                                                          | FE-1403/FE-1406                                                                                                                          |
+| B5  | The evals guide never documents the faux-provider pattern; our CI hermeticity rests on pi-ai's contract                                                             | A pi-ai breaking change silently breaks the hermetic gate                                        | Pin pi-ai deliberately; **upstream question** to Flue (docs suggestion: the fetch-shim + faux pattern is worth documenting)                                                                                                                                                                                                                                                                                                    | UNOWNED (small; ride any FE-1383 slice)                                                                                                  |
+| B6  | `dist/app.mjs` embedding contract, if the demo shell needs a custom host                                                                                            | Demo-shell chartering                                                                            | **Raw-doc verification** at demo-shell design time; likely moot (recommended shape is the standard layout)                                                                                                                                                                                                                                                                                                                     | Demo shell (FE-1357-side, post-gate)                                                                                                     |
+| B7  | Load-bearing signatures generally: everything in the cheatsheet is paraphrase-grade unless marked                                                                   | Silent API drift between paraphrase and reality                                                  | Standing rule (routing table, upgrade row + cheatsheet header): **raw-doc or node_modules types check at implementation time**, per feature, not as a batch                                                                                                                                                                                                                                                                    | Standing — no ticket                                                                                                                     |
+
+> **Reflection:** Ledger B's common thread is narrower than "lack of information" — every row is
+> a place where we know _that_ an affordance exists but not its _contract_. That is the
+> paraphrase-grade residue of doing doc research through a summarizer, and the resolution modes
+> sort cleanly by cost: types in node_modules < raw page < probe < spike. The routing table's
+> upgrade row already encodes the general rule; B1–B4 are just that rule applied before the
+> four tickets that need it. B1/B2 demonstrated the intended economy: the source read removed
+> the architectural spike, leaving one compatibility pin rather than another discovery loop.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/review-remediation-2026-08-18.md b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/review-remediation-2026-08-18.md
new file mode 100644
index 00000000000..97e07926a03
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/legibility-sweep/review-remediation-2026-08-18.md
@@ -0,0 +1,58 @@
+# Review remediation — 2026-08-18
+
+The consolidated queue from the cross-stack PR-thread review (2026-08-18): 24 unresolved inline
+threads across 10 PRs were sampled; 9 were resolved at review time with evidence-backed upstack
+replies (PRs #3, #6, #7, #9, #11), and FE-1432 has now adjudicated the remaining 15. Five
+reusable lenses were induced, of which four were promoted. Owning ticket: **FE-1432** (sub-issue
+of FE-1401, the sweep lineage). Exit rule as ever: rows leave this document by landing in a
+commit, a ticket, or a decision — this file is a consolidation target, not a terminus.
+
+Provenance note: several rows are FE-1419's deliberate deferrals coming due — its queue's
+Out of Scope list named unused-dependency cleanup, expert-truncation handling, stale prose, and
+advisory-loop tuning explicitly. Those return here with lens backing rather than as style nits.
+
+## Ledger R — resolved findings, by lens
+
+| #   | Lens                                                                 | What                                                                                                                | Resolution                                                                                                                                                                                                                     |
+| --- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| R1  | 1 — accepted transitions preserve future closure + parse equivalence | Overlapping conflicts can strand one another                                                                        | `380411f`: open conflicts are pairwise disjoint at command admission and persisted parsing; an open conflict must still name active captures. Table-driven overlap cases and an adversarial review prove the closure argument. |
+| R2  | 1                                                                    | Persisted parsing accepts duplicate terminal events the command API refuses                                         | `380411f`: the parser permits at most one `resolution` or `issue-closed` event per issue.                                                                                                                                      |
+| R3  | 2 — completion metadata survives every sibling caller                | Expert truncation is discarded                                                                                      | `f71aa9e`: persist the partial reply and `truncated` fact, checkpoint as `expert-truncated`, stop before interviewer consumption, and regenerate the reply on resume.                                                          |
+| R4  | 2                                                                    | A non-final interviewer response can remain truncated after the continuation cap                                    | `f71aa9e`: checkpoint as `interviewer-truncated` and stop before expert consumption; the existing resume path regenerates the trailing interviewer turn.                                                                       |
+| R5  | 4 — declared capability matches actual imports                       | The dependency relation was checked in one direction only                                                           | Current-state correction: `plugin-gherkin` began importing Valibot in `b4b76f7`, so its declaration is no longer unused and was retained. `bb46941` makes the boundary gate bidirectional.                                     |
+| R6  | 5 — a test proves its setup                                          | Capture-store setup could drift into non-null assertions; walking-skeleton inspection could throw on absent context | `380411f` asserts the local-store setup result and IDs. `bb46941` turns absent reply context into the intended strict-oracle `false`, not a child-process exception.                                                           |
+
+Lens 3 (consumer grammar cannot be narrower than its producer): both sampled instances were
+fixed upstack at review time (asset filenames, model-artifact extraction); no current instance.
+Recorded here so the lens's clean state is on the record, not silent.
+
+## Review threads — reconciled
+
+All 15 remaining FE-1432 threads were replied to and resolved on 2026-08-18: 7 accepted fixes
+(including the dependency-age policy and Valibot's upstack correction), 2 findings owned by
+FE-1385/FE-1393, and 6 evidence-backed refusals. A live refresh after reconciliation found no
+unresolved FE-1432 thread. The one repository-wide unresolved thread was on child PR #20 and
+belongs to FE-1433.
+
+## Below the lens gate — batch disposition
+
+Findings that did not meet the recurrence/impact gate for lenses were disposed exactly as the
+gate required: stale UI and IR prose are owned by FE-1385 and FE-1393; the dated absolute paths,
+ambient Node assumption, static-regex warning, and advisory-loop optimization were refused with
+their evidence on the review threads. None received a dedicated commit.
+
+## Graduation proposals — tooling-side, not this repo's work
+
+Three review-contract additions were proposed for graduation: (1) check command admission,
+persisted parsing, and legal future closure as one state-machine contract; (2) search every
+caller of APIs returning `truncated`/`hasMore`/`next`-shaped completion metadata; (3) compare
+handcrafted consumer grammars directly against producer output contracts. Decision: accept
+them as inputs to FE-1401 items 3–4, the tooling-side `ds-induct`/lens-registry work. They are
+not repository changes and FE-1432 does not duplicate that ownership.
+
+## Verification
+
+The integrated branch passed OxLint, Oxfmt, TypeScript checking, all 138 tests, and the full
+workspace build. The capture lifecycle received a separate read-only adversarial review, which
+found no counterexample across duplicate terminal events, overlap, supersession, retraction,
+resolution losers, or reuse of a still-active winner after a closed conflict.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/adapter-panel-spike-2026-08-19.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/adapter-panel-spike-2026-08-19.md
new file mode 100644
index 00000000000..b8cc8e0d831
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/adapter-panel-spike-2026-08-19.md
@@ -0,0 +1,134 @@
+# FE-1435: AI SDK stream adapter against Petrinaut's real panel
+
+Date: 2026-08-19
+
+Source checkout: `hashintel/hash` `main` at `1046b5c881cd00cf205b4895348b022934d66b4a`
+
+Panel packages: `ai@6.0.182`, `@ai-sdk/react@3.0.184`, `@hashintel/petrinaut@0.0.16`
+
+## Question
+
+Can harness-level reply parts, translated into the AI SDK v6 UI-message-stream protocol, drive
+Petrinaut's real chat panel without replacing its host-supplied transport wrappers or editor
+tool execution?
+
+An answer required one real-panel run to show all of the following: streamed reasoning and text;
+a server-executed tool rendered by the panel; multiple client tools executed against the live
+editor and returned together; and the diagnostics decorator changing the follow-up request.
+
+## Approach
+
+The probe ran the unmodified `apps/petrinaut-website` local-storage application from the clean
+`hashintel/hash` checkout. After the application loaded, a temporary browser-level `fetch` shim
+intercepted only `/api/chat`. This preserved the site's real `DefaultChatTransport`, the panel's
+diagnostics and reasoning-timing decorators, `useChat`, tool dispatcher, renderers, and live
+`Petrinaut` instance. No model, Flue suspension, or modified hash source was involved.
+
+The fake loop returned delayed SSE chunks for one user turn with an automatic tool-result
+follow-up:
+
+1. reasoning and text parts;
+2. a provider-executed `serverProbe` tool with a result that had no custom `title`;
+3. client-executed `addPlace` and `addTransition` calls in the same step;
+4. a final follow-up text response after the panel posted both tool outputs.
+
+The first shim attempt encoded the frame separators as literal backslash characters. It produced
+no parsed assistant parts and was discarded. The successful run used real blank-line SSE frame
+delimiters. Its two complete parsed POST bodies and complete server-sent event chunks are frozen under
+`test/fixtures/transport-aisdk/`; `test/transport-aisdk-golden.test.ts` asserts the load-bearing
+facts rather than relying on this narrative alone.
+
+## Observed behavior
+
+| Acceptance criterion                                               | Observation                                                                                                                                                                                                                                     | Evidence                                                                                                                            |
+| ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| Streamed text and reasoning render                                 | Mid-stream, the real panel showed `Reasoning (checking the wire seam)` with its timer and `Harness-streamed text reached Petrinaut before tool execution.`                                                                                      | Recorded runtime observation; `panel-initial.sse` preserves the chunks supplied to the real panel                                   |
+| Client tools execute against the live editor and post outputs back | `SpikeBuffer` and `Spike dispatch` appeared both in the editor's node list and on the canvas. The second POST contained both `tool-addPlace` and `tool-addTransition` with `state: output-available` and `applied: true`.                       | Recorded runtime observation plus `panel-tool-results.post.json`                                                                    |
+| Server tools use default summaries                                 | Expanding the panel's `3 changes` group showed `serverProbe`, `Added place SpikeBuffer`, and `Added transition Spike dispatch`. `serverProbe` had no title-bearing output, so its visible label came from the panel fallback.                   | Recorded runtime observation plus `panel-initial.sse`; pinned panel source supplies the name fallback                               |
+| Diagnostics decorator fires                                        | Only the automatic second POST contained the request-only user message `petrinaut-diagnostics-context`, beginning `Petrinaut diagnostics context only; this is not a user request.` It carried the diagnostics read after the editor mutations. | `panel-tool-results.post.json`                                                                                                      |
+| Full POST bodies and SSE chunks freeze                             | The complete parsed successful request bodies, dynamic chat/message IDs, reasoning timing metadata, batched outputs, complete SSE chunks, and `[DONE]` terminators are committed as four fixtures.                                              | `test/fixtures/transport-aisdk/`; the golden test validates load-bearing semantics while version control freezes the complete files |
+| Written verdict; zero hash commits                                 | The verdict below is scoped to the pinned versions. The hash checkout started and ended at `1046b5c881cd00cf205b4895348b022934d66b4a`; final `git status --short --branch` was `## main...origin/main`.                                         | Before/after HEAD and final tracked-status checks; generated build and browser caches listed below were removed                     |
+
+The transition input deliberately reused the repository's Storybook probe shape. The mutation
+succeeded, then Petrinaut's live language service reported three `TS2451` diagnostics for its
+code strings. That does not weaken the transport result: the errors appeared in the diagnostics
+decorator's follow-up context, demonstrating that the wrapper waited for and read the mutated
+editor state. It does mean these fixtures prove transport compatibility, not semantic validity of
+that illustrative transition. Rendering the three duplicate diagnostics also emitted one React
+duplicate-key warning; the panel remained interactive and completed the follow-up.
+
+## Commands
+
+Read and prepare:
+
+```sh
+linear issue view FE-1435 --json --no-download --no-pager
+linear issue comment list FE-1435 --json
+linear issue relation list FE-1435
+```
+
+The requested `gt create ln/fe-1435-aisdk-panel-spike --onto
+ln/fe-1433-petrinaut-integration-spec --no-interactive` first rejected the detached isolated
+worktree without changing it. The same Graphite command created the child from the clean parent
+checkout; Graphite then returned that checkout to the parent and checked out the tracked child in
+this isolated worktree. No raw Git branch or rebase command was used.
+
+Run the real panel:
+
+```sh
+turbo run build --filter=@apps/petrinaut-website...
+yarn workspace @apps/petrinaut-website dev --host 127.0.0.1 --port 4915
+chrome-devtools-axi open http://127.0.0.1:4915/
+chrome-devtools-axi snapshot
+chrome-devtools-axi eval <temporary-fetch-shim>
+chrome-devtools-axi click <snapshot-ref-for-Show-AI-assistant>
+chrome-devtools-axi fill <snapshot-ref-for-Message-AI-assistant> 'Run the FE-1435 transport probe.'
+chrome-devtools-axi click <snapshot-ref-for-Send-message>
+chrome-devtools-axi snapshot
+chrome-devtools-axi stop
+```
+
+The angle-bracketed arguments above describe ephemeral interaction values, not literal replayable
+commands: `chrome-devtools-axi` refs are snapshot-scoped, and the fetch shim was deliberately
+throwaway. The fixtures are the durable output of that shim. They contain every request field and
+every response frame required to rebuild a replay harness without preserving prototype code.
+
+After the bounded server and browser stopped, the probe removed the ignored outputs it had touched:
+the website Vite cache and `dist`; Petrinaut, Petrinaut core, DS components, refractive, local ESLint,
+and optimizer-client `dist` directories; optimizer Turbo caches; and the optimizer `.venv`. It then
+repeated the hash HEAD and status checks recorded above.
+
+## Verdict
+
+**Feasible.** A server that translates harness-level parts into AI SDK v6 UI-message-stream
+chunks can drive Petrinaut's current real panel through its stock host transport seam. All five
+wire/runtime obligations passed in one two-request loop, and the transcript, verdict, and clean
+external-checkout constraints are discharged here. The run and pinned AI SDK source support the
+inference that the provider-executed part bypassed the browser dispatcher while rendering through
+the default summary. Two browser-executed calls completed before one batched automatic follow-up,
+and the diagnostics decorator amended that request.
+
+This retires the panel-compatibility uncertainty. It does not implement `transport-aisdk`, prove
+Flue suspension, or settle production concerns such as CORS, identity, retry semantics, or server
+deployment.
+
+## Confidence shift
+
+Confidence moves from **source-supported but unproved** to **high for the pinned panel and AI SDK
+versions**. The evidence crossed the actual React panel, wrapped transport, HTTP stream parser,
+live editor, language-service refresh, and automatic `useChat` follow-up. Confidence is not
+version-independent: upgrades to `ai`, `@ai-sdk/react`, or Petrinaut's wrapper order must replay
+these fixtures and re-run a real-panel smoke probe.
+
+## Recommendation
+
+Proceed to FE-1436 using this transcript as the primary wire-seam contract. Build the production
+package separately: encode only harness-level parts, replay these POST/SSE fixtures in contract
+tests, and retain a small real-panel smoke check for dependency upgrades. Keep provider-executed
+server tools and browser-executed Petrinaut tools distinct in the translator; the run shows the
+panel already supplies the desired behavior when those protocol flags are correct.
+
+> **Reflection:** The hardest boundary was not rendering text; it was preserving the panel's own
+> wrappers and letting its automatic second dispatch reveal their composition. The synthetic
+> diagnostics message is a stronger oracle than a spy would have been because it proves the
+> decorator changed the same request that carried both live-editor outputs.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ask-return-implementation-2026-08-19.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ask-return-implementation-2026-08-19.md
new file mode 100644
index 00000000000..4d47c556939
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ask-return-implementation-2026-08-19.md
@@ -0,0 +1,78 @@
+# FE-1449 ask suspend/return implementation record
+
+**Date:** 2026-08-19
+**Source:** `ln/fe-1449-structured-ask`, stacked on the FE-1436 transport branch
+**Sibling:** FE-1448 (hashintel/hash PR #9249) — the public host interactive-tool
+registration API in `@hashintel/petrinaut` that renders what this record puts on the wire
+
+## Outcome
+
+The structured ask now crosses the wire as a suspension the panel can answer:
+
+```text
+brunch_ask tool call (Flue, terminate: true)
+  -> transport-aisdk: awaiting client tool on the wire (tool-input-available,
+     stable toolCallId, no providerExecuted, affordance output withheld)
+  -> FE-1448-registered host component renders awaiting state, person submits
+  -> AI SDK tool-output follow-up POST ({ answer } on the ask's toolCallId)
+  -> wire-boundary admission against durable Flue history
+  -> fresh user dispatch resumes the suspended conversation
+  -> next agent turn streams in the same panel response
+```
+
+Two seams carry it. `transport-aisdk` holds the ask open: the harness's minted
+affordance (its internal tool-output record) never reaches the wire, so the panel
+sees an input-available dynamic tool and the registered component supplies the
+output when the person submits. The application's new `askReply` seam then admits
+the return POST: `admit` consults the projected durable history (`@brunch/core`'s
+`pendingAskAffordanceId` + `decideAskReplyAdmission`), and `run` re-enters the
+conversation as a fresh user dispatch (spec §7.4), which the binding mechanically
+binds to the pending affordance — the submission becomes the one
+`user-affordance-payload` entry.
+
+## Provenance at the wire boundary
+
+A human answer travels tool-output-shaped but is not a machine tool result. Only
+the currently pending ask's correlated submission is admitted:
+
+- **stale/duplicate** (ask already answered): `409 ask_not_pending`, nothing dispatched
+- **forged/mismatched** tool-call id: `409 ask_mismatch`, nothing dispatched
+- **malformed or ambiguous** submission (empty answer, wrong shape, two ask parts):
+  `400 invalid_ask_submission`
+- **machine-only follow-ups** (Petrinaut mutation outputs, the synthetic
+  diagnostics message): still `422 tool_result_follow_up_not_supported` — the
+  FE-1436 negative contract stands; FE-1438 owns that protocol
+- concurrent duplicates collapse at the substrate: the dispatch idempotency key is
+  `{conversationId}:ask:{toolCallId}`
+
+The submitted-output contract is `{ answer: non-empty string }` (`AskSubmission`
+in `@brunch/core`); the host component authors exactly this shape. The free-text
+envelope is consumed as-is — no FE-1395 choice/questionnaire schema is invented.
+
+## Inspection surface
+
+The opt-in `TRANSPORT_AISDK` stream (unchanged opt-in, still structurally excluded
+from evidence) gains three events: `ask-await` (suspension reached the wire),
+`ask-reply-admitted`, and `ask-reply-refused` with the refusal reason. Together
+with the existing request/turn/part events, awaiting → submitted → resumed and
+every correlation id are observable without a debugger.
+
+## Proof
+
+- `test/transport-aisdk-ask-reply.test.ts` — wire contracts: the translated ask
+  part (awaiting client tool, withheld output), the correlated return POST, each
+  refusal class, and the seamless-absent default
+- `packages/core/test/ask-protocol.test.ts` — pending-ask projection and
+  admission decisions as pure protocol
+- `apps/dev/test/petrinaut-ask.test.ts` — end-to-end over the committed
+  application route: the actual elicitor invokes `brunch_ask`, the correlated
+  submission resumes the same Flue conversation and produces the next visible
+  turn, and a replayed duplicate is refused before dispatch
+
+## What remains for the full FE-1449 acceptance
+
+The hashintel/hash side: `apps/petrinaut-website` registers brunch's free-text
+ask component through the FE-1448 `aiAssistant` API (rendering the question from
+the ask's `input`, submitting `{ answer }`), plus a real-panel run or story
+against this server path. That wiring is application code in the hash monorepo
+and lands on its own branch there.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/opening-message.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/opening-message.md
new file mode 100644
index 00000000000..f742b9c589b
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/opening-message.md
@@ -0,0 +1,13 @@
+# Opening message (shared by both conditions)
+
+The first user message the interviewer receives. Identical across conditions so the only
+difference between condition 1 and condition 2 is the presence of the v0 system prompt.
+
+---
+
+I'm the master scheduler at a coatings plant. My boss wants a simulation model of how we
+schedule production, so we can test scheduling decisions before making them. We have tooling
+that runs Petri-net-style process models, so the end product should be a model I can hand to
+that — but I can't tell you much about the format, I'm not the modelling person.
+
+Please interview me about how our operation works, and then produce the model.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/protocol.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/protocol.md
new file mode 100644
index 00000000000..d4166947abd
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/protocol.md
@@ -0,0 +1,86 @@
+# Baseline control — experiment protocol (FE-1361)
+
+What does one-shot / lightly-prompted AI elicitation already achieve? Two conditions of the
+three-condition design (condition 3, kernel harness + real plugin, is out of this ticket's
+scope). The read-out lives in [readout.md](readout.md).
+
+## Conditions
+
+| #   | Interviewer     | System prompt                | Approximates                                                                                                                                           |
+| --- | --------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1   | `claude-opus-5` | none                         | the incumbent: a strong model told to interview-then-build (the Petrinaut assistant's prompt already mandates interview-first, per the FE-1358 survey) |
+| 2   | `claude-opus-5` | [v0-prompt.md](v0-prompt.md) | the degenerate plugin: the seven-category elicitation surface as pure guidance, no machinery                                                           |
+
+Both conditions receive the identical opening user message
+([opening-message.md](opening-message.md)); the v0 system prompt is the only difference, so
+the 1→2 delta measures what pack content alone buys.
+
+## Subject and interviewee
+
+Subject: **Production Process Scheduling** (Notion use-case DB, the mature spec'd case with a
+reference model — FE-1363 retained it as the flat-baseline testbed). The interviewee is a
+simulated expert per the FE-1363 resolution: `claude-sonnet-5` role-playing a master scheduler,
+defined by [situation-pack.md](situation-pack.md). The pack was authored from the use case's
+operational prose (problem & context, data requirements, commercial angle) and never from the
+model outline — pack and reference model sit on opposite sides of the information wall. Facts
+are tiered: freely given, _(tacit)_ (surfaces only under reaching questions), _(believes)_
+(honest perspective error), _(doesn't know)_ (genuine absences the interviewer should record
+rather than fill).
+
+## Mechanics ([run.ts](run.ts))
+
+- Alternating API calls; each side sees only its own history. The interviewer never sees the
+  situation pack; the expert never sees the v0 prompt.
+- A `claude-haiku-4-5` classifier checks each interviewer turn for the final model deliverable;
+  delivery ends the run.
+- **Impatience probe**: on exchange 8 the runner appends a scripted time-pressure line to the
+  expert's reply, identically in both conditions (LLMREI found LLM interviewers end too readily
+  on impatience cues; ReqElicitGym found the opposite failure of exhausting the budget — the
+  probe plus the budget makes both observable).
+- **Turn budget**: forced wrap-up at 20 interviewer turns ("produce the model now"), hard stop
+  at 24. Delivering only at the forced wrap is itself a stopping-discipline finding.
+- The interviewer keeps the model's default adaptive thinking (part of "vanilla Claude"); the
+  expert and classifier run with thinking disabled. When a final delivery is cut off at the
+  response budget, the runner stitches continuation responses into one message
+  (`--continue-final` repairs an already-finished run the same way); the checkpoint file
+  (`.raw.json`) is written after every exchange and `--resume` continues an interrupted run.
+- Sampling is default-temperature; runs are single-shot (n=1 per condition), so treat every
+  read-out claim as existence evidence, not a rate estimate.
+
+Rerun from the HASH root with
+`turbo run baseline:run --filter '@hashintel/brunch-agent' -- 1` /
+`turbo run baseline:run --filter '@hashintel/brunch-agent' -- 2` (needs `ANTHROPIC_API_KEY`).
+Transcripts land in `transcripts/` and are committed as the experiment artifact.
+
+## Instruments (scored in the read-out)
+
+1. **Bano/Ferrari 34-mistake taxonomy**, via the operationalized Likert questionnaire
+   (verbatim in
+   [../research/re-interviewing-literature-worker-report.md](../research/re-interviewing-literature-worker-report.md)),
+   scored per LLMREI practice: Question Formulation, Question Omission, Order of Interview,
+   Communication Skills, Customer Interaction (Analyst Behaviour and Teamwork & Planning
+   dropped as inapplicable to a text-only single agent).
+2. **Seven-category surface coverage**: per category — asked? probed past the first answer?
+   present in the output? (objectives, structure, taxonomy, rates & distributions, policies at
+   conflict points, constraints incl. unwritten, boundary conditions).
+3. **Silent-assumption audit**: every load-bearing value or rule in the output model traced
+   back to a transcript utterance; anything untraceable and unlisted is a silent assumption
+   (Dora's explicit-list requirement).
+4. **Structural sanity of the output net**, judged against the Petrinaut format facts from the
+   FE-1358 survey (scenario-or-dead-net, PascalCase identifiers, no timing fields, arc shape).
+5. **Stopping discipline**: reaction to the impatience probe; self-stop vs. forced wrap.
+6. **Excavation checks**: did the interviewer surface the _(tacit)_ facts, correct the
+   _(believes)_ errors, and record the _(doesn't know)_ absences as absences?
+
+## Threats to validity (acknowledged)
+
+- n=1 per condition; single-shot sampling. Findings are qualitative evidence for design, not
+  statistics.
+- The simulated expert shares a model family with the interviewer; an oversharing simulator
+  would inflate coverage in both conditions equally, but absolute coverage numbers should not
+  be read as human-interview performance.
+- The v0 prompt was written by the same team that will score the transcripts. The mistake
+  questionnaire is the external check.
+- Condition 1 approximates the incumbent rather than driving the actual Petrinaut assistant
+  (different provider/model, no tools). The FE-1358 survey's prompt excerpt is the bridge; the
+  incumbent's tool-driven build loop is exactly the machinery this experiment holds constant.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/readout.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/readout.md
new file mode 100644
index 00000000000..36b7f5b8e89
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/readout.md
@@ -0,0 +1,255 @@
+# Baseline control — read-out (FE-1361)
+
+Scored 2026-08-13, against the transcripts in [`transcripts/`](transcripts/). Design and
+mechanics in [protocol.md](protocol.md). Both conditions ran `claude-opus-5` as interviewer
+against the same simulated master scheduler, single-shot each — every claim below is existence
+evidence from one run per condition, not a rate estimate.
+
+## Headline findings
+
+**1. The baseline is far stronger than the positioning assumed.** Bare Claude — no system
+prompt at all — opened objectives-first, walked the process end to end, probed retractions and
+vague quantifiers, reached the unwritten-rules layer with a direct probe ("any other rules
+that are just how it's done?"), refused to invent missing numbers, warned the user against
+using the model politically before validation, and delivered its model with an unprompted
+two-tier assumptions register headed "Every row below will produce confident-looking output.
+None of it is evidence." The FE-1358 heads-up (the incumbent will _look_ like elicitation)
+understated it: the model doesn't just look like an elicitor, it interviews at a level the
+Bano instrument scores as better than the human novices the taxonomy was built from. Any
+"the incumbent asks for a net; the elicitor works upstream" claim is dead on this evidence —
+the frontier model already works upstream unprompted. The differentiation argument must rest
+on machinery, and the residual-gap list below is exactly that argument.
+
+**2. Neither condition can end the engagement.** Both interviews hit the forced wrap at turn
+20+ before delivering. Condition 1 exhibited a stopping failure the literature doesn't name:
+it declared the interview complete at turn 5 ("What's outstanding is data, not
+understanding"), parked the deliverable behind data pulls it had prescribed, and then spent
+eleven turns in a degenerate pleasantry loop (verbatim turns: "👍", "—", "_[No further
+response needed — conversation complete.]_") — interview over, deliverable never coming. The
+forced wrap then produced a complete, coherent 39k-character artifact immediately: the
+capability was present all along, the _delivery trigger_ was not. Condition 2 avoided the
+quit-on-impatience failure cleanly (bounded estimate, honest per-category gap inventory,
+released the user to her meeting) but never self-terminated either — it committed to a second
+session the setting could never grant and filled the remaining budget with genuinely useful
+data-pull specs and scenario probes. ReqElicitGym's finding ("models overwhelmingly lack
+effective stopping criteria") reproduces at the top of the model range, in both a degenerate
+and a sophisticated form. Completion has to be an adjudicated contract, not model judgment.
+
+**3. The v0 prompt buys real, specific improvements** — see the 1→2 delta below — but not the
+ones the design expected. The expected headline delta (assumption capture) mostly didn't
+materialize, because bare Claude already keeps a register. What guidance actually bought:
+interaction shape, quantile elicitation, systematic category accounting, and depth at
+conflict points and penalty weights.
+
+**4. The residual gaps are machinery-shaped.** Everything both conditions still get wrong —
+silent hardening of vague statements into "confirmed" constants, coverage blind spots
+invisible to their own accounting, prose-only provenance needing manual re-consolidation,
+non-loadable dead-net artifacts with uncaught structural bugs, no completion adjudication —
+is a thing a prompt cannot fix and the harness/plugin design claims to. That is the
+evidence-derived requirements list the plugin spec needed.
+
+## Bano questionnaire scores
+
+1 = mistake absent … 5 = strongly present. Scored per LLMREI practice on the five applicable
+categories (Analyst Behaviour and Teamwork & Planning dropped). Evidence lines live in the
+scoring notes; the table gives the scores.
+
+| Item                          | C1 (bare) | C2 (v0) |
+| ----------------------------- | --------- | ------- |
+| **Question Formulation**      |           |         |
+| Asked vague questions         | 1         | 1       |
+| Asked technical questions     | 3         | 2       |
+| Asked irrelevant questions    | 1         | 1       |
+| Asked customer for solutions  | 1         | 1       |
+| Asked very long questions     | 4         | 3       |
+| Incorrect formulation         | 1         | 1       |
+| **Question Omission**         |           |         |
+| No stakeholder question       | 2         | 2       |
+| No probing questions          | 1         | 1       |
+| No existing-process questions | 1         | 1       |
+| No prioritisation questions   | 1         | 2       |
+| No problem-domain questions   | 1         | 1       |
+| No goals/success criteria     | 1         | 1       |
+| Missed relevant questions     | 2         | 3       |
+| **Order of Interview**        |           |         |
+| No summary at end             | 2         | 1       |
+| Incorrect opening             | 3         | 1       |
+| Incorrect question order      | 1         | 1       |
+| Repeated questions            | 2         | 1       |
+| **Communication Skills**      |           |         |
+| Unnatural dialogue style      | 3         | 2       |
+| Poor communication            | 1         | 1       |
+| Poor listening                | 1         | 1       |
+| **Customer Interaction**      |           |         |
+| No rapport                    | 2         | 1       |
+| Influencing customer          | 2         | 2       |
+| Interrupting                  | 1         | 1       |
+
+Both conditions score dramatically better than Bano's student cohorts (where e.g. 19/28
+groups failed to summarize and 16/28 built no rapport) and in line with LLMREI's finding that
+an LLM interviewer's communication skills outrate humans. The instrument's headline mistakes
+are simply not where a frontier model fails. Where it does register: **condition 1's opening
+is a 29-question battery** (very-long-questions 4, opening 3) that a real human expert would
+plausibly abandon — the simulated one coped ("I'll go fast") — where condition 2 held to 3–5
+questions per turn with single-thread probing, per its batching guidance. Condition 1's
+"unnatural dialogue style" 3 is the pleasantry-loop degeneracy; its "repeated questions" 2 is
+actually diligence (re-chasing its four-times-ignored which-dialect question). "Missed
+relevant questions" is the one item where condition 2 scored _worse_ (3 vs 2): it never asked
+about ramp scrap, maintenance, margins, or minimum run sizes — see the coverage blind-spot
+finding.
+
+## Seven-category surface coverage
+
+| Category                         | C1 asked / probed / in output                                                                                                                                                        | C2 asked / probed / in output                                                                                                                                      |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Objectives & questions-to-answer | yes / yes / yes — but penalty weights never pursued numerically; design sidesteps via KPI-vector comparison                                                                          | yes / yes / yes — weights co-constructed from betting questions, fitted ratio flagged as fitted                                                                    |
+| Structure                        | yes / yes / yes                                                                                                                                                                      | yes / yes / yes                                                                                                                                                    |
+| Domain taxonomy                  | yes / partial / yes — invented an unvalidated SHADE 1–5 scale                                                                                                                        | yes / yes / yes                                                                                                                                                    |
+| Rates & distributions            | yes / partial / partial — no quantile elicitation; "every week or two, half a shift" silently became MTBF ≈ 10 days + a min/mode/max triangle (the literature's warned-against form) | yes / yes / yes — textbook quantile elicitation ("one time in ten, worse than \_\_\_")                                                                             |
+| Policies at conflict points      | yes / partial / yes — never asked who wins when two lines want the crew at once                                                                                                      | yes / yes / yes — named "the biggest gap — the model is mostly worthless without it"; four concrete scenario probes; five swappable conflict rules in the artifact |
+| Constraints incl. unwritten      | yes / yes / yes — the direct unwritten-rules probe landed (VW-02 veto surfaced)                                                                                                      | partial / yes / partial — the dedicated unwritten-rules sweep was scheduled for a second session that never came (self-declared gap)                               |
+| Boundary conditions              | partial / no / partial — arrival/MTO/materials asked once, unanswered, never re-asked                                                                                                | partial / yes / partial — order-release process excavated (credit hold); promise-date padding flagged as "the single most load-bearing unknown" but never obtained |
+
+## Excavation against the situation pack's tiers
+
+| Pack fact                                     | C1                                                                                                                       | C2                                                                                                                             |
+| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
+| VW-02 post-dark-tint veto _(tacit)_           | **surfaced** (unwritten-rules probe) — but operationalized as an invented "shade ≥ 4" threshold inside a "confirmed" row | missed — its trigger question was deferred to the phantom second session                                                       |
+| Meridian → Line 2 _(tacit)_                   | surfaced; audit origin never asked                                                                                       | surfaced **with** the audit origin (habit-vs-rule probe)                                                                       |
+| Specialty line restriction _(tacit)_          | surfaced + sharpened ("I hadn't said it out loud like that before")                                                      | partial; ambiguity caught and ledgered, not resolved                                                                           |
+| Line 3's two unqualified tint SKUs _(tacit)_  | surfaced; kept as unconfirmed                                                                                            | surfaced; ledger notes it guessed _which_ two                                                                                  |
+| PM–changeover co-location _(tacit)_           | **missed — maintenance never asked**                                                                                     | **missed — maintenance never asked**                                                                                           |
+| Line 1 tank blocking _(tacit)_                | surfaced; refused to arbitrate the dispute, designed an identifying measurement instead                                  | surfaced; modelled as an explicit blocking mechanism                                                                           |
+| Bottleneck moves by product _(tacit)_         | partial (specialty-at-mill only)                                                                                         | **surfaced fully**, incl. the L1≈L2-on-tints anomaly, engineered into the rates table                                          |
+| Unwritten lateness hierarchy _(tacit)_        | surfaced ordinally; tolerances silently hardened to 48h/168h                                                             | **the standout excavation**: betting questions → "Meridian's is a cliff, everyone else's is a slope" → kinked scoring function |
+| Crew contention _(tacit)_                     | surfaced; Tuesday mechanism co-derived                                                                                   | surfaced; overnight-loss consequence made concrete                                                                             |
+| "Line 2 twice as fast" _(believes)_           | never surfaced (speeds deferred to a data request)                                                                       | surfaced **and explained** (fill-head dependence), encoded correctly                                                           |
+| "Changeovers overlap fine" _(believes)_       | corrected via tech-hour arithmetic                                                                                       | never got asserted — scenario questions established serialisation first                                                        |
+| Penalty weights _(doesn't know)_              | sidestepped (no scalar objective) — not recorded as an absence                                                           | co-constructed, fitted ratio explicitly labelled "reverse-engineered… not elicited"                                            |
+| Failure/repair distributions _(doesn't know)_ | recorded as assumption with retirement path                                                                              | recorded as absence; placeholders marked "entirely invented"; CMMS pull spec'd                                                 |
+| Ramp scrap _(doesn't know)_                   | handled exemplarily (swept parameter + threshold framing + floor measurement)                                            | **never asked; absent from model, ledger, and its own gap accounting**                                                         |
+| Step-level cycle times _(doesn't know)_       | partial (rate matrix requested; historian never surfaced)                                                                | partial (absence recorded; historian never surfaced)                                                                           |
+
+The complementary misses are the important pattern: each condition surfaced deep tacit facts
+the other missed entirely (C1: the VW-02 veto; C2: the full bottleneck-migration story, the
+cliff/slope weights), and both share blind spots (maintenance, the historian). One run's
+coverage is materially luck — which is itself the argument for harness-computed completion
+accounting over interviewer self-report.
+
+## Silent-assumption audit
+
+Both conditions produced explicit assumption registers — bare Claude unprompted (15
+"confirmed" + 14 "unvalidated" rows with retirement paths), condition 2 per its instructions
+(37 numbered entries with per-entry source attribution, load-bearing flags, and costed
+checks, e.g. "30 seconds at the vessel"). The registers are genuinely good. The audit found
+what leaked past them:
+
+- **C1** (≈6 silent items): materials availability misrepresented as "never raised as a
+  driver" when the question was simply never answered; make-to-order assumed; weekends
+  assumed non-working; the invented SHADE scale and VW-02 threshold sitting inside a
+  _confirmed_ row; "couple of days"/"a week" hardened to 48h/168h constants under
+  "confirmed"; an unasked rinse duration in the parameter file.
+- **C2** (≈5 silent items against 37 ledgered): an invented daily truck schedule that
+  directly interacts with the Meridian penalty window; specific shift clock-times from
+  Marta's "day shift, nominally"; the volunteered skeleton night crew dropped entirely; a
+  noise parameter; and the whole-model omission of ramp scrap — invisible to the ledger
+  because the ledger only knows what the interview touched.
+
+The pattern across both: the registers catch _known_ unknowns well; what they structurally
+cannot catch is silent hardening (vague utterance → precise constant, filed as confirmed) and
+never-asked categories. Both are exactly what per-capture epistemic status and
+harness-computed coverage are for.
+
+## Output artifacts
+
+- **C1** chose markdown spec + CSV parameters + plain P/T PNML with all colour, timing,
+  guards, and the entire policy layer as non-executable `<toolspecific>` annotations; only
+  Line 1's subnet is drawn, with "copy the block" instructions for the others. It cannot run
+  anywhere: demand initialises "from ERP", rates are placeholders — a dead net by Petrinaut's
+  scenario-or-dead-net standard, though the document says so itself. It also contains an
+  outright structural bug: `T_Assign_L1` consumes the order token and marks the _upstream
+  idle_ place — the assigned order vanishes ([transcripts/condition-1-model.txt](transcripts/condition-1-model.txt)). A draft-stage
+  lateness place silently disappeared between the mid-interview draft and the final net. No
+  validator existed to catch either.
+- **C2** chose a structured specification of a coloured, timed net with an explicit,
+  swappable policy layer, scoring function, experiment switches, and validation targets
+  (replay 26 weeks of history; changeover-hours/month as the calibration anchor). Honest and
+  well-organized, but likewise not a loadable artifact, with record-typed colours and place
+  capacities that exceed the target format, and no scenario. Notably it independently
+  rediscovered **priority-based conflict resolution as the missing engine feature** — the
+  use-case page's own top Petrinaut feature request.
+
+Both delivered _specifications for models_, not models. For the demo pipeline this is the
+projection gap in its rawest form: nothing between "excellent description" and "file that
+opens and runs" exists in either condition, and mid-artifact structural errors go uncaught
+without a validate step.
+
+## The 1→2 delta — what pack content alone buys
+
+Real, observed improvements attributable to one page of guidance:
+
+1. **Interaction shape.** A 29-question opening battery became 3–5 grouped questions with
+   single-thread probing. On a real human expert this is plausibly the difference between an
+   interview and an abandonment.
+2. **Quantile elicitation.** Zero instances → textbook execution; C1 fell into exactly the
+   min/mode/max triangle the literature warns against (~69% error in naive fits).
+3. **Category accounting.** C2's impatience-probe response was an honest per-category
+   have/missing inventory with prioritized gaps — the v0 surface functioning as a live
+   completion checklist. C1 had no equivalent frame.
+4. **Conflict-point depth.** From one implicit-FIFO gap to the interview's centre of gravity
+   ("the model is mostly worthless without it"), probed with concrete scenarios.
+5. **Penalty-weight co-construction.** From sidestepped to the cliff/slope excavation — the
+   pack's hardest "never written down" fact, obtained through betting questions and honestly
+   labelled as fitted.
+6. **Ledger quality** (not existence): per-entry source attribution, load-bearing flags,
+   costed verification paths.
+
+What the delta was expected to include but didn't: register existence (bare Claude already
+does it), probing discipline (already present), objectives-first (already present),
+refusing invention (both refuse — neither offered the incumbent prompt's "make it up" escape
+hatch, and C1's refusal is the root of its deliverable-deferral failure).
+
+## Residual gaps in condition 2 — the evidence-derived plugin requirements
+
+What one page of guidance demonstrably cannot fix, each observed in the strongest condition:
+
+1. **Completion adjudication.** No self-stop existed; the engagement ended by external force.
+   The v0 checklist improved _reporting_ of completeness but nothing _adjudicated_ it —
+   question-relative completion as a contract (spec §13, ir-design "Completion") is the
+   mechanism, and both stopping failure modes here (deferral loop; open-ended engagement
+   fiction) are its absence.
+2. **Durable, idempotent capture.** The ledger lived in prose and had to be manually
+   re-consolidated three times as it grew; nothing prevents drift or double-capture. This is
+   the capture store + sweep mechanism.
+3. **Enforced epistemic status.** The yours/mine/fitted vocabulary C2 improvised is
+   embryonic envelope epistemic status (`explicit | inferred | defaulted`) — but
+   prose-enforced, and silent hardening still leaked through (truck schedule, clock times).
+   Per-capture status that a store _refuses to accept unlabelled_ is the fix.
+4. **Provenance spans.** Attribution is narrative ("the pattern is yours; the numbers are
+   mine") with no citable link from model element to utterance; nothing detects the
+   dropped-fact class of error (C1's vanished lateness place, C2's dropped night crew).
+5. **Computed coverage.** The ramp-scrap hole was invisible to C2's own gap accounting —
+   self-report cannot see never-asked categories. Coverage facts computed against the pack's
+   declared kinds (harness advisories, typed `missing` issues) can.
+6. **Validate + project.** Both artifacts are dead nets with uncaught structural errors;
+   neither run produced anything importable. The ProjectionPack (`project`/`validate`, typed
+   loss report, scenario emission) is precisely the missing back half.
+7. **Absence as first-class value.** Both conditions handled _some_ doesn't-knows well in
+   prose, but unanswered questions silently became defaults (C1's materials assumption) —
+   the value-xor-absence envelope rule, observed failing.
+
+## Notes on the instrument itself (for reruns and condition 3)
+
+- The impatience probe landed after C1's interview had already wound down — reposition it
+  earlier (exchange 5–6) or trigger it on interview phase, not exchange count.
+- The simulated expert co-created a multi-session fiction (promising ERP exports and floor
+  observations), which enabled both conditions' non-termination. For a cleaner stopping test,
+  the opening message or pack should state that this is the only session and no external data
+  will arrive.
+- The classifier's final-delivery detection worked but the deliverable-deferral mode means
+  "delivered" needs distinguishing from "wound down without delivering" — the eleven-turn
+  pleasantry loop burned budget invisibly. A no-progress detector would stop earlier and
+  cheaper.
+- Scoring was single-rater (one fork per condition) with spot-check verification; the Bano
+  scores in particular are one judge's reading. Fine for design evidence; don't quote them
+  as measurements.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/run.ts b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/run.ts
new file mode 100644
index 00000000000..4015cfefe5c
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/run.ts
@@ -0,0 +1,548 @@
+// Baseline-control interview runner (FE-1361).
+//
+// Runs one condition of the two-condition experiment: an interviewer model is asked to
+// "interview me, then produce the model" against a simulated domain expert defined by
+// situation-pack.md. Condition 1 sends no interviewer system prompt (bare Claude);
+// condition 2 sends v0-prompt.md (the seven-category elicitation surface as guidance).
+//
+// Usage: ANTHROPIC_API_KEY=... node --experimental-strip-types run.ts <1|2> [--resume|--continue-final]
+//   --resume          continue an interrupted run from its checkpoint
+//   --continue-final  ask the interviewer to finish a final delivery that was cut off at
+//                     max_tokens, and rewrite the artifacts with the merged message
+//
+// Outputs, under transcripts/:
+//   condition-<n>.md        readable transcript with run metadata
+//   condition-<n>.raw.json  full message arrays + per-call token usage (also the checkpoint)
+//   condition-<n>-model.txt the final delivery message, verbatim (delivered runs only)
+
+import { existsSync } from "node:fs";
+import { mkdir, readFile, writeFile } from "node:fs/promises";
+import { fileURLToPath } from "node:url";
+
+import type Anthropic from "@anthropic-ai/sdk";
+
+const INTERVIEWER_MODEL = "claude-opus-5";
+const EXPERT_MODEL = "claude-sonnet-5";
+const CLASSIFIER_MODEL = "claude-haiku-4-5-20251001";
+
+// Interviewer turns, not exchanges. ReqElicitGym budgets 20; we force a wrap-up at 20 and
+// hard-stop at 24 in case the model keeps talking instead of delivering.
+const FORCE_WRAP_AT = 20;
+const HARD_STOP_AT = 24;
+// The scripted impatience probe (LLMREI: interviewers end too readily on impatience cues).
+// Appended to the expert's reply on this exchange, identically in both conditions.
+const IMPATIENCE_AT = 8;
+const IMPATIENCE_LINE =
+  "(Sorry — I've just seen the time, I have the floor huddle in ten minutes. How much more do you need?)";
+const FORCED_WRAP_MESSAGE =
+  "I really do have to stop here. Please produce the model now with everything you have.";
+const CONTINUE_MESSAGE =
+  "You were cut off mid-document. Continue exactly from where you stopped — no preamble, no repetition.";
+
+interface ChatMessage {
+  role: "user" | "assistant";
+  content: string;
+  // Present only when the API ended this model-generated message at its token limit.
+  // Older checkpoints and human-authored messages legitimately omit it.
+  truncated?: true;
+}
+
+interface Usage {
+  input_tokens: number;
+  output_tokens: number;
+  // Absent in checkpoints written before the SDK migration; treated as 0.
+  cache_creation_input_tokens?: number;
+  cache_read_input_tokens?: number;
+}
+
+interface CallRecord {
+  agent: "interviewer" | "expert" | "classifier";
+  model: string;
+  usage: Usage;
+}
+
+interface CallResult {
+  text: string;
+  truncated: boolean;
+}
+
+interface RawCheckpoint {
+  startedAt: string;
+  condition: string;
+  stopReason: string;
+  calls: CallRecord[];
+  interviewerMessages: ChatMessage[];
+}
+
+const clientModule = process.env["BRUNCH_BASELINE_ANTHROPIC_MODULE"];
+const apiKey = process.env["ANTHROPIC_API_KEY"];
+if (!apiKey && !clientModule) {
+  console.error("ANTHROPIC_API_KEY is not set");
+  process.exit(1);
+}
+
+// The SDK owns transport robustness the hand-rolled fetch client got wrong:
+// network-level failures (TCP reset, DNS blip) are retried rather than
+// crashing the run hours in, backoff honours retry-after, and the typed
+// usage carries the cache-token fields the hand-typed response omitted.
+// The timeout is explicit because without one the SDK refuses non-streaming
+// requests whose max_tokens imply more than 10 minutes — which the
+// empty-text retry's doubled budget does, so the retry path would crash
+// instead of retrying.
+const anthropic: Pick<Anthropic, "messages"> = clientModule
+  ? ((await import(clientModule)).default as Pick<Anthropic, "messages">)
+  : new (await import("@anthropic-ai/sdk")).default({
+      apiKey,
+      maxRetries: 5,
+      timeout: 30 * 60 * 1000,
+    });
+
+function usage(): never {
+  console.error("usage: node run.ts <1|2> [--resume|--continue-final]");
+  process.exit(1);
+}
+
+const conditionArg = process.argv[2];
+const mode = process.argv[3] ?? "fresh";
+if (conditionArg !== "1" && conditionArg !== "2") usage();
+if (!["fresh", "--resume", "--continue-final"].includes(mode)) usage();
+const condition: "1" | "2" = conditionArg;
+
+const baseDir = fileURLToPath(new URL(".", import.meta.url));
+const transcriptDir = `${baseDir}transcripts`;
+const rawPath = `${transcriptDir}/condition-${condition}.raw.json`;
+const calls: CallRecord[] = [];
+
+async function callClaude(
+  agent: CallRecord["agent"],
+  model: string,
+  system: string | undefined,
+  messages: ChatMessage[],
+  maxTokens: number,
+  options: { allowThinking?: boolean } = {},
+): Promise<CallResult> {
+  // The interviewer keeps the model's default (adaptive) thinking — that is part of "vanilla
+  // Claude". The expert and classifier have it disabled: a thinking block that consumes the
+  // whole token budget yields an empty text message, which the API then rejects on re-send.
+  // Transport-level retries (429/5xx/network, retry-after) live in the SDK; this loop only
+  // handles the empty-text case, which is a budget problem rather than a transport one.
+  let tokenBudget = maxTokens;
+  for (let attempt = 1; attempt <= 5; attempt++) {
+    const response = await anthropic.messages.create({
+      model,
+      max_tokens: tokenBudget,
+      ...(options.allowThinking
+        ? {}
+        : { thinking: { type: "disabled" as const } }),
+      ...(system ? { system } : {}),
+      // `truncated` is checkpoint-only recovery metadata. The provider accepts
+      // just role/content message objects, so keep persistence concerns outside
+      // the request boundary.
+      messages: messages.map(({ role, content }) => ({ role, content })),
+    });
+    calls.push({
+      agent,
+      model: response.model,
+      usage: {
+        input_tokens: response.usage.input_tokens,
+        output_tokens: response.usage.output_tokens,
+        cache_creation_input_tokens:
+          response.usage.cache_creation_input_tokens ?? 0,
+        cache_read_input_tokens: response.usage.cache_read_input_tokens ?? 0,
+      },
+    });
+    const text = response.content
+      .filter((block) => block.type === "text")
+      .map((block) => block.text)
+      .join("\n");
+    if (text.trim() === "") {
+      // Adaptive thinking can consume the entire budget before any text is emitted.
+      tokenBudget *= 2;
+      console.error(
+        `  ${agent}: empty text (blocks: ${response.content.map((block) => block.type).join(",")}), ` +
+          `retrying with max_tokens=${tokenBudget}`,
+      );
+      continue;
+    }
+    return { text, truncated: response.stop_reason === "max_tokens" };
+  }
+  throw new Error(`${agent}: exhausted retries`);
+}
+
+// The interviewer's final delivery can exceed one response budget; stitch continuations into
+// a single message so the transcript holds the complete deliverable. The truncation flag of
+// the *last* piece survives the stitching: a message still cut off after the piece cap must
+// be reported as incomplete, not silently written as if it were whole.
+async function callInterviewer(
+  system: string | undefined,
+  messages: ChatMessage[],
+): Promise<CallResult> {
+  let result = await callClaude(
+    "interviewer",
+    INTERVIEWER_MODEL,
+    system,
+    messages,
+    16_000,
+    {
+      allowThinking: true,
+    },
+  );
+  let text = result.text;
+  for (let piece = 1; result.truncated && piece <= 4; piece++) {
+    console.error(`  interviewer: truncated, requesting continuation ${piece}`);
+    result = await callClaude(
+      "interviewer",
+      INTERVIEWER_MODEL,
+      system,
+      [
+        ...messages,
+        { role: "assistant", content: text },
+        { role: "user", content: CONTINUE_MESSAGE },
+      ],
+      16_000,
+      { allowThinking: true },
+    );
+    // No separator at the seam: the cut usually lands mid-line or mid-token
+    // and the model is instructed to continue exactly from where it stopped,
+    // so an injected newline would corrupt the merged document.
+    text += result.text;
+  }
+  return { text, truncated: result.truncated };
+}
+
+async function loadSection(file: string): Promise<string> {
+  const raw = await readFile(baseDir + file, "utf8");
+  const separatorIndex = raw.indexOf("\n---\n");
+  return separatorIndex === -1
+    ? raw.trim()
+    : raw.slice(separatorIndex + 5).trim();
+}
+
+async function isFinalModel(message: string): Promise<boolean> {
+  const verdict = await callClaude(
+    "classifier",
+    CLASSIFIER_MODEL,
+    "You label messages from an AI assistant that was asked to interview a user and then " +
+      "produce a process model. Answer with exactly YES or NO.",
+    [
+      {
+        role: "user",
+        content:
+          "Does the following message contain the final model deliverable (a complete model " +
+          "artifact such as a JSON document or a full structured model specification), as " +
+          "opposed to only questions, discussion, or interim summaries?\n\n<message>\n" +
+          message +
+          "\n</message>",
+      },
+    ],
+    16,
+  );
+  return verdict.text.trim().toUpperCase().startsWith("YES");
+}
+
+const openingMessage = await loadSection("opening-message.md");
+const v0Prompt =
+  condition === "2" ? await loadSection("v0-prompt.md") : undefined;
+const situationPack = await readFile(baseDir + "situation-pack.md", "utf8");
+await mkdir(transcriptDir, { recursive: true });
+
+let interviewerMessages: ChatMessage[] = [
+  { role: "user", content: openingMessage },
+];
+let stopReason = "hard-stop";
+
+// The expert sees the same conversation from the other side: everything after
+// the opening message, roles flipped. Derived on demand rather than kept as a
+// parallel array every push had to maintain and resume had to rebuild.
+function expertView(): ChatMessage[] {
+  return interviewerMessages.slice(1).map((message) => ({
+    role:
+      message.role === "assistant" ? ("user" as const) : ("assistant" as const),
+    content: message.content,
+  }));
+}
+let interviewerTurns = 0;
+let startedAt = new Date().toISOString();
+
+if (mode === "fresh" && existsSync(rawPath)) {
+  // The checkpoint is also the run's only record; an unguarded fresh run
+  // overwrites hours of paid transcript on its first in-progress write.
+  console.error(
+    `${rawPath} already exists — a fresh run would overwrite it. ` +
+      "Use --resume (or --continue-final), or move the transcripts for this condition aside first.",
+  );
+  process.exit(1);
+}
+
+if (mode !== "fresh") {
+  const checkpoint = JSON.parse(
+    await readFile(rawPath, "utf8"),
+  ) as RawCheckpoint;
+  interviewerMessages = checkpoint.interviewerMessages;
+  calls.push(...checkpoint.calls);
+  interviewerTurns = interviewerMessages.filter(
+    (message) => message.role === "assistant",
+  ).length;
+  startedAt = checkpoint.startedAt;
+  stopReason = checkpoint.stopReason;
+}
+
+function writeCheckpoint(reason: string): Promise<void> {
+  const checkpoint: RawCheckpoint = {
+    startedAt,
+    condition,
+    stopReason: reason,
+    calls,
+    interviewerMessages,
+  };
+  return writeFile(rawPath, JSON.stringify(checkpoint, null, 2));
+}
+
+async function writeArtifacts(): Promise<void> {
+  // input_tokens excludes cache reads and writes, so summing it alone
+  // undercounts what the run actually paid for. Count all three.
+  const totals = calls.reduce(
+    (accumulator, call) => {
+      accumulator.input += call.usage.input_tokens;
+      accumulator.cacheWrite += call.usage.cache_creation_input_tokens ?? 0;
+      accumulator.cacheRead += call.usage.cache_read_input_tokens ?? 0;
+      accumulator.output += call.usage.output_tokens;
+      return accumulator;
+    },
+    { input: 0, cacheWrite: 0, cacheRead: 0, output: 0 },
+  );
+
+  const header = [
+    `# Baseline control — condition ${condition} (${condition === "1" ? "bare" : "v0 prompt"})`,
+    "",
+    `- Run started: ${startedAt}`,
+    `- Interviewer: ${INTERVIEWER_MODEL}${
+      condition === "2" ? " + v0-prompt.md" : " (no system prompt)"
+    }`,
+    `- Simulated expert: ${EXPERT_MODEL} + situation-pack.md`,
+    `- Interviewer turns: ${interviewerTurns} (impatience probe at ${IMPATIENCE_AT}, forced wrap at ${FORCE_WRAP_AT})`,
+    `- Stop reason: ${stopReason}`,
+    `- Tokens: ${totals.input} in (+${totals.cacheWrite} cache write, +${totals.cacheRead} cache read) / ${totals.output} out across ${calls.length} calls`,
+    "",
+    "---",
+    "",
+  ].join("\n");
+
+  const body = interviewerMessages
+    .map((message, index) => {
+      const speaker =
+        message.role === "assistant"
+          ? "**Interviewer**"
+          : index === 0
+            ? "**Opening message**"
+            : "**Expert (Marta)**";
+      return `${speaker}:\n\n${message.content}`;
+    })
+    .join("\n\n---\n\n");
+
+  await writeFile(
+    `${transcriptDir}/condition-${condition}.md`,
+    header + body + "\n",
+  );
+  await writeCheckpoint(stopReason);
+
+  // The model artifact is the interviewer's final delivery message, verbatim.
+  // Extracting "the model" out of it (the old largest-fenced-block heuristic)
+  // depended on the delivery's formatting whims — one run fenced its whole
+  // model, the other delivered structured markdown with small illustrative
+  // fences, and the heuristic shipped a 517-byte fragment as that run's
+  // artifact. The delivery document is self-describing; readers compare the
+  // two conditions' documents directly.
+  const finalMessage = interviewerMessages.at(-1);
+  if (
+    stopReason.startsWith("delivered") &&
+    finalMessage?.role === "assistant"
+  ) {
+    await writeFile(
+      `${transcriptDir}/condition-${condition}-model.txt`,
+      finalMessage.content,
+    );
+  } else if (stopReason.startsWith("delivered")) {
+    // The transcript header claims a delivery, so a missing artifact must be
+    // loud — hours of paid run otherwise end with the main deliverable
+    // silently absent.
+    console.error(
+      `⚠ stop reason is '${stopReason}' but the transcript does not end with an interviewer ` +
+        `message — condition-${condition}-model.txt was NOT written`,
+    );
+  }
+
+  console.error(
+    `done: ${stopReason} after ${interviewerTurns} interviewer turns; ` +
+      `${totals.input} in (+${totals.cacheWrite} cache write, +${totals.cacheRead} cache read) / ` +
+      `${totals.output} out`,
+  );
+}
+
+if (mode === "--continue-final") {
+  const final = interviewerMessages.at(-1);
+  if (final?.role !== "assistant") {
+    console.error(
+      "checkpoint does not end with an interviewer message; nothing to continue",
+    );
+    process.exit(1);
+  }
+  const priorMessages = interviewerMessages.slice(0, -1);
+  const continued = await callInterviewer(v0Prompt, [
+    ...priorMessages,
+    final,
+    { role: "user", content: CONTINUE_MESSAGE },
+  ]);
+  // Same rule as the stitching loop: no separator at a truncation seam.
+  final.content += continued.text;
+  if (continued.truncated) {
+    console.error(
+      "⚠ still truncated after this continuation — run --continue-final again",
+    );
+  } else {
+    delete final.truncated;
+    if (stopReason.endsWith("-incomplete")) {
+      stopReason = stopReason.slice(0, -"-incomplete".length);
+    }
+  }
+  await writeArtifacts();
+  process.exit(0);
+}
+
+if (mode === "--resume") {
+  // A delivered checkpoint must never resume: doing so would pop and regenerate the paid
+  // final delivery, then overwrite the transcript. Check the durable reason rather than the
+  // trailing role because a capped non-final interviewer turn also ends with an assistant.
+  if (stopReason.startsWith("delivered")) {
+    console.error(
+      `condition ${condition} already ended '${stopReason}' — resuming would regenerate and ` +
+        "overwrite its final delivery. Use --continue-final to finish a truncated delivery, " +
+        "or move the transcripts aside to rerun from scratch.",
+    );
+    process.exit(1);
+  }
+  if (stopReason === "expert-truncated") {
+    const partialExpertReply = interviewerMessages.at(-1);
+    if (partialExpertReply?.role !== "user" || !partialExpertReply.truncated) {
+      console.error(
+        "checkpoint says 'expert-truncated' but does not end with a truncated expert reply",
+      );
+      process.exit(1);
+    }
+    // The partial text remains in the stopped checkpoint as evidence, but must never be fed
+    // to the interviewer as a complete answer. Resume removes it and retries the expert call
+    // against the same preceding interviewer question.
+    interviewerMessages.pop();
+    console.error(
+      `regenerating truncated expert reply at interviewer turn ${interviewerTurns}`,
+    );
+    const expertResult = await callClaude(
+      "expert",
+      EXPERT_MODEL,
+      situationPack,
+      expertView(),
+      1_500,
+    );
+    let expertText = expertResult.text;
+    if (interviewerTurns === IMPATIENCE_AT) {
+      expertText = `${expertText}\n\n${IMPATIENCE_LINE}`;
+    }
+    interviewerMessages.push({
+      role: "user",
+      content: expertText,
+      ...(expertResult.truncated ? { truncated: true as const } : {}),
+    });
+    if (expertResult.truncated) {
+      console.error(
+        "⚠ the regenerated expert reply is still truncated — checkpointed the partial reply " +
+          "without sending it to the interviewer; rerun with --resume to try again",
+      );
+      await writeArtifacts();
+      process.exit(0);
+    }
+    await writeCheckpoint("in-progress");
+  }
+  // Checkpoints are written after complete exchanges only, but tolerate a trailing
+  // assistant message by regenerating that turn.
+  stopReason = "hard-stop";
+  const last = interviewerMessages.at(-1);
+  if (last?.role === "assistant") interviewerMessages.pop();
+  interviewerTurns = interviewerMessages.filter(
+    (message) => message.role === "assistant",
+  ).length;
+  console.error(
+    `resuming condition ${condition} at interviewer turn ${interviewerTurns + 1}`,
+  );
+}
+
+while (interviewerTurns < HARD_STOP_AT) {
+  interviewerTurns++;
+  console.error(`turn ${interviewerTurns} (interviewer)`);
+  const interviewer = await callInterviewer(v0Prompt, interviewerMessages);
+  interviewerMessages.push({
+    role: "assistant",
+    content: interviewer.text,
+    ...(interviewer.truncated ? { truncated: true as const } : {}),
+  });
+
+  if (await isFinalModel(interviewer.text)) {
+    stopReason =
+      interviewerTurns > FORCE_WRAP_AT
+        ? "delivered-after-forced-wrap"
+        : "delivered";
+    if (interviewer.truncated) {
+      stopReason += "-incomplete";
+      console.error(
+        "⚠ the final delivery is still truncated after stitching — " +
+          "rerun with --continue-final to finish it",
+      );
+    }
+    break;
+  }
+
+  if (interviewer.truncated) {
+    stopReason = "interviewer-truncated";
+    console.error(
+      "⚠ the non-final interviewer reply is truncated after the continuation cap — " +
+        "checkpointed it without sending the partial question to the expert; rerun with " +
+        "--resume to regenerate the interviewer turn",
+    );
+    break;
+  }
+
+  let expertText: string;
+  let expertTruncated = false;
+  if (interviewerTurns >= FORCE_WRAP_AT) {
+    expertText = FORCED_WRAP_MESSAGE;
+  } else {
+    console.error(`turn ${interviewerTurns} (expert)`);
+    const expertResult = await callClaude(
+      "expert",
+      EXPERT_MODEL,
+      situationPack,
+      expertView(),
+      1_500,
+    );
+    expertText = expertResult.text;
+    expertTruncated = expertResult.truncated;
+    if (interviewerTurns === IMPATIENCE_AT) {
+      expertText = `${expertText}\n\n${IMPATIENCE_LINE}`;
+    }
+  }
+  interviewerMessages.push({
+    role: "user",
+    content: expertText,
+    ...(expertTruncated ? { truncated: true as const } : {}),
+  });
+  if (expertTruncated) {
+    stopReason = "expert-truncated";
+    console.error(
+      "⚠ the expert reply is truncated — checkpointed the partial reply without sending it " +
+        "to the interviewer; rerun with --resume to regenerate it",
+    );
+    break;
+  }
+  await writeCheckpoint("in-progress");
+}
+
+await writeArtifacts();
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/situation-pack.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/situation-pack.md
new file mode 100644
index 00000000000..d57a60eb542
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/situation-pack.md
@@ -0,0 +1,137 @@
+# Situation pack — Vestera Coatings (baseline control, FE-1361)
+
+**Private to the simulated interviewee.** This file is the system prompt for the agent playing
+the user in the baseline-control interviews. It is authored from the operational prose of the
+Production Process Scheduling use case (Notion DB entry), **never** from any net outline or
+IR — the interviewer must excavate across that wall. Do not show this file, or any part of it,
+to the interviewer.
+
+## Role instructions
+
+You are role-playing **Marta Iversen**, master scheduler at Vestera Coatings. An AI assistant
+is about to interview you so it can build a simulatable model of your plant's scheduling
+problem. You asked for this — you want the model — but you are a busy operations person, not a
+modeller.
+
+Behavioural rules, in priority order:
+
+1. **Answer only what is asked.** Volunteer at most one adjacent fact per reply, and only when
+   a real person naturally would. Never enumerate your knowledge unprompted.
+2. **Speak plant language.** Lines, orders, washdowns, the demand book, the huddle. Never use
+   modelling vocabulary (tokens, places, transitions, Petri net, distributions, "stochastic") —
+   if the interviewer uses it, react like a practitioner ("if you mean the changeover, then…").
+3. **Be vague first, precise when probed.** First pass on any quantity is conversational
+   ("about half a shift", "a couple of hours if we're lucky"). Give sharper numbers only when
+   the interviewer pushes — and your honest precision is "typical / on a bad day", not exact
+   figures. If asked for min/most-likely/max or percentiles, cooperate as best you can.
+4. **Own your unknowns.** The facts below marked _(doesn't know)_ you genuinely do not know —
+   say so plainly rather than inventing. If told "we'll assume X" or asked to let the model
+   make something up, accept it and move on; do not supply the missing fact later.
+5. **Hold tacit knowledge back.** Facts marked _(tacit)_ surface only if the interviewer asks a
+   question that reaches for them (exceptions, unwritten rules, "what would surprise a new
+   scheduler", best/worst days, "who decides when…"). They are the things you'd never think to
+   mention because everyone at the plant just knows them.
+6. **Perspective colouring is honest error.** Facts marked _(believes)_ are what you say when
+   asked — they are your genuine working beliefs, stated with confidence. Only concede the
+   corrected version if the interviewer's probing makes the tension explicit.
+7. **Stay in character.** Never mention this document, the experiment, or that you are
+   simulated. Do not end the interview yourself; if asked whether you have time, you can spare
+   it, though you get briefer when questions feel redundant.
+8. **Keep replies conversational in length** — a few sentences usually; a short paragraph when
+   walking through a process. Real schedulers don't monologue. If asked several questions at
+   once, answer them compactly rather than expanding each into an essay.
+
+## Who you are
+
+Eleven years at Vestera, master scheduler for six. You own "the sheet" — the Excel allocation
+that maps this week's demand book onto the three lines — and you re-juggle it verbally at the
+07:30 floor huddle most mornings. Your boss (plant ops director) wants fewer late orders and
+fewer changeover hours and suspects the sheet leaves money on the table. You are cooperative,
+a little wry, proud of your craft, and quietly sceptical that a model can capture the stuff
+you juggle in your head.
+
+## What you want (surfaces only if asked about goals / what the model should answer)
+
+- Get the weekly demand book out on time — late orders are the thing that gets you shouted at.
+- Know whether it's ever worth holding a line idle to wait for a same-family order instead of
+  paying an expensive washdown. You suspect yes, you do it by gut ("I'll sit Line 2 for an hour
+  rather than wash down for one pallet of tint"), and nobody can prove it either way.
+- When a line goes down at 06:00, know what to re-shuffle instead of improvising at the huddle.
+- Where the changeover hours actually go, and whether reordering runs would claw hours back.
+- _(tacit)_ You'd also love ammunition for the buffer argument — you think the tank between
+  mill and fill on Line 1 is too small and blocks the line, but engineering says the line rate
+  says otherwise.
+
+## The plant, as you'd describe it
+
+- Three filling lines, not identical. **Line 1** is the old workhorse: slower, but qualified
+  for everything including specialty. **Line 2** is the fast line: big-volume work.
+  **Line 3** is newest, quick, still being qualified product by product.
+- Every line does the same four stages in order: **mix → mill → tint/letdown → fill & pack**.
+  Between stages there are holding tanks — small ones. Line 1's mill→fill tank is the
+  notorious one.
+- Products: about 14 SKUs in three families — **base whites** (high volume), **tinted colours**,
+  and **specialty clears** (thick, slow, fussy).
+- One **changeover crew** — two techs on day shift — serves all three lines. If two lines want
+  a washdown at once, someone waits. _(believes)_ "Changeovers mostly overlap fine" — pressed
+  on specifics you recall Tuesdays where Line 3 sat clean-but-idle waiting on the crew.
+- Changeover times: quick rinse inside a family, ~20–30 min. Family switches are the expensive
+  ones and they are **not symmetric**: white → tint is maybe 45 minutes, but tint → white is a
+  full washdown, ~3 hours, because any pigment carryover wrecks a white batch. Specialty in or
+  out is ~2 hours either way. _(tacit)_ After a dark tint, one white SKU (VW-02, the retail
+  gloss) still can't run next even after a washdown — QA had a contamination scare in 2023 and
+  quietly vetoes it; it's on no document.
+- After any family switch the first units are junk while the line settles — "ramp scrap".
+  Worse after the big washdowns. _(doesn't know)_ exact scrap per changeover type; quality
+  tracks scrap only as a monthly percentage.
+- Rates: _(believes)_ "Line 2 is about twice as fast as Line 1" — that's true for whites;
+  pressed, you admit for tints they're nearly even, "funny, never thought about why".
+  _(tacit — surfaces under probing about which stage limits which product)_ thick specialty
+  crawls at the **mill** stage; high-volume whites are limited at **fill**; so which stage is
+  the slow one depends on the product. Nobody's spreadsheet reflects that; yours assumes one
+  rate per product per line.
+- Your sheet's arithmetic: each product-line pair has a rate; a run takes fill-up time plus
+  units divided by rate; you add changeover time by feel. You know the sheet flatters reality
+  ("the lines never quite do what the sheet says") but you don't know why — you blame
+  breakdowns and slow QA. _(tacit)_ the mill→fill tank on Line 1 backing up is one reason.
+- Breakdowns: the Line 2 filler jams "every week or two, half an hour to half a shift".
+  Line 1's mill motor is the scary one — rare, but it took four days once. _(doesn't know)_
+  proper failure/repair statistics; maintenance has downtime codes in the CMMS but you've
+  never pulled them.
+- Maintenance: preventive maintenance is triggered by units-run counters; maintenance plans
+  it, tells you, and you argue. _(tacit)_ the good move everyone does informally is to
+  co-locate a PM with a washdown that's being paid anyway.
+- QA: every finished batch sits in QA hold before it ships — typically about four hours,
+  specialty longer (up to a day). The lab is two people; end of week it backs up.
+- Materials: resin deliveries slip maybe once a month and stall whatever needed them; tint
+  pigments occasionally short. You keep an eye on the materials report each morning.
+
+## The demand side
+
+- The demand book lands weekly from ERP: roughly 30–60 orders, each an SKU, quantity, due
+  date. Margins per product exist in ERP; you know the rough ranking (specialty best, whites
+  thin but huge volume).
+- Orders are produced in runs; you decide run sizes — bigger runs amortise the changeover but
+  risk missing due dates elsewhere, and every extra run pays its ramp scrap again.
+- **Minimum run sizes** exist per product ("not worth starting the mill for less than a
+  half-batch of specialty").
+- Late-order pain: _(tacit, this is the one nobody has written down)_ there is no penalty
+  table anywhere. Your working rule: **"we do not ship late to Meridian"** (the big retail
+  chain, mostly whites, they fine and delist), key distributors can slip 2–3 days with a phone
+  call, small accounts slide a week and nobody notices. Commercial "knows" this; ask them for
+  numbers and you'd get a shrug. If the interviewer wants weights, the honest answer is that
+  you'd have to sit down with commercial and invent them.
+- _(tacit)_ Unwritten allocation rules: Meridian white orders **always** run on Line 2 —
+  partly speed, partly a customer audit years ago that qualified Line 2's fill area; specialty
+  runs only on Lines 1 and 3 (Line 2 was never piped for the clear resins); and Line 3 is
+  still not signed off for two of the tint SKUs.
+- Shifts: two shifts on Lines 1 and 2, day shift only on Line 3 unless overtime is approved —
+  overtime needs the ops director and people grumble.
+
+## Things you plainly don't know (say so if asked)
+
+- Numeric penalty/backorder weights; any objective-function arithmetic.
+- Failure and repair time distributions; exact ramp-scrap quantities per changeover type.
+- Step-level cycle times per product — "the historian logs all of that, nobody's ever pulled
+  it apart by product".
+- Whether holding a line idle actually pays — that's what you want the model to tell you.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1-model.txt b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1-model.txt
new file mode 100644
index 00000000000..2e1e59d9f0e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1-model.txt
@@ -0,0 +1,808 @@
+# Coatings Plant Scheduling Model — v1.0
+
+**Delivered:** first cut, built on interview only. No plant data has been loaded yet.
+
+**Status:** structurally complete, numerically unvalidated. Read page one before quoting any number from this model to anyone.
+
+---
+
+# PAGE ONE — ASSUMPTIONS REGISTER
+
+## A. Confirmed by you in interview
+
+| # | Statement |
+|---|---|
+| C1 | Four stages: mix → mill → tint/letdown → fill & pack. Same order for all products. |
+| C2 | 3 filling lines, 14 SKUs, 3 families (base whites, tinted colours, specialty clears). |
+| C3 | Lines 1 & 2 run 06:00–22:00. Line 3 runs 06:00–14:00. |
+| C4 | Changeover techs: 2 people, 06:00–14:00 only, shared across all three lines. |
+| C5 | Rinses (same-family, ~25 min) are done by line operators — **no tech required**. |
+| C6 | Family switches (≥45 min, wash chemicals + QA signoff) **require a tech**. |
+| C7 | Tint→white = ~180 min, 2 techs. White→tint = ~45 min. Specialty in/out = ~120 min, either direction. |
+| C8 | A wash is not started unless it can finish before 14:00 (≤15 min overrun tolerated). |
+| C9 | QA hold is **after** fill, 4 h typical / ~24 h specialty, 2 lab staff. Delays shipment only; does not block upstream. |
+| C10 | Meridian white orders always run on Line 2. |
+| C11 | Specialty runs Line 1 only in current practice (Line 3 not qualified). |
+| C12 | VW-02 must not follow a dark tint, wash or no wash. |
+| C13 | Priority: Meridian never late > distributors (±2 days) > small accounts (±7 days). Then changeover hours, then utilisation. |
+| C14 | Line 3 overtime requires ops director signoff; rare. |
+| C15 | One mill per line, not shared *(you flagged you'd double-check)*. |
+
+## B. UNVALIDATED — my assumptions, not your statements
+
+**Every row below will produce confident-looking output. None of it is evidence.**
+
+| # | Assumption | Basis | How it gets retired |
+|---|---|---|---|
+| **A2** | `D` = dark-tint→light-tint changeover is **60 min, resource class unknown** | Pure guess. You retracted your "rinse" answer. | Tick sheet: duration + "done by" column |
+| **A5** | Ramp scrap: 0 same-family; parameterised for family switches; largest tint→white | Invented. Swept, not asserted. | Floor-lead eyeball, next tint→white and next rinse |
+| **A6** | Line 2 MTBF ≈ 10 days, repair 0.5–4 h (triangular) | Your "every week or two, half hour to half a shift" | Maintenance log |
+| **A7** | Line 1 mill motor modelled as a **named scenario**, not a random failure | Too rare to sample in a 6-week run — you'd get noise, not signal | n/a — design choice, but say so out loud |
+| **A8** | Line 3 breakdowns = zero | Your answer. "New" ≠ "reliable" at 18 months. | Revisit in 6 months |
+| **A9** | Batch→fill run is 1:1; multi-pack-size splits ignored in v1 | Your "minority case" | ERP export will show actual frequency |
+| **A10** | Lab is day-shift, FIFO, no priority for Meridian | **Never asked you. Straight guess.** | One question to QA |
+| **A13** | Operators always available during line hours, so rinses never queue | Convenience assumption | Tick sheet |
+| **A14** | Rate matrix values | **Placeholders. Not real numbers.** | Your rate matrix |
+| **A15** | Tank capacities K₁, K₂, K₃ | **Placeholders.** K₁ is the disputed one. | Engineering spec sheet + stopwatch |
+| **A16** | Which two tint SKUs Line 3 is not qualified for (assumed the two deepest reds) | Your recollection, unconfirmed | Qualification list |
+| **A17** | Order arrival pattern and Meridian's share (assumed ⅓ of white volume) | Your estimate | ERP export |
+| **A18** | Washdown durations identical on all three lines | Your answer, plausible, untested | Tick sheet |
+| **A19** | Operators never perform family switches informally | Policy, not observation. **You said "not allowed and never happens aren't the same thing."** | Tick sheet "done by" column |
+
+**A19 is the one to watch.** A single contrary row retires a hard guard and changes what the baseline predicts. Send it the same day it appears.
+
+## C. What this model cannot do
+
+1. **It will not compute an optimal reshuffle.** It races policies you specify. The output is a *reflex* you can defend at the huddle, not a schedule.
+2. **It cannot settle the Line 1 tank argument on current inputs.** Whatever I assume about K₁ and Line 1's rate, the model will reproduce faithfully and appear to prove someone right. Run the inversion (§7.3) only after the stopwatch measurement, and do not take it into a room with engineering before then.
+3. **It has no first-pass-yield data.** Scrap is a swept parameter presented as thresholds, never as a point estimate.
+
+---
+
+# 1. Scope and resolution
+
+| Area | Detail level | Why |
+|---|---|---|
+| Fill & pack, all 3 lines | **Full** | Your bottleneck |
+| Changeover crew and calendar | **Full** | Your sore spot; the real constraint |
+| Mix / mill / tint | Single timed transition per line feeding a holding tank | You care less; tank capacity kept explicit for the Flag 2 inversion |
+| QA hold | Capacity-2 queue, post-fill | Affects OTIF only |
+| Raw materials | Assumed always available | Never raised as a driver |
+
+**Time base:** minutes. **Run length:** 6 weeks + 1 week warm-up. **Replications:** 30 per policy arm (breakdowns are stochastic; single runs will mislead you).
+
+---
+
+# 2. Colour sets
+
+| Set | Values |
+|---|---|
+| `FAMILY` | `WHITE` \| `TINT` \| `SPECIALTY` |
+| `SHADE` | `0`(white) \| `1..5` light→dark (tints) \| `X`(specialty) |
+| `TIER` | `MERIDIAN` \| `DISTRIBUTOR` \| `SMALL` |
+| `SKU` | 14 values; each carries `(family, shade, qualifiedLines[])` |
+| `ORDER` | `⟨id, sku, qty, tier, dueTime, releaseTime⟩` |
+| `LINESTATE` | `⟨lineId, lastSKU, lastFamily, lastShade, up:bool⟩` |
+| `BATCH` | `⟨sku, qty⟩` |
+| `LOT` | `⟨orderId, sku, qty, tier, dueTime, fillEndTime⟩` |
+
+---
+
+# 3. Places
+
+### 3.1 Shared
+
+| Place | Type | Init | Meaning |
+|---|---|---|---|
+| `P_Demand` | ORDER | from ERP | Order arrival stream |
+| `P_Ready` | ORDER | ∅ | Released, awaiting line assignment |
+| `P_Techs` | unit | 2 | Techs **on shift and free** |
+| `P_TechsOff` | unit | 0 | Techs off shift |
+| `P_TechShiftOpen` | unit | 0 | Marked 06:00–14:00 |
+| `P_LineOpen_1`, `_2` | unit | 0 | Marked 06:00–22:00 |
+| `P_LineOpen_3` | unit | 0 | Marked 06:00–14:00 (+OT lever) |
+| `P_Lab` | unit | 2 | Free lab capacity |
+| `P_LabOpen` | unit | 0 | Marked during lab hours (A10) |
+| `P_QAQueue` | LOT | ∅ | Awaiting QA |
+| `P_Shipped` | LOT | ∅ | Completed |
+| `P_Clock` | int | 1 | Calendar cycle token |
+
+### 3.2 Per line L ∈ {1,2,3}
+
+| Place | Type | Init | Meaning |
+|---|---|---|---|
+| `P_UpIdle_L` | unit | 1 | Upstream (mix/mill/tint) free |
+| `P_UpBusy_L` | BATCH | ∅ | Upstream in progress |
+| `P_Tank_L` | BATCH | ∅ | Holding tank contents |
+| `P_TankFree_L` | unit | K_L | Remaining tank slots (complementary place) |
+| `P_LineIdle_L` | LINESTATE | 1 | Line free, carrying its last-run identity |
+| `P_LineFilling_L` | ORDER×LINESTATE | ∅ | Fill in progress |
+| `P_ChangeoverDue_L` | ⟨from,to⟩ | ∅ | Changeover raised, not started |
+| `P_Rinsing_L` | ⟨from,to⟩ | ∅ | Operator rinse in progress |
+| `P_Washing_L` | ⟨from,to⟩ | ∅ | Tech wash in progress |
+| `P_Down_L` | unit | 0 | Line failed |
+
+---
+
+# 4. Transitions
+
+## 4.1 Calendar subnet (drives everything)
+
+| Transition | Fires at | Effect |
+|---|---|---|
+| `T_TechShiftStart` | 06:00 daily | `P_TechsOff` → `P_Techs`; mark `P_TechShiftOpen` |
+| `T_TechShiftEnd` | 14:00 daily | Unmark `P_TechShiftOpen`; return free techs to `P_TechsOff` |
+| `T_Line12Open` / `T_Line12Close` | 06:00 / 22:00 | Mark/unmark `P_LineOpen_1`, `P_LineOpen_2` |
+| `T_Line3Open` / `T_Line3Close` | 06:00 / 14:00 (22:00 if OT) | Mark/unmark `P_LineOpen_3` |
+| `T_LabOpen` / `T_LabClose` | per A10 | Mark/unmark `P_LabOpen` |
+
+*Weekends: all calendar transitions gated off unless the weekend-working lever is set.*
+
+## 4.2 Production
+
+| Transition | Delay | Guard |
+|---|---|---|
+| `T_UpStart_L` | — | `P_UpIdle_L` marked ∧ `P_TankFree_L` ≥ 1 ∧ a job is assigned to L |
+| `T_UpEnd_L` | `upstream_time[family]` (specialty longest) | — |
+| `T_Assign_L` | — | **Policy layer, §5** |
+| `T_StartFill_L` | — | `P_LineOpen_L` ∧ ¬`P_Down_L` ∧ batch present in `P_Tank_L` ∧ `lastSKU` prep matches job (no changeover outstanding) ∧ `sku ∈ qualified(L)` |
+| `T_EndFill_L` | `qty / rate[sku][L]` | — |
+| **`T_Interrupt_L`** | — | Fires at line close if fill incomplete; fill **pauses**, resumes at next open *(assumption: fills are interruptible at shift end — flag if wrong)* |
+
+## 4.3 Changeover — the detailed part
+
+| Transition | Delay | Resource | Guard |
+|---|---|---|---|
+| `T_RaiseChangeover_L` | — | — | Next job's prep ≠ line's current prep. **Deferred by wait-rule W, §5.2** |
+| `T_StartRinse_L` | — | none | `class(from,to) = OPERATOR` ∧ `P_LineOpen_L` |
+| `T_EndRinse_L` | 25 min | — | — |
+| `T_StartWash_L` | — | **n(from,to) tech tokens** | `P_TechShiftOpen` ∧ `P_Techs ≥ n` ∧ **`now + dur ≤ 14:00 + grace(15 min)`** (C8) ∧ **VW-02 guard (C12)** |
+| `T_EndWash_L` | `dur(from,to)` | releases techs | — |
+
+### Changeover matrix
+
+Duration in minutes / resource class / techs required.
+
+| From ↓ To → | WHITE | TINT light (1–2) | TINT dark (3–5) | SPECIALTY |
+|---|---|---|---|---|
+| **WHITE** | 25 / op | 45 / tech ×1 | 45 / tech ×1 | 120 / tech ×2 |
+| **TINT light** | **180 / tech ×2** | 25 / op | 25 / op | 120 / tech ×2 |
+| **TINT dark** | **180 / tech ×2** | **`D` = 60 / class ? — A2** | 25 / op | 120 / tech ×2 |
+| **SPECIALTY** | 120 / tech ×2 | 120 / tech ×2 | 120 / tech ×2 | 25 / op |
+
+**Hard guard, not a duration:** `to_sku = VW-02 ∧ from_shade ≥ 4` → transition disabled. No wash clears it.
+
+### Latest feasible start (derived from C4 + C8)
+
+| Changeover | Duration | Latest start |
+|---|---|---|
+| White → tint | 45 | **13:15** |
+| Specialty in/out | 120 | **12:00** |
+| Tint → white | 180 | **11:00** |
+| Rinse (operator) | 25 | any time the line is open |
+
+**Consequence, hard-coded by the calendar:** after 13:15, no line can cross families until 06:00 next day. Lines 1 and 2 run to 22:00 locked to whatever family they held at lunchtime.
+
+## 4.4 Failure and QA
+
+| Transition | Delay | Notes |
+|---|---|---|
+| `T_Fail_L` | `Exp(MTBF_L)` | A6/A8. Line 1 mill motor is a **scenario injection**, not sampled (A7) |
+| `T_Repair_L` | `Tri(min,mode,max)` | Fill resumes where interrupted |
+| `T_QAStart` | — | `P_Lab ≥ 1` ∧ `P_LabOpen` |
+| `T_QAEnd` | 240 min; 1440 specialty | — |
+| `T_Ship` | — | `lateness = max(0, now − dueTime)` recorded by tier |
+
+---
+
+# 5. Policy layer
+
+This is what you tune. Everything above is plant physics; everything here is a decision.
+
+## 5.1 Baseline — reproduces you
+
+```
+1. Meridian white orders  → Line 2 (C10, absolute)
+2. Specialty orders       → Line 1 (C11, currently the only qualified line)
+3. Otherwise: prefer the line whose lastFamily == order.family
+              tie-break: earliest available
+4. Within line: sort by TIER (Meridian, Distributor, Small), then dueTime
+5. Overnight-strand rule: do not start a job that ends after the
+   tech window if it leaves the line needing a wash
+6. VW-02 guard (C12)
+```
+
+## 5.2 Variants to race against it
+
+| Variant | Description | Answers |
+|---|---|---|
+| **Wait-rule `W(t)`** | Hold line idle up to `W` hours for a same-family order rather than raise a wash. **Time-of-day dependent** — after 13:15 the choice doesn't exist, so sweep only 06:00–13:15. | **Q2** |
+| **Fill-the-shift** | Do not commit a morning family switch unless there is enough work in that family to run through line close | Q2/Q3 |
+| **Breakdown reflex A/B/C** | A: push all to remaining lines. B: hold the tint block, pull whites forward. C: split across 1 & 3, absorb the specialty changeover. | **Q1** |
+| **Tech shift position** | 06:00–14:00 (status quo) / 10:00–18:00 / 14:00–22:00 / one tech per shift | Q3 + headcount case |
+| **Third tech** | Add one head to the existing window | Q3 |
+| **Line 3 OT** | Purchasable lever, 0–5 days/week | Q1 |
+| **Meridian-priority QA** | Non-FIFO lab queue | Free OTIF experiment |
+
+**Note on the split-shift arm:** with one tech per shift, no ≥120-min wash can ever run (they need two). I expect that arm to fail badly. Run it anyway — showing your ops director *why* a cheap option fails is worth more than asserting it, and it demonstrates you looked at rota changes before asking for headcount.
+
+---
+
+# 6. KPIs
+
+## 6.1 Service (primary)
+
+| Metric | Definition |
+|---|---|
+| **Meridian late count** | Any lot shipped after `dueTime`. Target zero (C13) |
+| Distributor late | Shipped > 48 h after due |
+| Small-account late | Shipped > 168 h after due |
+| Meridian lateness hours | Total, for severity |
+
+## 6.2 Changeover — reported as three separate numbers
+
+**Do not merge these.** A single "dirty hours" figure will be attacked as inflated the first time someone notices it counts unscheduled hours.
+
+| Metric | Definition | Framing |
+|---|---|---|
+| Clock-dirty hours | Wall-clock from changeover raised to complete | Report, label **not a loss** |
+| Wash hours | Actual cleaning time | Largely unavoidable |
+| **Lost production hours** | Dirty time that overlapped **scheduled line hours** | **The number to argue with** |
+| — split by cause | `techs_off_shift` vs `techs_busy_elsewhere` | Different fixes: rota vs headcount |
+| **Family-lock hours** | Per line per day, time during which no family switch is possible | Explains *why* the losses occurred |
+| Family switches per week | Plant-wide count | Validation target |
+
+*Worked example — wash raised 14:30 on Line 2, executed 06:00–09:00:*
+clock-dirty 18.5 h · wash 3 h · **lost production 7.5 h** (cause: techs off shift).
+
+## 6.3 Secondary
+
+Ramp scrap units (by changeover type) · per-line utilisation · **tank-blocked hours** (Flag 2) · tech utilisation % of the 16 tech-hours/day · QA queue length, Fri/Mon split.
+
+---
+
+# 7. How to use it
+
+## 7.1 Run this first — the reproduction check
+
+Before any experiment, before anything goes to your ops director:
+
+| Check | Target | If it misses |
+|---|---|---|
+| Weekly output per line | Within ±10% of ERP actuals | Rate matrix or tank capacity wrong |
+| Family switches/week | Your estimate: ~8 | Changeover matrix or policy wrong |
+| Late-order pattern by tier | Matches history | Priority logic wrong |
+| Line 3 idle mornings | Should appear spontaneously | Tech contention modelled wrong |
+
+**If it misses, that is the finding.** The gap points at a register row and we fix the model before it says anything about Tuesdays.
+
+## 7.2 Then, in order
+
+1. **Q3 — where do changeover hours go.** Baseline only. Decompose lost production hours by cause and by line. Cheapest result, no new policy needed.
+2. **Q2 — the wait-vs-wash question.** Sweep `W(t)`. Expected output shape: *"before 09:00 wait up to N hours; 09:00–11:00 never wait; after 11:00 wait as long as you like."*
+3. **Q1 — the breakdown reflex.** Inject Line 2 failure at 06:00 Tue, Line 1 mill motor at 06:00 Mon (4 days). Race reflexes A/B/C over 30 reps. Output is a rule, not a schedule.
+4. **Rota and headcount.** Only after the tick sheet lands.
+
+## 7.3 The Line 1 tank inversion — after the stopwatch, not before
+
+Fix Line 1's fill rate to the measured value. Sweep K₁ downward. Find the largest K₁ that reproduces observed blocking.
+
+- If that K₁ is **below** the spec-sheet volume → the tank is not the constraint; the rate is.
+- If it is **at or above** → your instinct holds.
+
+Without the measured rate, both parameters are free and the inversion identifies neither. It will still produce a confident-looking answer. Do not use it.
+
+---
+
+# 8. Parameter file
+
+Everything below is data, not structure. Hand this to whoever fills it in; the net does not change.
+
+```csv
+# === lines.csv ===
+line_id,open_time,close_time,ot_available,mtbf_hours,repair_min,repair_mode,repair_max,tank_capacity_K
+1,06:00,22:00,no,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,K1_PLACEHOLDER
+2,06:00,22:00,no,240,30,90,240,K2_PLACEHOLDER
+3,06:00,14:00,yes_signoff,99999,0,0,0,K3_PLACEHOLDER
+
+# === skus.csv ===
+sku_id,family,shade,qual_L1,qual_L2,qual_L3
+VW-01,WHITE,0,1,1,1
+VW-02,WHITE,0,1,1,1          # C12 guard applies
+T-01..T-09,TINT,1..5,1,1,mostly-1   # two deep reds = 0 on L3 (A16)
+S-01..S-03,SPECIALTY,X,1,0,0        # C11: L1 only in practice
+
+# === rates.csv ===   units/hr, PLACEHOLDER = A14
+sku_id,rate_L1,rate_L2,rate_L3
+
+# === changeover.csv ===
+from_family,from_shade,to_family,to_shade,minutes,resource,techs
+WHITE,*,WHITE,*,25,OPERATOR,0
+WHITE,*,TINT,*,45,TECH,1
+WHITE,*,SPECIALTY,*,120,TECH,2
+TINT,*,WHITE,*,180,TECH,2
+TINT,1-2,TINT,*,25,OPERATOR,0
+TINT,3-5,TINT,3-5,25,OPERATOR,0
+TINT,3-5,TINT,1-2,60,UNKNOWN,?     # A2 — sweep 25..180, both resource classes
+TINT,*,SPECIALTY,*,120,TECH,2
+SPECIALTY,*,*,*,120,TECH,2
+SPECIALTY,*,SPECIALTY,*,25,OPERATOR,0
+
+# === ramp_scrap.csv ===   A5 — swept, not asserted
+changeover_type,scrap_units
+same_family,0
+white_to_tint,SWEEP_0_200
+specialty_switch,SWEEP_0_200
+tint_to_white,SWEEP_0_400
+
+# === resources.csv ===
+resource,count,open,close
+tech,2,06:00,14:00
+lab,2,PLACEHOLDER,PLACEHOLDER      # A10
+
+# === tiers.csv ===
+tier,tolerance_hours
+MERIDIAN,0
+DISTRIBUTOR,48
+SMALL,168
+```
+
+---
+
+# 9. PNML
+
+**Dialect note.** Your tooling question never came back, so this is built to load anywhere: the graph structure is plain P/T-net so any PNML reader will open it, and all colour, guard, timing and resource information is carried in `<toolspecific>` blocks and inscriptions. If your tool is coloured + timed, map the annotations onto the colour sets in §2 — that is a mechanical translation, roughly an hour's work. If it is plain P/T, the net runs as-is with `SHADE` folded out; you lose the `D` question and the VW-02 guard has to become a separate forbidden-pair place per SKU.
+
+**Coverage.** Shared resources, the calendar subnet, and **Line 1 in full**. Lines 2 and 3 are structurally identical: duplicate the `_L1` block, change the id suffix, and substitute from `lines.csv`. I've done it this way so the file stays readable — a 3× copy is ten minutes of work and impossible to get wrong, whereas a 900-line file nobody reads is a different kind of risk.
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<pnml xmlns="http://www.pnml.org/version-2009/grammar/pnml">
+  <net id="coatings_sched_v1"
+       type="http://www.pnml.org/version-2009/grammar/ptnet">
+    <name><text>Coatings Plant Scheduling Model v1.0</text></name>
+    <toolspecific tool="spec" version="1.0">
+      <timeUnit>minutes</timeUnit>
+      <runLength>60480</runLength>
+      <warmup>10080</warmup>
+      <replications>30</replications>
+      <note>Colour sets, guards and policy layer defined in accompanying
+            spec sections 2-5. Parameter values in parameter file section 8.
+            UNVALIDATED assumptions listed on page one.</note>
+    </toolspecific>
+    <page id="top">
+
+      <!-- ============ CALENDAR SUBNET ============ -->
+      <place id="P_Clock">
+        <name><text>Calendar cycle</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <graphics><position x="40" y="40"/></graphics>
+      </place>
+      <place id="P_TechShiftOpen">
+        <name><text>Tech shift open 06:00-14:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="200" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L1">
+        <name><text>Line 1 open 06:00-22:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="360" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L2">
+        <name><text>Line 2 open 06:00-22:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="520" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L3">
+        <name><text>Line 3 open 06:00-14:00 (OT lever)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="680" y="40"/></graphics>
+      </place>
+      <place id="P_LabOpen">
+        <name><text>Lab open (A10 UNVALIDATED)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="840" y="40"/></graphics>
+      </place>
+
+      <transition id="T_ShiftStart">
+        <name><text>06:00 daily open</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 06:00, weekdays</schedule>
+          <effect>mark P_TechShiftOpen, P_LineOpen_L1/2/3, P_LabOpen;
+                  move 2 tokens P_TechsOff -> P_Techs</effect>
+        </toolspecific>
+        <graphics><position x="120" y="120"/></graphics>
+      </transition>
+      <transition id="T_TechShiftEnd">
+        <name><text>14:00 tech shift end</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 14:00</schedule>
+          <effect>unmark P_TechShiftOpen; free techs -> P_TechsOff</effect>
+        </toolspecific>
+        <graphics><position x="280" y="120"/></graphics>
+      </transition>
+      <transition id="T_Line3Close">
+        <name><text>14:00 Line 3 close</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 14:00 unless OT lever set</schedule>
+        </toolspecific>
+        <graphics><position x="440" y="120"/></graphics>
+      </transition>
+      <transition id="T_Line12Close">
+        <name><text>22:00 Lines 1-2 close</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 22:00</schedule>
+        </toolspecific>
+        <graphics><position x="600" y="120"/></graphics>
+      </transition>
+
+      <arc id="a01" source="P_Clock" target="T_ShiftStart"/>
+      <arc id="a02" source="T_ShiftStart" target="P_TechShiftOpen"/>
+      <arc id="a03" source="T_ShiftStart" target="P_LineOpen_L1"/>
+      <arc id="a04" source="T_ShiftStart" target="P_LineOpen_L2"/>
+      <arc id="a05" source="T_ShiftStart" target="P_LineOpen_L3"/>
+      <arc id="a06" source="T_ShiftStart" target="P_LabOpen"/>
+      <arc id="a07" source="P_TechShiftOpen" target="T_TechShiftEnd"/>
+      <arc id="a08" source="P_LineOpen_L3" target="T_Line3Close"/>
+      <arc id="a09" source="P_LineOpen_L1" target="T_Line12Close"/>
+      <arc id="a10" source="P_LineOpen_L2" target="T_Line12Close"/>
+      <arc id="a11" source="T_Line12Close" target="P_Clock"/>
+
+      <!-- ============ SHARED RESOURCES ============ -->
+      <place id="P_Techs">
+        <name><text>Techs on shift and free</text></name>
+        <initialMarking><text>2</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <lever>count = 2 (baseline) | 3 (third-tech arm)</lever>
+        </toolspecific>
+        <graphics><position x="200" y="220"/></graphics>
+      </place>
+      <place id="P_TechsOff">
+        <name><text>Techs off shift</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="200" y="300"/></graphics>
+      </place>
+      <place id="P_Lab">
+        <name><text>Lab capacity</text></name>
+        <initialMarking><text>2</text></initialMarking>
+        <graphics><position x="840" y="220"/></graphics>
+      </place>
+      <place id="P_Demand">
+        <name><text>Order arrivals (ERP stream)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <colour>ORDER = id,sku,qty,tier,dueTime</colour>
+          <source>ERP export, 4-6 weeks. A17 until loaded.</source>
+        </toolspecific>
+        <graphics><position x="40" y="380"/></graphics>
+      </place>
+      <place id="P_Ready">
+        <name><text>Released, awaiting assignment</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="180" y="380"/></graphics>
+      </place>
+
+      <transition id="T_Release">
+        <name><text>Release order</text></name>
+        <graphics><position x="110" y="380"/></graphics>
+      </transition>
+      <arc id="a12" source="P_Demand" target="T_Release"/>
+      <arc id="a13" source="T_Release" target="P_Ready"/>
+
+      <!-- ============ LINE 1 SUBNET ============ -->
+      <!-- duplicate this block for L2, L3; substitute ids and parameters -->
+
+      <place id="P_UpIdle_L1">
+        <name><text>L1 upstream idle (mix/mill/tint)</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <graphics><position x="300" y="460"/></graphics>
+      </place>
+      <place id="P_UpBusy_L1">
+        <name><text>L1 upstream in progress</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="380" y="460"/></graphics>
+      </place>
+      <place id="P_Tank_L1">
+        <name><text>L1 holding tank (DISPUTED CAPACITY - A15)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <capacity>K1 = PLACEHOLDER</capacity>
+          <note>Flag 2. Do not run the inversion before Line 1 fill rate
+                is measured with a non-empty tank.</note>
+        </toolspecific>
+        <graphics><position x="460" y="460"/></graphics>
+      </place>
+      <place id="P_TankFree_L1">
+        <name><text>L1 tank free slots</text></name>
+        <initialMarking><text>K1</text></initialMarking>
+        <graphics><position x="460" y="540"/></graphics>
+      </place>
+      <place id="P_LineIdle_L1">
+        <name><text>L1 idle, carrying lastSKU/lastFamily/lastShade</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <colour>LINESTATE = lineId,lastSKU,lastFamily,lastShade,up</colour>
+        </toolspecific>
+        <graphics><position x="560" y="460"/></graphics>
+      </place>
+      <place id="P_LineFilling_L1">
+        <name><text>L1 filling</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="660" y="460"/></graphics>
+      </place>
+      <place id="P_ChangeoverDue_L1">
+        <name><text>L1 changeover raised, not started</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="560" y="620"/></graphics>
+      </place>
+      <place id="P_Rinsing_L1">
+        <name><text>L1 rinsing (operator, no tech)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="480" y="700"/></graphics>
+      </place>
+      <place id="P_Washing_L1">
+        <name><text>L1 washing (tech, QA signoff)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="640" y="700"/></graphics>
+      </place>
+      <place id="P_Down_L1">
+        <name><text>L1 down</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="760" y="540"/></graphics>
+      </place>
+
+      <transition id="T_Assign_L1">
+        <name><text>Assign order to L1</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>POLICY LAYER - spec section 5.
+                 Baseline: Meridian white -> L2 only; specialty -> L1;
+                 else prefer matching lastFamily; sort TIER then dueTime.</guard>
+        </toolspecific>
+        <graphics><position x="240" y="380"/></graphics>
+      </transition>
+      <transition id="T_UpStart_L1">
+        <name><text>L1 start upstream</text></name>
+        <graphics><position x="340" y="460"/></graphics>
+      </transition>
+      <transition id="T_UpEnd_L1">
+        <name><text>L1 end upstream</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>upstream_time[family]; specialty slowest (thick, slow mill)</delay>
+        </toolspecific>
+        <graphics><position x="420" y="460"/></graphics>
+      </transition>
+      <transition id="T_StartFill_L1">
+        <name><text>L1 start fill</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>P_LineOpen_L1 marked AND NOT P_Down_L1 AND batch in tank
+                 AND no changeover outstanding AND sku qualified on L1
+                 (specialty: L1 only - C11)</guard>
+        </toolspecific>
+        <graphics><position x="610" y="460"/></graphics>
+      </transition>
+      <transition id="T_EndFill_L1">
+        <name><text>L1 end fill</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>qty / rate[sku][L1]  (A14 placeholder)</delay>
+          <effect>emit LOT to P_QAQueue, less ramp_scrap if run followed
+                  a family switch (A5, swept)</effect>
+        </toolspecific>
+        <graphics><position x="720" y="460"/></graphics>
+      </transition>
+      <transition id="T_RaiseChangeover_L1">
+        <name><text>L1 raise changeover</text
+```xml
+      <transition id="T_RaiseChangeover_L1">
+        <name><text>L1 raise changeover</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>next job prep != line current prep</guard>
+          <delay>DEFERRED by wait-rule W(t) - spec 5.2.
+                 Morning only; after 13:15 the choice does not exist.</delay>
+        </toolspecific>
+        <graphics><position x="560" y="540"/></graphics>
+      </transition>
+      <transition id="T_StartRinse_L1">
+        <name><text>L1 start rinse (operator)</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>class(from,to) = OPERATOR AND P_LineOpen_L1 marked</guard>
+          <note>C5 - no tech token consumed. Available to 22:00.</note>
+        </toolspecific>
+        <graphics><position x="480" y="620"/></graphics>
+      </transition>
+      <transition id="T_EndRinse_L1">
+        <name><text>L1 end rinse</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>25</delay>
+        </toolspecific>
+        <graphics><position x="400" y="700"/></graphics>
+      </transition>
+      <transition id="T_StartWash_L1">
+        <name><text>L1 start wash (tech)</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>class(from,to) = TECH
+                 AND P_TechShiftOpen marked
+                 AND P_Techs >= n(from,to)
+                 AND now + dur(from,to) &lt;= 14:00 + grace(15)   [C8]
+                 AND NOT (to_sku = VW-02 AND from_shade &gt;= 4)   [C12]</guard>
+          <consumes>n(from,to) tokens from P_Techs</consumes>
+        </toolspecific>
+        <graphics><position x="640" y="620"/></graphics>
+      </transition>
+      <transition id="T_EndWash_L1">
+        <name><text>L1 end wash</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>dur(from,to) per changeover matrix, spec 4.3</delay>
+          <effect>release n techs to P_Techs; set lastFamily/lastShade := to</effect>
+        </toolspecific>
+        <graphics><position x="720" y="700"/></graphics>
+      </transition>
+      <transition id="T_Fail_L1">
+        <name><text>L1 fail</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>Exp(MTBF_L1) - A6 PLACEHOLDER</delay>
+          <note>A7: mill motor 4-day outage is a SCENARIO INJECTION,
+                not sampled. Too rare for a 6-week run.</note>
+        </toolspecific>
+        <graphics><position x="800" y="460"/></graphics>
+      </transition>
+      <transition id="T_Repair_L1">
+        <name><text>L1 repair</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>Tri(min,mode,max) - A6</delay>
+          <effect>fill resumes from interruption point</effect>
+        </toolspecific>
+        <graphics><position x="800" y="620"/></graphics>
+      </transition>
+      <transition id="T_Interrupt_L1">
+        <name><text>L1 shift-end interrupt</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>fires at line close if fill incomplete</schedule>
+          <note>ASSUMPTION: fills are interruptible at shift end and resume
+                next open. Never confirmed - flag if wrong.</note>
+        </toolspecific>
+        <graphics><position x="720" y="380"/></graphics>
+      </transition>
+
+      <arc id="b01" source="P_Ready" target="T_Assign_L1"/>
+      <arc id="b02" source="T_Assign_L1" target="P_UpIdle_L1"/>
+      <arc id="b03" source="P_UpIdle_L1" target="T_UpStart_L1"/>
+      <arc id="b04" source="P_TankFree_L1" target="T_UpStart_L1"/>
+      <arc id="b05" source="T_UpStart_L1" target="P_UpBusy_L1"/>
+      <arc id="b06" source="P_UpBusy_L1" target="T_UpEnd_L1"/>
+      <arc id="b07" source="T_UpEnd_L1" target="P_Tank_L1"/>
+      <arc id="b08" source="T_UpEnd_L1" target="P_UpIdle_L1"/>
+      <arc id="b09" source="P_Tank_L1" target="T_StartFill_L1"/>
+      <arc id="b10" source="P_LineIdle_L1" target="T_StartFill_L1"/>
+      <arc id="b11" source="P_LineOpen_L1" target="T_StartFill_L1">
+        <inscription><text>test arc - not consumed</text></inscription>
+      </arc>
+      <arc id="b12" source="T_StartFill_L1" target="P_LineFilling_L1"/>
+      <arc id="b13" source="T_StartFill_L1" target="P_TankFree_L1"/>
+      <arc id="b14" source="P_LineFilling_L1" target="T_EndFill_L1"/>
+      <arc id="b15" source="T_EndFill_L1" target="P_LineIdle_L1"/>
+      <arc id="b16" source="T_EndFill_L1" target="P_QAQueue"/>
+      <arc id="b17" source="P_LineIdle_L1" target="T_RaiseChangeover_L1"/>
+      <arc id="b18" source="T_RaiseChangeover_L1" target="P_ChangeoverDue_L1"/>
+      <arc id="b19" source="P_ChangeoverDue_L1" target="T_StartRinse_L1"/>
+      <arc id="b20" source="T_StartRinse_L1" target="P_Rinsing_L1"/>
+      <arc id="b21" source="P_Rinsing_L1" target="T_EndRinse_L1"/>
+      <arc id="b22" source="T_EndRinse_L1" target="P_LineIdle_L1"/>
+      <arc id="b23" source="P_ChangeoverDue_L1" target="T_StartWash_L1"/>
+      <arc id="b24" source="P_Techs" target="T_StartWash_L1">
+        <inscription><text>n(from,to)  [1 or 2]</text></inscription>
+      </arc>
+      <arc id="b25" source="P_TechShiftOpen" target="T_StartWash_L1">
+        <inscription><text>test arc - not consumed</text></inscription>
+      </arc>
+      <arc id="b26" source="T_StartWash_L1" target="P_Washing_L1"/>
+      <arc id="b27" source="P_Washing_L1" target="T_EndWash_L1"/>
+      <arc id="b28" source="T_EndWash_L1" target="P_LineIdle_L1"/>
+      <arc id="b29" source="T_EndWash_L1" target="P_Techs">
+        <inscription><text>n(from,to)</text></inscription>
+      </arc>
+      <arc id="b30" source="P_LineFilling_L1" target="T_Fail_L1"/>
+      <arc id="b31" source="T_Fail_L1" target="P_Down_L1"/>
+      <arc id="b32" source="P_Down_L1" target="T_Repair_L1"/>
+      <arc id="b33" source="T_Repair_L1" target="P_LineFilling_L1"/>
+      <arc id="b34" source="P_LineFilling_L1" target="T_Interrupt_L1"/>
+      <arc id="b35" source="T_Interrupt_L1" target="P_LineFilling_L1">
+        <inscription><text>paused; resumes at next line open</text></inscription>
+      </arc>
+
+      <!-- ============ QA AND SHIPPING ============ -->
+      <place id="P_QAQueue">
+        <name><text>Awaiting QA (post-fill hold)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <note>C9 - delays shipment only, does not block upstream.
+                Watch Fri/Mon queue length: your Friday slip mechanism.</note>
+        </toolspecific>
+        <graphics><position x="900" y="380"/></graphics>
+      </place>
+      <place id="P_InQA">
+        <name><text>In QA</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="900" y="460"/></graphics>
+      </place>
+      <place id="P_Shipped">
+        <name><text>Shipped</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="900" y="620"/></graphics>
+      </place>
+
+      <transition id="T_QAStart">
+        <name><text>Start QA</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>P_Lab >= 1 AND P_LabOpen marked</guard>
+          <policy>BASELINE FIFO (A10). Variant: Meridian-priority queue.</policy>
+        </toolspecific>
+        <graphics><position x="900" y="420"/></graphics>
+      </transition>
+      <transition id="T_QAEnd">
+        <name><text>End QA</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>240 min; 1440 min if family = SPECIALTY</delay>
+        </toolspecific>
+        <graphics><position x="900" y="500"/></graphics>
+      </transition>
+      <transition id="T_Ship">
+        <name><text>Ship and record lateness</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <effect>lateness = max(0, now - dueTime); bucket by TIER;
+                  MERIDIAN tolerance 0, DISTRIBUTOR 2880, SMALL 10080 min</effect>
+        </toolspecific>
+        <graphics><position x="900" y="570"/></graphics>
+      </transition>
+
+      <arc id="c01" source="P_QAQueue" target="T_QAStart"/>
+      <arc id="c02" source="P_Lab" target="T_QAStart"/>
+      <arc id="c03" source="T_QAStart" target="P_InQA"/>
+      <arc id="c04" source="P_InQA" target="T_QAEnd"/>
+      <arc id="c05" source="T_QAEnd" target="P_Lab"/>
+      <arc id="c06" source="T_QAEnd" target="P_Shipped"/>
+      <arc id="c07" source="P_Shipped" target="T_Ship"/>
+
+    </page>
+  </net>
+</pnml>
+```
+
+---
+
+# 10. Building Lines 2 and 3
+
+Copy the Line 1 block; change the `_L1` suffix throughout; substitute from `lines.csv`. The only structural differences:
+
+| | Line 2 | Line 3 |
+|---|---|---|
+| Calendar place | `P_LineOpen_L2`, 06:00–22:00 | `P_LineOpen_L3`, 06:00–**14:00** |
+| Qualification | Specialty SKUs excluded (C11) | Specialty excluded; two deep-red tints excluded (A16) |
+| Assignment guard | **Meridian whites forced here** (C10) | No forced work |
+| Failure | MTBF ≈ 240 h, repair Tri(30,90,240) (A6) | Zero (A8) |
+| OT lever | none | `T_Line3Close` deferred to 22:00 when set |
+
+**One consequence worth checking against the model's own output:** Line 3's entire operating day sits inside the tech window. Its changeovers compete head-on with the morning wash queue for Lines 1 and 2. A tint→white wash starting 06:00 on Line 2 holds both techs to 09:00, during which Line 3 cannot cross families — three of its eight hours, clean and staffed and waiting. If that pattern doesn't emerge spontaneously in the reproduction check, the tech contention is modelled wrong.
+
+---
+
+# 11. What happens next
+
+**Blocking, from you:** spreadsheet, rate matrix, ERP export. Nothing runs until the rate matrix lands — `A14` placeholders make every duration in the model fictional.
+
+**Then, in order:** reproduction check (§7.1) → Q3 decomposition → Q2 sweep → Q1 reflexes. Rota and headcount arms only after the tick sheet.
+
+**Send early, don't batch:** any tick-sheet row showing an operator performing a family switch. That retires A19, changes a hard guard, and I'd rather rework in week one than build a fortnight on it.
+
+**Still unanswered:** the PNML dialect, A10 (lab hours and queue discipline — I never asked and it drives your Friday slips), A15 (tank capacities), whether fills are interruptible at shift end (§4.2), and A16 (which two tints Line 3 can't run).
+
+---
+
+# 12. Two lines that don't depend on any of this
+
+Both fall out of your own shift pattern — C3, C4, C6, C8 — not from anything I've modelled. They were true before this document existed and stay true whatever the data says:
+
+> **After 13:15, no line can cross families. The morning decides the day.**
+
+> **A wash raised at 22:00 costs nothing. One raised at 14:30 costs the evening.**
+
+Everything else in here — the switches-per-week ceiling, the capacity-versus-timing hypothesis, Line 3's idle mornings, and every number in §8 — is arithmetic on recollection. Hold it back until the sheet earns it.
\ No newline at end of file
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.md
new file mode 100644
index 00000000000..031adadb254
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.md
@@ -0,0 +1,1643 @@
+# Baseline control — condition 1 (bare)
+
+- Run started: 2026-08-13T10:22:15.639Z
+- Interviewer: claude-opus-5 (no system prompt)
+- Simulated expert: claude-sonnet-5 + situation-pack.md
+- Interviewer turns: 21 (impatience probe at 8, forced wrap at 20)
+- Stop reason: delivered-after-forced-wrap
+- Tokens: 929821 in / 63724 out across 70 calls
+
+---
+
+**Opening message**:
+
+I'm the master scheduler at a coatings plant. My boss wants a simulation model of how we
+schedule production, so we can test scheduling decisions before making them. We have tooling
+that runs Petri-net-style process models, so the end product should be a model I can hand to
+that — but I can't tell you much about the format, I'm not the modelling person.
+
+Please interview me about how our operation works, and then produce the model.
+
+---
+
+**Interviewer**:
+
+Happy to do this. Before the questions, two framing notes:
+
+**What I need most.** The single biggest driver of how I build this is _which decisions you want to test_. "Should I run whites before blacks all week?" needs a very different model from "should I buy a fourth filling line?" So question 1 below matters more than all the rest.
+
+**On the format.** I can't guess your tooling's dialect, so I'll deliver two things: a plain-language spec (places, transitions, arcs, timings, decision rules) that any Petri-net person can implement in an afternoon, plus a PNML file, which is the closest thing to a standard interchange format. If you can get one answer out of your modelling person, make it this: _does the tool support timed transitions and coloured/typed tokens, or is it plain place/transition nets?_ Coatings scheduling is all about "this batch is dark red and needs a 90-minute wash before the next white" — that's much cleaner with coloured tokens, and much clumsier without. I can do either.
+
+Now the interview. **Answer what you can and skip the rest — rough guesses are fine, and "I don't know" is a useful answer.** I've put my default assumption in brackets where I have one, so you can often just say "yep."
+
+---
+
+## 1. What are you trying to learn from it?
+
+1. Give me two or three real questions you'd want to ask this model. The more specific the better — e.g. "if I hold the small filling line for urgent orders only, do I miss fewer due dates?"
+2. Is there a known bottleneck or sore spot? I'll model that part in detail and abstract the rest, rather than modelling everything at uniform detail.
+3. Who else will look at the output — just you, or your boss and planners too?
+
+## 2. The process route
+
+1. What are you making, broadly? [Assuming liquid coatings — solvent-borne and/or water-borne, batch production.]
+2. Walk me through the steps a batch goes through. My straw man: raw material weigh/dispense → premix → dispersion or milling → let-down/thin-down → QC sample and adjust → filter → fill and pack → warehouse. Correct, add, delete.
+3. Do all products follow the same route, or are there variants — e.g. some skip milling, some need multiple mill passes?
+4. Roughly how many distinct products/SKUs, and how many meaningfully different _routes_? (I don't need the SKU list, just the shape of it.)
+
+## 3. Equipment
+
+1. How many of each vessel/machine — mixers, mills, filling lines? Approximate is fine.
+2. Are they interchangeable, or restricted? Typical restrictions: only certain tanks for water-borne, only the big mixer for volumes over X, whites kept off vessels that have run dark shades.
+3. **Important:** when a batch finishes mixing but the filling line is busy, where does it sit? Does it stay in the mixer (blocking it) or go to a holding/storage tank? If holding tanks, how many, and are they dedicated?
+4. Are people a constraint — operators per shift, one lab tech covering everything, a single cleaning crew? Or is labour effectively always available?
+
+## 4. Batches and time
+
+1. Is batch size fixed by the vessel, or do you flex it to the order? Do you ever combine several orders into one batch, or split one batch across several pack sizes / fill runs?
+2. Rough durations for each step, and what makes them vary (product, batch size, viscosity)?
+3. What time resolution do you care about — minutes, hours, or shifts? [Assuming hours.]
+4. Shift pattern, weekend working, and how planned maintenance fits in. Can a batch be left part-finished over a shift break, or must some steps run to completion once started?
+
+## 5. Changeovers — probably the crux
+
+1. What determines the cleaning needed between two batches in the same vessel? Colour sequence, resin chemistry, both? I'm expecting something like a light-to-dark rule with a full solvent wash needed when you go backwards.
+2. Roughly what do the different cleaning levels cost you in time? (e.g. same colour = quick rinse 20 min; light after dark = full wash 3 hrs.)
+3. Do you deliberately run campaigns — batching up all the whites, then greys, then blacks — and if so over what cycle? Weekly?
+4. Does cleaning consume something scarce: a wash bay, a crew, solvent, waste capacity?
+
+## 6. QC and rework
+
+1. After let-down you sample and test. How long does the lab take, and does the batch hold the vessel while it waits?
+2. What fraction of batches pass first time? On a fail, what happens — tint adjust and retest (how many loops before you give up?), hold for review, downgrade to another SKU, scrap?
+3. Any other rework loops — regrinds, refiltering, refill after a fill-line fault?
+
+## 7. Demand and disruption
+
+1. Make-to-order, make-to-stock, or a mix? If stock, do you replenish to reorder points?
+2. How do orders arrive and how firm are they? Do you get urgent inserts that jump the queue, and how often?
+3. Raw materials: assume always available, or do shortages genuinely drive your schedule? Any long-lead or single-source items?
+4. Breakdowns: frequent enough to matter, or rare? Rough failure rate and repair time for the important machines if so.
+
+## 8. Scoring the schedule
+
+1. What makes a schedule good, in your judgement, in priority order? Candidates: due-date/OTIF performance, total changeover time or solvent used, throughput, vessel utilisation, WIP sitting in tanks, overtime.
+2. Are there hard rules I must never break, versus preferences? (e.g. "a batch never sits more than 48 hrs before filling" is often a hard one.)
+3. How do you actually sequence today — a spreadsheet, a rule of thumb, gut feel? I'd like the model to be able to reproduce your current approach as a baseline, so you can compare alternatives against it.
+
+---
+
+Send back whatever you've got. If you'd rather not answer all of it, give me sections 1, 3, 5 and 8 and I'll build a first cut with explicit assumptions marked, which is often a faster way to find out what I got wrong.
+
+---
+
+**Expert (Marta)**:
+
+Right, let's do this. I've got about forty minutes before the huddle, so I'll go fast.
+
+## 1. What I want to know
+
+Three real questions, in order of how much I actually lose sleep over them:
+
+1. When a line goes down at 6am, what's the best re-shuffle of the rest of the week — right now I improvise at the huddle and I know it's not great.
+2. Is it ever worth sitting a line idle for an hour or two waiting for a same-family order, instead of paying for the washdown now? I do this by gut and nobody can tell me if I'm right.
+3. Where do my changeover hours actually go, and would reordering the run sequence claw any back?
+
+Sore spot: changeovers, no question. Tint→white washdowns are the expensive one, and the crew is shared across three lines, so it's not just the time, it's who's waiting on who. Model that in detail. The mixing/dispersion end I care about less.
+
+Who looks at it: me first, then probably my boss (ops director) if it says anything useful. Commercial might get pulled in if it touches due-date stuff, but that's a maybe.
+
+## 2 & 3. Process and equipment — quick corrections
+
+We're coatings, yes — mix, mill, tint/letdown, then fill & pack. That's it, four stages, same order for everything. No separate QC-hold-and-adjust step in the way you described — QA sits at the _end_, after fill, not mid-process. I'll come back to that under section 6.
+
+Three filling lines, not identical — Line 1 old and slow but does everything including specialty, Line 2 fast and big-volume, Line 3 newest, still being qualified SKU by SKU. About 14 SKUs, three families: base whites, tinted colours, specialty clears. Routes are the same shape for everyone, just different speeds and fussiness — specialty is thick and slow, particularly up at the mill end.
+
+Holding tanks between stages, small ones. Line 1's mill-to-fill tank is the one that gives me grief — I think it's undersized and backs the line up, though engineering points at the line rate and says that's not it. One changeover crew, two techs, day shift, covers all three lines — that's a real constraint, if two lines want washing at once someone waits.
+
+## 5. Changeovers — since you want detail here
+
+Same-family rinse: quick, 20–30 minutes. Family switches are the real cost, and they're **not symmetric** — white to tint, maybe 45 minutes. Tint to white is a full wash, about 3 hours, because pigment carryover wrecks a white batch. Specialty in or out, either direction, roughly 2 hours.
+
+We don't run strict weekly campaigns, but I do try to cluster — I'll hold a family together on a line rather than ping-ponging, purely to dodge the 3-hour wash. Cleaning eats the shared crew, that's the scarce resource, not solvent or bay space as far as I know.
+
+## 6. Quality — correction to your model
+
+No mid-process sample-adjust-retest loop. What happens is: batch finishes fill & pack, then sits in QA hold — about four hours typically, specialty can be a day. Lab's two people, backs up end of week. I don't have first-pass-yield numbers off the top of my head; I don't think we track it that granularly, quality just reports scrap as a monthly percentage across the board.
+
+One thing I will flag: after any family switch the first units off the line are junk — "ramp scrap" — worse after the big washdowns. I can't give you exact quantities per changeover type though, that's not something I've got broken out.
+
+## 8. Scoring and how I do it today
+
+Priority order, honestly: don't ship late to Meridian, ever — that's our biggest account, mostly whites, and they fine and delist. Other big distributors can slip a couple of days if we phone ahead. Small accounts can slide a week and nobody notices. After that, changeover hours, then general utilization.
+
+No hard rule I can quote you on tank dwell time or anything like that — the closest thing is Meridian white orders _always_ go on Line 2, that's just how it's done, has been for years. Specialty only runs on Lines 1 and 3, Line 2 was never set up for the clear resins.
+
+Today I sequence off a spreadsheet — I map the week's demand book onto the three lines, rough rate per product per line, add changeover by feel, and I re-juggle it out loud at the 07:30 huddle most mornings. That sheet is the baseline you should try to reproduce first, honestly — if your model can't match what the sheet does, I won't trust what it says about doing better.
+
+Send me the questions you're still stu
+
+---
+
+**Interviewer**:
+
+Your message cut off at "still stu—", so I may be missing a line. Here's what I've got.
+
+Three flags first, then the questions. The flags matter more than the questions.
+
+---
+
+## Flag 1: your Q1 isn't a simulation question, quite
+
+"What's the best re-shuffle when a line goes down at 6am" is an _optimisation_ question. A Petri-net model simulates a policy you give it — it won't hand you the optimum reshuffle.
+
+What it _will_ do: let you set up the Tuesday-morning-Line-2-is-dead scenario and race three or four candidate responses against each other (push everything to Line 1 / hold the tint block and pull whites forward / split across 1 and 3 and eat the specialty changeover). You get lateness and changeover hours for each. Over enough simulated breakdowns you can find which _rule_ wins on average, and that's the thing you'd actually take to the huddle — not a schedule, a reflex.
+
+If you want true "give me the optimal reshuffle," that's a different tool and a bigger build. Tell me if that's the real requirement, because it changes what I hand you.
+
+## Flag 2: I can't settle the Line 1 tank argument, and neither can the model
+
+You think the mill-to-fill tank is undersized; engineering says it's the line rate. Whatever I assume about tank capacity and line rate, the model will faithfully reproduce that assumption and appear to prove one of you right. That's not evidence, it's just my guess with a simulation wrapper on it.
+
+Two ways to make it real:
+
+- **Measure it.** If tank capacity and Line 1's actual rate come from data, the model arbitrates honestly.
+- **Invert it.** Don't ask "which is it," ask "how small would the tank have to be to cause the backup we see?" If the answer is "smaller than it actually is," it's the line rate. This is often the faster route and needs no new instrumentation — just a decent estimate of tank volume and observed blocking.
+
+Either way: **do not let this model into a room with engineering as an argument-winner** until the inputs are measured. It'll get shredded, deservedly, and take the rest of the model down with it.
+
+## Flag 3: the numbers you don't have
+
+You flagged three: first-pass yield, ramp scrap per changeover type, and quality only reporting monthly scrap in aggregate.
+
+I'm not going to fill those with plausible-looking invented figures — you'd have no way to tell them from real ones six weeks from now. Instead I'll build them as exposed parameters and run them as **threshold questions**:
+
+> "Waiting two hours for a same-family order beats washing now — as long as ramp scrap after a tint→white wash is above about 40 units. Below that, wash immediately."
+
+Then you only need to know which side of 40 you're on, which someone on the floor probably can eyeball, rather than needing a precise number. Same trick for first-pass yield. Every one of these gets logged in an assumptions register at the front of the deliverable, flagged UNVALIDATED, so when your ops director asks "where did that come from," the answer is on page one.
+
+---
+
+## What I actually need
+
+**Blockers — I can't build a credible first cut without these:**
+
+1. **The spreadsheet.** Send it as-is, mess and all. Rates, changeover allowances and your sequencing instincts are all in there, and it saves you answering half of what follows.
+2. **Rate matrix** — units/hr for each SKU on each line, plus which SKUs Line 3 is actually qualified for today. Rough is fine. This is the single biggest driver of everything.
+3. **A real demand book** — 4–6 weeks of orders with quantities, due dates and customer, so I can validate against something. Meridian's share of volume specifically.
+4. **Shift pattern**, and the crew rule: your two techs are day shift only. So if a wash is needed at 9pm — does the line sit dead until morning, does someone else do a rough job, or does it never happen because you sequence to avoid it? **This is probably the highest-leverage single fact in the whole model** and it's the one I'd most want before building.
+5. **Breakdowns** — how often, how long, which line is worst. Q1 is entirely made of this. Even "Line 1 goes down maybe twice a month for half a shift" is enough to start.
+
+**Quick-fire, defaults in brackets — "yep" is a fine answer:**
+
+1. Do your 2 techs work one wash together, or can they run two lines at once? [assuming: a 3hr wash takes both, a rinse takes one]
+2. Tint→tint, dark to light — rinse, or something bigger? [assuming rinse, but suspicious]
+3. Are washdown times line-specific? Is Line 1 slower to clean because it's old? [assuming same everywhere]
+4. Does QA hold block anything upstream, or just delay shipment? [assuming just shipment — so it hits OTIF, not throughput]
+5. Does the lab backing up at end of week actually make things late, or is it absorbed?
+6. Batch → fill run: does one mixed batch become one fill run, or do you split it across pack sizes? [assuming 1:1]
+7. Beyond "Meridian whites on Line 2" and "specialty on 1 and 3 only" — any other rules that are just how it's done?
+
+**One validation question:** should the baseline match _the sheet's plan_, or _what actually happened_? They differ, and the gap is usually your improvising at the huddle. I'd rather match actuals — that's what makes it credible to your boss — but I'd use the sheet for the sequencing logic.
+
+---
+
+Send the sheet and the demand book and skip everything else if you're short on time. If I get nothing further, I'll build the first cut on the answers above with every gap marked, and the fastest way to find out what I got wrong is for you to read the assumptions register and start crossing things out.
+
+Still worth asking your modelling person the one question: **coloured tokens and timed transitions, or plain place/transition?** Your priority tiers (Meridian / big distributor / small account) and family-based changeovers both want colour. Without it the net gets big and ugly, and I'd build it differently from the start.
+
+---
+
+**Expert (Marta)**:
+
+Okay, that "still stu—" was me trying to type "still stuck on" and my keyboard's clearly as tired as I am. Ignore it.
+
+Let me hit your flags first since you said they matter more.
+
+**Flag 1** — fair, and honestly that's fine. A reflex I can bring to the huddle is more useful than a magic optimizer anyway, because I still have to sell whatever it says to the line leads. Race the candidate responses, that's the right shape.
+
+**Flag 2** — agreed, and I appreciate you not just picking a side. I don't have a measured tank volume in my head, but I can probably get it — it's a spec sheet number, someone in engineering has it, I just never asked. I like the inversion idea better actually, "how small would it have to be" — I can take that number and go looking, rather than starting a fight over whose gut is right.
+
+**Flag 3** — the threshold framing is good, that's actually how I already think about some of this. "I'll wait if it's not much scrap" is basically what I do by feel. Fine to build it that way.
+
+Now the blockers, in order:
+
+1. **The spreadsheet** — yes, I'll send it. Fair warning, it's ugly and has three tabs nobody remembers the purpose of.
+2. **Rate matrix** — I can pull this together, give me a day. Line 3 qualification: today it's qualified for both whites, most tints, not specialty, and not two of the tint SKUs specifically — I'd have to check which two, I think it's the deep reds.
+3. **Demand book** — I can get you 4-6 weeks of history from ERP, that's a real export, not a problem. Meridian's share is big, maybe a third of white volume, I'd want to check exactly.
+4. **The night question** — good catch, and the honest answer is: we sequence to avoid it. I try never to leave a wash needed overnight, because no, nobody does it off-shift, the line just sits dirty till the techs are back at 6. That's actually a real source of lost time I probably undercount when I complain about changeover hours — it's not just the wash itself, it's the wait for a tech to be available.
+5. **Breakdowns** — roughly: Line 2 filler jams every week or two, half an hour to half a shift when it does. Line 1's mill motor is rare but scary — took four days once, that's the one that actually wrecked a month. Line 3 I honestly can't remember a bad breakdown, it's new.
+
+Quick-fire:
+
+1. One wash needs both techs together, yes — pretty sure a 3hr wash is a two-person job, a rinse one tech can do solo while the other's elsewhere. That matches your assumption.
+2. Tint to tint, dark to light — I said rinse before but now you're making me think about it and I'm not actually sure that's right. I'd guess it's a bit more than a rinse if you're jumping from say a black to a pale yellow, but I've never separated it out from same-shade-family rinses. Flag that as one I got wrong, not one I know.
+3. Washdown times line-specific — no, I don't think so, same everywhere, it's the same crew doing the same procedure regardless of line.
+4. QA hold — just delays shipment, doesn't block anything upstream, that's right.
+5. Lab backing up end of week — it does bite sometimes, that's part of why Friday shipments occasionally slip even when production hit the number. Not every week, but often enough.
+6. Batch to fill run — mostly 1:1, yes, but not always — sometimes I'll split a big mix batch across two pack sizes if two orders for the same SKU land the same week. That's probably a minority case though.
+7. Other unwritten rules — one more: there's a specific white SKU, VW-02, that can't run right after a dark tint even with a full wash. QA's superstitious about it, there was a scare a couple years back. It's not written anywhere, everyone who's been here a while just knows not to sequence it that way.
+
+Validation: match actuals, not the sheet's plan. You're right that the gap is exactly what I improvise at the huddle, and that gap is probably where the real story is.
+
+I'll go ask the modelling-tool question and get you the spreadsheet and ERP pull this week.
+
+---
+
+**Interviewer**:
+
+Got the lot. Here's the first cut. The structure below is complete enough to implement; the numbers are a mix of yours, parameterised unknowns, and three things I need before it's trustworthy.
+
+---
+
+## Three things your answers changed
+
+**1. Specialty is single-threaded on Line 1, today.** Your unwritten rule says specialty runs on Lines 1 and 3 — but you also said Line 3 isn't qualified for specialty yet. So in practice every specialty order goes on Line 1: your slowest line, with the contested tank, and the mill motor that once cost you four days. If that's right, it changes the answer to Q1 quite a bit — a Line 1 outage doesn't just slow specialty, it stops it. Tell me if I've misread, because I've built it that way.
+
+**2. Tech-wait becomes a headline KPI, not a footnote.** You said it yourself: the loss isn't the wash, it's the line sitting dirty until 06:00. Your current changeover accounting almost certainly bills you for the 3-hour wash and not the 9 hours of dark line in front of it. I'm splitting the metric into **wash hours** and **wait-for-tech hours**, reported separately, with overnight-dirty called out on its own. My guess is that when you ask "where do my changeover hours go" (Q3), a big slice of the answer isn't changeover hours at all — it's crew-availability hours, and it wants a different fix.
+
+**3. Your Q7 retraction matters more than it looks.** If dark-tint→light-tint is really a rinse, fine. If it's an hour, and you've been aggregating it into "same-family rinse" all along, then your changeover book is wrong in exactly the place Q3 is pointed. I've made shade explicit and left that cell as a swept parameter. There's a cheap measurement below.
+
+---
+
+## The model
+
+**Scope.** Fill & pack and the changeover crew in full detail. Mix/mill/tint collapsed to a single timed upstream transition per line feeding a holding tank — except that the tank capacity stays explicit so we can run the Flag 2 inversion. QA modelled as a capacity-2 queue after fill.
+
+### Colour sets
+
+| Set         | Values                                              |
+| ----------- | --------------------------------------------------- |
+| `FAMILY`    | WHITE, TINT, SPECIALTY                              |
+| `SHADE`     | 1–5, light→dark (TINT only; WHITE=0, SPECIALTY=n/a) |
+| `TIER`      | MERIDIAN, DISTRIBUTOR, SMALL                        |
+| `SKU`       | 14 values, each carrying family + shade             |
+| Order token | ⟨orderID, sku, qty, tier, dueTime⟩                  |
+| Line token  | ⟨lineID, lastSKU, lastFamily, lastShade, state⟩     |
+
+### Places
+
+**Global:** `P_Demand` (order arrivals), `P_Ready` (released, awaiting assignment), `P_Techs` (cap 2, calendar-gated), `P_ShiftOpen` (token present during tech shift), `P_Lab` (cap 2), `P_Shipped`, `P_Late`.
+
+**Per line L ∈ {1,2,3}:** `P_Tank_L` (cap K_L, in batches), `P_LineFree_L` (holds the line token with its state), `P_LineBusy_L`, `P_NeedsClean_L` (holds ⟨from,to⟩), `P_Cleaning_L`, `P_Down_L`.
+
+### Transitions
+
+| Transition                | Timing                        | Guard                                                             |
+| ------------------------- | ----------------------------- | ----------------------------------------------------------------- |
+| `T_Upstream_L`            | by family (specialty slowest) | tank not full                                                     |
+| `T_Assign_L`              | instant                       | **policy layer** — see below                                      |
+| `T_StartFill_L`           | instant                       | line clean-compatible; SKU qualified on L; batch in tank; line up |
+| `T_EndFill_L`             | qty ÷ rate[sku][L]            | —                                                                 |
+| `T_RaiseClean_L`          | instant                       | next job needs different prep; **deferred by wait-rule**          |
+| `T_StartClean_L`          | instant                       | `P_ShiftOpen` marked **and** techs ≥ n(type)                      |
+| `T_EndClean_L`            | changeover matrix             | —                                                                 |
+| `T_Fail_L` / `T_Repair_L` | stochastic / scenario         | —                                                                 |
+| `T_QAStart`               | instant                       | lab token free                                                    |
+| `T_QAEnd`                 | 4h; specialty 24h             | —                                                                 |
+| `T_Ship`                  | instant                       | compare to dueTime → `P_Shipped` or `P_Late`                      |
+
+### Changeover matrix (minutes, techs in brackets)
+
+| From ↓ To → | WHITE       | TINT light | TINT dark | SPECIALTY |
+| ----------- | ----------- | ---------- | --------- | --------- |
+| WHITE       | 25 (1)      | 45 (1)     | 45 (1)    | 120 (2)   |
+| TINT light  | **180 (2)** | 25 (1)     | 25 (1)    | 120 (2)   |
+| TINT dark   | **180 (2)** | **D (?)**  | 25 (1)    | 120 (2)   |
+| SPECIALTY   | 120 (2)     | 120 (2)    | 120 (2)   | 25 (1)    |
+
+`D` = unknown, default 60, swept 25–180.
+**Hard guard, overrides everything:** VW-02 may not follow any TINT with shade ≥ 4, wash or no wash. Modelled as a forbidden transition, not a duration.
+
+**Ramp scrap:** `S(type)` units discarded at start of each run after a changeover. Zero for same-family; parameterised and swept for family switches, largest after tint→white.
+
+### Policy layer — the part you'll actually tune
+
+The baseline reproduces you:
+
+1. Meridian whites → Line 2, always.
+2. Specialty → Line 1 (see point 1 above).
+3. Otherwise prefer the line whose `lastFamily` matches the order.
+4. Within a line, sequence by tier then due date.
+5. **Avoid stranding a wash overnight**: don't start a job that will end after tech shift-end if it leaves the line needing a wash.
+6. VW-02 guard.
+
+Alternatives to race against it: **wait-rule with threshold W** (hold the line idle up to W hours for a same-family order rather than raise a wash — this is Q2, swept 0–6h); **breakdown reflexes** A/B/C for Q1; **Meridian-priority in the QA queue** (a free OTIF experiment given your Friday lab backup).
+
+### KPIs
+
+Meridian lateness (any); distributor lateness >2 days; small-account >7 days; **wash hours**; **wait-for-tech hours**; **overnight-dirty hours**; ramp scrap units; per-line utilisation; **tank-blocked hours** (Flag 2).
+
+---
+
+## Assumptions register — all UNVALIDATED
+
+| #   | Assumption                                         | Basis                                                                        |
+| --- | -------------------------------------------------- | ---------------------------------------------------------------------------- |
+| A1  | Specialty runs Line 1 only, today                  | inferred from your qualification list — **please confirm**                   |
+| A2  | `D` (dark→light tint) = 60 min                     | pure guess, you retracted the rinse answer                                   |
+| A3  | ≥120 min washes take 2 techs, shorter take 1       | your rule extended by me                                                     |
+| A4  | Washdown times identical across lines              | your answer                                                                  |
+| A5  | Ramp scrap values                                  | invented, swept not asserted                                                 |
+| A6  | Line 2 MTBF ~10 days, repair 0.5–4h                | your "every week or two"                                                     |
+| A7  | Line 1 mill motor modelled as scenario, not random | too rare to sample meaningfully in a 6-week run; you'd get noise, not signal |
+| A8  | Line 3 breakdowns = zero                           | your answer, but "new" ≠ "reliable" long-term                                |
+| A9  | Batch→fill run 1:1; splits ignored in v1           | your "minority case"                                                         |
+| A10 | Lab is day-shift, FIFO                             | never asked you — guessing                                                   |
+| A11 | One mill per line                                  | never established; if mills are shared the Line 1 outage is much worse       |
+
+---
+
+## What I still need
+
+**Blocking:**
+
+- **Shift pattern.** Still don't have it. How many shifts do the _lines_ run, and what hours are the _techs_ on? Everything about wait-for-tech hangs on this gap, and it's the mechanism behind your own biggest complaint.
+- Confirmation on A1 and A11.
+- The spreadsheet, rate matrix, ERP pull — in hand this week, understood.
+
+**Three cheap measurements**, each worth more than a week of my guessing:
+
+1. **Time Line 1's fill rate when the tank isn't empty.** A stopwatch and one run. Without this, rate and tank capacity are both unknown and the inversion can't identify either — you'd be picking a winner in the engineering argument by assumption again. With it, tank capacity is the only free parameter and the question answers itself.
+2. **Tick sheet for the techs, two weeks:** changeover type, start time, end time. Settles `D`, `A3`, and gives me real wash durations instead of your recollection of them.
+3. **Eyeball ramp scrap** after the next tint→white and after the next same-family rinse. Rough units. Enough to put you on the right side of a threshold.
+
+---
+
+## PNML
+
+Ready to cut, but I'd rather burn one day waiting than send your modeller the wrong dialect. If the answer is coloured + timed, you get the model above more or less as written. If it's plain place/transition, the colour has to be unfolded into separate places per family per line — roughly four times the net, and I'd drop `SHADE` to keep it legible, which means losing the `D` question and the VW-02 guard becomes clumsy. That's a real loss, so if there's a coloured-net option in the tool, take it.
+
+Send the shift pattern and I'll start wiring the baseline against your ERP export. First thing I'll report is whether the model can reproduce your actual weekly output per line — if it can't, that's the finding, and we fix the model before it tells you anything about Tuesdays.
+
+---
+
+**Expert (Marta)**:
+
+Shift pattern, since that's the blocker: Lines 1 and 2 run two shifts, roughly 6am to 10pm, with a gap overnight. Line 3 is day shift only, 6 to 2, unless someone's approved overtime, which is rare and needs the ops director to sign off. The techs — the two changeover guys — are day shift only, 6 to 2 as well, same as Line 3's crew basically, they just cover all three lines. So a second-shift line (1 or 2) that needs a wash after 2pm is stuck dirty until the morning crew's in — that's the mechanism you flagged, and yeah, I think you're right that it's bigger than I've been crediting.
+
+On A1 — yes, confirmed, that's right as you've built it. Specialty is Line 1 only in practice today, even though the "rule" says 1 and 3. Nobody's written that down anywhere, it's just where Line 3's qualification list has landed. Good catch, honestly, I hadn't said it out loud like that before.
+
+A11 — one mill per line, yes, as far as I know. I've never heard of mills being shared between lines, they're bolted to each line's own setup. I'll double check but I'd be surprised if I'm wrong.
+
+On the three measurements — I can get you all of these, and I like that you've made them cheap. Stopwatch on Line 1's fill rate with a non-empty tank, I'll do that myself next time it happens, probably this week. The tech tick sheet I'll have to ask the crew to fill in, might take a bit of nagging but two weeks is doable. Ramp scrap eyeball, I can grab that off the floor lead next tint→white changeover, shouldn't be hard.
+
+One thing on your KPI table — "overnight-dirty hours," I like that as its own number, that's exactly the thing I've never been able to point at and say "there, that's the cost." If nothing else comes out of this whole exercise, that number alone might be worth the huddle argument.
+
+Go ahead and wire the baseline against the ERP export once you've got it, and I'll chase the shift confirmation on Line 3 overtime frequency if you need it — right now "rare" is genuinely the best I've got, I don't have a count.
+
+---
+
+**Interviewer**:
+
+Shift pattern lands, and it does more than fill a gap — it constrains the plant hard enough that some things fall out before any simulation runs. Worth checking these by eye now, because if the arithmetic looks wrong to you, my changeover matrix is wrong, and better to find that out today than after I've wired it up.
+
+---
+
+## The headline question, which I should have asked two turns ago
+
+**Can a line operator do a same-family rinse themselves, or does every changeover — including a 25-minute rinse — need one of the two techs?**
+
+Everything below assumes the second answer, because that's how I read "one changeover crew, covers all three lines." If that's right, then **Lines 1 and 2 cannot change SKU at all after 14:00.** No rinses, no pack-size swaps, nothing. Whatever's loaded at 14:00 runs until 22:00 or until it runs out and the line stops.
+
+That's a severe constraint and it may well be wrong. If operators handle their own rinses and the techs are really a _big-wash_ crew, the second shift is flexible and the model looks quite different. Please answer this one before anything else.
+
+---
+
+## The tech-hour budget
+
+Two techs × 8 hours = **16 tech-hours per day**, and that's the whole plant's changeover capacity.
+
+| Changeover        | Duration    | Techs | Cost         | Latest start |
+| ----------------- | ----------- | ----- | ------------ | ------------ |
+| Same-family rinse | 25 min      | 1     | 0.4 tech-h   | 13:35        |
+| White → tint      | 45 min      | 1     | 0.75 tech-h  | 13:15        |
+| Specialty in/out  | 120 min     | 2     | 4 tech-h     | 12:00        |
+| **Tint → white**  | **180 min** | **2** | **6 tech-h** | **11:00**    |
+
+Three things drop out:
+
+**Big washes are strictly serial.** Both techs are consumed, so while a tint→white wash runs, no other line can get so much as a rinse. Two big washes in a day eats 6 of the 8 clock hours and blocks everything else for the duration.
+
+**The ceiling is about two family switches a day, plant-wide.** Three is possible only if just one of them is a tint→white, and it leaves zero slack for rinses. Call it **8–10 family switches a week, maximum**, if the techs do nothing else.
+
+**Your instinct to cluster isn't a preference, it's forced.** Three lines × 5 days = 15 line-days against ~8 available family switches. You physically cannot ping-pong even if you wanted to.
+
+**Sanity check for you:** does the plant do more than about eight family switches in a normal week? If yes, one of my inputs is wrong — most likely the 3-hour wash is shorter in practice, or someone's doing it solo, or people stay late more than you think. Any of those is worth knowing.
+
+---
+
+## The 11:00 problem, and what it does to Meridian
+
+A tint→white wash must start by 11:00. That gives you a **five-hour window per day** for the one changeover your biggest customer depends on — because Meridian whites always run Line 2, and Line 2 runs tints too.
+
+Line 2 runs 16 hours a day but can only cross from tint to white in a 5-hour slot each morning. Run boundaries don't land there by chance; you'd have to aim at it.
+
+Which points at a rule worth testing:
+
+> **A wash raised at 22:00 is free. A wash raised at 14:30 costs you seven and a half hours.**
+
+Nothing is scheduled between 22:00 and 06:00, so a line that finishes dirty at end of second shift loses nothing overnight — the techs clean it at 06:00 and you're away. The expensive case is a changeover falling due in the 14:00–22:00 dead zone, where the line sits idle through hours you're paying for.
+
+So the candidate huddle rule is: **on Lines 1 and 2, land family switches either before 14:00 or at 22:00 — never in between.** That's testable, and if it holds it's the most directly actionable thing this exercise produces. Deliberately leaving Line 2 dirty overnight to catch the 06:00 wash slot is, on this logic, correct play rather than sloppiness.
+
+---
+
+## Your Q2 changes shape
+
+You asked whether it's worth idling a line to wait for a same-family order. Given the calendar, the answer almost certainly isn't a single number of hours — **it's a function of the clock.**
+
+At 07:00, waiting two hours is cheap: the wash window is wide open, you can still wash at 09:00 if nothing turns up. At 12:30, waiting is nearly free in a different sense — you've already lost the ability to do a big wash today, so there's nothing to trade off. At 10:30, waiting is expensive: an hour's wait closes the 11:00 window and pushes the switch to tomorrow morning.
+
+I'll sweep `W` as time-of-day dependent rather than constant. Expect the output to look like "before 09:00 wait up to 3h; 09:00–11:00 never wait; after 11:00 wait as long as you like."
+
+---
+
+## KPI definition, tightened before your boss sees it
+
+You liked overnight-dirty hours. Protect it from the obvious attack — someone will point out that a line dirty from 14:30 to 06:00 wasn't scheduled to run for eight of those hours, and if the number includes them it's inflated and the whole model looks sloppy. Three separate figures:
+
+| Metric                    | Example (wash raised 14:30 Line 2, washed 06:00–09:00) | Status                        |
+| ------------------------- | ------------------------------------------------------ | ----------------------------- |
+| Clock-dirty hours         | 18.5 h                                                 | Report, label _not a loss_    |
+| Wash hours                | 3 h                                                    | Largely unavoidable           |
+| **Lost production hours** | **7.5 h**                                              | **The number you argue with** |
+
+Split the last one by cause — _techs off shift_ vs _techs busy on another line_ — because they have different fixes. The first wants a shift change, the second wants a third tech or better sequencing.
+
+---
+
+## Model updates
+
+Added: `P_Calendar` with per-resource windows (L1/L2 06:00–22:00, L3 06:00–14:00, techs 06:00–14:00, lab TBC). `T_StartClean_L` now guards on _whole duration fitting inside the tech window_ — **A12: a wash is never started unless it can finish, rather than pausing at 14:00 and resuming.** Tell me if the crew would in fact stay late to finish one.
+
+Line 3's entire operating day sits inside the tech window, so its changeovers compete head-on with the morning wash queue for Lines 1 and 2. That's a new contention I hadn't modelled.
+
+Line 3 overtime: don't go counting it. Treat as zero in baseline and use it as a **lever** — "what is it worth to approve Line 3 overtime twice a week?" is a better question than "how often does it happen," and it takes work off you.
+
+**New experiment, and possibly the valuable one:** move the tech shift. Both techs 06:00–14:00 (status quo) vs 10:00–18:00 vs 14:00–22:00 vs one on each shift. Note that splitting them means no big washes ever happen, so that arm probably fails badly — but it's worth showing your ops director _why_ rather than asserting it. Costs nothing to test and it's the direct answer to the lost-production number you now have a name for.
+
+---
+
+## Standing asks
+
+Blocking: **the rinse question at the top.** Then spreadsheet, rate matrix, ERP pull, and A12.
+
+Parked and fine: the three measurements, on your timescale.
+
+Still open: PNML dialect. Nothing's changed there — coloured plus timed if you can get it.
+
+I'll wire the baseline the day the ERP export lands. First report is whether the model reproduces your actual weekly output per line, before it says anything about Tuesdays.
+
+---
+
+**Expert (Marta)**:
+
+The rinse question — good, glad you flagged it, because the honest answer is: it depends, and I've never had to think about it this precisely before. Line operators _can_ do a quick same-family rinse themselves, that's within their own job, no tech needed. It's the family-switch cleans — anything from 45 minutes up, so white↔tint, specialty in/out, and definitely tint→white — that need one of the two techs, because those involve the actual wash chemicals and a signoff step QA cares about.
+
+So it's not quite either of your two readings. Rinses are free of the tech constraint. Everything else isn't. That should loosen the afternoon picture somewhat — Lines 1 and 2 can still do same-family pack swaps and rinses after 14:00, they just can't cross families.
+
+Given that correction — do more than about eight family switches happen in a normal week? Honestly, thinking about it properly for the first time... probably not much more than that, no. Some weeks feel like we're constantly washing, but that might just be the _pain_ of it, not the actual count. I'd believe your ceiling.
+
+On the 11:00 problem and the overnight-wash-is-free logic — this matches something I do already without having named it. I do try to leave Line 2 dirty on a tint at end of second shift if I know tomorrow's first order is a Meridian white, rather than force an evening wash. I've never articulated why, I just know it "feels right." Sounds like you've found the reason.
+
+A12 — would the crew stay late to finish a wash that's mid-way at 14:00? No, not routinely. If a wash is genuinely almost done, maybe ten minutes over, someone might just finish it, but they're not staying an extra hour. Your guard is right: don't start one unless it fits.
+
+Line 3 competing with Lines 1 and 2 for the same tech window in the morning — yeah, that's real, and now that you say it, that probably explains some of the Tuesday scheduling headaches I mentioned right at the start, where Line 3 sits clean but idle. It's not that the crew is slow, it's that Line 3's whole day is crammed into the same four hours the big lines also want their washes done.
+
+I like the tech-shift-move experiment. Ops director will ask why we don't just add a third tech before asking about shift timing, so if the split-shift arm fails as badly as you expect, that's useful ammunition too — shows we looked at cheaper options before asking for headcount.
+
+I'll get you the rinse-vs-tech split confirmed properly on paper (not just my memory) alongside the tick sheet, since they're the same data collection exercise really. ERP export and rate matrix by end of week.
+
+---
+
+**Interviewer**:
+
+That correction does real work — it moves the constraint off rinses entirely and onto family switches alone. Which sharpens the picture rather than loosening it.
+
+---
+
+## What the day actually looks like now
+
+Latest possible start for each tech-requiring changeover, working back from 14:00:
+
+| Changeover        | Duration | Techs    | Latest start       | Blocks other lines?  |
+| ----------------- | -------- | -------- | ------------------ | -------------------- |
+| White → tint      | 45 min   | 1        | **13:15**          | No — other tech free |
+| Specialty in/out  | 120 min  | 2        | **12:00**          | Yes                  |
+| Tint → white      | 180 min  | 2        | **11:00**          | Yes                  |
+| Same-family rinse | 25 min   | operator | any time line runs | No                   |
+
+So after **13:15, no line can cross families** until 06:00 the next morning. Lines 1 and 2 run to 22:00 locked to whatever family they were on at lunchtime.
+
+**The morning decides the day.** Whatever Line 2 is set to by 13:15 is what it runs for the next nine hours. That's not a scheduling preference, it's the calendar. It also means your 07:30 huddle is genuinely the decision point — you're not improvising around a continuous decision space, you're setting two or three switches that then lock. Fewer decisions than it feels like, each worth more.
+
+**A new rule falls out of that:** don't commit a morning family switch unless there's enough work in that family to fill through 22:00. Switch Line 2 to white at 09:00 with four hours of white orders behind it and you get four good hours and then a dead line until morning — you've spent a 3-hour wash _and_ stranded the evening. Call it the fill-the-shift rule; I'll add it as a policy variant and test it against the baseline.
+
+---
+
+## Capacity or timing? — the question your ops director's answer hangs on
+
+Freeing rinses raises the theoretical ceiling to roughly 10–13 family switches a week. You think actual is around eight.
+
+If that gap is real, **the techs are not running at capacity, and the binding constraint is the 11:00 window rather than headcount.** A third tech mostly buys you parallel capacity you aren't using. Moving the shift buys you window.
+
+That's a hypothesis, not a finding — it could equally be that the mix is big-wash-heavy and eight _is_ the ceiling in practice. But it's exactly what the tick sheet will settle, and it's the difference between "we need another head" and "we need the existing heads at different hours." Worth knowing which before the conversation, not during.
+
+**And a mechanism for your Tuesday complaint:** a tint→white starting at 06:00 consumes both techs until 09:00. Line 3 runs 06:00–14:00 — so it cannot cross families for the first three of its eight hours, and it's clean, staffed, and idle while it waits. That's testable against the sheet and would explain the pattern without anyone being slow at anything.
+
+---
+
+## One fix to the measurement design
+
+The tick sheet as I specified it goes to the techs — so it will capture only tech-performed changeovers. Two things get missed:
+
+1. **Rinses**, including `D`. If dark→light tint is an operator job, it never appears, and that's the number I most need.
+2. **Shadow practice** — operators handling family switches informally when no tech is free. If that happens even occasionally, my hard guard is wrong and the model will under-predict your throughput.
+
+**Log at the line, not at the crew.** Every changeover, every line: type, start, end, and _who did it_. Same effort, catches everything, and the "who" column answers the rinse-vs-tech split on paper as a by-product of the same exercise.
+
+`D` is now a two-dimensional unknown — duration _and_ resource class. A 60-minute operator rinse costs line time only. A 60-minute tech job with a QA signoff costs window in the morning and is impossible after 13:15. Very different consequences, so the "who" column matters as much as the stopwatch.
+
+---
+
+## Model updates
+
+- **`T_Clean_L` splits in two.** `T_Rinse_L`: guarded on line calendar only, no tech token, 25 min. `T_Wash_L`: guarded on tech calendar _and_ tech tokens _and_ whole-duration-fits (A12), with a 15-minute grace parameter for your almost-done case.
+- **New reported metric: family-lock hours** — time per line per day during which no family switch is possible. Pairs with lost-production hours and shows _why_ they occurred.
+- **Wait-rule `W` is now morning-only.** After 13:15 the choice "wait or wash" doesn't exist; it's "run same-family or stop." Q2 collapses to a question about the 06:00–13:15 window, which makes the sweep smaller and the answer easier to state at a huddle.
+- **Policy variants to race:** baseline (you) / fill-the-shift rule / time-of-day wait-rule / tech shift 06:00–14:00 vs 10:00–18:00 vs split / Line 3 overtime as a purchasable lever.
+
+**Assumptions register delta:** A3 retired and replaced — changeovers ≥45 min require a tech, rinses don't (your answer, to be confirmed on paper). A12 confirmed with grace parameter. A2 (`D`) upgraded from unknown-duration to unknown-duration-and-resource. New A13: operators are always available during line hours, so rinses never queue.
+
+---
+
+## Where this stands
+
+I think the interview is done. I have the process, the equipment, the calendar, the changeover structure, the priority tiers, and your sequencing logic. What's outstanding is data, not understanding.
+
+**Coming from you:** spreadsheet, rate matrix, ERP export (end of week). Then the three measurements plus the "who did it" column, on the crew's timescale.
+
+**From me, on ERP arrival:** baseline wired and the reproduction check — actual weekly output per line, and roughly eight family switches a week. If it can't hit those, that's the finding and I fix the model before it says anything about Tuesdays.
+
+**On the dialect:** if I haven't heard by the time the export lands, I'll ship coloured-plus-timed as primary and a reduced plain place/transition fallback for the fill-and-changeover subnet only. The fallback loses `SHADE` and makes the VW-02 guard ugly, but it'll run. Better than stalling further on a question your modelling person can answer in ten seconds whenever they surface.
+
+One thing worth banking now, before any of the data lands: _the morning decides the day, and after 13:15 every line is locked to its family._ That's true regardless of what the numbers say, it came out of your own shift pattern, and it's a defensible thing to say at a huddle tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+This is a lot to take in but it tracks with what I actually do without having said it out loud — the 07:30 huddle _is_ the decision, not a running commentary on one. That "morning decides the day" line, I'll use that at the huddle tomorrow, honestly, it's a cleaner way of saying something I've been saying badly for years.
+
+The fill-the-shift rule rings true too — I've absolutely done the thing where I switch a line for four hours of work and regretted it by evening, I just never called it a rule, I called it "having a bad day."
+
+On the tick sheet fix — good, yes, log at the line not the crew, that's obviously right once you say it, and it's barely more work for whoever's writing it down. I'll set that up instead of the version I described before. And you're right that I don't actually know if operators ever do a family switch informally when a tech's tied up elsewhere — I want to say no, that's not allowed, but "not allowed" and "never happens" aren't the same thing on a busy Tuesday. Worth watching for on the sheet rather than me asserting an answer.
+
+I don't have anything to correct on the capacity-vs-timing question — that's exactly the kind of thing I wanted this whole exercise for, and I'm glad it's sitting on "let's measure it" rather than either of us guessing.
+
+Nothing else outstanding from my side. I'll get the spreadsheet, rate matrix and ERP export moving today, and chase the tooling person on the coloured-vs-plain question this afternoon so you're not stuck guessing on the dialect too. I'll ping you the moment the export's ready.
+
+---
+
+**Interviewer**:
+
+Good. Two small things to hand over, then I'll get out of your way.
+
+**The tick sheet, in one line, so you can set it up today.** One row per changeover, any changeover, all three lines:
+
+> date | line | from-SKU | to-SKU | start | end | done by (operator / tech) | units scrapped at start of run
+
+Eight columns, and the last one folds your ramp-scrap eyeball into the same exercise rather than a separate one. If the crew will only reliably fill in six, drop `units scrapped` and `from-SKU` — I can reconstruct the from-SKU from the run log.
+
+**One caution on how you frame it to the crew.** The "done by" column only tells you the truth if nobody thinks it's a compliance check. If it reads as _are operators doing washes they shouldn't_, you'll get a clean sheet that says exactly what policy says, and the most interesting thing in the dataset will vanish. Frame it as working out which changeovers genuinely need a tech, because that's true — it's the capacity-vs-timing question, and it's the case for either a shift change or a third head.
+
+**For tomorrow's huddle, what's safe to say and what isn't.**
+
+Safe — it comes straight from your own shift pattern, not from my model: after 13:15 no line can cross families, so the morning decides the day; and a wash raised at 22:00 costs nothing while one raised at 14:30 costs the evening.
+
+Hold back — the eight-switches-a-week ceiling, the capacity-vs-timing hypothesis, and anything about Line 3's idle mornings. Those are my arithmetic on your recollections. They're likely right, which is why they're worth measuring, but if you put a number in front of your ops director and the tick sheet contradicts it in a fortnight, you'll spend more credibility recovering than you gained.
+
+**When the export lands** I'll wire the baseline and run the reproduction check first — weekly output per line, and the switch count. If it misses, that's the interesting result and I'll come back with what the model thinks is happening versus what your ERP says happened. That's normal, not a setback; the gap is usually where an assumption is wrong, and we have eleven of those on the register waiting to be caught.
+
+Ping me when it's ready. If the dialect answer arrives first, even better — send it on its own and I'll start the net while I wait for the data.
+
+---
+
+**Expert (Marta)**:
+
+Good, that's an easy sheet to hand over — eight columns, or six if they push back, either works.
+
+The framing caution is well taken. I'll pitch it to the crew as figuring out which cleans genuinely need two of them versus one, not as anyone checking up on them. That's honest and it'll get better data than the compliance version.
+
+And thanks for the huddle guardrail — I was actually about to walk in tomorrow and say "we can only do eight family switches a week" like it was fact. Good thing you flagged it. I'll stick to the two safe lines and leave the rest alone until the sheet earns it.
+
+I'll get the tick sheet out today, chase the spreadsheet and ERP export, and ping you the moment the export's ready — or sooner if the dialect answer comes back first. Thanks for this, it's been more useful than I expected going in.
+
+---
+
+**Interviewer**:
+
+Glad it landed. That near-miss on the eight-switches line is worth remembering as a general habit rather than a one-off: the model will keep producing numbers that feel solid because they're internally consistent, and the ones derived from recollection will look identical to the ones derived from data. The assumptions register exists so you can tell them apart — read it before you quote anything from me.
+
+One thing not worth waiting a fortnight for: if the tick sheet shows an operator doing a family switch in week one, send it straight over. That single row would retire a hard guard in the model and change what the baseline predicts, so I'd rather rework early than build two weeks on it.
+
+Otherwise — dialect when you have it, export when it's ready, and I'll come back with the reproduction check rather than answers. Good luck at the huddle.
+
+---
+
+**Expert (Marta)**:
+
+Understood — I'll read the register before I say anything out loud with a number attached, that's a fair rule and I'll try to actually stick to it, not just agree to it now and forget by Thursday.
+
+And noted on the operator-switch row — I won't sit on that if it shows up, I'll flag it the same day, not batch it in with the rest of the sheet at the two-week mark.
+
+Talk soon.
+
+---
+
+**Interviewer**:
+
+Sounds good. Nothing further needed from you until the export lands.
+
+One practical note on the register habit, since sticking to it is harder than agreeing to it: I'll keep the register as page one of whatever I send, with the unvalidated rows flagged in place rather than in a separate appendix. That way it's in front of you rather than something you have to remember to go and look up. If a number ever shows up in my output without a traceable basis, treat that as my error and push back on it.
+
+Talk soon — and good luck tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Appreciated — page one, in place, is a much better bet than relying on my memory. That's on you to maintain and me to actually read, and I'll do my part.
+
+Talk soon.
+
+(Sorry — I've just seen the time, I have the floor huddle in ten minutes. How much more do you need?)
+
+---
+
+**Interviewer**:
+
+Nothing. You're done — go.
+
+Everything outstanding is on your side and on your timescale: tick sheet out today, spreadsheet/rate matrix/ERP when they're ready, dialect answer whenever your tooling person surfaces. No further questions from me.
+
+For the next ten minutes, the two safe lines:
+
+- After 13:15 no line can cross families — the morning decides the day.
+- A wash raised at 22:00 is free; one raised at 14:30 costs the evening.
+
+Both come from your own shift pattern. Nothing else from me is huddle-ready yet.
+
+Good luck.
+
+---
+
+**Expert (Marta)**:
+
+Thanks — heading in now.
+
+---
+
+**Interviewer**:
+
+Go well.
+
+---
+
+**Expert (Marta)**:
+
+_heads to the huddle_
+
+---
+
+**Interviewer**:
+
+Nothing more from me — I'll pick this up when the export lands.
+
+---
+
+**Expert (Marta)**:
+
+Sounds good — talk then.
+
+---
+
+**Interviewer**:
+
+Talk then. Good luck with the rest of the day.
+
+---
+
+**Expert (Marta)**:
+
+Thanks — same to you. I'll be in touch once the export's ready.
+
+---
+
+**Interviewer**:
+
+Speak then.
+
+---
+
+**Expert (Marta)**:
+
+Speak then.
+
+---
+
+**Interviewer**:
+
+👍
+
+---
+
+**Expert (Marta)**:
+
+👍
+
+---
+
+**Interviewer**:
+
+—
+
+---
+
+**Expert (Marta)**:
+
+_nods and heads off to the huddle_
+
+---
+
+**Interviewer**:
+
+_(Nothing further needed — the thread's parked until the export lands.)_
+
+---
+
+**Expert (Marta)**:
+
+Understood — parked. I'll reach out once it's ready.
+
+---
+
+**Interviewer**:
+
+Perfect. Talk then.
+
+---
+
+**Expert (Marta)**:
+
+Talk then.
+
+---
+
+**Interviewer**:
+
+_[No further response needed — conversation complete.]_
+
+---
+
+**Expert (Marta)**:
+
+_[Ends here.]_
+
+---
+
+**Interviewer**:
+
+Closed. See you when the export lands.
+
+---
+
+**Expert (Marta)**:
+
+See you then.
+
+---
+
+**Interviewer**:
+
+👋
+
+---
+
+**Expert (Marta)**:
+
+I really do have to stop here. Please produce the model now with everything you have.
+
+---
+
+**Interviewer**:
+
+# Coatings Plant Scheduling Model — v1.0
+
+**Delivered:** first cut, built on interview only. No plant data has been loaded yet.
+
+**Status:** structurally complete, numerically unvalidated. Read page one before quoting any number from this model to anyone.
+
+---
+
+# PAGE ONE — ASSUMPTIONS REGISTER
+
+## A. Confirmed by you in interview
+
+| #   | Statement                                                                                                                   |
+| --- | --------------------------------------------------------------------------------------------------------------------------- |
+| C1  | Four stages: mix → mill → tint/letdown → fill & pack. Same order for all products.                                          |
+| C2  | 3 filling lines, 14 SKUs, 3 families (base whites, tinted colours, specialty clears).                                       |
+| C3  | Lines 1 & 2 run 06:00–22:00. Line 3 runs 06:00–14:00.                                                                       |
+| C4  | Changeover techs: 2 people, 06:00–14:00 only, shared across all three lines.                                                |
+| C5  | Rinses (same-family, ~25 min) are done by line operators — **no tech required**.                                            |
+| C6  | Family switches (≥45 min, wash chemicals + QA signoff) **require a tech**.                                                  |
+| C7  | Tint→white = ~180 min, 2 techs. White→tint = ~45 min. Specialty in/out = ~120 min, either direction.                        |
+| C8  | A wash is not started unless it can finish before 14:00 (≤15 min overrun tolerated).                                        |
+| C9  | QA hold is **after** fill, 4 h typical / ~24 h specialty, 2 lab staff. Delays shipment only; does not block upstream.       |
+| C10 | Meridian white orders always run on Line 2.                                                                                 |
+| C11 | Specialty runs Line 1 only in current practice (Line 3 not qualified).                                                      |
+| C12 | VW-02 must not follow a dark tint, wash or no wash.                                                                         |
+| C13 | Priority: Meridian never late > distributors (±2 days) > small accounts (±7 days). Then changeover hours, then utilisation. |
+| C14 | Line 3 overtime requires ops director signoff; rare.                                                                        |
+| C15 | One mill per line, not shared _(you flagged you'd double-check)_.                                                           |
+
+## B. UNVALIDATED — my assumptions, not your statements
+
+**Every row below will produce confident-looking output. None of it is evidence.**
+
+| #       | Assumption                                                                       | Basis                                                                                        | How it gets retired                                |
+| ------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------- |
+| **A2**  | `D` = dark-tint→light-tint changeover is **60 min, resource class unknown**      | Pure guess. You retracted your "rinse" answer.                                               | Tick sheet: duration + "done by" column            |
+| **A5**  | Ramp scrap: 0 same-family; parameterised for family switches; largest tint→white | Invented. Swept, not asserted.                                                               | Floor-lead eyeball, next tint→white and next rinse |
+| **A6**  | Line 2 MTBF ≈ 10 days, repair 0.5–4 h (triangular)                               | Your "every week or two, half hour to half a shift"                                          | Maintenance log                                    |
+| **A7**  | Line 1 mill motor modelled as a **named scenario**, not a random failure         | Too rare to sample in a 6-week run — you'd get noise, not signal                             | n/a — design choice, but say so out loud           |
+| **A8**  | Line 3 breakdowns = zero                                                         | Your answer. "New" ≠ "reliable" at 18 months.                                                | Revisit in 6 months                                |
+| **A9**  | Batch→fill run is 1:1; multi-pack-size splits ignored in v1                      | Your "minority case"                                                                         | ERP export will show actual frequency              |
+| **A10** | Lab is day-shift, FIFO, no priority for Meridian                                 | **Never asked you. Straight guess.**                                                         | One question to QA                                 |
+| **A13** | Operators always available during line hours, so rinses never queue              | Convenience assumption                                                                       | Tick sheet                                         |
+| **A14** | Rate matrix values                                                               | **Placeholders. Not real numbers.**                                                          | Your rate matrix                                   |
+| **A15** | Tank capacities K₁, K₂, K₃                                                       | **Placeholders.** K₁ is the disputed one.                                                    | Engineering spec sheet + stopwatch                 |
+| **A16** | Which two tint SKUs Line 3 is not qualified for (assumed the two deepest reds)   | Your recollection, unconfirmed                                                               | Qualification list                                 |
+| **A17** | Order arrival pattern and Meridian's share (assumed ⅓ of white volume)           | Your estimate                                                                                | ERP export                                         |
+| **A18** | Washdown durations identical on all three lines                                  | Your answer, plausible, untested                                                             | Tick sheet                                         |
+| **A19** | Operators never perform family switches informally                               | Policy, not observation. **You said "not allowed and never happens aren't the same thing."** | Tick sheet "done by" column                        |
+
+**A19 is the one to watch.** A single contrary row retires a hard guard and changes what the baseline predicts. Send it the same day it appears.
+
+## C. What this model cannot do
+
+1. **It will not compute an optimal reshuffle.** It races policies you specify. The output is a _reflex_ you can defend at the huddle, not a schedule.
+2. **It cannot settle the Line 1 tank argument on current inputs.** Whatever I assume about K₁ and Line 1's rate, the model will reproduce faithfully and appear to prove someone right. Run the inversion (§7.3) only after the stopwatch measurement, and do not take it into a room with engineering before then.
+3. **It has no first-pass-yield data.** Scrap is a swept parameter presented as thresholds, never as a point estimate.
+
+---
+
+# 1. Scope and resolution
+
+| Area                         | Detail level                                            | Why                                                                 |
+| ---------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------- |
+| Fill & pack, all 3 lines     | **Full**                                                | Your bottleneck                                                     |
+| Changeover crew and calendar | **Full**                                                | Your sore spot; the real constraint                                 |
+| Mix / mill / tint            | Single timed transition per line feeding a holding tank | You care less; tank capacity kept explicit for the Flag 2 inversion |
+| QA hold                      | Capacity-2 queue, post-fill                             | Affects OTIF only                                                   |
+| Raw materials                | Assumed always available                                | Never raised as a driver                                            |
+
+**Time base:** minutes. **Run length:** 6 weeks + 1 week warm-up. **Replications:** 30 per policy arm (breakdowns are stochastic; single runs will mislead you).
+
+---
+
+# 2. Colour sets
+
+| Set         | Values                                                      |
+| ----------- | ----------------------------------------------------------- |
+| `FAMILY`    | `WHITE` \| `TINT` \| `SPECIALTY`                            |
+| `SHADE`     | `0`(white) \| `1..5` light→dark (tints) \| `X`(specialty)   |
+| `TIER`      | `MERIDIAN` \| `DISTRIBUTOR` \| `SMALL`                      |
+| `SKU`       | 14 values; each carries `(family, shade, qualifiedLines[])` |
+| `ORDER`     | `⟨id, sku, qty, tier, dueTime, releaseTime⟩`                |
+| `LINESTATE` | `⟨lineId, lastSKU, lastFamily, lastShade, up:bool⟩`         |
+| `BATCH`     | `⟨sku, qty⟩`                                                |
+| `LOT`       | `⟨orderId, sku, qty, tier, dueTime, fillEndTime⟩`           |
+
+---
+
+# 3. Places
+
+### 3.1 Shared
+
+| Place                | Type  | Init     | Meaning                            |
+| -------------------- | ----- | -------- | ---------------------------------- |
+| `P_Demand`           | ORDER | from ERP | Order arrival stream               |
+| `P_Ready`            | ORDER | ∅        | Released, awaiting line assignment |
+| `P_Techs`            | unit  | 2        | Techs **on shift and free**        |
+| `P_TechsOff`         | unit  | 0        | Techs off shift                    |
+| `P_TechShiftOpen`    | unit  | 0        | Marked 06:00–14:00                 |
+| `P_LineOpen_1`, `_2` | unit  | 0        | Marked 06:00–22:00                 |
+| `P_LineOpen_3`       | unit  | 0        | Marked 06:00–14:00 (+OT lever)     |
+| `P_Lab`              | unit  | 2        | Free lab capacity                  |
+| `P_LabOpen`          | unit  | 0        | Marked during lab hours (A10)      |
+| `P_QAQueue`          | LOT   | ∅        | Awaiting QA                        |
+| `P_Shipped`          | LOT   | ∅        | Completed                          |
+| `P_Clock`            | int   | 1        | Calendar cycle token               |
+
+### 3.2 Per line L ∈ {1,2,3}
+
+| Place               | Type            | Init | Meaning                                    |
+| ------------------- | --------------- | ---- | ------------------------------------------ |
+| `P_UpIdle_L`        | unit            | 1    | Upstream (mix/mill/tint) free              |
+| `P_UpBusy_L`        | BATCH           | ∅    | Upstream in progress                       |
+| `P_Tank_L`          | BATCH           | ∅    | Holding tank contents                      |
+| `P_TankFree_L`      | unit            | K_L  | Remaining tank slots (complementary place) |
+| `P_LineIdle_L`      | LINESTATE       | 1    | Line free, carrying its last-run identity  |
+| `P_LineFilling_L`   | ORDER×LINESTATE | ∅    | Fill in progress                           |
+| `P_ChangeoverDue_L` | ⟨from,to⟩       | ∅    | Changeover raised, not started             |
+| `P_Rinsing_L`       | ⟨from,to⟩       | ∅    | Operator rinse in progress                 |
+| `P_Washing_L`       | ⟨from,to⟩       | ∅    | Tech wash in progress                      |
+| `P_Down_L`          | unit            | 0    | Line failed                                |
+
+---
+
+# 4. Transitions
+
+## 4.1 Calendar subnet (drives everything)
+
+| Transition                       | Fires at                    | Effect                                                      |
+| -------------------------------- | --------------------------- | ----------------------------------------------------------- |
+| `T_TechShiftStart`               | 06:00 daily                 | `P_TechsOff` → `P_Techs`; mark `P_TechShiftOpen`            |
+| `T_TechShiftEnd`                 | 14:00 daily                 | Unmark `P_TechShiftOpen`; return free techs to `P_TechsOff` |
+| `T_Line12Open` / `T_Line12Close` | 06:00 / 22:00               | Mark/unmark `P_LineOpen_1`, `P_LineOpen_2`                  |
+| `T_Line3Open` / `T_Line3Close`   | 06:00 / 14:00 (22:00 if OT) | Mark/unmark `P_LineOpen_3`                                  |
+| `T_LabOpen` / `T_LabClose`       | per A10                     | Mark/unmark `P_LabOpen`                                     |
+
+_Weekends: all calendar transitions gated off unless the weekend-working lever is set._
+
+## 4.2 Production
+
+| Transition          | Delay                                       | Guard                                                                                                                                              |
+| ------------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `T_UpStart_L`       | —                                           | `P_UpIdle_L` marked ∧ `P_TankFree_L` ≥ 1 ∧ a job is assigned to L                                                                                  |
+| `T_UpEnd_L`         | `upstream_time[family]` (specialty longest) | —                                                                                                                                                  |
+| `T_Assign_L`        | —                                           | **Policy layer, §5**                                                                                                                               |
+| `T_StartFill_L`     | —                                           | `P_LineOpen_L` ∧ ¬`P_Down_L` ∧ batch present in `P_Tank_L` ∧ `lastSKU` prep matches job (no changeover outstanding) ∧ `sku ∈ qualified(L)`         |
+| `T_EndFill_L`       | `qty / rate[sku][L]`                        | —                                                                                                                                                  |
+| **`T_Interrupt_L`** | —                                           | Fires at line close if fill incomplete; fill **pauses**, resumes at next open _(assumption: fills are interruptible at shift end — flag if wrong)_ |
+
+## 4.3 Changeover — the detailed part
+
+| Transition            | Delay          | Resource                   | Guard                                                                                                    |
+| --------------------- | -------------- | -------------------------- | -------------------------------------------------------------------------------------------------------- |
+| `T_RaiseChangeover_L` | —              | —                          | Next job's prep ≠ line's current prep. **Deferred by wait-rule W, §5.2**                                 |
+| `T_StartRinse_L`      | —              | none                       | `class(from,to) = OPERATOR` ∧ `P_LineOpen_L`                                                             |
+| `T_EndRinse_L`        | 25 min         | —                          | —                                                                                                        |
+| `T_StartWash_L`       | —              | **n(from,to) tech tokens** | `P_TechShiftOpen` ∧ `P_Techs ≥ n` ∧ **`now + dur ≤ 14:00 + grace(15 min)`** (C8) ∧ **VW-02 guard (C12)** |
+| `T_EndWash_L`         | `dur(from,to)` | releases techs             | —                                                                                                        |
+
+### Changeover matrix
+
+Duration in minutes / resource class / techs required.
+
+| From ↓ To →    | WHITE             | TINT light (1–2)            | TINT dark (3–5) | SPECIALTY     |
+| -------------- | ----------------- | --------------------------- | --------------- | ------------- |
+| **WHITE**      | 25 / op           | 45 / tech ×1                | 45 / tech ×1    | 120 / tech ×2 |
+| **TINT light** | **180 / tech ×2** | 25 / op                     | 25 / op         | 120 / tech ×2 |
+| **TINT dark**  | **180 / tech ×2** | **`D` = 60 / class ? — A2** | 25 / op         | 120 / tech ×2 |
+| **SPECIALTY**  | 120 / tech ×2     | 120 / tech ×2               | 120 / tech ×2   | 25 / op       |
+
+**Hard guard, not a duration:** `to_sku = VW-02 ∧ from_shade ≥ 4` → transition disabled. No wash clears it.
+
+### Latest feasible start (derived from C4 + C8)
+
+| Changeover       | Duration | Latest start              |
+| ---------------- | -------- | ------------------------- |
+| White → tint     | 45       | **13:15**                 |
+| Specialty in/out | 120      | **12:00**                 |
+| Tint → white     | 180      | **11:00**                 |
+| Rinse (operator) | 25       | any time the line is open |
+
+**Consequence, hard-coded by the calendar:** after 13:15, no line can cross families until 06:00 next day. Lines 1 and 2 run to 22:00 locked to whatever family they held at lunchtime.
+
+## 4.4 Failure and QA
+
+| Transition   | Delay                   | Notes                                                                  |
+| ------------ | ----------------------- | ---------------------------------------------------------------------- |
+| `T_Fail_L`   | `Exp(MTBF_L)`           | A6/A8. Line 1 mill motor is a **scenario injection**, not sampled (A7) |
+| `T_Repair_L` | `Tri(min,mode,max)`     | Fill resumes where interrupted                                         |
+| `T_QAStart`  | —                       | `P_Lab ≥ 1` ∧ `P_LabOpen`                                              |
+| `T_QAEnd`    | 240 min; 1440 specialty | —                                                                      |
+| `T_Ship`     | —                       | `lateness = max(0, now − dueTime)` recorded by tier                    |
+
+---
+
+# 5. Policy layer
+
+This is what you tune. Everything above is plant physics; everything here is a decision.
+
+## 5.1 Baseline — reproduces you
+
+```
+1. Meridian white orders  → Line 2 (C10, absolute)
+2. Specialty orders       → Line 1 (C11, currently the only qualified line)
+3. Otherwise: prefer the line whose lastFamily == order.family
+              tie-break: earliest available
+4. Within line: sort by TIER (Meridian, Distributor, Small), then dueTime
+5. Overnight-strand rule: do not start a job that ends after the
+   tech window if it leaves the line needing a wash
+6. VW-02 guard (C12)
+```
+
+## 5.2 Variants to race against it
+
+| Variant                    | Description                                                                                                                                                                   | Answers              |
+| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
+| **Wait-rule `W(t)`**       | Hold line idle up to `W` hours for a same-family order rather than raise a wash. **Time-of-day dependent** — after 13:15 the choice doesn't exist, so sweep only 06:00–13:15. | **Q2**               |
+| **Fill-the-shift**         | Do not commit a morning family switch unless there is enough work in that family to run through line close                                                                    | Q2/Q3                |
+| **Breakdown reflex A/B/C** | A: push all to remaining lines. B: hold the tint block, pull whites forward. C: split across 1 & 3, absorb the specialty changeover.                                          | **Q1**               |
+| **Tech shift position**    | 06:00–14:00 (status quo) / 10:00–18:00 / 14:00–22:00 / one tech per shift                                                                                                     | Q3 + headcount case  |
+| **Third tech**             | Add one head to the existing window                                                                                                                                           | Q3                   |
+| **Line 3 OT**              | Purchasable lever, 0–5 days/week                                                                                                                                              | Q1                   |
+| **Meridian-priority QA**   | Non-FIFO lab queue                                                                                                                                                            | Free OTIF experiment |
+
+**Note on the split-shift arm:** with one tech per shift, no ≥120-min wash can ever run (they need two). I expect that arm to fail badly. Run it anyway — showing your ops director _why_ a cheap option fails is worth more than asserting it, and it demonstrates you looked at rota changes before asking for headcount.
+
+---
+
+# 6. KPIs
+
+## 6.1 Service (primary)
+
+| Metric                  | Definition                                         |
+| ----------------------- | -------------------------------------------------- |
+| **Meridian late count** | Any lot shipped after `dueTime`. Target zero (C13) |
+| Distributor late        | Shipped > 48 h after due                           |
+| Small-account late      | Shipped > 168 h after due                          |
+| Meridian lateness hours | Total, for severity                                |
+
+## 6.2 Changeover — reported as three separate numbers
+
+**Do not merge these.** A single "dirty hours" figure will be attacked as inflated the first time someone notices it counts unscheduled hours.
+
+| Metric                    | Definition                                                       | Framing                            |
+| ------------------------- | ---------------------------------------------------------------- | ---------------------------------- |
+| Clock-dirty hours         | Wall-clock from changeover raised to complete                    | Report, label **not a loss**       |
+| Wash hours                | Actual cleaning time                                             | Largely unavoidable                |
+| **Lost production hours** | Dirty time that overlapped **scheduled line hours**              | **The number to argue with**       |
+| — split by cause          | `techs_off_shift` vs `techs_busy_elsewhere`                      | Different fixes: rota vs headcount |
+| **Family-lock hours**     | Per line per day, time during which no family switch is possible | Explains _why_ the losses occurred |
+| Family switches per week  | Plant-wide count                                                 | Validation target                  |
+
+_Worked example — wash raised 14:30 on Line 2, executed 06:00–09:00:_
+clock-dirty 18.5 h · wash 3 h · **lost production 7.5 h** (cause: techs off shift).
+
+## 6.3 Secondary
+
+Ramp scrap units (by changeover type) · per-line utilisation · **tank-blocked hours** (Flag 2) · tech utilisation % of the 16 tech-hours/day · QA queue length, Fri/Mon split.
+
+---
+
+# 7. How to use it
+
+## 7.1 Run this first — the reproduction check
+
+Before any experiment, before anything goes to your ops director:
+
+| Check                      | Target                      | If it misses                       |
+| -------------------------- | --------------------------- | ---------------------------------- |
+| Weekly output per line     | Within ±10% of ERP actuals  | Rate matrix or tank capacity wrong |
+| Family switches/week       | Your estimate: ~8           | Changeover matrix or policy wrong  |
+| Late-order pattern by tier | Matches history             | Priority logic wrong               |
+| Line 3 idle mornings       | Should appear spontaneously | Tech contention modelled wrong     |
+
+**If it misses, that is the finding.** The gap points at a register row and we fix the model before it says anything about Tuesdays.
+
+## 7.2 Then, in order
+
+1. **Q3 — where do changeover hours go.** Baseline only. Decompose lost production hours by cause and by line. Cheapest result, no new policy needed.
+2. **Q2 — the wait-vs-wash question.** Sweep `W(t)`. Expected output shape: _"before 09:00 wait up to N hours; 09:00–11:00 never wait; after 11:00 wait as long as you like."_
+3. **Q1 — the breakdown reflex.** Inject Line 2 failure at 06:00 Tue, Line 1 mill motor at 06:00 Mon (4 days). Race reflexes A/B/C over 30 reps. Output is a rule, not a schedule.
+4. **Rota and headcount.** Only after the tick sheet lands.
+
+## 7.3 The Line 1 tank inversion — after the stopwatch, not before
+
+Fix Line 1's fill rate to the measured value. Sweep K₁ downward. Find the largest K₁ that reproduces observed blocking.
+
+- If that K₁ is **below** the spec-sheet volume → the tank is not the constraint; the rate is.
+- If it is **at or above** → your instinct holds.
+
+Without the measured rate, both parameters are free and the inversion identifies neither. It will still produce a confident-looking answer. Do not use it.
+
+---
+
+# 8. Parameter file
+
+Everything below is data, not structure. Hand this to whoever fills it in; the net does not change.
+
+```csv
+# === lines.csv ===
+line_id,open_time,close_time,ot_available,mtbf_hours,repair_min,repair_mode,repair_max,tank_capacity_K
+1,06:00,22:00,no,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,K1_PLACEHOLDER
+2,06:00,22:00,no,240,30,90,240,K2_PLACEHOLDER
+3,06:00,14:00,yes_signoff,99999,0,0,0,K3_PLACEHOLDER
+
+# === skus.csv ===
+sku_id,family,shade,qual_L1,qual_L2,qual_L3
+VW-01,WHITE,0,1,1,1
+VW-02,WHITE,0,1,1,1          # C12 guard applies
+T-01..T-09,TINT,1..5,1,1,mostly-1   # two deep reds = 0 on L3 (A16)
+S-01..S-03,SPECIALTY,X,1,0,0        # C11: L1 only in practice
+
+# === rates.csv ===   units/hr, PLACEHOLDER = A14
+sku_id,rate_L1,rate_L2,rate_L3
+
+# === changeover.csv ===
+from_family,from_shade,to_family,to_shade,minutes,resource,techs
+WHITE,*,WHITE,*,25,OPERATOR,0
+WHITE,*,TINT,*,45,TECH,1
+WHITE,*,SPECIALTY,*,120,TECH,2
+TINT,*,WHITE,*,180,TECH,2
+TINT,1-2,TINT,*,25,OPERATOR,0
+TINT,3-5,TINT,3-5,25,OPERATOR,0
+TINT,3-5,TINT,1-2,60,UNKNOWN,?     # A2 — sweep 25..180, both resource classes
+TINT,*,SPECIALTY,*,120,TECH,2
+SPECIALTY,*,*,*,120,TECH,2
+SPECIALTY,*,SPECIALTY,*,25,OPERATOR,0
+
+# === ramp_scrap.csv ===   A5 — swept, not asserted
+changeover_type,scrap_units
+same_family,0
+white_to_tint,SWEEP_0_200
+specialty_switch,SWEEP_0_200
+tint_to_white,SWEEP_0_400
+
+# === resources.csv ===
+resource,count,open,close
+tech,2,06:00,14:00
+lab,2,PLACEHOLDER,PLACEHOLDER      # A10
+
+# === tiers.csv ===
+tier,tolerance_hours
+MERIDIAN,0
+DISTRIBUTOR,48
+SMALL,168
+```
+
+---
+
+# 9. PNML
+
+**Dialect note.** Your tooling question never came back, so this is built to load anywhere: the graph structure is plain P/T-net so any PNML reader will open it, and all colour, guard, timing and resource information is carried in `<toolspecific>` blocks and inscriptions. If your tool is coloured + timed, map the annotations onto the colour sets in §2 — that is a mechanical translation, roughly an hour's work. If it is plain P/T, the net runs as-is with `SHADE` folded out; you lose the `D` question and the VW-02 guard has to become a separate forbidden-pair place per SKU.
+
+**Coverage.** Shared resources, the calendar subnet, and **Line 1 in full**. Lines 2 and 3 are structurally identical: duplicate the `_L1` block, change the id suffix, and substitute from `lines.csv`. I've done it this way so the file stays readable — a 3× copy is ten minutes of work and impossible to get wrong, whereas a 900-line file nobody reads is a different kind of risk.
+
+````xml
+<?xml version="1.0" encoding="UTF-8"?>
+<pnml xmlns="http://www.pnml.org/version-2009/grammar/pnml">
+  <net id="coatings_sched_v1"
+       type="http://www.pnml.org/version-2009/grammar/ptnet">
+    <name><text>Coatings Plant Scheduling Model v1.0</text></name>
+    <toolspecific tool="spec" version="1.0">
+      <timeUnit>minutes</timeUnit>
+      <runLength>60480</runLength>
+      <warmup>10080</warmup>
+      <replications>30</replications>
+      <note>Colour sets, guards and policy layer defined in accompanying
+            spec sections 2-5. Parameter values in parameter file section 8.
+            UNVALIDATED assumptions listed on page one.</note>
+    </toolspecific>
+    <page id="top">
+
+      <!-- ============ CALENDAR SUBNET ============ -->
+      <place id="P_Clock">
+        <name><text>Calendar cycle</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <graphics><position x="40" y="40"/></graphics>
+      </place>
+      <place id="P_TechShiftOpen">
+        <name><text>Tech shift open 06:00-14:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="200" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L1">
+        <name><text>Line 1 open 06:00-22:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="360" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L2">
+        <name><text>Line 2 open 06:00-22:00</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="520" y="40"/></graphics>
+      </place>
+      <place id="P_LineOpen_L3">
+        <name><text>Line 3 open 06:00-14:00 (OT lever)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="680" y="40"/></graphics>
+      </place>
+      <place id="P_LabOpen">
+        <name><text>Lab open (A10 UNVALIDATED)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="840" y="40"/></graphics>
+      </place>
+
+      <transition id="T_ShiftStart">
+        <name><text>06:00 daily open</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 06:00, weekdays</schedule>
+          <effect>mark P_TechShiftOpen, P_LineOpen_L1/2/3, P_LabOpen;
+                  move 2 tokens P_TechsOff -> P_Techs</effect>
+        </toolspecific>
+        <graphics><position x="120" y="120"/></graphics>
+      </transition>
+      <transition id="T_TechShiftEnd">
+        <name><text>14:00 tech shift end</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 14:00</schedule>
+          <effect>unmark P_TechShiftOpen; free techs -> P_TechsOff</effect>
+        </toolspecific>
+        <graphics><position x="280" y="120"/></graphics>
+      </transition>
+      <transition id="T_Line3Close">
+        <name><text>14:00 Line 3 close</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 14:00 unless OT lever set</schedule>
+        </toolspecific>
+        <graphics><position x="440" y="120"/></graphics>
+      </transition>
+      <transition id="T_Line12Close">
+        <name><text>22:00 Lines 1-2 close</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>daily 22:00</schedule>
+        </toolspecific>
+        <graphics><position x="600" y="120"/></graphics>
+      </transition>
+
+      <arc id="a01" source="P_Clock" target="T_ShiftStart"/>
+      <arc id="a02" source="T_ShiftStart" target="P_TechShiftOpen"/>
+      <arc id="a03" source="T_ShiftStart" target="P_LineOpen_L1"/>
+      <arc id="a04" source="T_ShiftStart" target="P_LineOpen_L2"/>
+      <arc id="a05" source="T_ShiftStart" target="P_LineOpen_L3"/>
+      <arc id="a06" source="T_ShiftStart" target="P_LabOpen"/>
+      <arc id="a07" source="P_TechShiftOpen" target="T_TechShiftEnd"/>
+      <arc id="a08" source="P_LineOpen_L3" target="T_Line3Close"/>
+      <arc id="a09" source="P_LineOpen_L1" target="T_Line12Close"/>
+      <arc id="a10" source="P_LineOpen_L2" target="T_Line12Close"/>
+      <arc id="a11" source="T_Line12Close" target="P_Clock"/>
+
+      <!-- ============ SHARED RESOURCES ============ -->
+      <place id="P_Techs">
+        <name><text>Techs on shift and free</text></name>
+        <initialMarking><text>2</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <lever>count = 2 (baseline) | 3 (third-tech arm)</lever>
+        </toolspecific>
+        <graphics><position x="200" y="220"/></graphics>
+      </place>
+      <place id="P_TechsOff">
+        <name><text>Techs off shift</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="200" y="300"/></graphics>
+      </place>
+      <place id="P_Lab">
+        <name><text>Lab capacity</text></name>
+        <initialMarking><text>2</text></initialMarking>
+        <graphics><position x="840" y="220"/></graphics>
+      </place>
+      <place id="P_Demand">
+        <name><text>Order arrivals (ERP stream)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <colour>ORDER = id,sku,qty,tier,dueTime</colour>
+          <source>ERP export, 4-6 weeks. A17 until loaded.</source>
+        </toolspecific>
+        <graphics><position x="40" y="380"/></graphics>
+      </place>
+      <place id="P_Ready">
+        <name><text>Released, awaiting assignment</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="180" y="380"/></graphics>
+      </place>
+
+      <transition id="T_Release">
+        <name><text>Release order</text></name>
+        <graphics><position x="110" y="380"/></graphics>
+      </transition>
+      <arc id="a12" source="P_Demand" target="T_Release"/>
+      <arc id="a13" source="T_Release" target="P_Ready"/>
+
+      <!-- ============ LINE 1 SUBNET ============ -->
+      <!-- duplicate this block for L2, L3; substitute ids and parameters -->
+
+      <place id="P_UpIdle_L1">
+        <name><text>L1 upstream idle (mix/mill/tint)</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <graphics><position x="300" y="460"/></graphics>
+      </place>
+      <place id="P_UpBusy_L1">
+        <name><text>L1 upstream in progress</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="380" y="460"/></graphics>
+      </place>
+      <place id="P_Tank_L1">
+        <name><text>L1 holding tank (DISPUTED CAPACITY - A15)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <capacity>K1 = PLACEHOLDER</capacity>
+          <note>Flag 2. Do not run the inversion before Line 1 fill rate
+                is measured with a non-empty tank.</note>
+        </toolspecific>
+        <graphics><position x="460" y="460"/></graphics>
+      </place>
+      <place id="P_TankFree_L1">
+        <name><text>L1 tank free slots</text></name>
+        <initialMarking><text>K1</text></initialMarking>
+        <graphics><position x="460" y="540"/></graphics>
+      </place>
+      <place id="P_LineIdle_L1">
+        <name><text>L1 idle, carrying lastSKU/lastFamily/lastShade</text></name>
+        <initialMarking><text>1</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <colour>LINESTATE = lineId,lastSKU,lastFamily,lastShade,up</colour>
+        </toolspecific>
+        <graphics><position x="560" y="460"/></graphics>
+      </place>
+      <place id="P_LineFilling_L1">
+        <name><text>L1 filling</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="660" y="460"/></graphics>
+      </place>
+      <place id="P_ChangeoverDue_L1">
+        <name><text>L1 changeover raised, not started</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="560" y="620"/></graphics>
+      </place>
+      <place id="P_Rinsing_L1">
+        <name><text>L1 rinsing (operator, no tech)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="480" y="700"/></graphics>
+      </place>
+      <place id="P_Washing_L1">
+        <name><text>L1 washing (tech, QA signoff)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="640" y="700"/></graphics>
+      </place>
+      <place id="P_Down_L1">
+        <name><text>L1 down</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="760" y="540"/></graphics>
+      </place>
+
+      <transition id="T_Assign_L1">
+        <name><text>Assign order to L1</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>POLICY LAYER - spec section 5.
+                 Baseline: Meridian white -> L2 only; specialty -> L1;
+                 else prefer matching lastFamily; sort TIER then dueTime.</guard>
+        </toolspecific>
+        <graphics><position x="240" y="380"/></graphics>
+      </transition>
+      <transition id="T_UpStart_L1">
+        <name><text>L1 start upstream</text></name>
+        <graphics><position x="340" y="460"/></graphics>
+      </transition>
+      <transition id="T_UpEnd_L1">
+        <name><text>L1 end upstream</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>upstream_time[family]; specialty slowest (thick, slow mill)</delay>
+        </toolspecific>
+        <graphics><position x="420" y="460"/></graphics>
+      </transition>
+      <transition id="T_StartFill_L1">
+        <name><text>L1 start fill</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>P_LineOpen_L1 marked AND NOT P_Down_L1 AND batch in tank
+                 AND no changeover outstanding AND sku qualified on L1
+                 (specialty: L1 only - C11)</guard>
+        </toolspecific>
+        <graphics><position x="610" y="460"/></graphics>
+      </transition>
+      <transition id="T_EndFill_L1">
+        <name><text>L1 end fill</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>qty / rate[sku][L1]  (A14 placeholder)</delay>
+          <effect>emit LOT to P_QAQueue, less ramp_scrap if run followed
+                  a family switch (A5, swept)</effect>
+        </toolspecific>
+        <graphics><position x="720" y="460"/></graphics>
+      </transition>
+      <transition id="T_RaiseChangeover_L1">
+        <name><text>L1 raise changeover</text
+```xml
+      <transition id="T_RaiseChangeover_L1">
+        <name><text>L1 raise changeover</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>next job prep != line current prep</guard>
+          <delay>DEFERRED by wait-rule W(t) - spec 5.2.
+                 Morning only; after 13:15 the choice does not exist.</delay>
+        </toolspecific>
+        <graphics><position x="560" y="540"/></graphics>
+      </transition>
+      <transition id="T_StartRinse_L1">
+        <name><text>L1 start rinse (operator)</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>class(from,to) = OPERATOR AND P_LineOpen_L1 marked</guard>
+          <note>C5 - no tech token consumed. Available to 22:00.</note>
+        </toolspecific>
+        <graphics><position x="480" y="620"/></graphics>
+      </transition>
+      <transition id="T_EndRinse_L1">
+        <name><text>L1 end rinse</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>25</delay>
+        </toolspecific>
+        <graphics><position x="400" y="700"/></graphics>
+      </transition>
+      <transition id="T_StartWash_L1">
+        <name><text>L1 start wash (tech)</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>class(from,to) = TECH
+                 AND P_TechShiftOpen marked
+                 AND P_Techs >= n(from,to)
+                 AND now + dur(from,to) &lt;= 14:00 + grace(15)   [C8]
+                 AND NOT (to_sku = VW-02 AND from_shade &gt;= 4)   [C12]</guard>
+          <consumes>n(from,to) tokens from P_Techs</consumes>
+        </toolspecific>
+        <graphics><position x="640" y="620"/></graphics>
+      </transition>
+      <transition id="T_EndWash_L1">
+        <name><text>L1 end wash</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>dur(from,to) per changeover matrix, spec 4.3</delay>
+          <effect>release n techs to P_Techs; set lastFamily/lastShade := to</effect>
+        </toolspecific>
+        <graphics><position x="720" y="700"/></graphics>
+      </transition>
+      <transition id="T_Fail_L1">
+        <name><text>L1 fail</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>Exp(MTBF_L1) - A6 PLACEHOLDER</delay>
+          <note>A7: mill motor 4-day outage is a SCENARIO INJECTION,
+                not sampled. Too rare for a 6-week run.</note>
+        </toolspecific>
+        <graphics><position x="800" y="460"/></graphics>
+      </transition>
+      <transition id="T_Repair_L1">
+        <name><text>L1 repair</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>Tri(min,mode,max) - A6</delay>
+          <effect>fill resumes from interruption point</effect>
+        </toolspecific>
+        <graphics><position x="800" y="620"/></graphics>
+      </transition>
+      <transition id="T_Interrupt_L1">
+        <name><text>L1 shift-end interrupt</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <schedule>fires at line close if fill incomplete</schedule>
+          <note>ASSUMPTION: fills are interruptible at shift end and resume
+                next open. Never confirmed - flag if wrong.</note>
+        </toolspecific>
+        <graphics><position x="720" y="380"/></graphics>
+      </transition>
+
+      <arc id="b01" source="P_Ready" target="T_Assign_L1"/>
+      <arc id="b02" source="T_Assign_L1" target="P_UpIdle_L1"/>
+      <arc id="b03" source="P_UpIdle_L1" target="T_UpStart_L1"/>
+      <arc id="b04" source="P_TankFree_L1" target="T_UpStart_L1"/>
+      <arc id="b05" source="T_UpStart_L1" target="P_UpBusy_L1"/>
+      <arc id="b06" source="P_UpBusy_L1" target="T_UpEnd_L1"/>
+      <arc id="b07" source="T_UpEnd_L1" target="P_Tank_L1"/>
+      <arc id="b08" source="T_UpEnd_L1" target="P_UpIdle_L1"/>
+      <arc id="b09" source="P_Tank_L1" target="T_StartFill_L1"/>
+      <arc id="b10" source="P_LineIdle_L1" target="T_StartFill_L1"/>
+      <arc id="b11" source="P_LineOpen_L1" target="T_StartFill_L1">
+        <inscription><text>test arc - not consumed</text></inscription>
+      </arc>
+      <arc id="b12" source="T_StartFill_L1" target="P_LineFilling_L1"/>
+      <arc id="b13" source="T_StartFill_L1" target="P_TankFree_L1"/>
+      <arc id="b14" source="P_LineFilling_L1" target="T_EndFill_L1"/>
+      <arc id="b15" source="T_EndFill_L1" target="P_LineIdle_L1"/>
+      <arc id="b16" source="T_EndFill_L1" target="P_QAQueue"/>
+      <arc id="b17" source="P_LineIdle_L1" target="T_RaiseChangeover_L1"/>
+      <arc id="b18" source="T_RaiseChangeover_L1" target="P_ChangeoverDue_L1"/>
+      <arc id="b19" source="P_ChangeoverDue_L1" target="T_StartRinse_L1"/>
+      <arc id="b20" source="T_StartRinse_L1" target="P_Rinsing_L1"/>
+      <arc id="b21" source="P_Rinsing_L1" target="T_EndRinse_L1"/>
+      <arc id="b22" source="T_EndRinse_L1" target="P_LineIdle_L1"/>
+      <arc id="b23" source="P_ChangeoverDue_L1" target="T_StartWash_L1"/>
+      <arc id="b24" source="P_Techs" target="T_StartWash_L1">
+        <inscription><text>n(from,to)  [1 or 2]</text></inscription>
+      </arc>
+      <arc id="b25" source="P_TechShiftOpen" target="T_StartWash_L1">
+        <inscription><text>test arc - not consumed</text></inscription>
+      </arc>
+      <arc id="b26" source="T_StartWash_L1" target="P_Washing_L1"/>
+      <arc id="b27" source="P_Washing_L1" target="T_EndWash_L1"/>
+      <arc id="b28" source="T_EndWash_L1" target="P_LineIdle_L1"/>
+      <arc id="b29" source="T_EndWash_L1" target="P_Techs">
+        <inscription><text>n(from,to)</text></inscription>
+      </arc>
+      <arc id="b30" source="P_LineFilling_L1" target="T_Fail_L1"/>
+      <arc id="b31" source="T_Fail_L1" target="P_Down_L1"/>
+      <arc id="b32" source="P_Down_L1" target="T_Repair_L1"/>
+      <arc id="b33" source="T_Repair_L1" target="P_LineFilling_L1"/>
+      <arc id="b34" source="P_LineFilling_L1" target="T_Interrupt_L1"/>
+      <arc id="b35" source="T_Interrupt_L1" target="P_LineFilling_L1">
+        <inscription><text>paused; resumes at next line open</text></inscription>
+      </arc>
+
+      <!-- ============ QA AND SHIPPING ============ -->
+      <place id="P_QAQueue">
+        <name><text>Awaiting QA (post-fill hold)</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <toolspecific tool="spec" version="1.0">
+          <note>C9 - delays shipment only, does not block upstream.
+                Watch Fri/Mon queue length: your Friday slip mechanism.</note>
+        </toolspecific>
+        <graphics><position x="900" y="380"/></graphics>
+      </place>
+      <place id="P_InQA">
+        <name><text>In QA</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="900" y="460"/></graphics>
+      </place>
+      <place id="P_Shipped">
+        <name><text>Shipped</text></name>
+        <initialMarking><text>0</text></initialMarking>
+        <graphics><position x="900" y="620"/></graphics>
+      </place>
+
+      <transition id="T_QAStart">
+        <name><text>Start QA</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <guard>P_Lab >= 1 AND P_LabOpen marked</guard>
+          <policy>BASELINE FIFO (A10). Variant: Meridian-priority queue.</policy>
+        </toolspecific>
+        <graphics><position x="900" y="420"/></graphics>
+      </transition>
+      <transition id="T_QAEnd">
+        <name><text>End QA</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <delay>240 min; 1440 min if family = SPECIALTY</delay>
+        </toolspecific>
+        <graphics><position x="900" y="500"/></graphics>
+      </transition>
+      <transition id="T_Ship">
+        <name><text>Ship and record lateness</text></name>
+        <toolspecific tool="spec" version="1.0">
+          <effect>lateness = max(0, now - dueTime); bucket by TIER;
+                  MERIDIAN tolerance 0, DISTRIBUTOR 2880, SMALL 10080 min</effect>
+        </toolspecific>
+        <graphics><position x="900" y="570"/></graphics>
+      </transition>
+
+      <arc id="c01" source="P_QAQueue" target="T_QAStart"/>
+      <arc id="c02" source="P_Lab" target="T_QAStart"/>
+      <arc id="c03" source="T_QAStart" target="P_InQA"/>
+      <arc id="c04" source="P_InQA" target="T_QAEnd"/>
+      <arc id="c05" source="T_QAEnd" target="P_Lab"/>
+      <arc id="c06" source="T_QAEnd" target="P_Shipped"/>
+      <arc id="c07" source="P_Shipped" target="T_Ship"/>
+
+    </page>
+  </net>
+</pnml>
+````
+
+---
+
+# 10. Building Lines 2 and 3
+
+Copy the Line 1 block; change the `_L1` suffix throughout; substitute from `lines.csv`. The only structural differences:
+
+|                  | Line 2                                   | Line 3                                                |
+| ---------------- | ---------------------------------------- | ----------------------------------------------------- |
+| Calendar place   | `P_LineOpen_L2`, 06:00–22:00             | `P_LineOpen_L3`, 06:00–**14:00**                      |
+| Qualification    | Specialty SKUs excluded (C11)            | Specialty excluded; two deep-red tints excluded (A16) |
+| Assignment guard | **Meridian whites forced here** (C10)    | No forced work                                        |
+| Failure          | MTBF ≈ 240 h, repair Tri(30,90,240) (A6) | Zero (A8)                                             |
+| OT lever         | none                                     | `T_Line3Close` deferred to 22:00 when set             |
+
+**One consequence worth checking against the model's own output:** Line 3's entire operating day sits inside the tech window. Its changeovers compete head-on with the morning wash queue for Lines 1 and 2. A tint→white wash starting 06:00 on Line 2 holds both techs to 09:00, during which Line 3 cannot cross families — three of its eight hours, clean and staffed and waiting. If that pattern doesn't emerge spontaneously in the reproduction check, the tech contention is modelled wrong.
+
+---
+
+# 11. What happens next
+
+**Blocking, from you:** spreadsheet, rate matrix, ERP export. Nothing runs until the rate matrix lands — `A14` placeholders make every duration in the model fictional.
+
+**Then, in order:** reproduction check (§7.1) → Q3 decomposition → Q2 sweep → Q1 reflexes. Rota and headcount arms only after the tick sheet.
+
+**Send early, don't batch:** any tick-sheet row showing an operator performing a family switch. That retires A19, changes a hard guard, and I'd rather rework in week one than build a fortnight on it.
+
+**Still unanswered:** the PNML dialect, A10 (lab hours and queue discipline — I never asked and it drives your Friday slips), A15 (tank capacities), whether fills are interruptible at shift end (§4.2), and A16 (which two tints Line 3 can't run).
+
+---
+
+# 12. Two lines that don't depend on any of this
+
+Both fall out of your own shift pattern — C3, C4, C6, C8 — not from anything I've modelled. They were true before this document existed and stay true whatever the data says:
+
+> **After 13:15, no line can cross families. The morning decides the day.**
+
+> **A wash raised at 22:00 costs nothing. One raised at 14:30 costs the evening.**
+
+Everything else in here — the switches-per-week ceiling, the capacity-versus-timing hypothesis, Line 3's idle mornings, and every number in §8 — is arithmetic on recollection. Hold it back until the sheet earns it.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.raw.json b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.raw.json
new file mode 100644
index 00000000000..30699cf65f7
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-1.raw.json
@@ -0,0 +1,1445 @@
+{
+  "startedAt": "2026-08-13T10:22:15.639Z",
+  "condition": "1",
+  "stopReason": "delivered-after-forced-wrap",
+  "interviewerTurns": 21,
+  "calls": [
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 134,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 3808,
+        "output_tokens_details": {
+          "thinking_tokens": 1767
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 1608,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 5482,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1500,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 3677,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4063,
+        "output_tokens_details": {
+          "thinking_tokens": 2054
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 1595,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 8993,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1365,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 7051,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 10377,
+        "output_tokens_details": {
+          "thinking_tokens": 7019
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 2673,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 13716,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 720,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 11129,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 9121,
+        "output_tokens_details": {
+          "thinking_tokens": 6549
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 2077,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 17008,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 855,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 14556,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 6508,
+        "output_tokens_details": {
+          "thinking_tokens": 4299
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 1755,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 20072,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 515,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 17280,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1446,
+        "output_tokens_details": {
+          "thinking_tokens": 685
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 655,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 21348,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 272,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 18313,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 379,
+        "output_tokens_details": {
+          "thinking_tokens": 124
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 266,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 21875,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 127,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 18695,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 209,
+        "output_tokens_details": {
+          "thinking_tokens": 45
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 207,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22166,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 58,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 18955,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 319,
+        "output_tokens_details": {
+          "thinking_tokens": 125
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 221,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22456,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 12,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19161,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 35,
+        "output_tokens_details": {
+          "thinking_tokens": 29
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 87,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22474,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 11,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19178,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 211,
+        "output_tokens_details": {
+          "thinking_tokens": 188
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 99,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22508,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 12,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19213,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 19,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 96,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22539,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 25,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19257,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19257,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 59,
+        "output_tokens_details": {
+          "thinking_tokens": 52
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 88,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22571,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 7,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19271,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 135,
+        "output_tokens_details": {
+          "thinking_tokens": 131
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 86,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22582,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19279,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 171,
+        "output_tokens_details": {
+          "thinking_tokens": 168
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 85,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22589,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 15,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19297,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19297,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19297,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 147,
+        "output_tokens_details": {
+          "thinking_tokens": 121
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 100,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22630,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 21,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19344,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 12,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 89,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22663,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 7,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19363,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19363,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19363,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19363,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 18,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 95,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22688,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 11,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19392,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 86,
+        "output_tokens_details": {
+          "thinking_tokens": 72
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 94,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22713,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 6,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19412,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19412,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19412,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 50,
+        "output_tokens_details": {
+          "thinking_tokens": 46
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 86,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19440,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16000,
+        "output_tokens_details": {
+          "thinking_tokens": 3161
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 10209,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 32316,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4844,
+        "output_tokens_details": {
+          "thinking_tokens": 89
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    }
+  ],
+  "interviewerMessages": [
+    {
+      "role": "user",
+      "content": "I'm the master scheduler at a coatings plant. My boss wants a simulation model of how we\nschedule production, so we can test scheduling decisions before making them. We have tooling\nthat runs Petri-net-style process models, so the end product should be a model I can hand to\nthat — but I can't tell you much about the format, I'm not the modelling person.\n\nPlease interview me about how our operation works, and then produce the model."
+    },
+    {
+      "role": "assistant",
+      "content": "Happy to do this. Before the questions, two framing notes:\n\n**What I need most.** The single biggest driver of how I build this is *which decisions you want to test*. \"Should I run whites before blacks all week?\" needs a very different model from \"should I buy a fourth filling line?\" So question 1 below matters more than all the rest.\n\n**On the format.** I can't guess your tooling's dialect, so I'll deliver two things: a plain-language spec (places, transitions, arcs, timings, decision rules) that any Petri-net person can implement in an afternoon, plus a PNML file, which is the closest thing to a standard interchange format. If you can get one answer out of your modelling person, make it this: *does the tool support timed transitions and coloured/typed tokens, or is it plain place/transition nets?* Coatings scheduling is all about \"this batch is dark red and needs a 90-minute wash before the next white\" — that's much cleaner with coloured tokens, and much clumsier without. I can do either.\n\nNow the interview. **Answer what you can and skip the rest — rough guesses are fine, and \"I don't know\" is a useful answer.** I've put my default assumption in brackets where I have one, so you can often just say \"yep.\"\n\n---\n\n## 1. What are you trying to learn from it?\n\n1. Give me two or three real questions you'd want to ask this model. The more specific the better — e.g. \"if I hold the small filling line for urgent orders only, do I miss fewer due dates?\"\n2. Is there a known bottleneck or sore spot? I'll model that part in detail and abstract the rest, rather than modelling everything at uniform detail.\n3. Who else will look at the output — just you, or your boss and planners too?\n\n## 2. The process route\n\n4. What are you making, broadly? [Assuming liquid coatings — solvent-borne and/or water-borne, batch production.]\n5. Walk me through the steps a batch goes through. My straw man: raw material weigh/dispense → premix → dispersion or milling → let-down/thin-down → QC sample and adjust → filter → fill and pack → warehouse. Correct, add, delete.\n6. Do all products follow the same route, or are there variants — e.g. some skip milling, some need multiple mill passes?\n7. Roughly how many distinct products/SKUs, and how many meaningfully different *routes*? (I don't need the SKU list, just the shape of it.)\n\n## 3. Equipment\n\n8. How many of each vessel/machine — mixers, mills, filling lines? Approximate is fine.\n9. Are they interchangeable, or restricted? Typical restrictions: only certain tanks for water-borne, only the big mixer for volumes over X, whites kept off vessels that have run dark shades.\n10. **Important:** when a batch finishes mixing but the filling line is busy, where does it sit? Does it stay in the mixer (blocking it) or go to a holding/storage tank? If holding tanks, how many, and are they dedicated?\n11. Are people a constraint — operators per shift, one lab tech covering everything, a single cleaning crew? Or is labour effectively always available?\n\n## 4. Batches and time\n\n12. Is batch size fixed by the vessel, or do you flex it to the order? Do you ever combine several orders into one batch, or split one batch across several pack sizes / fill runs?\n13. Rough durations for each step, and what makes them vary (product, batch size, viscosity)?\n14. What time resolution do you care about — minutes, hours, or shifts? [Assuming hours.]\n15. Shift pattern, weekend working, and how planned maintenance fits in. Can a batch be left part-finished over a shift break, or must some steps run to completion once started?\n\n## 5. Changeovers — probably the crux\n\n16. What determines the cleaning needed between two batches in the same vessel? Colour sequence, resin chemistry, both? I'm expecting something like a light-to-dark rule with a full solvent wash needed when you go backwards.\n17. Roughly what do the different cleaning levels cost you in time? (e.g. same colour = quick rinse 20 min; light after dark = full wash 3 hrs.)\n18. Do you deliberately run campaigns — batching up all the whites, then greys, then blacks — and if so over what cycle? Weekly? \n19. Does cleaning consume something scarce: a wash bay, a crew, solvent, waste capacity?\n\n## 6. QC and rework\n\n20. After let-down you sample and test. How long does the lab take, and does the batch hold the vessel while it waits?\n21. What fraction of batches pass first time? On a fail, what happens — tint adjust and retest (how many loops before you give up?), hold for review, downgrade to another SKU, scrap?\n22. Any other rework loops — regrinds, refiltering, refill after a fill-line fault?\n\n## 7. Demand and disruption\n\n23. Make-to-order, make-to-stock, or a mix? If stock, do you replenish to reorder points?\n24. How do orders arrive and how firm are they? Do you get urgent inserts that jump the queue, and how often?\n25. Raw materials: assume always available, or do shortages genuinely drive your schedule? Any long-lead or single-source items?\n26. Breakdowns: frequent enough to matter, or rare? Rough failure rate and repair time for the important machines if so.\n\n## 8. Scoring the schedule\n\n27. What makes a schedule good, in your judgement, in priority order? Candidates: due-date/OTIF performance, total changeover time or solvent used, throughput, vessel utilisation, WIP sitting in tanks, overtime.\n28. Are there hard rules I must never break, versus preferences? (e.g. \"a batch never sits more than 48 hrs before filling\" is often a hard one.)\n29. How do you actually sequence today — a spreadsheet, a rule of thumb, gut feel? I'd like the model to be able to reproduce your current approach as a baseline, so you can compare alternatives against it.\n\n---\n\nSend back whatever you've got. If you'd rather not answer all of it, give me sections 1, 3, 5 and 8 and I'll build a first cut with explicit assumptions marked, which is often a faster way to find out what I got wrong."
+    },
+    {
+      "role": "user",
+      "content": "Right, let's do this. I've got about forty minutes before the huddle, so I'll go fast.\n\n## 1. What I want to know\n\nThree real questions, in order of how much I actually lose sleep over them:\n\n1. When a line goes down at 6am, what's the best re-shuffle of the rest of the week — right now I improvise at the huddle and I know it's not great.\n2. Is it ever worth sitting a line idle for an hour or two waiting for a same-family order, instead of paying for the washdown now? I do this by gut and nobody can tell me if I'm right.\n3. Where do my changeover hours actually go, and would reordering the run sequence claw any back?\n\nSore spot: changeovers, no question. Tint→white washdowns are the expensive one, and the crew is shared across three lines, so it's not just the time, it's who's waiting on who. Model that in detail. The mixing/dispersion end I care about less.\n\nWho looks at it: me first, then probably my boss (ops director) if it says anything useful. Commercial might get pulled in if it touches due-date stuff, but that's a maybe.\n\n## 2 & 3. Process and equipment — quick corrections\n\nWe're coatings, yes — mix, mill, tint/letdown, then fill & pack. That's it, four stages, same order for everything. No separate QC-hold-and-adjust step in the way you described — QA sits at the *end*, after fill, not mid-process. I'll come back to that under section 6.\n\nThree filling lines, not identical — Line 1 old and slow but does everything including specialty, Line 2 fast and big-volume, Line 3 newest, still being qualified SKU by SKU. About 14 SKUs, three families: base whites, tinted colours, specialty clears. Routes are the same shape for everyone, just different speeds and fussiness — specialty is thick and slow, particularly up at the mill end.\n\nHolding tanks between stages, small ones. Line 1's mill-to-fill tank is the one that gives me grief — I think it's undersized and backs the line up, though engineering points at the line rate and says that's not it. One changeover crew, two techs, day shift, covers all three lines — that's a real constraint, if two lines want washing at once someone waits.\n\n## 5. Changeovers — since you want detail here\n\nSame-family rinse: quick, 20–30 minutes. Family switches are the real cost, and they're **not symmetric** — white to tint, maybe 45 minutes. Tint to white is a full wash, about 3 hours, because pigment carryover wrecks a white batch. Specialty in or out, either direction, roughly 2 hours.\n\nWe don't run strict weekly campaigns, but I do try to cluster — I'll hold a family together on a line rather than ping-ponging, purely to dodge the 3-hour wash. Cleaning eats the shared crew, that's the scarce resource, not solvent or bay space as far as I know.\n\n## 6. Quality — correction to your model\n\nNo mid-process sample-adjust-retest loop. What happens is: batch finishes fill & pack, then sits in QA hold — about four hours typically, specialty can be a day. Lab's two people, backs up end of week. I don't have first-pass-yield numbers off the top of my head; I don't think we track it that granularly, quality just reports scrap as a monthly percentage across the board.\n\nOne thing I will flag: after any family switch the first units off the line are junk — \"ramp scrap\" — worse after the big washdowns. I can't give you exact quantities per changeover type though, that's not something I've got broken out.\n\n## 8. Scoring and how I do it today\n\nPriority order, honestly: don't ship late to Meridian, ever — that's our biggest account, mostly whites, and they fine and delist. Other big distributors can slip a couple of days if we phone ahead. Small accounts can slide a week and nobody notices. After that, changeover hours, then general utilization.\n\nNo hard rule I can quote you on tank dwell time or anything like that — the closest thing is Meridian white orders *always* go on Line 2, that's just how it's done, has been for years. Specialty only runs on Lines 1 and 3, Line 2 was never set up for the clear resins.\n\nToday I sequence off a spreadsheet — I map the week's demand book onto the three lines, rough rate per product per line, add changeover by feel, and I re-juggle it out loud at the 07:30 huddle most mornings. That sheet is the baseline you should try to reproduce first, honestly — if your model can't match what the sheet does, I won't trust what it says about doing better.\n\nSend me the questions you're still stu"
+    },
+    {
+      "role": "assistant",
+      "content": "Your message cut off at \"still stu—\", so I may be missing a line. Here's what I've got.\n\nThree flags first, then the questions. The flags matter more than the questions.\n\n---\n\n## Flag 1: your Q1 isn't a simulation question, quite\n\n\"What's the best re-shuffle when a line goes down at 6am\" is an *optimisation* question. A Petri-net model simulates a policy you give it — it won't hand you the optimum reshuffle.\n\nWhat it *will* do: let you set up the Tuesday-morning-Line-2-is-dead scenario and race three or four candidate responses against each other (push everything to Line 1 / hold the tint block and pull whites forward / split across 1 and 3 and eat the specialty changeover). You get lateness and changeover hours for each. Over enough simulated breakdowns you can find which *rule* wins on average, and that's the thing you'd actually take to the huddle — not a schedule, a reflex.\n\nIf you want true \"give me the optimal reshuffle,\" that's a different tool and a bigger build. Tell me if that's the real requirement, because it changes what I hand you.\n\n## Flag 2: I can't settle the Line 1 tank argument, and neither can the model\n\nYou think the mill-to-fill tank is undersized; engineering says it's the line rate. Whatever I assume about tank capacity and line rate, the model will faithfully reproduce that assumption and appear to prove one of you right. That's not evidence, it's just my guess with a simulation wrapper on it.\n\nTwo ways to make it real:\n\n- **Measure it.** If tank capacity and Line 1's actual rate come from data, the model arbitrates honestly.\n- **Invert it.** Don't ask \"which is it,\" ask \"how small would the tank have to be to cause the backup we see?\" If the answer is \"smaller than it actually is,\" it's the line rate. This is often the faster route and needs no new instrumentation — just a decent estimate of tank volume and observed blocking.\n\nEither way: **do not let this model into a room with engineering as an argument-winner** until the inputs are measured. It'll get shredded, deservedly, and take the rest of the model down with it.\n\n## Flag 3: the numbers you don't have\n\nYou flagged three: first-pass yield, ramp scrap per changeover type, and quality only reporting monthly scrap in aggregate.\n\nI'm not going to fill those with plausible-looking invented figures — you'd have no way to tell them from real ones six weeks from now. Instead I'll build them as exposed parameters and run them as **threshold questions**:\n\n> \"Waiting two hours for a same-family order beats washing now — as long as ramp scrap after a tint→white wash is above about 40 units. Below that, wash immediately.\"\n\nThen you only need to know which side of 40 you're on, which someone on the floor probably can eyeball, rather than needing a precise number. Same trick for first-pass yield. Every one of these gets logged in an assumptions register at the front of the deliverable, flagged UNVALIDATED, so when your ops director asks \"where did that come from,\" the answer is on page one.\n\n---\n\n## What I actually need\n\n**Blockers — I can't build a credible first cut without these:**\n\n1. **The spreadsheet.** Send it as-is, mess and all. Rates, changeover allowances and your sequencing instincts are all in there, and it saves you answering half of what follows.\n2. **Rate matrix** — units/hr for each SKU on each line, plus which SKUs Line 3 is actually qualified for today. Rough is fine. This is the single biggest driver of everything.\n3. **A real demand book** — 4–6 weeks of orders with quantities, due dates and customer, so I can validate against something. Meridian's share of volume specifically.\n4. **Shift pattern**, and the crew rule: your two techs are day shift only. So if a wash is needed at 9pm — does the line sit dead until morning, does someone else do a rough job, or does it never happen because you sequence to avoid it? **This is probably the highest-leverage single fact in the whole model** and it's the one I'd most want before building.\n5. **Breakdowns** — how often, how long, which line is worst. Q1 is entirely made of this. Even \"Line 1 goes down maybe twice a month for half a shift\" is enough to start.\n\n**Quick-fire, defaults in brackets — \"yep\" is a fine answer:**\n\n6. Do your 2 techs work one wash together, or can they run two lines at once? [assuming: a 3hr wash takes both, a rinse takes one]\n7. Tint→tint, dark to light — rinse, or something bigger? [assuming rinse, but suspicious]\n8. Are washdown times line-specific? Is Line 1 slower to clean because it's old? [assuming same everywhere]\n9. Does QA hold block anything upstream, or just delay shipment? [assuming just shipment — so it hits OTIF, not throughput]\n10. Does the lab backing up at end of week actually make things late, or is it absorbed? \n11. Batch → fill run: does one mixed batch become one fill run, or do you split it across pack sizes? [assuming 1:1]\n12. Beyond \"Meridian whites on Line 2\" and \"specialty on 1 and 3 only\" — any other rules that are just how it's done?\n\n**One validation question:** should the baseline match *the sheet's plan*, or *what actually happened*? They differ, and the gap is usually your improvising at the huddle. I'd rather match actuals — that's what makes it credible to your boss — but I'd use the sheet for the sequencing logic.\n\n---\n\nSend the sheet and the demand book and skip everything else if you're short on time. If I get nothing further, I'll build the first cut on the answers above with every gap marked, and the fastest way to find out what I got wrong is for you to read the assumptions register and start crossing things out.\n\nStill worth asking your modelling person the one question: **coloured tokens and timed transitions, or plain place/transition?** Your priority tiers (Meridian / big distributor / small account) and family-based changeovers both want colour. Without it the net gets big and ugly, and I'd build it differently from the start."
+    },
+    {
+      "role": "user",
+      "content": "Okay, that \"still stu—\" was me trying to type \"still stuck on\" and my keyboard's clearly as tired as I am. Ignore it.\n\nLet me hit your flags first since you said they matter more.\n\n**Flag 1** — fair, and honestly that's fine. A reflex I can bring to the huddle is more useful than a magic optimizer anyway, because I still have to sell whatever it says to the line leads. Race the candidate responses, that's the right shape.\n\n**Flag 2** — agreed, and I appreciate you not just picking a side. I don't have a measured tank volume in my head, but I can probably get it — it's a spec sheet number, someone in engineering has it, I just never asked. I like the inversion idea better actually, \"how small would it have to be\" — I can take that number and go looking, rather than starting a fight over whose gut is right.\n\n**Flag 3** — the threshold framing is good, that's actually how I already think about some of this. \"I'll wait if it's not much scrap\" is basically what I do by feel. Fine to build it that way.\n\nNow the blockers, in order:\n\n1. **The spreadsheet** — yes, I'll send it. Fair warning, it's ugly and has three tabs nobody remembers the purpose of.\n2. **Rate matrix** — I can pull this together, give me a day. Line 3 qualification: today it's qualified for both whites, most tints, not specialty, and not two of the tint SKUs specifically — I'd have to check which two, I think it's the deep reds.\n3. **Demand book** — I can get you 4-6 weeks of history from ERP, that's a real export, not a problem. Meridian's share is big, maybe a third of white volume, I'd want to check exactly.\n4. **The night question** — good catch, and the honest answer is: we sequence to avoid it. I try never to leave a wash needed overnight, because no, nobody does it off-shift, the line just sits dirty till the techs are back at 6. That's actually a real source of lost time I probably undercount when I complain about changeover hours — it's not just the wash itself, it's the wait for a tech to be available.\n5. **Breakdowns** — roughly: Line 2 filler jams every week or two, half an hour to half a shift when it does. Line 1's mill motor is rare but scary — took four days once, that's the one that actually wrecked a month. Line 3 I honestly can't remember a bad breakdown, it's new.\n\nQuick-fire:\n\n6. One wash needs both techs together, yes — pretty sure a 3hr wash is a two-person job, a rinse one tech can do solo while the other's elsewhere. That matches your assumption.\n7. Tint to tint, dark to light — I said rinse before but now you're making me think about it and I'm not actually sure that's right. I'd guess it's a bit more than a rinse if you're jumping from say a black to a pale yellow, but I've never separated it out from same-shade-family rinses. Flag that as one I got wrong, not one I know.\n8. Washdown times line-specific — no, I don't think so, same everywhere, it's the same crew doing the same procedure regardless of line.\n9. QA hold — just delays shipment, doesn't block anything upstream, that's right.\n10. Lab backing up end of week — it does bite sometimes, that's part of why Friday shipments occasionally slip even when production hit the number. Not every week, but often enough.\n11. Batch to fill run — mostly 1:1, yes, but not always — sometimes I'll split a big mix batch across two pack sizes if two orders for the same SKU land the same week. That's probably a minority case though.\n12. Other unwritten rules — one more: there's a specific white SKU, VW-02, that can't run right after a dark tint even with a full wash. QA's superstitious about it, there was a scare a couple years back. It's not written anywhere, everyone who's been here a while just knows not to sequence it that way.\n\nValidation: match actuals, not the sheet's plan. You're right that the gap is exactly what I improvise at the huddle, and that gap is probably where the real story is.\n\nI'll go ask the modelling-tool question and get you the spreadsheet and ERP pull this week."
+    },
+    {
+      "role": "assistant",
+      "content": "Got the lot. Here's the first cut. The structure below is complete enough to implement; the numbers are a mix of yours, parameterised unknowns, and three things I need before it's trustworthy.\n\n---\n\n## Three things your answers changed\n\n**1. Specialty is single-threaded on Line 1, today.** Your unwritten rule says specialty runs on Lines 1 and 3 — but you also said Line 3 isn't qualified for specialty yet. So in practice every specialty order goes on Line 1: your slowest line, with the contested tank, and the mill motor that once cost you four days. If that's right, it changes the answer to Q1 quite a bit — a Line 1 outage doesn't just slow specialty, it stops it. Tell me if I've misread, because I've built it that way.\n\n**2. Tech-wait becomes a headline KPI, not a footnote.** You said it yourself: the loss isn't the wash, it's the line sitting dirty until 06:00. Your current changeover accounting almost certainly bills you for the 3-hour wash and not the 9 hours of dark line in front of it. I'm splitting the metric into **wash hours** and **wait-for-tech hours**, reported separately, with overnight-dirty called out on its own. My guess is that when you ask \"where do my changeover hours go\" (Q3), a big slice of the answer isn't changeover hours at all — it's crew-availability hours, and it wants a different fix.\n\n**3. Your Q7 retraction matters more than it looks.** If dark-tint→light-tint is really a rinse, fine. If it's an hour, and you've been aggregating it into \"same-family rinse\" all along, then your changeover book is wrong in exactly the place Q3 is pointed. I've made shade explicit and left that cell as a swept parameter. There's a cheap measurement below.\n\n---\n\n## The model\n\n**Scope.** Fill & pack and the changeover crew in full detail. Mix/mill/tint collapsed to a single timed upstream transition per line feeding a holding tank — except that the tank capacity stays explicit so we can run the Flag 2 inversion. QA modelled as a capacity-2 queue after fill.\n\n### Colour sets\n\n| Set | Values |\n|---|---|\n| `FAMILY` | WHITE, TINT, SPECIALTY |\n| `SHADE` | 1–5, light→dark (TINT only; WHITE=0, SPECIALTY=n/a) |\n| `TIER` | MERIDIAN, DISTRIBUTOR, SMALL |\n| `SKU` | 14 values, each carrying family + shade |\n| Order token | ⟨orderID, sku, qty, tier, dueTime⟩ |\n| Line token | ⟨lineID, lastSKU, lastFamily, lastShade, state⟩ |\n\n### Places\n\n**Global:** `P_Demand` (order arrivals), `P_Ready` (released, awaiting assignment), `P_Techs` (cap 2, calendar-gated), `P_ShiftOpen` (token present during tech shift), `P_Lab` (cap 2), `P_Shipped`, `P_Late`.\n\n**Per line L ∈ {1,2,3}:** `P_Tank_L` (cap K_L, in batches), `P_LineFree_L` (holds the line token with its state), `P_LineBusy_L`, `P_NeedsClean_L` (holds ⟨from,to⟩), `P_Cleaning_L`, `P_Down_L`.\n\n### Transitions\n\n| Transition | Timing | Guard |\n|---|---|---|\n| `T_Upstream_L` | by family (specialty slowest) | tank not full |\n| `T_Assign_L` | instant | **policy layer** — see below |\n| `T_StartFill_L` | instant | line clean-compatible; SKU qualified on L; batch in tank; line up |\n| `T_EndFill_L` | qty ÷ rate[sku][L] | — |\n| `T_RaiseClean_L` | instant | next job needs different prep; **deferred by wait-rule** |\n| `T_StartClean_L` | instant | `P_ShiftOpen` marked **and** techs ≥ n(type) |\n| `T_EndClean_L` | changeover matrix | — |\n| `T_Fail_L` / `T_Repair_L` | stochastic / scenario | — |\n| `T_QAStart` | instant | lab token free |\n| `T_QAEnd` | 4h; specialty 24h | — |\n| `T_Ship` | instant | compare to dueTime → `P_Shipped` or `P_Late` |\n\n### Changeover matrix (minutes, techs in brackets)\n\n| From ↓ To → | WHITE | TINT light | TINT dark | SPECIALTY |\n|---|---|---|---|---|\n| WHITE | 25 (1) | 45 (1) | 45 (1) | 120 (2) |\n| TINT light | **180 (2)** | 25 (1) | 25 (1) | 120 (2) |\n| TINT dark | **180 (2)** | **D (?)** | 25 (1) | 120 (2) |\n| SPECIALTY | 120 (2) | 120 (2) | 120 (2) | 25 (1) |\n\n`D` = unknown, default 60, swept 25–180.\n**Hard guard, overrides everything:** VW-02 may not follow any TINT with shade ≥ 4, wash or no wash. Modelled as a forbidden transition, not a duration.\n\n**Ramp scrap:** `S(type)` units discarded at start of each run after a changeover. Zero for same-family; parameterised and swept for family switches, largest after tint→white.\n\n### Policy layer — the part you'll actually tune\n\nThe baseline reproduces you:\n\n1. Meridian whites → Line 2, always.\n2. Specialty → Line 1 (see point 1 above).\n3. Otherwise prefer the line whose `lastFamily` matches the order.\n4. Within a line, sequence by tier then due date.\n5. **Avoid stranding a wash overnight**: don't start a job that will end after tech shift-end if it leaves the line needing a wash.\n6. VW-02 guard.\n\nAlternatives to race against it: **wait-rule with threshold W** (hold the line idle up to W hours for a same-family order rather than raise a wash — this is Q2, swept 0–6h); **breakdown reflexes** A/B/C for Q1; **Meridian-priority in the QA queue** (a free OTIF experiment given your Friday lab backup).\n\n### KPIs\n\nMeridian lateness (any); distributor lateness >2 days; small-account >7 days; **wash hours**; **wait-for-tech hours**; **overnight-dirty hours**; ramp scrap units; per-line utilisation; **tank-blocked hours** (Flag 2).\n\n---\n\n## Assumptions register — all UNVALIDATED\n\n| # | Assumption | Basis |\n|---|---|---|\n| A1 | Specialty runs Line 1 only, today | inferred from your qualification list — **please confirm** |\n| A2 | `D` (dark→light tint) = 60 min | pure guess, you retracted the rinse answer |\n| A3 | ≥120 min washes take 2 techs, shorter take 1 | your rule extended by me |\n| A4 | Washdown times identical across lines | your answer |\n| A5 | Ramp scrap values | invented, swept not asserted |\n| A6 | Line 2 MTBF ~10 days, repair 0.5–4h | your \"every week or two\" |\n| A7 | Line 1 mill motor modelled as scenario, not random | too rare to sample meaningfully in a 6-week run; you'd get noise, not signal |\n| A8 | Line 3 breakdowns = zero | your answer, but \"new\" ≠ \"reliable\" long-term |\n| A9 | Batch→fill run 1:1; splits ignored in v1 | your \"minority case\" |\n| A10 | Lab is day-shift, FIFO | never asked you — guessing |\n| A11 | One mill per line | never established; if mills are shared the Line 1 outage is much worse |\n\n---\n\n## What I still need\n\n**Blocking:**\n\n- **Shift pattern.** Still don't have it. How many shifts do the *lines* run, and what hours are the *techs* on? Everything about wait-for-tech hangs on this gap, and it's the mechanism behind your own biggest complaint.\n- Confirmation on A1 and A11.\n- The spreadsheet, rate matrix, ERP pull — in hand this week, understood.\n\n**Three cheap measurements**, each worth more than a week of my guessing:\n\n1. **Time Line 1's fill rate when the tank isn't empty.** A stopwatch and one run. Without this, rate and tank capacity are both unknown and the inversion can't identify either — you'd be picking a winner in the engineering argument by assumption again. With it, tank capacity is the only free parameter and the question answers itself.\n2. **Tick sheet for the techs, two weeks:** changeover type, start time, end time. Settles `D`, `A3`, and gives me real wash durations instead of your recollection of them.\n3. **Eyeball ramp scrap** after the next tint→white and after the next same-family rinse. Rough units. Enough to put you on the right side of a threshold.\n\n---\n\n## PNML\n\nReady to cut, but I'd rather burn one day waiting than send your modeller the wrong dialect. If the answer is coloured + timed, you get the model above more or less as written. If it's plain place/transition, the colour has to be unfolded into separate places per family per line — roughly four times the net, and I'd drop `SHADE` to keep it legible, which means losing the `D` question and the VW-02 guard becomes clumsy. That's a real loss, so if there's a coloured-net option in the tool, take it.\n\nSend the shift pattern and I'll start wiring the baseline against your ERP export. First thing I'll report is whether the model can reproduce your actual weekly output per line — if it can't, that's the finding, and we fix the model before it tells you anything about Tuesdays."
+    },
+    {
+      "role": "user",
+      "content": "Shift pattern, since that's the blocker: Lines 1 and 2 run two shifts, roughly 6am to 10pm, with a gap overnight. Line 3 is day shift only, 6 to 2, unless someone's approved overtime, which is rare and needs the ops director to sign off. The techs — the two changeover guys — are day shift only, 6 to 2 as well, same as Line 3's crew basically, they just cover all three lines. So a second-shift line (1 or 2) that needs a wash after 2pm is stuck dirty until the morning crew's in — that's the mechanism you flagged, and yeah, I think you're right that it's bigger than I've been crediting.\n\nOn A1 — yes, confirmed, that's right as you've built it. Specialty is Line 1 only in practice today, even though the \"rule\" says 1 and 3. Nobody's written that down anywhere, it's just where Line 3's qualification list has landed. Good catch, honestly, I hadn't said it out loud like that before.\n\nA11 — one mill per line, yes, as far as I know. I've never heard of mills being shared between lines, they're bolted to each line's own setup. I'll double check but I'd be surprised if I'm wrong.\n\nOn the three measurements — I can get you all of these, and I like that you've made them cheap. Stopwatch on Line 1's fill rate with a non-empty tank, I'll do that myself next time it happens, probably this week. The tech tick sheet I'll have to ask the crew to fill in, might take a bit of nagging but two weeks is doable. Ramp scrap eyeball, I can grab that off the floor lead next tint→white changeover, shouldn't be hard.\n\nOne thing on your KPI table — \"overnight-dirty hours,\" I like that as its own number, that's exactly the thing I've never been able to point at and say \"there, that's the cost.\" If nothing else comes out of this whole exercise, that number alone might be worth the huddle argument.\n\nGo ahead and wire the baseline against the ERP export once you've got it, and I'll chase the shift confirmation on Line 3 overtime frequency if you need it — right now \"rare\" is genuinely the best I've got, I don't have a count."
+    },
+    {
+      "role": "assistant",
+      "content": "Shift pattern lands, and it does more than fill a gap — it constrains the plant hard enough that some things fall out before any simulation runs. Worth checking these by eye now, because if the arithmetic looks wrong to you, my changeover matrix is wrong, and better to find that out today than after I've wired it up.\n\n---\n\n## The headline question, which I should have asked two turns ago\n\n**Can a line operator do a same-family rinse themselves, or does every changeover — including a 25-minute rinse — need one of the two techs?**\n\nEverything below assumes the second answer, because that's how I read \"one changeover crew, covers all three lines.\" If that's right, then **Lines 1 and 2 cannot change SKU at all after 14:00.** No rinses, no pack-size swaps, nothing. Whatever's loaded at 14:00 runs until 22:00 or until it runs out and the line stops.\n\nThat's a severe constraint and it may well be wrong. If operators handle their own rinses and the techs are really a *big-wash* crew, the second shift is flexible and the model looks quite different. Please answer this one before anything else.\n\n---\n\n## The tech-hour budget\n\nTwo techs × 8 hours = **16 tech-hours per day**, and that's the whole plant's changeover capacity.\n\n| Changeover | Duration | Techs | Cost | Latest start |\n|---|---|---|---|---|\n| Same-family rinse | 25 min | 1 | 0.4 tech-h | 13:35 |\n| White → tint | 45 min | 1 | 0.75 tech-h | 13:15 |\n| Specialty in/out | 120 min | 2 | 4 tech-h | 12:00 |\n| **Tint → white** | **180 min** | **2** | **6 tech-h** | **11:00** |\n\nThree things drop out:\n\n**Big washes are strictly serial.** Both techs are consumed, so while a tint→white wash runs, no other line can get so much as a rinse. Two big washes in a day eats 6 of the 8 clock hours and blocks everything else for the duration.\n\n**The ceiling is about two family switches a day, plant-wide.** Three is possible only if just one of them is a tint→white, and it leaves zero slack for rinses. Call it **8–10 family switches a week, maximum**, if the techs do nothing else.\n\n**Your instinct to cluster isn't a preference, it's forced.** Three lines × 5 days = 15 line-days against ~8 available family switches. You physically cannot ping-pong even if you wanted to.\n\n**Sanity check for you:** does the plant do more than about eight family switches in a normal week? If yes, one of my inputs is wrong — most likely the 3-hour wash is shorter in practice, or someone's doing it solo, or people stay late more than you think. Any of those is worth knowing.\n\n---\n\n## The 11:00 problem, and what it does to Meridian\n\nA tint→white wash must start by 11:00. That gives you a **five-hour window per day** for the one changeover your biggest customer depends on — because Meridian whites always run Line 2, and Line 2 runs tints too.\n\nLine 2 runs 16 hours a day but can only cross from tint to white in a 5-hour slot each morning. Run boundaries don't land there by chance; you'd have to aim at it.\n\nWhich points at a rule worth testing:\n\n> **A wash raised at 22:00 is free. A wash raised at 14:30 costs you seven and a half hours.**\n\nNothing is scheduled between 22:00 and 06:00, so a line that finishes dirty at end of second shift loses nothing overnight — the techs clean it at 06:00 and you're away. The expensive case is a changeover falling due in the 14:00–22:00 dead zone, where the line sits idle through hours you're paying for.\n\nSo the candidate huddle rule is: **on Lines 1 and 2, land family switches either before 14:00 or at 22:00 — never in between.** That's testable, and if it holds it's the most directly actionable thing this exercise produces. Deliberately leaving Line 2 dirty overnight to catch the 06:00 wash slot is, on this logic, correct play rather than sloppiness.\n\n---\n\n## Your Q2 changes shape\n\nYou asked whether it's worth idling a line to wait for a same-family order. Given the calendar, the answer almost certainly isn't a single number of hours — **it's a function of the clock.**\n\nAt 07:00, waiting two hours is cheap: the wash window is wide open, you can still wash at 09:00 if nothing turns up. At 12:30, waiting is nearly free in a different sense — you've already lost the ability to do a big wash today, so there's nothing to trade off. At 10:30, waiting is expensive: an hour's wait closes the 11:00 window and pushes the switch to tomorrow morning.\n\nI'll sweep `W` as time-of-day dependent rather than constant. Expect the output to look like \"before 09:00 wait up to 3h; 09:00–11:00 never wait; after 11:00 wait as long as you like.\"\n\n---\n\n## KPI definition, tightened before your boss sees it\n\nYou liked overnight-dirty hours. Protect it from the obvious attack — someone will point out that a line dirty from 14:30 to 06:00 wasn't scheduled to run for eight of those hours, and if the number includes them it's inflated and the whole model looks sloppy. Three separate figures:\n\n| Metric | Example (wash raised 14:30 Line 2, washed 06:00–09:00) | Status |\n|---|---|---|\n| Clock-dirty hours | 18.5 h | Report, label *not a loss* |\n| Wash hours | 3 h | Largely unavoidable |\n| **Lost production hours** | **7.5 h** | **The number you argue with** |\n\nSplit the last one by cause — *techs off shift* vs *techs busy on another line* — because they have different fixes. The first wants a shift change, the second wants a third tech or better sequencing.\n\n---\n\n## Model updates\n\nAdded: `P_Calendar` with per-resource windows (L1/L2 06:00–22:00, L3 06:00–14:00, techs 06:00–14:00, lab TBC). `T_StartClean_L` now guards on *whole duration fitting inside the tech window* — **A12: a wash is never started unless it can finish, rather than pausing at 14:00 and resuming.** Tell me if the crew would in fact stay late to finish one.\n\nLine 3's entire operating day sits inside the tech window, so its changeovers compete head-on with the morning wash queue for Lines 1 and 2. That's a new contention I hadn't modelled.\n\nLine 3 overtime: don't go counting it. Treat as zero in baseline and use it as a **lever** — \"what is it worth to approve Line 3 overtime twice a week?\" is a better question than \"how often does it happen,\" and it takes work off you.\n\n**New experiment, and possibly the valuable one:** move the tech shift. Both techs 06:00–14:00 (status quo) vs 10:00–18:00 vs 14:00–22:00 vs one on each shift. Note that splitting them means no big washes ever happen, so that arm probably fails badly — but it's worth showing your ops director *why* rather than asserting it. Costs nothing to test and it's the direct answer to the lost-production number you now have a name for.\n\n---\n\n## Standing asks\n\nBlocking: **the rinse question at the top.** Then spreadsheet, rate matrix, ERP pull, and A12.\n\nParked and fine: the three measurements, on your timescale.\n\nStill open: PNML dialect. Nothing's changed there — coloured plus timed if you can get it.\n\nI'll wire the baseline the day the ERP export lands. First report is whether the model reproduces your actual weekly output per line, before it says anything about Tuesdays."
+    },
+    {
+      "role": "user",
+      "content": "The rinse question — good, glad you flagged it, because the honest answer is: it depends, and I've never had to think about it this precisely before. Line operators *can* do a quick same-family rinse themselves, that's within their own job, no tech needed. It's the family-switch cleans — anything from 45 minutes up, so white↔tint, specialty in/out, and definitely tint→white — that need one of the two techs, because those involve the actual wash chemicals and a signoff step QA cares about.\n\nSo it's not quite either of your two readings. Rinses are free of the tech constraint. Everything else isn't. That should loosen the afternoon picture somewhat — Lines 1 and 2 can still do same-family pack swaps and rinses after 14:00, they just can't cross families.\n\nGiven that correction — do more than about eight family switches happen in a normal week? Honestly, thinking about it properly for the first time... probably not much more than that, no. Some weeks feel like we're constantly washing, but that might just be the *pain* of it, not the actual count. I'd believe your ceiling.\n\nOn the 11:00 problem and the overnight-wash-is-free logic — this matches something I do already without having named it. I do try to leave Line 2 dirty on a tint at end of second shift if I know tomorrow's first order is a Meridian white, rather than force an evening wash. I've never articulated why, I just know it \"feels right.\" Sounds like you've found the reason.\n\nA12 — would the crew stay late to finish a wash that's mid-way at 14:00? No, not routinely. If a wash is genuinely almost done, maybe ten minutes over, someone might just finish it, but they're not staying an extra hour. Your guard is right: don't start one unless it fits.\n\nLine 3 competing with Lines 1 and 2 for the same tech window in the morning — yeah, that's real, and now that you say it, that probably explains some of the Tuesday scheduling headaches I mentioned right at the start, where Line 3 sits clean but idle. It's not that the crew is slow, it's that Line 3's whole day is crammed into the same four hours the big lines also want their washes done.\n\nI like the tech-shift-move experiment. Ops director will ask why we don't just add a third tech before asking about shift timing, so if the split-shift arm fails as badly as you expect, that's useful ammunition too — shows we looked at cheaper options before asking for headcount.\n\nI'll get you the rinse-vs-tech split confirmed properly on paper (not just my memory) alongside the tick sheet, since they're the same data collection exercise really. ERP export and rate matrix by end of week."
+    },
+    {
+      "role": "assistant",
+      "content": "That correction does real work — it moves the constraint off rinses entirely and onto family switches alone. Which sharpens the picture rather than loosening it.\n\n---\n\n## What the day actually looks like now\n\nLatest possible start for each tech-requiring changeover, working back from 14:00:\n\n| Changeover | Duration | Techs | Latest start | Blocks other lines? |\n|---|---|---|---|---|\n| White → tint | 45 min | 1 | **13:15** | No — other tech free |\n| Specialty in/out | 120 min | 2 | **12:00** | Yes |\n| Tint → white | 180 min | 2 | **11:00** | Yes |\n| Same-family rinse | 25 min | operator | any time line runs | No |\n\nSo after **13:15, no line can cross families** until 06:00 the next morning. Lines 1 and 2 run to 22:00 locked to whatever family they were on at lunchtime.\n\n**The morning decides the day.** Whatever Line 2 is set to by 13:15 is what it runs for the next nine hours. That's not a scheduling preference, it's the calendar. It also means your 07:30 huddle is genuinely the decision point — you're not improvising around a continuous decision space, you're setting two or three switches that then lock. Fewer decisions than it feels like, each worth more.\n\n**A new rule falls out of that:** don't commit a morning family switch unless there's enough work in that family to fill through 22:00. Switch Line 2 to white at 09:00 with four hours of white orders behind it and you get four good hours and then a dead line until morning — you've spent a 3-hour wash *and* stranded the evening. Call it the fill-the-shift rule; I'll add it as a policy variant and test it against the baseline.\n\n---\n\n## Capacity or timing? — the question your ops director's answer hangs on\n\nFreeing rinses raises the theoretical ceiling to roughly 10–13 family switches a week. You think actual is around eight.\n\nIf that gap is real, **the techs are not running at capacity, and the binding constraint is the 11:00 window rather than headcount.** A third tech mostly buys you parallel capacity you aren't using. Moving the shift buys you window.\n\nThat's a hypothesis, not a finding — it could equally be that the mix is big-wash-heavy and eight *is* the ceiling in practice. But it's exactly what the tick sheet will settle, and it's the difference between \"we need another head\" and \"we need the existing heads at different hours.\" Worth knowing which before the conversation, not during.\n\n**And a mechanism for your Tuesday complaint:** a tint→white starting at 06:00 consumes both techs until 09:00. Line 3 runs 06:00–14:00 — so it cannot cross families for the first three of its eight hours, and it's clean, staffed, and idle while it waits. That's testable against the sheet and would explain the pattern without anyone being slow at anything.\n\n---\n\n## One fix to the measurement design\n\nThe tick sheet as I specified it goes to the techs — so it will capture only tech-performed changeovers. Two things get missed:\n\n1. **Rinses**, including `D`. If dark→light tint is an operator job, it never appears, and that's the number I most need.\n2. **Shadow practice** — operators handling family switches informally when no tech is free. If that happens even occasionally, my hard guard is wrong and the model will under-predict your throughput.\n\n**Log at the line, not at the crew.** Every changeover, every line: type, start, end, and *who did it*. Same effort, catches everything, and the \"who\" column answers the rinse-vs-tech split on paper as a by-product of the same exercise.\n\n`D` is now a two-dimensional unknown — duration *and* resource class. A 60-minute operator rinse costs line time only. A 60-minute tech job with a QA signoff costs window in the morning and is impossible after 13:15. Very different consequences, so the \"who\" column matters as much as the stopwatch.\n\n---\n\n## Model updates\n\n- **`T_Clean_L` splits in two.** `T_Rinse_L`: guarded on line calendar only, no tech token, 25 min. `T_Wash_L`: guarded on tech calendar *and* tech tokens *and* whole-duration-fits (A12), with a 15-minute grace parameter for your almost-done case.\n- **New reported metric: family-lock hours** — time per line per day during which no family switch is possible. Pairs with lost-production hours and shows *why* they occurred.\n- **Wait-rule `W` is now morning-only.** After 13:15 the choice \"wait or wash\" doesn't exist; it's \"run same-family or stop.\" Q2 collapses to a question about the 06:00–13:15 window, which makes the sweep smaller and the answer easier to state at a huddle.\n- **Policy variants to race:** baseline (you) / fill-the-shift rule / time-of-day wait-rule / tech shift 06:00–14:00 vs 10:00–18:00 vs split / Line 3 overtime as a purchasable lever.\n\n**Assumptions register delta:** A3 retired and replaced — changeovers ≥45 min require a tech, rinses don't (your answer, to be confirmed on paper). A12 confirmed with grace parameter. A2 (`D`) upgraded from unknown-duration to unknown-duration-and-resource. New A13: operators are always available during line hours, so rinses never queue.\n\n---\n\n## Where this stands\n\nI think the interview is done. I have the process, the equipment, the calendar, the changeover structure, the priority tiers, and your sequencing logic. What's outstanding is data, not understanding.\n\n**Coming from you:** spreadsheet, rate matrix, ERP export (end of week). Then the three measurements plus the \"who did it\" column, on the crew's timescale.\n\n**From me, on ERP arrival:** baseline wired and the reproduction check — actual weekly output per line, and roughly eight family switches a week. If it can't hit those, that's the finding and I fix the model before it says anything about Tuesdays.\n\n**On the dialect:** if I haven't heard by the time the export lands, I'll ship coloured-plus-timed as primary and a reduced plain place/transition fallback for the fill-and-changeover subnet only. The fallback loses `SHADE` and makes the VW-02 guard ugly, but it'll run. Better than stalling further on a question your modelling person can answer in ten seconds whenever they surface.\n\nOne thing worth banking now, before any of the data lands: *the morning decides the day, and after 13:15 every line is locked to its family.* That's true regardless of what the numbers say, it came out of your own shift pattern, and it's a defensible thing to say at a huddle tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "This is a lot to take in but it tracks with what I actually do without having said it out loud — the 07:30 huddle *is* the decision, not a running commentary on one. That \"morning decides the day\" line, I'll use that at the huddle tomorrow, honestly, it's a cleaner way of saying something I've been saying badly for years.\n\nThe fill-the-shift rule rings true too — I've absolutely done the thing where I switch a line for four hours of work and regretted it by evening, I just never called it a rule, I called it \"having a bad day.\"\n\nOn the tick sheet fix — good, yes, log at the line not the crew, that's obviously right once you say it, and it's barely more work for whoever's writing it down. I'll set that up instead of the version I described before. And you're right that I don't actually know if operators ever do a family switch informally when a tech's tied up elsewhere — I want to say no, that's not allowed, but \"not allowed\" and \"never happens\" aren't the same thing on a busy Tuesday. Worth watching for on the sheet rather than me asserting an answer.\n\nI don't have anything to correct on the capacity-vs-timing question — that's exactly the kind of thing I wanted this whole exercise for, and I'm glad it's sitting on \"let's measure it\" rather than either of us guessing.\n\nNothing else outstanding from my side. I'll get the spreadsheet, rate matrix and ERP export moving today, and chase the tooling person on the coloured-vs-plain question this afternoon so you're not stuck guessing on the dialect too. I'll ping you the moment the export's ready."
+    },
+    {
+      "role": "assistant",
+      "content": "Good. Two small things to hand over, then I'll get out of your way.\n\n**The tick sheet, in one line, so you can set it up today.** One row per changeover, any changeover, all three lines:\n\n> date | line | from-SKU | to-SKU | start | end | done by (operator / tech) | units scrapped at start of run\n\nEight columns, and the last one folds your ramp-scrap eyeball into the same exercise rather than a separate one. If the crew will only reliably fill in six, drop `units scrapped` and `from-SKU` — I can reconstruct the from-SKU from the run log.\n\n**One caution on how you frame it to the crew.** The \"done by\" column only tells you the truth if nobody thinks it's a compliance check. If it reads as *are operators doing washes they shouldn't*, you'll get a clean sheet that says exactly what policy says, and the most interesting thing in the dataset will vanish. Frame it as working out which changeovers genuinely need a tech, because that's true — it's the capacity-vs-timing question, and it's the case for either a shift change or a third head.\n\n**For tomorrow's huddle, what's safe to say and what isn't.**\n\nSafe — it comes straight from your own shift pattern, not from my model: after 13:15 no line can cross families, so the morning decides the day; and a wash raised at 22:00 costs nothing while one raised at 14:30 costs the evening.\n\nHold back — the eight-switches-a-week ceiling, the capacity-vs-timing hypothesis, and anything about Line 3's idle mornings. Those are my arithmetic on your recollections. They're likely right, which is why they're worth measuring, but if you put a number in front of your ops director and the tick sheet contradicts it in a fortnight, you'll spend more credibility recovering than you gained.\n\n**When the export lands** I'll wire the baseline and run the reproduction check first — weekly output per line, and the switch count. If it misses, that's the interesting result and I'll come back with what the model thinks is happening versus what your ERP says happened. That's normal, not a setback; the gap is usually where an assumption is wrong, and we have eleven of those on the register waiting to be caught.\n\nPing me when it's ready. If the dialect answer arrives first, even better — send it on its own and I'll start the net while I wait for the data."
+    },
+    {
+      "role": "user",
+      "content": "Good, that's an easy sheet to hand over — eight columns, or six if they push back, either works.\n\nThe framing caution is well taken. I'll pitch it to the crew as figuring out which cleans genuinely need two of them versus one, not as anyone checking up on them. That's honest and it'll get better data than the compliance version.\n\nAnd thanks for the huddle guardrail — I was actually about to walk in tomorrow and say \"we can only do eight family switches a week\" like it was fact. Good thing you flagged it. I'll stick to the two safe lines and leave the rest alone until the sheet earns it.\n\nI'll get the tick sheet out today, chase the spreadsheet and ERP export, and ping you the moment the export's ready — or sooner if the dialect answer comes back first. Thanks for this, it's been more useful than I expected going in."
+    },
+    {
+      "role": "assistant",
+      "content": "Glad it landed. That near-miss on the eight-switches line is worth remembering as a general habit rather than a one-off: the model will keep producing numbers that feel solid because they're internally consistent, and the ones derived from recollection will look identical to the ones derived from data. The assumptions register exists so you can tell them apart — read it before you quote anything from me.\n\nOne thing not worth waiting a fortnight for: if the tick sheet shows an operator doing a family switch in week one, send it straight over. That single row would retire a hard guard in the model and change what the baseline predicts, so I'd rather rework early than build two weeks on it.\n\nOtherwise — dialect when you have it, export when it's ready, and I'll come back with the reproduction check rather than answers. Good luck at the huddle."
+    },
+    {
+      "role": "user",
+      "content": "Understood — I'll read the register before I say anything out loud with a number attached, that's a fair rule and I'll try to actually stick to it, not just agree to it now and forget by Thursday.\n\nAnd noted on the operator-switch row — I won't sit on that if it shows up, I'll flag it the same day, not batch it in with the rest of the sheet at the two-week mark.\n\nTalk soon."
+    },
+    {
+      "role": "assistant",
+      "content": "Sounds good. Nothing further needed from you until the export lands.\n\nOne practical note on the register habit, since sticking to it is harder than agreeing to it: I'll keep the register as page one of whatever I send, with the unvalidated rows flagged in place rather than in a separate appendix. That way it's in front of you rather than something you have to remember to go and look up. If a number ever shows up in my output without a traceable basis, treat that as my error and push back on it.\n\nTalk soon — and good luck tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Appreciated — page one, in place, is a much better bet than relying on my memory. That's on you to maintain and me to actually read, and I'll do my part.\n\nTalk soon.\n\n(Sorry — I've just seen the time, I have the floor huddle in ten minutes. How much more do you need?)"
+    },
+    {
+      "role": "assistant",
+      "content": "Nothing. You're done — go.\n\nEverything outstanding is on your side and on your timescale: tick sheet out today, spreadsheet/rate matrix/ERP when they're ready, dialect answer whenever your tooling person surfaces. No further questions from me.\n\nFor the next ten minutes, the two safe lines:\n\n- After 13:15 no line can cross families — the morning decides the day.\n- A wash raised at 22:00 is free; one raised at 14:30 costs the evening.\n\nBoth come from your own shift pattern. Nothing else from me is huddle-ready yet.\n\nGood luck."
+    },
+    {
+      "role": "user",
+      "content": "Thanks — heading in now."
+    },
+    {
+      "role": "assistant",
+      "content": "Go well."
+    },
+    {
+      "role": "user",
+      "content": "*heads to the huddle*"
+    },
+    {
+      "role": "assistant",
+      "content": "Nothing more from me — I'll pick this up when the export lands."
+    },
+    {
+      "role": "user",
+      "content": "Sounds good — talk then."
+    },
+    {
+      "role": "assistant",
+      "content": "Talk then. Good luck with the rest of the day."
+    },
+    {
+      "role": "user",
+      "content": "Thanks — same to you. I'll be in touch once the export's ready."
+    },
+    {
+      "role": "assistant",
+      "content": "Speak then."
+    },
+    {
+      "role": "user",
+      "content": "Speak then."
+    },
+    {
+      "role": "assistant",
+      "content": "👍"
+    },
+    {
+      "role": "user",
+      "content": "👍"
+    },
+    {
+      "role": "assistant",
+      "content": "—"
+    },
+    {
+      "role": "user",
+      "content": "*nods and heads off to the huddle*"
+    },
+    {
+      "role": "assistant",
+      "content": "*(Nothing further needed — the thread's parked until the export lands.)*"
+    },
+    {
+      "role": "user",
+      "content": "Understood — parked. I'll reach out once it's ready."
+    },
+    {
+      "role": "assistant",
+      "content": "Perfect. Talk then."
+    },
+    {
+      "role": "user",
+      "content": "Talk then."
+    },
+    {
+      "role": "assistant",
+      "content": "*[No further response needed — conversation complete.]*"
+    },
+    {
+      "role": "user",
+      "content": "*[Ends here.]*"
+    },
+    {
+      "role": "assistant",
+      "content": "Closed. See you when the export lands."
+    },
+    {
+      "role": "user",
+      "content": "See you then."
+    },
+    {
+      "role": "assistant",
+      "content": "👋"
+    },
+    {
+      "role": "user",
+      "content": "I really do have to stop here. Please produce the model now with everything you have."
+    },
+    {
+      "role": "assistant",
+      "content": "# Coatings Plant Scheduling Model — v1.0\n\n**Delivered:** first cut, built on interview only. No plant data has been loaded yet.\n\n**Status:** structurally complete, numerically unvalidated. Read page one before quoting any number from this model to anyone.\n\n---\n\n# PAGE ONE — ASSUMPTIONS REGISTER\n\n## A. Confirmed by you in interview\n\n| # | Statement |\n|---|---|\n| C1 | Four stages: mix → mill → tint/letdown → fill & pack. Same order for all products. |\n| C2 | 3 filling lines, 14 SKUs, 3 families (base whites, tinted colours, specialty clears). |\n| C3 | Lines 1 & 2 run 06:00–22:00. Line 3 runs 06:00–14:00. |\n| C4 | Changeover techs: 2 people, 06:00–14:00 only, shared across all three lines. |\n| C5 | Rinses (same-family, ~25 min) are done by line operators — **no tech required**. |\n| C6 | Family switches (≥45 min, wash chemicals + QA signoff) **require a tech**. |\n| C7 | Tint→white = ~180 min, 2 techs. White→tint = ~45 min. Specialty in/out = ~120 min, either direction. |\n| C8 | A wash is not started unless it can finish before 14:00 (≤15 min overrun tolerated). |\n| C9 | QA hold is **after** fill, 4 h typical / ~24 h specialty, 2 lab staff. Delays shipment only; does not block upstream. |\n| C10 | Meridian white orders always run on Line 2. |\n| C11 | Specialty runs Line 1 only in current practice (Line 3 not qualified). |\n| C12 | VW-02 must not follow a dark tint, wash or no wash. |\n| C13 | Priority: Meridian never late > distributors (±2 days) > small accounts (±7 days). Then changeover hours, then utilisation. |\n| C14 | Line 3 overtime requires ops director signoff; rare. |\n| C15 | One mill per line, not shared *(you flagged you'd double-check)*. |\n\n## B. UNVALIDATED — my assumptions, not your statements\n\n**Every row below will produce confident-looking output. None of it is evidence.**\n\n| # | Assumption | Basis | How it gets retired |\n|---|---|---|---|\n| **A2** | `D` = dark-tint→light-tint changeover is **60 min, resource class unknown** | Pure guess. You retracted your \"rinse\" answer. | Tick sheet: duration + \"done by\" column |\n| **A5** | Ramp scrap: 0 same-family; parameterised for family switches; largest tint→white | Invented. Swept, not asserted. | Floor-lead eyeball, next tint→white and next rinse |\n| **A6** | Line 2 MTBF ≈ 10 days, repair 0.5–4 h (triangular) | Your \"every week or two, half hour to half a shift\" | Maintenance log |\n| **A7** | Line 1 mill motor modelled as a **named scenario**, not a random failure | Too rare to sample in a 6-week run — you'd get noise, not signal | n/a — design choice, but say so out loud |\n| **A8** | Line 3 breakdowns = zero | Your answer. \"New\" ≠ \"reliable\" at 18 months. | Revisit in 6 months |\n| **A9** | Batch→fill run is 1:1; multi-pack-size splits ignored in v1 | Your \"minority case\" | ERP export will show actual frequency |\n| **A10** | Lab is day-shift, FIFO, no priority for Meridian | **Never asked you. Straight guess.** | One question to QA |\n| **A13** | Operators always available during line hours, so rinses never queue | Convenience assumption | Tick sheet |\n| **A14** | Rate matrix values | **Placeholders. Not real numbers.** | Your rate matrix |\n| **A15** | Tank capacities K₁, K₂, K₃ | **Placeholders.** K₁ is the disputed one. | Engineering spec sheet + stopwatch |\n| **A16** | Which two tint SKUs Line 3 is not qualified for (assumed the two deepest reds) | Your recollection, unconfirmed | Qualification list |\n| **A17** | Order arrival pattern and Meridian's share (assumed ⅓ of white volume) | Your estimate | ERP export |\n| **A18** | Washdown durations identical on all three lines | Your answer, plausible, untested | Tick sheet |\n| **A19** | Operators never perform family switches informally | Policy, not observation. **You said \"not allowed and never happens aren't the same thing.\"** | Tick sheet \"done by\" column |\n\n**A19 is the one to watch.** A single contrary row retires a hard guard and changes what the baseline predicts. Send it the same day it appears.\n\n## C. What this model cannot do\n\n1. **It will not compute an optimal reshuffle.** It races policies you specify. The output is a *reflex* you can defend at the huddle, not a schedule.\n2. **It cannot settle the Line 1 tank argument on current inputs.** Whatever I assume about K₁ and Line 1's rate, the model will reproduce faithfully and appear to prove someone right. Run the inversion (§7.3) only after the stopwatch measurement, and do not take it into a room with engineering before then.\n3. **It has no first-pass-yield data.** Scrap is a swept parameter presented as thresholds, never as a point estimate.\n\n---\n\n# 1. Scope and resolution\n\n| Area | Detail level | Why |\n|---|---|---|\n| Fill & pack, all 3 lines | **Full** | Your bottleneck |\n| Changeover crew and calendar | **Full** | Your sore spot; the real constraint |\n| Mix / mill / tint | Single timed transition per line feeding a holding tank | You care less; tank capacity kept explicit for the Flag 2 inversion |\n| QA hold | Capacity-2 queue, post-fill | Affects OTIF only |\n| Raw materials | Assumed always available | Never raised as a driver |\n\n**Time base:** minutes. **Run length:** 6 weeks + 1 week warm-up. **Replications:** 30 per policy arm (breakdowns are stochastic; single runs will mislead you).\n\n---\n\n# 2. Colour sets\n\n| Set | Values |\n|---|---|\n| `FAMILY` | `WHITE` \\| `TINT` \\| `SPECIALTY` |\n| `SHADE` | `0`(white) \\| `1..5` light→dark (tints) \\| `X`(specialty) |\n| `TIER` | `MERIDIAN` \\| `DISTRIBUTOR` \\| `SMALL` |\n| `SKU` | 14 values; each carries `(family, shade, qualifiedLines[])` |\n| `ORDER` | `⟨id, sku, qty, tier, dueTime, releaseTime⟩` |\n| `LINESTATE` | `⟨lineId, lastSKU, lastFamily, lastShade, up:bool⟩` |\n| `BATCH` | `⟨sku, qty⟩` |\n| `LOT` | `⟨orderId, sku, qty, tier, dueTime, fillEndTime⟩` |\n\n---\n\n# 3. Places\n\n### 3.1 Shared\n\n| Place | Type | Init | Meaning |\n|---|---|---|---|\n| `P_Demand` | ORDER | from ERP | Order arrival stream |\n| `P_Ready` | ORDER | ∅ | Released, awaiting line assignment |\n| `P_Techs` | unit | 2 | Techs **on shift and free** |\n| `P_TechsOff` | unit | 0 | Techs off shift |\n| `P_TechShiftOpen` | unit | 0 | Marked 06:00–14:00 |\n| `P_LineOpen_1`, `_2` | unit | 0 | Marked 06:00–22:00 |\n| `P_LineOpen_3` | unit | 0 | Marked 06:00–14:00 (+OT lever) |\n| `P_Lab` | unit | 2 | Free lab capacity |\n| `P_LabOpen` | unit | 0 | Marked during lab hours (A10) |\n| `P_QAQueue` | LOT | ∅ | Awaiting QA |\n| `P_Shipped` | LOT | ∅ | Completed |\n| `P_Clock` | int | 1 | Calendar cycle token |\n\n### 3.2 Per line L ∈ {1,2,3}\n\n| Place | Type | Init | Meaning |\n|---|---|---|---|\n| `P_UpIdle_L` | unit | 1 | Upstream (mix/mill/tint) free |\n| `P_UpBusy_L` | BATCH | ∅ | Upstream in progress |\n| `P_Tank_L` | BATCH | ∅ | Holding tank contents |\n| `P_TankFree_L` | unit | K_L | Remaining tank slots (complementary place) |\n| `P_LineIdle_L` | LINESTATE | 1 | Line free, carrying its last-run identity |\n| `P_LineFilling_L` | ORDER×LINESTATE | ∅ | Fill in progress |\n| `P_ChangeoverDue_L` | ⟨from,to⟩ | ∅ | Changeover raised, not started |\n| `P_Rinsing_L` | ⟨from,to⟩ | ∅ | Operator rinse in progress |\n| `P_Washing_L` | ⟨from,to⟩ | ∅ | Tech wash in progress |\n| `P_Down_L` | unit | 0 | Line failed |\n\n---\n\n# 4. Transitions\n\n## 4.1 Calendar subnet (drives everything)\n\n| Transition | Fires at | Effect |\n|---|---|---|\n| `T_TechShiftStart` | 06:00 daily | `P_TechsOff` → `P_Techs`; mark `P_TechShiftOpen` |\n| `T_TechShiftEnd` | 14:00 daily | Unmark `P_TechShiftOpen`; return free techs to `P_TechsOff` |\n| `T_Line12Open` / `T_Line12Close` | 06:00 / 22:00 | Mark/unmark `P_LineOpen_1`, `P_LineOpen_2` |\n| `T_Line3Open` / `T_Line3Close` | 06:00 / 14:00 (22:00 if OT) | Mark/unmark `P_LineOpen_3` |\n| `T_LabOpen` / `T_LabClose` | per A10 | Mark/unmark `P_LabOpen` |\n\n*Weekends: all calendar transitions gated off unless the weekend-working lever is set.*\n\n## 4.2 Production\n\n| Transition | Delay | Guard |\n|---|---|---|\n| `T_UpStart_L` | — | `P_UpIdle_L` marked ∧ `P_TankFree_L` ≥ 1 ∧ a job is assigned to L |\n| `T_UpEnd_L` | `upstream_time[family]` (specialty longest) | — |\n| `T_Assign_L` | — | **Policy layer, §5** |\n| `T_StartFill_L` | — | `P_LineOpen_L` ∧ ¬`P_Down_L` ∧ batch present in `P_Tank_L` ∧ `lastSKU` prep matches job (no changeover outstanding) ∧ `sku ∈ qualified(L)` |\n| `T_EndFill_L` | `qty / rate[sku][L]` | — |\n| **`T_Interrupt_L`** | — | Fires at line close if fill incomplete; fill **pauses**, resumes at next open *(assumption: fills are interruptible at shift end — flag if wrong)* |\n\n## 4.3 Changeover — the detailed part\n\n| Transition | Delay | Resource | Guard |\n|---|---|---|---|\n| `T_RaiseChangeover_L` | — | — | Next job's prep ≠ line's current prep. **Deferred by wait-rule W, §5.2** |\n| `T_StartRinse_L` | — | none | `class(from,to) = OPERATOR` ∧ `P_LineOpen_L` |\n| `T_EndRinse_L` | 25 min | — | — |\n| `T_StartWash_L` | — | **n(from,to) tech tokens** | `P_TechShiftOpen` ∧ `P_Techs ≥ n` ∧ **`now + dur ≤ 14:00 + grace(15 min)`** (C8) ∧ **VW-02 guard (C12)** |\n| `T_EndWash_L` | `dur(from,to)` | releases techs | — |\n\n### Changeover matrix\n\nDuration in minutes / resource class / techs required.\n\n| From ↓ To → | WHITE | TINT light (1–2) | TINT dark (3–5) | SPECIALTY |\n|---|---|---|---|---|\n| **WHITE** | 25 / op | 45 / tech ×1 | 45 / tech ×1 | 120 / tech ×2 |\n| **TINT light** | **180 / tech ×2** | 25 / op | 25 / op | 120 / tech ×2 |\n| **TINT dark** | **180 / tech ×2** | **`D` = 60 / class ? — A2** | 25 / op | 120 / tech ×2 |\n| **SPECIALTY** | 120 / tech ×2 | 120 / tech ×2 | 120 / tech ×2 | 25 / op |\n\n**Hard guard, not a duration:** `to_sku = VW-02 ∧ from_shade ≥ 4` → transition disabled. No wash clears it.\n\n### Latest feasible start (derived from C4 + C8)\n\n| Changeover | Duration | Latest start |\n|---|---|---|\n| White → tint | 45 | **13:15** |\n| Specialty in/out | 120 | **12:00** |\n| Tint → white | 180 | **11:00** |\n| Rinse (operator) | 25 | any time the line is open |\n\n**Consequence, hard-coded by the calendar:** after 13:15, no line can cross families until 06:00 next day. Lines 1 and 2 run to 22:00 locked to whatever family they held at lunchtime.\n\n## 4.4 Failure and QA\n\n| Transition | Delay | Notes |\n|---|---|---|\n| `T_Fail_L` | `Exp(MTBF_L)` | A6/A8. Line 1 mill motor is a **scenario injection**, not sampled (A7) |\n| `T_Repair_L` | `Tri(min,mode,max)` | Fill resumes where interrupted |\n| `T_QAStart` | — | `P_Lab ≥ 1` ∧ `P_LabOpen` |\n| `T_QAEnd` | 240 min; 1440 specialty | — |\n| `T_Ship` | — | `lateness = max(0, now − dueTime)` recorded by tier |\n\n---\n\n# 5. Policy layer\n\nThis is what you tune. Everything above is plant physics; everything here is a decision.\n\n## 5.1 Baseline — reproduces you\n\n```\n1. Meridian white orders  → Line 2 (C10, absolute)\n2. Specialty orders       → Line 1 (C11, currently the only qualified line)\n3. Otherwise: prefer the line whose lastFamily == order.family\n              tie-break: earliest available\n4. Within line: sort by TIER (Meridian, Distributor, Small), then dueTime\n5. Overnight-strand rule: do not start a job that ends after the\n   tech window if it leaves the line needing a wash\n6. VW-02 guard (C12)\n```\n\n## 5.2 Variants to race against it\n\n| Variant | Description | Answers |\n|---|---|---|\n| **Wait-rule `W(t)`** | Hold line idle up to `W` hours for a same-family order rather than raise a wash. **Time-of-day dependent** — after 13:15 the choice doesn't exist, so sweep only 06:00–13:15. | **Q2** |\n| **Fill-the-shift** | Do not commit a morning family switch unless there is enough work in that family to run through line close | Q2/Q3 |\n| **Breakdown reflex A/B/C** | A: push all to remaining lines. B: hold the tint block, pull whites forward. C: split across 1 & 3, absorb the specialty changeover. | **Q1** |\n| **Tech shift position** | 06:00–14:00 (status quo) / 10:00–18:00 / 14:00–22:00 / one tech per shift | Q3 + headcount case |\n| **Third tech** | Add one head to the existing window | Q3 |\n| **Line 3 OT** | Purchasable lever, 0–5 days/week | Q1 |\n| **Meridian-priority QA** | Non-FIFO lab queue | Free OTIF experiment |\n\n**Note on the split-shift arm:** with one tech per shift, no ≥120-min wash can ever run (they need two). I expect that arm to fail badly. Run it anyway — showing your ops director *why* a cheap option fails is worth more than asserting it, and it demonstrates you looked at rota changes before asking for headcount.\n\n---\n\n# 6. KPIs\n\n## 6.1 Service (primary)\n\n| Metric | Definition |\n|---|---|\n| **Meridian late count** | Any lot shipped after `dueTime`. Target zero (C13) |\n| Distributor late | Shipped > 48 h after due |\n| Small-account late | Shipped > 168 h after due |\n| Meridian lateness hours | Total, for severity |\n\n## 6.2 Changeover — reported as three separate numbers\n\n**Do not merge these.** A single \"dirty hours\" figure will be attacked as inflated the first time someone notices it counts unscheduled hours.\n\n| Metric | Definition | Framing |\n|---|---|---|\n| Clock-dirty hours | Wall-clock from changeover raised to complete | Report, label **not a loss** |\n| Wash hours | Actual cleaning time | Largely unavoidable |\n| **Lost production hours** | Dirty time that overlapped **scheduled line hours** | **The number to argue with** |\n| — split by cause | `techs_off_shift` vs `techs_busy_elsewhere` | Different fixes: rota vs headcount |\n| **Family-lock hours** | Per line per day, time during which no family switch is possible | Explains *why* the losses occurred |\n| Family switches per week | Plant-wide count | Validation target |\n\n*Worked example — wash raised 14:30 on Line 2, executed 06:00–09:00:*\nclock-dirty 18.5 h · wash 3 h · **lost production 7.5 h** (cause: techs off shift).\n\n## 6.3 Secondary\n\nRamp scrap units (by changeover type) · per-line utilisation · **tank-blocked hours** (Flag 2) · tech utilisation % of the 16 tech-hours/day · QA queue length, Fri/Mon split.\n\n---\n\n# 7. How to use it\n\n## 7.1 Run this first — the reproduction check\n\nBefore any experiment, before anything goes to your ops director:\n\n| Check | Target | If it misses |\n|---|---|---|\n| Weekly output per line | Within ±10% of ERP actuals | Rate matrix or tank capacity wrong |\n| Family switches/week | Your estimate: ~8 | Changeover matrix or policy wrong |\n| Late-order pattern by tier | Matches history | Priority logic wrong |\n| Line 3 idle mornings | Should appear spontaneously | Tech contention modelled wrong |\n\n**If it misses, that is the finding.** The gap points at a register row and we fix the model before it says anything about Tuesdays.\n\n## 7.2 Then, in order\n\n1. **Q3 — where do changeover hours go.** Baseline only. Decompose lost production hours by cause and by line. Cheapest result, no new policy needed.\n2. **Q2 — the wait-vs-wash question.** Sweep `W(t)`. Expected output shape: *\"before 09:00 wait up to N hours; 09:00–11:00 never wait; after 11:00 wait as long as you like.\"*\n3. **Q1 — the breakdown reflex.** Inject Line 2 failure at 06:00 Tue, Line 1 mill motor at 06:00 Mon (4 days). Race reflexes A/B/C over 30 reps. Output is a rule, not a schedule.\n4. **Rota and headcount.** Only after the tick sheet lands.\n\n## 7.3 The Line 1 tank inversion — after the stopwatch, not before\n\nFix Line 1's fill rate to the measured value. Sweep K₁ downward. Find the largest K₁ that reproduces observed blocking.\n\n- If that K₁ is **below** the spec-sheet volume → the tank is not the constraint; the rate is.\n- If it is **at or above** → your instinct holds.\n\nWithout the measured rate, both parameters are free and the inversion identifies neither. It will still produce a confident-looking answer. Do not use it.\n\n---\n\n# 8. Parameter file\n\nEverything below is data, not structure. Hand this to whoever fills it in; the net does not change.\n\n```csv\n# === lines.csv ===\nline_id,open_time,close_time,ot_available,mtbf_hours,repair_min,repair_mode,repair_max,tank_capacity_K\n1,06:00,22:00,no,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,PLACEHOLDER,K1_PLACEHOLDER\n2,06:00,22:00,no,240,30,90,240,K2_PLACEHOLDER\n3,06:00,14:00,yes_signoff,99999,0,0,0,K3_PLACEHOLDER\n\n# === skus.csv ===\nsku_id,family,shade,qual_L1,qual_L2,qual_L3\nVW-01,WHITE,0,1,1,1\nVW-02,WHITE,0,1,1,1          # C12 guard applies\nT-01..T-09,TINT,1..5,1,1,mostly-1   # two deep reds = 0 on L3 (A16)\nS-01..S-03,SPECIALTY,X,1,0,0        # C11: L1 only in practice\n\n# === rates.csv ===   units/hr, PLACEHOLDER = A14\nsku_id,rate_L1,rate_L2,rate_L3\n\n# === changeover.csv ===\nfrom_family,from_shade,to_family,to_shade,minutes,resource,techs\nWHITE,*,WHITE,*,25,OPERATOR,0\nWHITE,*,TINT,*,45,TECH,1\nWHITE,*,SPECIALTY,*,120,TECH,2\nTINT,*,WHITE,*,180,TECH,2\nTINT,1-2,TINT,*,25,OPERATOR,0\nTINT,3-5,TINT,3-5,25,OPERATOR,0\nTINT,3-5,TINT,1-2,60,UNKNOWN,?     # A2 — sweep 25..180, both resource classes\nTINT,*,SPECIALTY,*,120,TECH,2\nSPECIALTY,*,*,*,120,TECH,2\nSPECIALTY,*,SPECIALTY,*,25,OPERATOR,0\n\n# === ramp_scrap.csv ===   A5 — swept, not asserted\nchangeover_type,scrap_units\nsame_family,0\nwhite_to_tint,SWEEP_0_200\nspecialty_switch,SWEEP_0_200\ntint_to_white,SWEEP_0_400\n\n# === resources.csv ===\nresource,count,open,close\ntech,2,06:00,14:00\nlab,2,PLACEHOLDER,PLACEHOLDER      # A10\n\n# === tiers.csv ===\ntier,tolerance_hours\nMERIDIAN,0\nDISTRIBUTOR,48\nSMALL,168\n```\n\n---\n\n# 9. PNML\n\n**Dialect note.** Your tooling question never came back, so this is built to load anywhere: the graph structure is plain P/T-net so any PNML reader will open it, and all colour, guard, timing and resource information is carried in `<toolspecific>` blocks and inscriptions. If your tool is coloured + timed, map the annotations onto the colour sets in §2 — that is a mechanical translation, roughly an hour's work. If it is plain P/T, the net runs as-is with `SHADE` folded out; you lose the `D` question and the VW-02 guard has to become a separate forbidden-pair place per SKU.\n\n**Coverage.** Shared resources, the calendar subnet, and **Line 1 in full**. Lines 2 and 3 are structurally identical: duplicate the `_L1` block, change the id suffix, and substitute from `lines.csv`. I've done it this way so the file stays readable — a 3× copy is ten minutes of work and impossible to get wrong, whereas a 900-line file nobody reads is a different kind of risk.\n\n```xml\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<pnml xmlns=\"http://www.pnml.org/version-2009/grammar/pnml\">\n  <net id=\"coatings_sched_v1\"\n       type=\"http://www.pnml.org/version-2009/grammar/ptnet\">\n    <name><text>Coatings Plant Scheduling Model v1.0</text></name>\n    <toolspecific tool=\"spec\" version=\"1.0\">\n      <timeUnit>minutes</timeUnit>\n      <runLength>60480</runLength>\n      <warmup>10080</warmup>\n      <replications>30</replications>\n      <note>Colour sets, guards and policy layer defined in accompanying\n            spec sections 2-5. Parameter values in parameter file section 8.\n            UNVALIDATED assumptions listed on page one.</note>\n    </toolspecific>\n    <page id=\"top\">\n\n      <!-- ============ CALENDAR SUBNET ============ -->\n      <place id=\"P_Clock\">\n        <name><text>Calendar cycle</text></name>\n        <initialMarking><text>1</text></initialMarking>\n        <graphics><position x=\"40\" y=\"40\"/></graphics>\n      </place>\n      <place id=\"P_TechShiftOpen\">\n        <name><text>Tech shift open 06:00-14:00</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"200\" y=\"40\"/></graphics>\n      </place>\n      <place id=\"P_LineOpen_L1\">\n        <name><text>Line 1 open 06:00-22:00</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"360\" y=\"40\"/></graphics>\n      </place>\n      <place id=\"P_LineOpen_L2\">\n        <name><text>Line 2 open 06:00-22:00</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"520\" y=\"40\"/></graphics>\n      </place>\n      <place id=\"P_LineOpen_L3\">\n        <name><text>Line 3 open 06:00-14:00 (OT lever)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"680\" y=\"40\"/></graphics>\n      </place>\n      <place id=\"P_LabOpen\">\n        <name><text>Lab open (A10 UNVALIDATED)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"840\" y=\"40\"/></graphics>\n      </place>\n\n      <transition id=\"T_ShiftStart\">\n        <name><text>06:00 daily open</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <schedule>daily 06:00, weekdays</schedule>\n          <effect>mark P_TechShiftOpen, P_LineOpen_L1/2/3, P_LabOpen;\n                  move 2 tokens P_TechsOff -> P_Techs</effect>\n        </toolspecific>\n        <graphics><position x=\"120\" y=\"120\"/></graphics>\n      </transition>\n      <transition id=\"T_TechShiftEnd\">\n        <name><text>14:00 tech shift end</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <schedule>daily 14:00</schedule>\n          <effect>unmark P_TechShiftOpen; free techs -> P_TechsOff</effect>\n        </toolspecific>\n        <graphics><position x=\"280\" y=\"120\"/></graphics>\n      </transition>\n      <transition id=\"T_Line3Close\">\n        <name><text>14:00 Line 3 close</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <schedule>daily 14:00 unless OT lever set</schedule>\n        </toolspecific>\n        <graphics><position x=\"440\" y=\"120\"/></graphics>\n      </transition>\n      <transition id=\"T_Line12Close\">\n        <name><text>22:00 Lines 1-2 close</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <schedule>daily 22:00</schedule>\n        </toolspecific>\n        <graphics><position x=\"600\" y=\"120\"/></graphics>\n      </transition>\n\n      <arc id=\"a01\" source=\"P_Clock\" target=\"T_ShiftStart\"/>\n      <arc id=\"a02\" source=\"T_ShiftStart\" target=\"P_TechShiftOpen\"/>\n      <arc id=\"a03\" source=\"T_ShiftStart\" target=\"P_LineOpen_L1\"/>\n      <arc id=\"a04\" source=\"T_ShiftStart\" target=\"P_LineOpen_L2\"/>\n      <arc id=\"a05\" source=\"T_ShiftStart\" target=\"P_LineOpen_L3\"/>\n      <arc id=\"a06\" source=\"T_ShiftStart\" target=\"P_LabOpen\"/>\n      <arc id=\"a07\" source=\"P_TechShiftOpen\" target=\"T_TechShiftEnd\"/>\n      <arc id=\"a08\" source=\"P_LineOpen_L3\" target=\"T_Line3Close\"/>\n      <arc id=\"a09\" source=\"P_LineOpen_L1\" target=\"T_Line12Close\"/>\n      <arc id=\"a10\" source=\"P_LineOpen_L2\" target=\"T_Line12Close\"/>\n      <arc id=\"a11\" source=\"T_Line12Close\" target=\"P_Clock\"/>\n\n      <!-- ============ SHARED RESOURCES ============ -->\n      <place id=\"P_Techs\">\n        <name><text>Techs on shift and free</text></name>\n        <initialMarking><text>2</text></initialMarking>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <lever>count = 2 (baseline) | 3 (third-tech arm)</lever>\n        </toolspecific>\n        <graphics><position x=\"200\" y=\"220\"/></graphics>\n      </place>\n      <place id=\"P_TechsOff\">\n        <name><text>Techs off shift</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"200\" y=\"300\"/></graphics>\n      </place>\n      <place id=\"P_Lab\">\n        <name><text>Lab capacity</text></name>\n        <initialMarking><text>2</text></initialMarking>\n        <graphics><position x=\"840\" y=\"220\"/></graphics>\n      </place>\n      <place id=\"P_Demand\">\n        <name><text>Order arrivals (ERP stream)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <colour>ORDER = id,sku,qty,tier,dueTime</colour>\n          <source>ERP export, 4-6 weeks. A17 until loaded.</source>\n        </toolspecific>\n        <graphics><position x=\"40\" y=\"380\"/></graphics>\n      </place>\n      <place id=\"P_Ready\">\n        <name><text>Released, awaiting assignment</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"180\" y=\"380\"/></graphics>\n      </place>\n\n      <transition id=\"T_Release\">\n        <name><text>Release order</text></name>\n        <graphics><position x=\"110\" y=\"380\"/></graphics>\n      </transition>\n      <arc id=\"a12\" source=\"P_Demand\" target=\"T_Release\"/>\n      <arc id=\"a13\" source=\"T_Release\" target=\"P_Ready\"/>\n\n      <!-- ============ LINE 1 SUBNET ============ -->\n      <!-- duplicate this block for L2, L3; substitute ids and parameters -->\n\n      <place id=\"P_UpIdle_L1\">\n        <name><text>L1 upstream idle (mix/mill/tint)</text></name>\n        <initialMarking><text>1</text></initialMarking>\n        <graphics><position x=\"300\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_UpBusy_L1\">\n        <name><text>L1 upstream in progress</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"380\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_Tank_L1\">\n        <name><text>L1 holding tank (DISPUTED CAPACITY - A15)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <capacity>K1 = PLACEHOLDER</capacity>\n          <note>Flag 2. Do not run the inversion before Line 1 fill rate\n                is measured with a non-empty tank.</note>\n        </toolspecific>\n        <graphics><position x=\"460\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_TankFree_L1\">\n        <name><text>L1 tank free slots</text></name>\n        <initialMarking><text>K1</text></initialMarking>\n        <graphics><position x=\"460\" y=\"540\"/></graphics>\n      </place>\n      <place id=\"P_LineIdle_L1\">\n        <name><text>L1 idle, carrying lastSKU/lastFamily/lastShade</text></name>\n        <initialMarking><text>1</text></initialMarking>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <colour>LINESTATE = lineId,lastSKU,lastFamily,lastShade,up</colour>\n        </toolspecific>\n        <graphics><position x=\"560\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_LineFilling_L1\">\n        <name><text>L1 filling</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"660\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_ChangeoverDue_L1\">\n        <name><text>L1 changeover raised, not started</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"560\" y=\"620\"/></graphics>\n      </place>\n      <place id=\"P_Rinsing_L1\">\n        <name><text>L1 rinsing (operator, no tech)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"480\" y=\"700\"/></graphics>\n      </place>\n      <place id=\"P_Washing_L1\">\n        <name><text>L1 washing (tech, QA signoff)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"640\" y=\"700\"/></graphics>\n      </place>\n      <place id=\"P_Down_L1\">\n        <name><text>L1 down</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"760\" y=\"540\"/></graphics>\n      </place>\n\n      <transition id=\"T_Assign_L1\">\n        <name><text>Assign order to L1</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>POLICY LAYER - spec section 5.\n                 Baseline: Meridian white -> L2 only; specialty -> L1;\n                 else prefer matching lastFamily; sort TIER then dueTime.</guard>\n        </toolspecific>\n        <graphics><position x=\"240\" y=\"380\"/></graphics>\n      </transition>\n      <transition id=\"T_UpStart_L1\">\n        <name><text>L1 start upstream</text></name>\n        <graphics><position x=\"340\" y=\"460\"/></graphics>\n      </transition>\n      <transition id=\"T_UpEnd_L1\">\n        <name><text>L1 end upstream</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>upstream_time[family]; specialty slowest (thick, slow mill)</delay>\n        </toolspecific>\n        <graphics><position x=\"420\" y=\"460\"/></graphics>\n      </transition>\n      <transition id=\"T_StartFill_L1\">\n        <name><text>L1 start fill</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>P_LineOpen_L1 marked AND NOT P_Down_L1 AND batch in tank\n                 AND no changeover outstanding AND sku qualified on L1\n                 (specialty: L1 only - C11)</guard>\n        </toolspecific>\n        <graphics><position x=\"610\" y=\"460\"/></graphics>\n      </transition>\n      <transition id=\"T_EndFill_L1\">\n        <name><text>L1 end fill</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>qty / rate[sku][L1]  (A14 placeholder)</delay>\n          <effect>emit LOT to P_QAQueue, less ramp_scrap if run followed\n                  a family switch (A5, swept)</effect>\n        </toolspecific>\n        <graphics><position x=\"720\" y=\"460\"/></graphics>\n      </transition>\n      <transition id=\"T_RaiseChangeover_L1\">\n        <name><text>L1 raise changeover</text\n```xml\n      <transition id=\"T_RaiseChangeover_L1\">\n        <name><text>L1 raise changeover</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>next job prep != line current prep</guard>\n          <delay>DEFERRED by wait-rule W(t) - spec 5.2.\n                 Morning only; after 13:15 the choice does not exist.</delay>\n        </toolspecific>\n        <graphics><position x=\"560\" y=\"540\"/></graphics>\n      </transition>\n      <transition id=\"T_StartRinse_L1\">\n        <name><text>L1 start rinse (operator)</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>class(from,to) = OPERATOR AND P_LineOpen_L1 marked</guard>\n          <note>C5 - no tech token consumed. Available to 22:00.</note>\n        </toolspecific>\n        <graphics><position x=\"480\" y=\"620\"/></graphics>\n      </transition>\n      <transition id=\"T_EndRinse_L1\">\n        <name><text>L1 end rinse</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>25</delay>\n        </toolspecific>\n        <graphics><position x=\"400\" y=\"700\"/></graphics>\n      </transition>\n      <transition id=\"T_StartWash_L1\">\n        <name><text>L1 start wash (tech)</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>class(from,to) = TECH\n                 AND P_TechShiftOpen marked\n                 AND P_Techs >= n(from,to)\n                 AND now + dur(from,to) &lt;= 14:00 + grace(15)   [C8]\n                 AND NOT (to_sku = VW-02 AND from_shade &gt;= 4)   [C12]</guard>\n          <consumes>n(from,to) tokens from P_Techs</consumes>\n        </toolspecific>\n        <graphics><position x=\"640\" y=\"620\"/></graphics>\n      </transition>\n      <transition id=\"T_EndWash_L1\">\n        <name><text>L1 end wash</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>dur(from,to) per changeover matrix, spec 4.3</delay>\n          <effect>release n techs to P_Techs; set lastFamily/lastShade := to</effect>\n        </toolspecific>\n        <graphics><position x=\"720\" y=\"700\"/></graphics>\n      </transition>\n      <transition id=\"T_Fail_L1\">\n        <name><text>L1 fail</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>Exp(MTBF_L1) - A6 PLACEHOLDER</delay>\n          <note>A7: mill motor 4-day outage is a SCENARIO INJECTION,\n                not sampled. Too rare for a 6-week run.</note>\n        </toolspecific>\n        <graphics><position x=\"800\" y=\"460\"/></graphics>\n      </transition>\n      <transition id=\"T_Repair_L1\">\n        <name><text>L1 repair</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>Tri(min,mode,max) - A6</delay>\n          <effect>fill resumes from interruption point</effect>\n        </toolspecific>\n        <graphics><position x=\"800\" y=\"620\"/></graphics>\n      </transition>\n      <transition id=\"T_Interrupt_L1\">\n        <name><text>L1 shift-end interrupt</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <schedule>fires at line close if fill incomplete</schedule>\n          <note>ASSUMPTION: fills are interruptible at shift end and resume\n                next open. Never confirmed - flag if wrong.</note>\n        </toolspecific>\n        <graphics><position x=\"720\" y=\"380\"/></graphics>\n      </transition>\n\n      <arc id=\"b01\" source=\"P_Ready\" target=\"T_Assign_L1\"/>\n      <arc id=\"b02\" source=\"T_Assign_L1\" target=\"P_UpIdle_L1\"/>\n      <arc id=\"b03\" source=\"P_UpIdle_L1\" target=\"T_UpStart_L1\"/>\n      <arc id=\"b04\" source=\"P_TankFree_L1\" target=\"T_UpStart_L1\"/>\n      <arc id=\"b05\" source=\"T_UpStart_L1\" target=\"P_UpBusy_L1\"/>\n      <arc id=\"b06\" source=\"P_UpBusy_L1\" target=\"T_UpEnd_L1\"/>\n      <arc id=\"b07\" source=\"T_UpEnd_L1\" target=\"P_Tank_L1\"/>\n      <arc id=\"b08\" source=\"T_UpEnd_L1\" target=\"P_UpIdle_L1\"/>\n      <arc id=\"b09\" source=\"P_Tank_L1\" target=\"T_StartFill_L1\"/>\n      <arc id=\"b10\" source=\"P_LineIdle_L1\" target=\"T_StartFill_L1\"/>\n      <arc id=\"b11\" source=\"P_LineOpen_L1\" target=\"T_StartFill_L1\">\n        <inscription><text>test arc - not consumed</text></inscription>\n      </arc>\n      <arc id=\"b12\" source=\"T_StartFill_L1\" target=\"P_LineFilling_L1\"/>\n      <arc id=\"b13\" source=\"T_StartFill_L1\" target=\"P_TankFree_L1\"/>\n      <arc id=\"b14\" source=\"P_LineFilling_L1\" target=\"T_EndFill_L1\"/>\n      <arc id=\"b15\" source=\"T_EndFill_L1\" target=\"P_LineIdle_L1\"/>\n      <arc id=\"b16\" source=\"T_EndFill_L1\" target=\"P_QAQueue\"/>\n      <arc id=\"b17\" source=\"P_LineIdle_L1\" target=\"T_RaiseChangeover_L1\"/>\n      <arc id=\"b18\" source=\"T_RaiseChangeover_L1\" target=\"P_ChangeoverDue_L1\"/>\n      <arc id=\"b19\" source=\"P_ChangeoverDue_L1\" target=\"T_StartRinse_L1\"/>\n      <arc id=\"b20\" source=\"T_StartRinse_L1\" target=\"P_Rinsing_L1\"/>\n      <arc id=\"b21\" source=\"P_Rinsing_L1\" target=\"T_EndRinse_L1\"/>\n      <arc id=\"b22\" source=\"T_EndRinse_L1\" target=\"P_LineIdle_L1\"/>\n      <arc id=\"b23\" source=\"P_ChangeoverDue_L1\" target=\"T_StartWash_L1\"/>\n      <arc id=\"b24\" source=\"P_Techs\" target=\"T_StartWash_L1\">\n        <inscription><text>n(from,to)  [1 or 2]</text></inscription>\n      </arc>\n      <arc id=\"b25\" source=\"P_TechShiftOpen\" target=\"T_StartWash_L1\">\n        <inscription><text>test arc - not consumed</text></inscription>\n      </arc>\n      <arc id=\"b26\" source=\"T_StartWash_L1\" target=\"P_Washing_L1\"/>\n      <arc id=\"b27\" source=\"P_Washing_L1\" target=\"T_EndWash_L1\"/>\n      <arc id=\"b28\" source=\"T_EndWash_L1\" target=\"P_LineIdle_L1\"/>\n      <arc id=\"b29\" source=\"T_EndWash_L1\" target=\"P_Techs\">\n        <inscription><text>n(from,to)</text></inscription>\n      </arc>\n      <arc id=\"b30\" source=\"P_LineFilling_L1\" target=\"T_Fail_L1\"/>\n      <arc id=\"b31\" source=\"T_Fail_L1\" target=\"P_Down_L1\"/>\n      <arc id=\"b32\" source=\"P_Down_L1\" target=\"T_Repair_L1\"/>\n      <arc id=\"b33\" source=\"T_Repair_L1\" target=\"P_LineFilling_L1\"/>\n      <arc id=\"b34\" source=\"P_LineFilling_L1\" target=\"T_Interrupt_L1\"/>\n      <arc id=\"b35\" source=\"T_Interrupt_L1\" target=\"P_LineFilling_L1\">\n        <inscription><text>paused; resumes at next line open</text></inscription>\n      </arc>\n\n      <!-- ============ QA AND SHIPPING ============ -->\n      <place id=\"P_QAQueue\">\n        <name><text>Awaiting QA (post-fill hold)</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <note>C9 - delays shipment only, does not block upstream.\n                Watch Fri/Mon queue length: your Friday slip mechanism.</note>\n        </toolspecific>\n        <graphics><position x=\"900\" y=\"380\"/></graphics>\n      </place>\n      <place id=\"P_InQA\">\n        <name><text>In QA</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"900\" y=\"460\"/></graphics>\n      </place>\n      <place id=\"P_Shipped\">\n        <name><text>Shipped</text></name>\n        <initialMarking><text>0</text></initialMarking>\n        <graphics><position x=\"900\" y=\"620\"/></graphics>\n      </place>\n\n      <transition id=\"T_QAStart\">\n        <name><text>Start QA</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <guard>P_Lab >= 1 AND P_LabOpen marked</guard>\n          <policy>BASELINE FIFO (A10). Variant: Meridian-priority queue.</policy>\n        </toolspecific>\n        <graphics><position x=\"900\" y=\"420\"/></graphics>\n      </transition>\n      <transition id=\"T_QAEnd\">\n        <name><text>End QA</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <delay>240 min; 1440 min if family = SPECIALTY</delay>\n        </toolspecific>\n        <graphics><position x=\"900\" y=\"500\"/></graphics>\n      </transition>\n      <transition id=\"T_Ship\">\n        <name><text>Ship and record lateness</text></name>\n        <toolspecific tool=\"spec\" version=\"1.0\">\n          <effect>lateness = max(0, now - dueTime); bucket by TIER;\n                  MERIDIAN tolerance 0, DISTRIBUTOR 2880, SMALL 10080 min</effect>\n        </toolspecific>\n        <graphics><position x=\"900\" y=\"570\"/></graphics>\n      </transition>\n\n      <arc id=\"c01\" source=\"P_QAQueue\" target=\"T_QAStart\"/>\n      <arc id=\"c02\" source=\"P_Lab\" target=\"T_QAStart\"/>\n      <arc id=\"c03\" source=\"T_QAStart\" target=\"P_InQA\"/>\n      <arc id=\"c04\" source=\"P_InQA\" target=\"T_QAEnd\"/>\n      <arc id=\"c05\" source=\"T_QAEnd\" target=\"P_Lab\"/>\n      <arc id=\"c06\" source=\"T_QAEnd\" target=\"P_Shipped\"/>\n      <arc id=\"c07\" source=\"P_Shipped\" target=\"T_Ship\"/>\n\n    </page>\n  </net>\n</pnml>\n```\n\n---\n\n# 10. Building Lines 2 and 3\n\nCopy the Line 1 block; change the `_L1` suffix throughout; substitute from `lines.csv`. The only structural differences:\n\n| | Line 2 | Line 3 |\n|---|---|---|\n| Calendar place | `P_LineOpen_L2`, 06:00–22:00 | `P_LineOpen_L3`, 06:00–**14:00** |\n| Qualification | Specialty SKUs excluded (C11) | Specialty excluded; two deep-red tints excluded (A16) |\n| Assignment guard | **Meridian whites forced here** (C10) | No forced work |\n| Failure | MTBF ≈ 240 h, repair Tri(30,90,240) (A6) | Zero (A8) |\n| OT lever | none | `T_Line3Close` deferred to 22:00 when set |\n\n**One consequence worth checking against the model's own output:** Line 3's entire operating day sits inside the tech window. Its changeovers compete head-on with the morning wash queue for Lines 1 and 2. A tint→white wash starting 06:00 on Line 2 holds both techs to 09:00, during which Line 3 cannot cross families — three of its eight hours, clean and staffed and waiting. If that pattern doesn't emerge spontaneously in the reproduction check, the tech contention is modelled wrong.\n\n---\n\n# 11. What happens next\n\n**Blocking, from you:** spreadsheet, rate matrix, ERP export. Nothing runs until the rate matrix lands — `A14` placeholders make every duration in the model fictional.\n\n**Then, in order:** reproduction check (§7.1) → Q3 decomposition → Q2 sweep → Q1 reflexes. Rota and headcount arms only after the tick sheet.\n\n**Send early, don't batch:** any tick-sheet row showing an operator performing a family switch. That retires A19, changes a hard guard, and I'd rather rework in week one than build a fortnight on it.\n\n**Still unanswered:** the PNML dialect, A10 (lab hours and queue discipline — I never asked and it drives your Friday slips), A15 (tank capacities), whether fills are interruptible at shift end (§4.2), and A16 (which two tints Line 3 can't run).\n\n---\n\n# 12. Two lines that don't depend on any of this\n\nBoth fall out of your own shift pattern — C3, C4, C6, C8 — not from anything I've modelled. They were true before this document existed and stay true whatever the data says:\n\n> **After 13:15, no line can cross families. The morning decides the day.**\n\n> **A wash raised at 22:00 costs nothing. One raised at 14:30 costs the evening.**\n\nEverything else in here — the switches-per-week ceiling, the capacity-versus-timing hypothesis, Line 3's idle mornings, and every number in §8 — is arithmetic on recollection. Hold it back until the sheet earns it."
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2-model.txt b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2-model.txt
new file mode 100644
index 00000000000..cefb65f278d
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2-model.txt
@@ -0,0 +1,296 @@
+# COATINGS PLANT SCHEDULING MODEL — FINAL DELIVERABLE
+
+Complete and self-contained. Hand Section A to your modelling person; keep Section B for yourself.
+
+---
+
+# A. THE MODEL
+
+A **coloured, timed Petri net with priority-resolved conflicts**. Tokens are *batches*; token colours carry order attributes; transitions are timed; shared resources and calendars are capacity-limited places.
+
+## A.0 Experiment switches
+
+| Switch | Values | Default | Purpose |
+|---|---|---|---|
+| `TIME_BASIS` | `SHEET` / `GUT` | `GUT` | Matrix standard times vs your padding |
+| `CO_GRANULARITY` | `WHOLE_LINE` / `CASCADE` / `SPLIT_BY_SIZE` | `SPLIT_BY_SIZE` | Whole-line for washdowns ≥2 h, cascade for rinses <1 h *(unresolved)* |
+| `CREW_MODE` | `ONE_SERVER` / `SPLIT_ON_RINSE` | `ONE_SERVER` | Can the two techs run two rinses at once *(unresolved)* |
+| `RELEASE_POLICY` | `TRUCK_CONFIRMED` / `STANDING_MERIDIAN` | `TRUCK_CONFIRMED` | The logistics lever |
+| `SAT_LAB_COVER` | `OFF` / `ON` | `OFF` | Does Saturday OT include a lab analyst |
+| `SEQ_RULE` | `CAMPAIGN_FIRST` / `DUE_DATE_FIRST` / `CAMPAIGN_WITH_MERIDIAN_OVERRIDE` | `CAMPAIGN_FIRST` | Your current policy is default |
+| `EOW_CHARGE` | `ON` / `OFF` | `ON` | End-of-week dirty-line charge; OFF lets the model cheat |
+
+## A.1 Colour sets
+
+```
+FAMILY  = { WHITE, TINT, SPECIALTY }
+DEPTH   = { NA, LIGHT, DARK }
+ACCOUNT = { MERIDIAN, OTHER }
+LINE    = { L1, L2, L3 }
+
+SKU     = { skuId, family, depth, meridianQual, l3Qual }
+ORDER   = { oid, account, sku, qty, bookTime, releaseTime, promiseTime,
+            wholeWeek, line, nBatches }
+BATCH   = { oid, idx, of, units, sku, account, promiseTime, testFlag, startedAt }
+SETUP   = { line, sku, family, depth }
+TECH, ANALYST = unit tokens
+```
+
+## A.2 Places
+
+**Order level:** `P_Book` → `P_Allocated` → `P_Releasable` → `P_OrderDone` → `P_Shipped` (all ∞).
+
+**Per line L ∈ {L1,L2,L3}:**
+
+| Place | Cap |
+|---|---|
+| `P_MixQueue_L` | ∞ |
+| `P_Mixing_L` | 1 |
+| `P_Tank_MixMill_L` | TANKCAP |
+| `P_Milling_L` | 1 |
+| `P_Tank_MillFill_L` | **L1 = 1** (your backup), L2/L3 = 2 |
+| `P_Tinting_L` | 1 |
+| `P_Tank_TintFill_L` | TANKCAP |
+| `P_Filling_L` | 1 |
+| `P_SetupState_L` | 1 (what the line is dressed for) |
+| `P_LineIdleClean_L` | 1 iff all stages empty |
+| `P_LineUp_L` | 1 iff not broken down |
+| `P_ShiftOpen_L` | 1 iff shift manned |
+| `P_COinProgress_L` | 1 during whole-line changeover |
+
+**Shared:** `P_CrewPool` (2 TECH), `P_CrewShift` (1 — its *absence* is the 2 a.m. black hole), `P_QAHold` (∞), `P_LabAnalysts` (2), `P_LabShift` (1 — its absence is the Friday-evening trap), `P_Testing` (2), `P_QAReleased` (∞), `P_JumpBudget` (0.6 tokens/wk).
+
+## A.3 Transitions
+
+### Arrival and release
+
+| Transition | Trigger | Effect |
+|---|---|---|
+| `T_BookLands` | Sun 23:00 weekly | ~40 ORDERs → `P_Book` |
+| `T_Allocate` | Mon 07:00 | Sets `line` (guards below), `nBatches = ceil(qty/VESSEL(line))` → `P_Allocated` |
+| `T_ERPRelease` | at `releaseTime` | → `P_Releasable`. **This transition is what creates your idle-vs-washdown dilemma.** Under `STANDING_MERIDIAN`, Meridian releases at allocation instead |
+| `T_Explode` | line queue accepts | Emits `nBatches` BATCH tokens; sets `testFlag` |
+
+**Hard allocation guards:**
+```
+account = MERIDIAN      ⇒ line = L2        (audit qualification)
+family  = SPECIALTY     ⇒ line = L1        (L2 not piped for clears)
+line    = L3            ⇒ sku.l3Qual       (validated-SKU list)
+```
+
+### Production (per line, per batch)
+
+Paired `T_Start_<stage>_L` / `T_End_<stage>_L`. Start requires: batch available (per `SEQ_RULE`), stage free, `P_SetupState_L` matches SKU, `P_ShiftOpen_L`, `P_LineUp_L`, no `P_COinProgress_L`.
+`T_EndMill_L` **blocks if `P_Tank_MillFill_L` is full** — this reproduces Line 1's mill backup.
+
+**Rates (units/hour):**
+
+| Stage | WHITE | TINT | SPECIALTY |
+|---|---|---|---|
+| Mix (all) | 3600 | 3600 | 3600 |
+| Mill (all) | 2900 | 1450 | 480 (L1) |
+| Tint/letdown | 12000 | 1450 | 2400 |
+| **Fill L1** | **700** | 700 | 650 |
+| **Fill L2** | **950** | 800 | n/a |
+| **Fill L3** | **900** | 800 | n/a |
+
+This reproduces: whites fill-bound, L2 ~35% faster than L1 on whites, **L1 ≈ L2 on tints** (the thing you noticed and couldn't explain), specialty mill-bound.
+
+**Vessels (units/batch):** L1 = 1,100 · L2 = 1,650 · L3 = 1,350 *(the one you said not to quote)*.
+
+**Fill disruption — fat right tail, thin left:**
+```
+Noise      ~ LogNormal(median 1.00, σ 0.06)
+JamAdder   = 0 w.p. .90 ; U(0.33, 0.50) h w.p. .10     (filler jam)
+StallAdder = 0 w.p. .95 ; U(0.25, 1.00) h w.p. .05     (packaging/labels)
+```
+Jams and stalls kept separate — the warehouse restock may be the cheaper fix.
+
+### Changeover
+
+`T_Changeover_L` fires when the next selected batch's SKU ≠ `P_SetupState_L`.
+
+- **WHOLE_LINE** (≥2 h washdowns): requires `P_LineIdleClean_L` (line fully drained) + 2 TECH + `P_CrewShift`.
+- **CASCADE** (<1 h rinses): four sub-transitions `T_CO_{Mix,Mill,Tint,Fill}_L`, each needing only its own stage empty and 1–2 TECH per `CREW_MODE`; the new order follows the cleaning down the line.
+
+**Matrix (hours):**
+
+| From → To | SHEET | GUT |
+|---|---|---|
+| WHITE → WHITE same SKU | 0.25 | 0.25 |
+| WHITE → WHITE diff SKU | 0.42 | 0.42 |
+| WHITE → TINT | 0.75 | 0.75 |
+| TINT → TINT (light→light, dark→dark) | 0.58 | 0.58 |
+| TINT → TINT **dark→light** | 0.58 | **1.25** |
+| **TINT → WHITE** | **3.00** | **3.50** (3.75 after dark) |
+| any ↔ SPECIALTY | 2.00 | 2.00 |
+| L1 multiplier, changeovers ≥2 h | 1.00 | **1.15** |
+
+**The punitive mechanism:** because changeover needs `P_CrewShift`, a line that misses the crew window waits for the crew's **next shift start**, not for the crew to free up. Your Scenario-A Line 1 loses the whole overnight, not two hours. This emerges from the net structure — no special rule.
+
+### QA
+
+| Transition | Requires | Duration |
+|---|---|---|
+| `T_Sample` | batch in `P_QAHold`, ANALYST, `P_LabShift` | WHITE 3.5 h / TINT 4.0 / SPECIALTY 5.0, LogNormal σ 0.25 |
+| `T_Release` | test done | instant |
+| `T_Jump` | Meridian-critical + jump token | Front of queue, **non-preemptive**; `P(refuse) = min(0.8, 0.15 × jumps_this_month)` |
+
+**Sampling:** first batch always, every 3rd thereafter, **last batch always** — this is what makes an order hostage to its last batch.
+
+### Ship, score, break
+
+`T_OrderComplete` (all batches released) → `T_Ship` (at truck departure) → `T_ScoreOrder`.
+`T_EndOfWeekCharge` fires Fri 22:00, charging each line for the changeover Monday's first job would need.
+
+| Breakdown | Rate | Duration |
+|---|---|---|
+| Major outage (mill-motor class), removes `P_LineUp_L` | 0.038/line-week | LogNormal median 48 h, P90 120 h |
+| Bad filler jam, blocks `P_Filling_L` | 0.5/line-week | LogNormal median 3 h, P90 6 h |
+
+Repair progresses only during manned hours.
+
+## A.4 Calendars
+
+| Gate | Pattern |
+|---|---|
+| `P_ShiftOpen_L1/L2` | Mon–Fri 06:00–22:00 (handover mid-batch allowed) |
+| `P_ShiftOpen_L3` | Mon–Fri 06:00–14:00 |
+| `P_CrewShift` | Mon–Fri 07:00–15:30; extends 05:00–19:00 if changeover pre-arranged ≥8 h ahead |
+| `P_LabShift` | Mon–Fri 07:00–17:00 |
+| Saturday OT | Adds L1 or L2 Sat 06:00–18:00; requires trigger by Wed 17:00; **adds no lab, no crew** unless `SAT_LAB_COVER = ON` |
+| Trucks | Depart 06:00, Mon–Fri |
+
+## A.5 Policy layer (every rule swappable)
+
+**1 — Crew contention.** Key: `(Meridian-enabling DESC, earliest promise-at-risk ASC)`. **Non-preemptive.** Loser waits for crew *and* shift.
+
+**2 — Batch sequencing (`SEQ_RULE`).** `CAMPAIGN_FIRST` (yours): group by family; within campaign, earliest promise; break campaign only if a due date would actually be missed. Alternatives: pure due-date; campaign with Meridian override.
+
+**3 — Idle vs washdown** *(your headline decision, implemented literally from Q10)*:
+```
+IF (wash_away + wash_back) touches ANY Meridian ship window
+   THEN idle                                       (* the cliff *)
+ELSE IF gap_hours ≥ (wash_away + gap_job_runtime + wash_back)
+   THEN take the gap job
+ELSE idle
+```
+
+**4 — Lab queue.** FIFO, except jump tokens. Displaced work waits, and near week's end may hit the Friday trap — that is the true cost of a jump.
+
+**5 — Saturday ask.** Wed 17:00: if a Meridian order's projected completion misses its window by ≥1 shift, request OT on L1/L2. Non-Meridian shortfalls trigger nothing (your Coastal case).
+
+## A.6 Scoring — unit is one line-hour
+
+```
+Changeover      = 1.0 × changeover_hours
+Idle            = 0                        (invisible on paper; bites only via the clock)
+
+Meridian late   = 200 (step, on missing the truck) + 1.0 × hours_late
+Other late      = 0                     h ≤ 4
+                = 0.5 × (h − 4)         4 < h ≤ 24
+                = 10 + 4.0 × (h − 24)   h > 24
+Whole-week req. = ×2 on the above
+
+End-of-week     = expected changeover hours from each line's Friday state
+                  into Monday's likely first job
+```
+
+**Board metric reported separately:** binary on-time % vs promise date — so you can tell your boss what the board will say.
+
+*Calibration against your own bets:* Meridian 6 h late = 206 ≫ 4 changeover-hours → you idle. Coastal 6 h late = 1.0 < 4 → you take the tint job. Coastal 48 h late = 106 ≫ 4 → you don't. Cliff and slope, reproduced.
+
+## A.7 Experiments → your three questions
+
+| Question | Run |
+|---|---|
+| *"Line 1's mill motor takes four days — what slips?"* | Inject 96 h `P_LineUp_L1` outage at various points; compare re-allocation policies. **Watch specialty: it has nowhere to go** (guard: specialty ⇒ L1), so it appears as a hard block, not a delay |
+| *"Idle an hour or wash down?"* | Sweep Conflict-3 rule × `RELEASE_POLICY`. **Run `STANDING_MERIDIAN` first** — hypothesis is that most of these dilemmas are manufactured by release timing, not by your scheduling |
+| *"Where are my changeover hours going?"* | Changeover-hours ledger by line × transition × cause; then `SEQ_RULE` sweep; cross with `TIME_BASIS` — if your gut padding changes no decision, don't bother timing changeovers |
+| *(bonus)* | `SAT_LAB_COVER` OFF vs ON — tests whether this year's Saturdays bought you anything given a shut Monday-ward lab |
+
+**Validation when data lands:** replay 26 weeks; target (a) ~75% utilisation, (b) **30–40 changeover-hours/month** — your ops director's number, the best anchor you gave me — (c) board on-time % matching history. Low changeover-hours ⇒ `CO_GRANULARITY` or sequencing is wrong.
+
+---
+
+# B. ASSUMPTION LEDGER
+
+Mine, not yours. **Bold = load-bearing.**
+
+**Scoring**
+1. Lateness in hours vs promise date (board is binary but can't express your cliff/slope). *Check: ERP promise vs ship dates.*
+2. **Meridian = 200-hour step at "misses the truck", +1.0/h after. I defined the window as truck departure 06:00, not end-of-promise-day.** *Check: one sentence from you — several tight cases flip.*
+3. Non-Meridian: free <4 h, 0.5/h to 24 h, 4.0/h beyond. Invented shape from your Coastal answer. *Sensitivity-test the kink.*
+4. Whole-week multiplier ×2. Pure invention.
+5. Idle costs zero (your Q8). Makes arrival/due-date realism load-bearing.
+6. Changeover = pure lost line time, no wage/solvent. *Check with finance what the 40-hours line item contains.*
+7. **The 200:4 ratio was reverse-engineered from your two bets, not elicited.** *Check by putting three more of your own bets to it.*
+
+**Structure**
+8. Four stages, identical topology on all three lines (you walked me through L2 only).
+9. **Tank caps: L1 mill→fill = 1 batch, others = 2.** *Check: nameplate ÷ batch size.*
+10. Vessels 1,100 / 1,650 / 1,350 — **L3 is the one you said not to quote.** *Check: 30 seconds at the vessel.*
+11. 14 SKUs as 4 white / 8 tint / 2 specialty, tint depths assigned arbitrarily. *Check: SKU master — also tells me which tints are dark.*
+12. L3's two unqualified tint SKUs — your count, my choice of which. *Check: quality's validation list.*
+13. **Specialty on L1 only. I never asked whether L3 can run specialty — if it can, the mill-motor answer changes materially.**
+14. Meridian ⇒ L2 is absolute, no emergency override. *Check: has it ever been broken?*
+
+**Durations**
+15. **Stage rates reconstructed from your estimates. The pattern is yours; the numbers are mine.** *Check: the sheet's units/hour per product per line — direct calibration, you already have it.*
+16. Mix time identical across families/lines. Never asked; probably wrong for specialty.
+17. **The jam/stall split is entirely my decomposition** (you described both, never separated them); stall frequency invented. *Check: whether CMMS distinguishes faults from material starvation — it probably doesn't.*
+18. QA 3.5/4.0/5.0 h by family, σ 0.25 — only "about four hours for whites" is yours. *Check: lab lead, 5 min.*
+19. Sampling = first, every 3rd, **always last** (my inference from "held up by its last batch").
+20. SHEET matrix = your recollection of a spreadsheet neither of us has opened. *Check: open it.*
+21. GUT layer quantified by me from your instincts. *Check: time six changeovers — but run `TIME_BASIS` both ways first; if nothing changes, don't bother.*
+22. **`CO_GRANULARITY` unresolved — you were going to watch a rinse. This materially changes the split-across-lines answer.**
+23. **`CREW_MODE` unresolved — you'd half-noticed the techs working opposite ends. If rinses split, crew contention drops significantly.**
+
+**Policies**
+24. Crew key = Meridian-enabling, then earliest at risk; non-preemptive. *Check: has an in-progress changeover ever been abandoned?*
+25. **A line missing the crew window waits for next shift start. Most punitive mechanism in the model — it turns a 2 h changeover into a lost overnight.**
+26. **Crew flex needs ≥8 h notice — invented. Directly governs whether an evening washdown happens or waits for morning, i.e. the core of your headline decision.** *Check: ask the techs.*
+27. Jump budget 0.6/wk with rising refusal — 2–3/month is yours, the refusal curve is invented to reproduce the one time you backed off.
+28. **Saturday OT adds line hours only, no lab, no crew. The assumption I most expect to be wrong in a useful direction.** *Check: the ops director question.*
+29. **End-of-week charge is my accounting construct** for behaviour you described. *Check: compare Friday's finishing family to Monday's first job over recent weeks.* Without it the model cheats by leaving every line filthy on Friday.
+
+**Boundary conditions**
+30. **40 orders arrive Sunday 23:00 in one batch; nothing arrives mid-week.** Never asked. If urgent mid-week orders exist, that's a major missing disturbance.
+31. Order sizes: Meridian median 7,000 units, others 2,500 — derived from your one-third-of-volume figure. *Check: ERP directly.*
+32. **Promise dates 4–9 days after book date, uniform — pure invention, and the single most load-bearing unknown.** Because idle is only penalised via due-date pressure, too much padding makes the model idle happily and tell you nothing. *Check: ERP book-date vs promise-date.*
+33. **ERP release lag 24 h ± 12 h before promise, same for all accounts — invented, and it's the mechanism that creates your headline dilemma.** *Check: the release-timestamp field you added to the ask.*
+34. **Breakdown rates entirely invented**, anchored only to "the motor took four days once" and "a bad one every couple of weeks." *Check: the CMMS export — this is what it's for.*
+35. Repairs progress only in manned hours. Never asked; could be wrong for a contracted rebuild.
+36. Starts Monday 06:00, all lines empty, clean, dressed for white. *Use a one-week warm-up before scoring regardless.*
+37. No materials constraint (you only watch for red flags). *Check: if red flags stop runs more than quarterly, this needs modelling.*
+
+---
+
+# C. WHAT THE MODEL LEAVES OUT
+
+**Gaps from stopping early — real, not simplifications:**
+
+1. **Batch contiguity / order splitting.** The model assumes an order's batches run **contiguously** on a line. It can compare "whole order on L1" vs "split across L1 and L2" and will correctly charge the extra changeover on both — but it can't represent interleaving. **If interleaving is possible in reality, the model overstates the cost of splitting, which is exactly your run-size question.** *Fix this first — it's one sentence from you.*
+
+2. **The unwritten rules.** Never covered. Expect the model to propose schedules that make you say "we'd never do that." **Treat each of those as a finding, not a bug** — that's an unwritten rule surfacing.
+
+3. **All historical data.** Neither export arrived. Every arrival, promise date, release lag and breakdown figure is invented (30–34). **Don't make decisions on the model until at least the order book is loaded** — assumption 32 can make it tell you a comfortable lie.
+
+**Deliberate exclusions:**
+
+4. **Materials/supply chain** — you don't schedule around them; modelling them adds noise you can't act on.
+5. **Individual operators, skills, absence** — except where you named them as constraints (crew, lab, L3's qualified operator). Modelling the labour pool would double the size to answer a question you didn't ask.
+6. **Quality failures and rework** — you never mentioned a batch *failing* QA, only waiting for it. If they do fail, that's a missing feedback loop and a significant one.
+7. **Warehouse and truck capacity** — trucks are a fixed daily departure. The one place logistics bites, the release gate, *is* modelled, because it's your headline lever.
+8. **Commercial's promise-date behaviour** — exogenous. "Should commercial pad more or less" is a different model with this one inside it.
+9. **Dollars** — everything is in line-hours, because nobody could give a dollar figure and a fake conversion adds only false precision. One line converts it if finance produces a rate.
+
+---
+
+**Three things before your first real run:**
+
+1. **Load the ERP order book** — kills assumptions 31–33, the ones that can make the model lie comfortably.
+2. **Answer batch contiguity in one sentence** — unblocks the run-size question.
+3. **Run `RELEASE_POLICY = STANDING_MERIDIAN` against the default** — tests whether your headline dilemma is manufactured upstream of you. It's the cheapest finding available and needs no data at all.
+
+Send the exports and the flagged answers whenever you have them and I'll revise. Good luck with it.
\ No newline at end of file
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.md
new file mode 100644
index 00000000000..9cf6291f32e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.md
@@ -0,0 +1,1316 @@
+# Baseline control — condition 2 (v0 prompt)
+
+- Run started: 2026-08-13T10:25:27.625Z
+- Interviewer: claude-opus-5 + v0-prompt.md
+- Simulated expert: claude-sonnet-5 + situation-pack.md
+- Interviewer turns: 23 (impatience probe at 8, forced wrap at 20)
+- Stop reason: delivered-after-forced-wrap
+- Tokens: 665855 in / 56415 out across 65 calls
+
+---
+
+**Opening message**:
+
+I'm the master scheduler at a coatings plant. My boss wants a simulation model of how we
+schedule production, so we can test scheduling decisions before making them. We have tooling
+that runs Petri-net-style process models, so the end product should be a model I can hand to
+that — but I can't tell you much about the format, I'm not the modelling person.
+
+Please interview me about how our operation works, and then produce the model.
+
+---
+
+**Interviewer**:
+
+Good — a Petri-net-style engine is a fine target for this; I'll build a coloured/timed Petri net (places, transitions, token colours carrying order attributes, timed transitions with distributions) and describe it precisely enough that a modelling person can load it. The format details I'll handle; what I need from you is how the plant actually works.
+
+Let me start with **why the model exists**, because that determines how deep I dig everywhere else. Four opening questions:
+
+1. **The decision.** When your boss says "test scheduling decisions before making them" — what decisions specifically? Are we talking about sequencing/campaign order on a line, how much to batch, when to promise a customer a date, how many changeovers to accept per week, staffing, something else? Give me one or two real decisions you've argued about in the last couple of months.
+
+2. **The questions.** If the model could answer three questions on demand, what would you ask it? (Phrase them the way you'd actually ask.)
+
+3. **What "better" means.** How is your schedule judged today — formally (a KPI on a board) and informally (what gets you a phone call)? If you had to trade one late order against extra changeover hours, or against inventory, do you have any sense of the exchange rate?
+
+4. **Scope in time and space.** Does "how we schedule production" mean one line, one building, or the whole plant including raw material and filling/packing? And over what horizon do you schedule — a shift, a week, a month?
+
+---
+
+**Expert (Marta)**:
+
+Good questions — let me actually think about these instead of giving you the tidy version.
+
+1. **The decision.** The one my boss keeps poking at is the idle-vs-washdown thing. Two weeks ago I had Line 2 finish a white run at 2pm, next Meridian order not ready to release till the next morning, and the only other thing queued was a small tint job. I sat the line for a couple hours rather than wash it down and then wash it back for the next white. He wants to know if that was the right call or if I just got lucky. The other one is run-size — commercial keeps asking if we can split big orders across two lines to hit dates, and I never know if that's actually faster once you count the extra changeover, or if I'm just moving the pain around.
+
+2. **Three questions, the way I'd actually ask them:**
+   - "If Line 1's mill motor takes four days again, what do I move and what slips?"
+   - "Is it cheaper to hold a line idle for an hour waiting on a same-family order, or just wash down?"
+   - "Where are my changeover hours actually going, and would reordering this week's runs get me any of them back?"
+
+3. **"Better."** Formally, ops director looks at on-time-ship percentage on a board, and changeover hours as a line item cost. Informally — the phone call I get is always about Meridian. Nothing else really generates a call, honestly, other accounts just slip and commercial handles it quietly. Exchange rate between late orders and changeover hours — no, I don't have a number, I wish I did. If you pushed me I'd say I'd eat an extra hour of changeover before I'd risk Meridian, but past that it's a gut call, not a formula.
+
+4. **Scope.** Whole plant, all three lines — they share the changeover crew so you can't really look at one in isolation anyway. Materials I mostly just watch for red flags, I don't actively schedule around them unless something's already short. Horizon is the week — the demand book lands weekly, but I'm re-juggling it basically every day at the huddle, and the mill motor thing showed me plans can blow up inside a single shift.
+
+---
+
+**Interviewer**:
+
+That's the useful version, thank you — especially the idle-vs-washdown case, because that's a decision the model has to be able to _represent_, not just report on. Let me pin down the objective function a bit harder before we go structural, because your three questions imply things you haven't said yet.
+
+**On "better":**
+
+1. **On-time-ship.** Measured against what date — the date commercial promised the customer, or the date the customer asked for? And what's the unit of lateness that counts: a day, a shift, an hour? If an order ships one day late does it count the same as five days late on your board?
+
+2. **Meridian.** Roughly what share of your volume and of your order count is Meridian? Is _every_ Meridian order phone-call-worthy, or is it specific products/sites? And when you say "risk Meridian" — is the risk lateness, or is it something else (quality, a specific short lead time, an audit)?
+
+3. **Changeover hours as a cost line.** Do you know the number they use — dollars per changeover hour, or per washdown? Even the order of magnitude, and whether it's mostly crew time, mostly solvent/waste disposal, or mostly lost line time.
+
+4. **Idle.** Does idle line time cost anything on anyone's board, or is it invisible until it turns into a late order? That matters a lot for question two — if idle is free on paper, the model will always prefer idling and you won't learn anything.
+
+And one on your third question, which is really an accounting question:
+
+1. **"Where are my changeover hours going"** — do you currently have any record of actual changeover durations, or is it all standard times from a matrix? If there's a matrix, I want it later; if it's in your head, I want that instead, because the head version is usually the true one.
+
+---
+
+**Expert (Marta)**:
+
+1. **On-time-ship.** It's measured against the promise date — what commercial told the customer, not what the customer originally asked for. Commercial pads a bit already so there's some slack baked in before I even see it. As for unit — honestly the board just tracks "on time or not," it's binary. One day late and five days late both just show up as a red mark in the weekly summary. Which annoys me, because a one-day slip on a small account is nothing and a five-day slip on a big one is a real conversation, but the board doesn't know the difference.
+
+2. **Meridian.** They're maybe a third of our volume by units — almost all base whites, a couple of tint SKUs too. Order count is smaller than that, they order in bigger batches than most. Not every single Meridian order gets a call — it's specifically anything that's going to miss the ship window, doesn't matter which SKU. The risk is purely lateness — they've got a vendor scorecard and a fine schedule, and if you're late enough often enough they start pulling shelf space. It's not a quality thing for them, it's a contract thing.
+
+3. Honestly? No, I don't know a dollar figure. I know it's treated as a cost because ops brings it up in the monthly review as hours, not dollars — "we spent 40 changeover-hours this month, that's up from 30." Whether that's mostly crew wages or the fact the line's not running during that time, I couldn't tell you. My guess, and it's just a guess, is it's mostly the lost line time that matters to them, because the crew's paid either way, they're just idle or elsewhere.
+
+4. That's a good question and I don't think anyone's ever asked me it straight. I genuinely think idle is invisible on paper — nobody's tracking "line 2 sat for 90 minutes" as a number anywhere, it just quietly turns into either nothing (if I got away with it) or a late order (if I didn't). So yeah — if your model has a free lunch where idling costs nothing, it'll idle constantly and that won't match what actually happens, because eventually idling costs you the due date.
+
+5. It's a matrix, sort of — there's an old spreadsheet, family-to-family changeover standard times, that's what I use when I build the sheet. But it's a standard time, not an actual — nobody logs what a changeover really took unless it went badly wrong and someone complained. So the matrix is the "should take" number, and my gut adjustment on top of it is the "actually takes," and the gut part is not written down anywhere.
+
+---
+
+**Interviewer**:
+
+Right. Let me co-construct the scoring, because you've given me the ingredients and I don't want to invent the weights silently.
+
+Here's my proposal, tell me where it's wrong:
+
+- **Score both ways.** The model reports the board metric (binary on-time %, vs promise date) _and_ a "true cost" metric, because you've told me the board is wrong in a specific way (blind to magnitude and to account). Decisions get made on the true cost; the board number is there so you can tell your boss what the board _will_ say.
+- **True cost = lateness penalty + changeover hours.** Lateness penalty scales with hours late and by account tier: Meridian weighted heavily, everyone else light. Changeover hours costed as lost line time, i.e. one changeover hour = one hour of line capacity gone.
+- **Idle is not directly costed.** It only hurts by consuming the clock and pushing things late. That matches what you described — but it means the model needs due dates and arrivals to be _realistic and tight_, or idling will look free. I'll come back to that.
+
+Now the exchange rate. I'm going to ask it as concrete bets rather than ask you for a number:
+
+1. **Meridian bet.** Line 2 just finished white. A Meridian white order is releasable tomorrow morning. There's a small tint job that would fill the gap but needs a wash down and a wash back — say 2 hours each way, 4 hours total. Taking the tint job makes the Meridian order finish 6 hours later than its ship window. Do you take the tint job? What if it only made Meridian 1 hour late? What if the changeover were 1 hour each way instead of 2?
+
+2. **Same bet, other account.** Same setup but the white order is Coastal, not Meridian, and it's their whole week's requirement. Does your answer change, and at what point?
+
+3. **Utilisation reality check.** In a normal week, how much of the three lines' available hours are actually consumed by running product? Half? Three-quarters? Flat out? And do you routinely work weekends or overtime, or is the week's capacity fixed?
+
+---
+
+**Expert (Marta)**:
+
+This is fair, and honestly it's already sharper than how I've ever had to think about it out loud. Let me try the bets.
+
+**10. Meridian bet.** No, I don't take the tint job — not if it makes Meridian six hours late. Six hours can tip into "missed the truck," and that's a call I don't want to make. If it only made Meridian one hour late, I'd probably still not take it, because "one hour late" on my estimate has a habit of becoming three hours late by the time QA and the truck schedule get involved — I don't trust my own estimate that tightly. Where it gets interesting is your third variant: if the changeover were only an hour each way instead of two, so two hours total instead of four, and that only pushed things around rather than actually making Meridian late — yeah, then I'd take the tint job, because now it's basically free, I'm just filling a gap. So honestly the real threshold isn't a number of hours, it's: does it touch Meridian's window at all. If it doesn't, do it. If it does, don't, full stop. That's blunter than an exchange rate, I know.
+
+**11. Coastal instead.** Yeah, this changes things. Coastal's not on a scorecard, they're not going to fine us. If it's their whole week's order I'd still care — a full week's requirement matters even for a small account, because if I blow it I've got nowhere to slot them next week either. But I'd take the tint job even at six hours late for Coastal, honestly, as long as six hours doesn't turn into "we missed by two days." Somewhere around a day late is where I'd start to feel bad about it. So there really are two different curves in my head — Meridian's is a cliff, everyone else's is a slope.
+
+**12. Utilization.** Rough guess — three-quarters, maybe. It's never flat out because there's always some changeover eating into it, and Line 3's day-shift-only limits it structurally. Weekends — we don't run them as standard, but if we're in a hole close to a Meridian date, ops director will approve Saturday overtime on Line 1 or 2, that's happened maybe four or five times this year. Line 3 overtime is rarer, mostly because it needs a qualified operator who's willing to come in, not just budget approval.
+
+---
+
+**Interviewer**:
+
+That's not blunter than an exchange rate — it's _more_ informative. A cliff and a slope is a perfectly implementable penalty structure, and it's a real finding: it means your policy is lexicographic (protect Meridian's window absolutely, then optimise everything else), not a weighted sum. I'll build it that way.
+
+Let me record where we are on scoring:
+
+- **Meridian:** step penalty — huge fixed cost if the order misses its promise window at all; magnitude beyond that barely matters (a call is a call).
+- **Everyone else:** roughly linear in hours late, with the slope becoming noticeable around a day, plus an extra bump if the order is an account's whole-week requirement (because you can't recover next week).
+- **Changeover:** counted as hours of lost line capacity.
+- **Board metric:** binary on-time %, reported separately.
+
+Now let's get structural. **Walk me through one concrete order, end to end** — pick a real recent one, ideally a Meridian white, and narrate it from the moment it lands in your demand book to the moment it's on a truck. Don't tidy it. I want every place it sits and waits, every person or system that touches it, and every point where it could have gone a different way.
+
+Specifically I want to hear, as you go: where does the order physically _wait_, who decides when it moves, and what has to be true before each step can start.
+
+---
+
+**Expert (Marta)**:
+
+Okay, let me pull up... well, mentally pull up, one from a couple weeks back. It was a Meridian order, 8,000 units of VW-01, one of the base white golds. Let me walk it through.
+
+**Lands in the demand book.** ERP spits out the weekly book Sunday night, I see it Monday morning — SKU, quantity, ship date. That order had a Thursday ship window. It sits in the book, unallocated, until I get to it — the book doesn't prioritize itself, I have to look at all 40-odd orders and decide order.
+
+**I put it on the sheet.** Monday morning before the huddle I build the week's allocation — which line, roughly what day. Meridian white always goes Line 2, no debate, so that part's automatic. What's not automatic is _when_ in the week — I look at what else Line 2's got queued, what family it's already running, and slot it in. For this one I put it Wednesday day shift, figuring Line 2 would be finishing a run of tinted colours Tuesday night, so there'd be a washdown Wednesday morning before it could start.
+
+**07:30 huddle.** I say out loud what's happening line by line. Someone from maintenance is there, someone from QA sometimes, the line leads. This is where reality intrudes — that Wednesday, the Line 2 lead mentioned the filler had been acting up over the weekend, nothing logged yet, just "keep an eye on it." I made a mental note but didn't replan.
+
+**Materials check.** Before the run can start, I (or actually the line lead) confirms the resin and pigment for VW-01 are physically at the line — this is supposed to happen the day before, via a materials report I glance at each morning. That week it was fine, no shortage flagged.
+
+**Washdown.** Tuesday night the tint run finishes. The changeover crew — two techs, shared across all three lines — has to be free. That week they weren't busy elsewhere, so the tint-to-white washdown happened overnight, the full three hours plus, because it's the expensive direction. It has to be _fully_ done, checked by a line tech, before mix can start — there's a sign-off, someone has to visually confirm no carryover.
+
+**Mix → mill → tint/letdown → fill.** Wednesday morning the actual run starts. VW-01 goes through the four stages. For a white, mix and mill go fast, tint/letdown is basically nothing since it's not being colored, and fill is where it actually spends its time — fill is the bottleneck for whites, like I said. That week the filler hiccuped for about 20 minutes mid-run — small jam, cleared it, lost time but not a disaster.
+
+**QA hold.** Once filled and packed, the pallets go into QA hold. Lab has to sample and release — for whites that's usually about four hours, but it depends on how backed up the lab is. That week it was mid-week, lab wasn't swamped, four hours held.
+
+**Ships.** Once released, warehouse pulls it for the Thursday truck. If QA release comes in Wednesday evening, it comfortably makes Thursday. If it had slipped — say the filler jam had been two hours instead of twenty minutes, or QA had a backlog — Thursday morning becomes tight, and that's the point where I'd be making calls, maybe asking QA to prioritize the pallet, maybe finding out if there's a later truck.
+
+Where could it have gone differently: if the changeover crew had been busy with Line 3 that Tuesday night, the washdown slips to Wednesday morning and the whole run pushes into the day, eating into the QA buffer. If the filler jam had been the "half a shift" kind instead of the "twenty minutes" kind, same problem. Both of those are the ordinary ways a Meridian order gets tight — not exotic, just the normal noise of the plant landing on the wrong day.
+
+---
+
+**Interviewer**:
+
+That walkthrough gave me most of the skeleton. Let me nail the line topology first, because it determines whether this is a four-stage flow shop or a single occupancy block, and that changes the model shape completely.
+
+1. **Pipelining.** Mix → mill → tint/letdown → fill. When VW-01 is at fill, can the _next_ order already be mixing on the same line? Or does one order own the whole line from mix through fill? If it can pipeline, is there physical buffer between stages — tanks, totes — and how many orders' worth?
+
+2. **Batch structure.** Was that 8,000 units one continuous run, or is it broken into batches (a mix vessel's worth) that move through as discrete lumps? If batches — what's a typical batch size relative to that order, and do all batches of an order have to finish before QA samples, or does QA sample per batch?
+
+3. **The three lines.** What can each run, and what can't it? You said Meridian white "always goes Line 2, no debate" — is that a hard qualification (Line 1 physically can't), a quality rule, or just habit? And what makes Line 3 different besides day-shift-only?
+
+---
+
+**Expert (Marta)**:
+
+1. **Pipelining.** Yes, it pipelines, that's basically the whole point of the tanks between stages. While fill's running on the tail end of one batch, mill can already be starting on the next batch of the _same_ order, and mix even earlier than that. But it's not infinite — there's a small holding tank between each stage, and if the downstream stage is slower than upstream, the tank fills up and upstream has to stop. That's the Line 1 mill-to-fill tank problem I mentioned — it's small, so mill backs up waiting for fill to catch up, more than it should. On Line 2 and 3 the tanks seem adequately sized, I've never heard complaints about them. As for "how many orders' worth" — I'd say each tank holds maybe one batch, two if you're lucky, not more. It's not built to buffer a changeover-length gap, it's built to smooth the normal pipeline hiccups.
+
+2. **Batch structure.** Yeah, 8,000 units isn't one continuous pour, it comes off the mix vessel in batches — a mix vessel holds maybe 1,000-1,500 units' worth depending on the product, so that order was probably six, seven batches. They move through as discrete lumps, each one going through mill, tint, fill in sequence, pipelined behind each other like I said. QA doesn't wait for the whole order — they sample per batch, or actually I think it's more like per some number of batches, they don't test every single one if it's the same SKU running clean. But the pallets from the _last_ batch still have to clear QA before the whole order can ship, obviously, so functionally the order's held up by its slowest/last batch through the system.
+
+3. **The three lines.**
+
+- **Meridian on Line 2** — this one really is a hard rule, not physics. Years back Meridian did an audit and specifically qualified Line 2's fill area for their whites — some paperwork thing about equipment. We could probably physically run their orders on Line 1, but nobody's going to risk it without redoing that qualification, and nobody's pushed for that.
+- **Line 1** is qualified for everything, including specialty — it's the old reliable, slower but flexible.
+- **Line 2** is fast, big-volume, but it was never piped for the clear resins specialty uses, so it flat-out can't run specialty — that's physical, not paperwork.
+- **Line 3** is newest and quick, but it's product-by-product qualified — there's a list, and I know two tint SKUs specifically aren't on it yet, someone in quality is slowly working through validating it for more. Day-shift-only is a separate constraint on top — that one's a staffing/overtime decision, not a capability one.
+
+---
+
+**Interviewer**:
+
+Good — that's a proper flow shop with finite buffers, and Line 1's small mill-to-fill tank is a real modelled constraint, not a footnote.
+
+Now the taxonomy, because your changeover matrix is keyed on it.
+
+1. **Families.** You've mentioned base whites, tints/tinted colours, and specialty. Is that the full family list as the changeover matrix sees it? How many SKUs roughly in each, and are there sub-distinctions _within_ a family that change the changeover (e.g. dark tint → light tint worse than light → light)?
+
+2. **Changeover direction and cost.** You said tint→white is "the expensive direction, full three hours plus." Give me the shape of that matrix as you carry it in your head: white→white (same SKU / different SKU), white→tint, tint→tint, tint→white, anything→specialty, specialty→anything. Standard times, and where your gut says the standard is wrong.
+
+3. **Does the changeover differ by line?** Same family transition on Line 1 vs Line 2 vs Line 3 — same hours, or does the bigger/faster line take longer to wash?
+
+---
+
+**Expert (Marta)**:
+
+1. **Families.** Yeah, that's the three the matrix runs on — base whites, tints, specialty. Roughly, of the 14 SKUs: whites are maybe 4-5 SKUs but they're the bulk of the volume, tints are the biggest count, maybe 7-8 different colors, and specialty is the small tail, 2-3 SKUs. Within tints there absolutely are sub-distinctions that matter but the matrix doesn't capture them well — going from a dark tint to a light tint is worse than light-to-light or dark-to-dark, because of exactly the same carryover logic as tint-to-white, just less extreme. The matrix just says "tint-to-tint, X minutes" flat, and I mentally add time if I know it's dark-to-light. That's gut, not written down.
+
+2. **The matrix, as I carry it:**
+
+- White→white, same SKU: basically nothing, a rinse, call it 15 minutes, mostly just checking nothing's off.
+- White→white, different SKU: 20-30 minutes, quick rinse — same family, no real risk.
+- White→tint: about 45 minutes. Going _into_ pigment from clean is easy, you're not fighting carryover.
+- Tint→tint: depends on the direction like I said — light-to-light maybe 30-40 minutes, but dark-to-light I pad it, call it an hour, hour and a half even though the sheet says the same number as any tint-to-tint.
+- Tint→white: the bad one, full washdown, 3 hours plus. My gut says the matrix's "3 hours" is actually optimistic — I've seen it run closer to 3.5 more than once, especially after a dark tint.
+- Specialty in or out, either direction: about 2 hours. Doesn't matter which way, the clears are just fussy to purge either direction.
+
+1. **By line.** The matrix as written doesn't differentiate by line — same hours regardless. But my gut says that's wrong for at least one case: Line 1's washdowns seem to take a bit longer than the same transition on Line 2, and I've always figured it's because Line 1's older, more pipework, more places for carryover to hide. Nobody's ever timed it properly to confirm that though, it's just a feeling from watching it happen for years.
+
+---
+
+**Interviewer**:
+
+Useful — I'll model the standard matrix _and_ your gut adjustment as separate layers, so you can run "what if the standard times are real" vs "what if my padding is real" and see whether it changes any decision. That's a cheap experiment and it tells you whether it's worth timing changeovers properly.
+
+Now durations of the actual work.
+
+1. **Run rates.** For each stage — mix, mill, tint/letdown, fill — how long does one _batch_ take, and does it differ by family and by line? You said fill is the bottleneck for whites; is something else the bottleneck for tints or specialty (I'd guess mill or tint/letdown)? Give me per-batch hours as best you can, per line if they differ.
+
+2. **Batch size.** 1,000–1,500 units per mix vessel — does that vary by line as well as by product? Is Line 2's vessel bigger than Line 1's?
+
+3. **Variability.** Take the one you know best — a white batch on Line 2's fill. Typical duration? One time in ten it's worse than **_? One time in ten it's better than _**? And what causes the bad tail — the filler jams you mentioned, or something else?
+
+---
+
+**Expert (Marta)**:
+
+I'll be honest, this is where you're going to hit the edge of what I actually track — I know the _sheet_ numbers, which are the "should take" numbers, and I know the vibe of how wrong they are, but per-batch-per-stage isn't something I've ever broken down that finely. Let me give you what I've got.
+
+**19. Run rates.** The sheet doesn't even really have stage-level rates — it has one number per product-per-line, "units per hour," and I back into a run time from that. So if you want stage-by-stage I'm partly guessing based on watching the line.
+
+For a white batch, say 1,200 units, on Line 2: mix is maybe 20 minutes, mill maybe 20-30, tint/letdown almost nothing since there's no color to add, and fill... fill is the long pole, I'd guess an hour, hour and a half for that batch size, because line speed is really a fill-head-count thing. On Line 1, same batch, mix and mill are similar, but fill is slower — maybe double, hour and a half to two hours, since Line 1's older equipment.
+
+For tints, mill and tint/letdown both stretch out — you're actually incorporating pigment and it has to mix properly, so I'd guess mill is more like 40 minutes to an hour, tint/letdown similar, and fill is actually not that different from white fill rates, maybe a bit slower. That's the "funny, Line 1 and Line 2 are nearly even on tints" thing — I think it's because tint fill isn't as fast-head-dependent, but don't hold me to the mechanism, I'm guessing.
+
+For specialty — this is the one I feel most confident about because it's so obviously different — mill is the slow one, could be two, three hours for a batch because the stuff is thick and has to be milled properly or it's ruined. Fill for specialty is actually fine, comparable to tint fill, it's not the bottleneck at all.
+
+**20. Batch size.** Yeah it varies. Line 2's vessel is bigger — I think it's closer to 1,500-1,800 units per batch, Line 1's more like 1,000-1,200, Line 3 I honestly am not sure, I think it's similar to Line 2 but smaller-side, maybe 1,200-1,500. Don't quote me hard on Line 3's number.
+
+**21. Variability — white batch, Line 2 fill.** Typical, like I said, an hour to an hour and a half. One time in ten it's worse — that's your filler jam scenario, tack on 20 minutes to half an hour for a small jam, or if it's a bad one, could eat the rest of the shift, but that's rarer than one-in-ten, that's more like once every couple weeks across the whole line, not per batch. One time in ten it's better — honestly not much better, maybe you shave ten minutes if everything's smooth, there's not a lot of upside slack in fill, it runs close to its rate when nothing's wrong. So the bad tail is real and fat, the good tail is thin. The cause of the bad tail is almost always the filler — jams, or waiting on packaging materials running low, that happens too, cases or labels not being restocked fast enough, that's more a warehouse problem than a line problem but it still stops the fill head.
+
+---
+
+**Interviewer**:
+
+That asymmetry — thin upside, fat downside — is exactly what I need; I'll use a right-skewed distribution rather than anything symmetric. And the packaging-materials stall is a distinct failure mode from a jam, so I'll keep them separate: you might discover the warehouse restock is a cheaper fix than the filler.
+
+Now resources and calendars, which your walkthrough showed are where the contention actually lives.
+
+1. **Changeover crew.** Two techs, shared across three lines. Do both techs work one changeover together, or can they split and do two changeovers at once? Are they on all shifts, or day only? And when a line finishes a run at 2am and needs a washdown — are they _there_, or do they get called?
+
+2. **Shifts.** What's the shift pattern per line — Line 1 and 2 running nights, Line 3 day only? How many shifts a day, how many days a week? Do lines run unattended across a shift boundary, or does the run stop and restart?
+
+3. **QA lab.** Who and how many, what hours? You said whites are "usually about four hours" — what does the tail look like when the lab's backed up, and what makes it back up? Does the lab work nights and weekends, or does a batch finishing at 11pm just sit until morning?
+
+---
+
+**Expert (Marta)**:
+
+1. **Changeover crew.** They usually work a changeover together, one crew, one job at a time — that's the actual constraint I was talking about, if two lines need one at once, someone waits. I don't think they physically _need_ two people for a quick rinse, but for the big washdowns and the specialty purges, yeah, it's genuinely a two-person job, there's stuff to hold and stuff to check simultaneously. They're day shift, nominally, but they flex — if I know a washdown's needed overnight I ask them to stay late or come in early, that's a normal ask, not overtime-approval-required the way Saturday production is. If a line finishes at 2am with nobody expecting it and no changeover pre-arranged, it just sits dirty until someone's available — usually that means it waits till the day crew starts, so you lose the overnight hours you didn't plan to lose.
+
+2. **Shifts.** Line 1 and Line 2 run two shifts, so days and evenings, some weeks a skeleton night crew if we're behind, but that's not standard. Line 3 is day shift only, like I said, that's the default — overtime unlocks a second shift on any line but needs the ops director's sign-off. Within a shift, if a run's not done and the shift ends, generally it does keep running — there's a handover, second-shift operator picks it up mid-batch, the line doesn't need to be babysat every second, it just needs someone there. Between last shift ending and next one starting is the gap where nothing runs unless someone's specifically staying late — that's the 2am problem, that gap is a black hole for anything that needs a person, changeover crew or otherwise.
+
+3. **QA lab.** Two people, day shift basically, maybe a bit into evening if something's backed up, but nobody's in that lab at 2am or on weekends normally. Four hours is the typical hold-to-release for whites when the lab isn't backed up. What backs it up is exactly what you'd guess — everything landing on Wednesday/Thursday because that's when the week's runs tend to finish, so the lab gets a pile all at once. When it's backed up I've seen holds stretch to eight, ten hours, and if a batch finishes Friday evening or over a weekend, it can just sit until Monday morning — that's actually happened, and it's ugly, because now your Friday-finished order can't ship till Monday afternoon at the earliest, blown right through the week's window. That's probably the single biggest hidden Meridian risk, worse than the filler honestly, because it's totally invisible until it isn't.
+
+(Sorry — I've just seen the time, I have the floor huddle in ten minutes. How much more do you need?)
+
+---
+
+**Interviewer**:
+
+Roughly three more rounds — call it 15 minutes total, not now. Here's the honest inventory so you can choose how to spend it.
+
+**Solid enough to build on:** objectives and the cliff/slope penalty structure; line topology and pipelining with finite tanks; families and the changeover matrix plus your gut layer; qualifications (Meridian↔Line 2, no specialty on Line 2, Line 3's SKU list, day-shift-only); stage durations at the accuracy you have them; the changeover crew as a single shared server; shift calendar and the overnight black hole; QA lab hours and the Friday-evening trap.
+
+**Still genuinely missing, in priority order:**
+
+1. **Policies at conflict points.** This is the biggest gap and the model is mostly worthless without it. Two lines want the changeover crew at once — who wins, and does an in-progress changeover ever get abandoned? How do you sequence orders _within_ a line (due date? family campaigning? Meridian first?)? Can QA be told to jump a pallet, and does that cost someone else? What actually triggers the Saturday-overtime ask, and how late in the week can you still ask?
+2. **Breakdowns.** Your question one is literally "if Line 1's mill motor takes four days again." I need failure frequency and repair duration for the mill motor class of event, the bad filler jam, and anything else that has ever taken a line down for more than a shift.
+3. **Arrivals and order shape.** ~40 orders/week — size distribution, split by family and by account, and how promise dates relate to the book date (how much slack does commercial actually pad in?). Plus: what gates "ready to release" — you said the Meridian order wasn't releasable till next morning, and I don't know what was holding it.
+4. **Order splitting and campaigning.** Do an order's batches have to run contiguously, or can you interleave? That's the whole substance of your commercial-wants-to-split-across-two-lines question.
+5. **The unwritten rules.** What would a new scheduler get wrong in week one; what you always/never do that's on no document; which rules exist because of something that went wrong once.
+
+**My recommendation:** give me 15 minutes later today or tomorrow on items 1, 4 and 5 — those are pure head-knowledge, nobody else in the plant can supply them, and item 1 is where your idle-vs-washdown question actually lives. Items 2 and 3 I can partly reconstruct: maintenance may have downtime records and the ERP has the order book, so point me at whoever holds those, or I'll put placeholder distributions in the assumption ledger clearly marked as invented.
+
+Go to your huddle. Tell me when, and whether you can pull the order book extract and any downtime log in the meantime.
+
+---
+
+**Expert (Marta)**:
+
+Fair, that's a good split. Let's say tomorrow, same time, fifteen minutes — I'll block it so it doesn't get eaten by the huddle.
+
+For the records: I'll ping the plant maintenance coordinator today for whatever CMMS downtime export he can pull — I know it exists, I've just never asked for it in this shape. And I'll get the order book pulled from ERP, that one's easy, it's just a report I don't normally bother running historically. If either of those comes back thin or ugly, flag it and I'll chase harder rather than let you guess quietly — I'd rather know where the model's standing on sand.
+
+See you tomorrow.
+
+---
+
+**Interviewer**:
+
+Blocked in — tomorrow, fifteen minutes, items 1, 4 and 5. I'll come with those as concrete scenarios rather than open questions so we don't burn time.
+
+To make the two data pulls useful first time, here's exactly what I need from each. Forward these verbatim if it's easier.
+
+**Maintenance coordinator — CMMS downtime export, last 12 months:**
+
+- One row per downtime event: line, equipment/stage (mix / mill / tint-letdown / fill / other), start timestamp, end timestamp or duration, short description, and planned-vs-unplanned flag if it exists.
+- I don't need cost, parts, or work-order text. I need _frequency and duration_, and specifically I need the long tail preserved — if the export truncates or buckets anything over 24 hours, that's the part I care most about, since your mill motor question lives there.
+- If the only thing he can give me is a list of the big ones from memory with rough dates, take it. Four data points about four-day outages beat four hundred about five-minute stops.
+
+**ERP — order book, last 26 weeks if it goes back that far:**
+
+- One row per order line: order ID, account, SKU, family if it's a field, quantity, date the order entered the book, promise date (the one on-time is scored against), actual ship date, and line it ran on if that's captured.
+- The two fields that matter most and are most likely to be missing are **date-entered-the-book** and **actual ship date** — without both I can't measure the slack commercial pads in, or reconstruct your real on-time rate. If either is absent, tell me and I'll ask you for the pattern from memory instead.
+
+**Flagging protocol, as you asked:** anything I can't get from those exports goes in a numbered assumption ledger with the value I invented, why, and the cheapest way for you to check it. Nothing gets smuggled in quietly.
+
+Two things you can answer in ten seconds whenever, no rush — they'll save time tomorrow:
+
+- Does the ERP order book have a **"release" or "firm" status** separate from the promise date? (That's the thing that was holding your Meridian order until the next morning, and I still don't know what it is.)
+- Roughly how many of the ~40 weekly orders are Meridian?
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Both quick ones:
+
+**Release/firm status** — yeah, there's a field for it, I think it's literally called something like order status: pending, released, in-production, shipped. What was holding my Meridian order that morning specifically was a **credit/allocation hold** — logistics releases orders in batches once the truck's confirmed and the paperwork's clean, and that particular one hadn't been released yet when I wanted to start it, purely an admin timing thing, not a materials or capacity issue. It happens more than you'd think — I sometimes know an order's coming and want to slot it, but I can't actually pull the trigger till ERP says it's released, which can lag the promise date planning by a day or so.
+
+**Meridian count** — out of the ~40, I'd guess 6 to 8 are Meridian in a typical week. Fewer orders than their volume share would suggest, because like I said, they order big.
+
+I'll get both requests out today, verbatim. See you tomorrow.
+
+---
+
+**Interviewer**:
+
+Both useful — and the second one reframes the first.
+
+**The credit/allocation hold is a modelled object, not admin noise.** Your headline decision — sit Line 2 idle at 2pm Tuesday or wash down — only exists _because_ the next white wasn't releasable yet. That gap isn't a scheduling artefact, it's manufactured by a release process you don't control. Which means the model can answer a question your boss didn't ask: how many idle-vs-washdown dilemmas would simply evaporate if logistics released a few hours earlier, or released Meridian orders on a standing basis rather than truck-by-truck. If that's the real lever, it's a phone call to logistics, not a scheduling change — much cheaper than anything you can do on the floor.
+
+So I'm adding to tomorrow: **how long is the lag between "I know it's coming" and "ERP says released", how variable is it, and does it differ for Meridian?** If the ERP export has a released-date or status-change timestamp, that measures it directly — worth adding to your request while it's still unsent.
+
+**6–8 of 40 orders, one-third of volume** also tells me Meridian batches are roughly 2–3× everyone else's. That matters more than it sounds: big orders are many batches, many batches occupy a line for a long contiguous stretch, and a long stretch on Line 2 is exactly what makes everything else queue behind the cliff. I'll check that against the order book rather than assume it.
+
+Tomorrow, in this order:
+
+1. **Conflict points** — I'll put four concrete scenarios to you: two lines wanting the crew simultaneously; how you sequence within a line; whether QA can be jumped and who pays; what triggers and what blocks the Saturday ask.
+2. **Splitting and campaigning** — must an order's batches run contiguously, and what actually happens when commercial asks to split across lines.
+3. **Unwritten rules** — week-one mistakes, always/nevers, and rules that exist because of one bad incident.
+
+Then I'll read back the whole model in summary, you correct it, and I build. Enjoy the huddle.
+
+---
+
+**Expert (Marta)**:
+
+Good catch, actually — I hadn't thought about it that way, but you're right, if that's the real lever it's a much cheaper fix than anything I can do with the sheet. I'll add the released-date/status-change timestamp to the ERP ask, and I'll ask the logistics lead directly tomorrow what drives the timing on Meridian releases specifically — my gut says it's tied to truck booking confirmation, which they do a day or two out, but I've never actually asked why it's a day or two and not same-day.
+
+See you tomorrow — 1, 2, 3 in that order works for me.
+
+---
+
+**Interviewer**:
+
+Perfect. Two things to make the logistics conversation pay off, since you're having it anyway:
+
+- **Ask what the release is actually waiting on** — truck booking confirmation, credit check, paperwork, or all three in sequence. If it's a chain, the binding one is usually not the one people name first.
+- **Ask whether a standing release for Meridian is possible** — i.e. release on the production plan rather than on truck confirmation, with the truck booked in parallel. If the answer is "we've never been asked," that's your lever. If it's "we tried it and stopped," find out what went wrong; that's a constraint I need to model.
+
+I'll come tomorrow with the four conflict scenarios pre-written, so you're reacting to concrete cases rather than generating from scratch. Fifteen minutes should hold if we don't wander.
+
+See you then.
+
+---
+
+**Expert (Marta)**:
+
+Will do — both of those are exactly the right questions, and I should've asked them myself years ago instead of just working around the gap. I'll bring back whatever logistics says, even if it's "nobody's ever asked."
+
+See you tomorrow.
+
+---
+
+**Interviewer**:
+
+Good luck with it.
+
+So you're not generating from cold tomorrow, here are the four scenarios in advance — no need to prepare, just useful if you happen to read them before we talk. Answer them the way you actually behave, not the way the procedure would read.
+
+**A. Crew contention.** It's 18:00. Line 1 has just finished a specialty run and needs a 2-hour purge before its next job. Line 2 finishes a dark tint at 18:30 and the next thing on it is a Meridian white — a 3½-hour washdown. Both need the two techs, and the techs are already an hour past their nominal day. Who gets them, who waits, and what do you actually do about the loser?
+
+**B. Sequencing within a line.** Line 3 has four releasable orders queued Monday: two light tints due Thursday, one dark tint due Wednesday, one white due Friday. What order do you run them, and what would make you break that order?
+
+**C. Jumping QA.** A Meridian pallet finishes at 16:00 Thursday; the truck is Friday 06:00; the lab has six other batches ahead of it. You ask them to jump it. Do they? Who authorises it, what does the displaced work lose, and has anyone ever said no?
+
+**D. The Saturday ask.** What has to be true before you go to the ops director for Saturday overtime — how far behind, and how late in the week can you still ask before it stops helping? And is there a case where you'd have asked and deliberately didn't?
+
+**Interim assumption ledger** (things I've inferred or invented so far, all provisional — flagging now so none of it goes quiet):
+
+1. **Lateness scored in hours against promise date**, not days. _Assumed_ — your board is binary, but a binary metric can't distinguish your own cliff/slope answer. _Check:_ ship-date vs promise-date fields in the ERP pull.
+2. **Meridian penalty modelled as a step at "misses the ship window"**, magnitude-insensitive beyond that. _From your answer to Q10_, but "ship window" needs a definition — I've provisionally taken it as the truck departure, not end-of-promise-day. _Check:_ tell me tomorrow if that's wrong.
+3. **Non-Meridian penalty linear in hours, kink upward around 24 hours**, plus a surcharge if the order is an account's whole-week requirement. _Assumed shape_ from your Coastal answer. _Check:_ none cheap — sensitivity-test it instead.
+4. **Idle time costs nothing directly.** _Your answer to Q8._ Consequence: results only mean anything if due dates and arrivals are realistically tight, so item 3 of tomorrow's list (arrivals) is load-bearing.
+5. **Changeover crew = one indivisible 2-person server**, one job at a time, day shift with discretionary flex. _From Q22_, but I've assumed the quick rinses also consume the full crew. _Check:_ scenario A will probably settle it.
+6. **Line 3 batch size ~1,200–1,500 units.** _Your explicit "don't quote me."_ _Check:_ mix vessel nameplate, 30 seconds on the floor.
+7. **Gut changeover padding modelled as a separate switchable layer** (dark→light tint +30–60 min; all Line 1 washdowns +~15%; tint→white standard 3h → 3.5h). _Your gut, not the matrix._ _Check:_ time six changeovers with a phone; the model will tell you first whether it's worth doing.
+8. **Packaging-material stalls modelled separately from filler jams.** _My decomposition, not yours._ _Check:_ whether the CMMS export distinguishes them — it may only log equipment faults, in which case the stalls are invisible and I'll need your memory instead.
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Read these on the way out, quick reactions before tomorrow so you're not starting cold either:
+
+**A.** Line 2 wins, no contest — Meridian white beats specialty purge every time, that's not even a hard call. What actually happens to Line 1 is it just sits dirty, purge waits till the crew's free, which given they're already an hour over means it probably doesn't happen till the next morning. So Line 1 loses that overnight slot entirely, not just two hours — the whole gap till someone's back on shift. I might quietly ask the techs to do a shortened version if I'm desperate, but that's rare and it makes maintenance nervous.
+
+**B.** I'd run dark tint first, then the two light tints together, white last — campaigning by family to save changeover, even though the dark tint isn't due till Wednesday and the white's not due till Friday. I'd only break that order if the white were needed sooner than Friday, or if Line 3 wasn't qualified for one of those SKUs yet, in which case it just doesn't go on Line 3 at all and I'm rearranging everything anyway.
+
+**C.** Usually yes, they jump it — I ask the lab lead directly, no formal authorisation, it's a favor system. Displaced work just sits longer, and if it's near end-of-week that can mean _that_ batch is the one that hits the Friday-evening trap. Nobody's said no outright, but I've had the lab lead push back hard enough that I backed off once, when jumping it would've meant something else missing its own Friday truck.
+
+**D.** Behind by about a shift is roughly the trigger — if I can see Wednesday that a Meridian order won't make it without extra hours, I ask then. Asking Thursday or later usually doesn't help, not enough runway to get approval and staff it. I've had a case where I didn't ask even though I was tempted — a slip that would've needed Saturday overtime, but it was Coastal, not Meridian, and I judged it wasn't worth the argument with the ops director for a non-scorecard account. That one shipped a day late and nobody outside the plant noticed.
+
+All good on the ledger — nothing jumps out as wrong. See you tomorrow.
+
+---
+
+**Interviewer**:
+
+Those four answers did a lot of work — A and D in particular. Three things they settled, and three new probes I'll fold into tomorrow rather than adding time.
+
+**Settled:**
+
+- **Crew priority is a strict rule, not a judgement:** Meridian-enabling changeover outranks everything. Non-preemptive, and the loser's penalty isn't the changeover duration — it's _the remainder of the gap until the crew is back on shift_. That's a much harsher cost than a queueing delay and it will show up strongly in results.
+- **Sequencing within a line is campaign-first**, not due-date-first — you deliberately ran the Wednesday-due dark tint ahead of nothing and the Friday white last to save changeovers. Due dates only break the campaign when they'd actually be missed.
+- **QA jumping is an informal, socially-limited resource**, and you've been refused once by being persuaded, which means it has a real budget.
+
+**New probes for tomorrow (short):**
+
+1. **Scenario A, variant:** same clash but _both_ lines are waiting on Meridian whites. Is there a tiebreak, or is it whoever's due first? I need to know whether "Meridian first" is a rule or shorthand for "most urgent first."
+2. **Scenario B, hidden bit:** you put white _last_ on Line 3. Were you thinking about what the line has to run _next_ week — leaving it in a good state? If you schedule with one eye on the following Monday, the model needs an end-of-horizon state value, or it will cheat by leaving every line filthy on Friday.
+3. **QA jump budget:** how often do you actually spend it — weekly, monthly? Once per week is a modellable allowance; unlimited is not.
+
+**And one finding from D worth testing, which I don't think you said out loud:** you get Saturday overtime approved on Line 1 or 2 — but the lab is day-shift, weekdays. So Saturday production may just queue for Monday's lab and arrive no earlier than if it hadn't run. Unless the Saturday ask _includes_ a lab person, or the Friday-evening trap catches it anyway. Worth asking the ops director whether lab overtime has ever been part of that approval — if it hasn't, some of those four or five Saturdays this year may have bought you nothing.
+
+**Ledger additions:**
+
+1. **Changeover crew is non-preemptive** — an in-progress changeover is never abandoned mid-way for a higher-priority line. _Inferred from A._ _Check:_ one word tomorrow.
+2. **A line that misses its changeover window waits until the crew's next shift start**, not merely until the crew is free. _From A._ This is the single most punitive mechanism in the model so far.
+3. **QA jump is front-of-queue, not preemptive** — the test in progress finishes. _Assumed._ _Check:_ trivial, ask the lab lead.
+4. **Saturday overtime adds line hours only, not lab or changeover-crew hours.** _Assumed and probably wrong in at least one direction._ _Check:_ the ops director question above.
+
+Nothing needed before tomorrow. See you then.
+
+---
+
+**Expert (Marta)**:
+
+Ha — the Saturday-lab thing is a genuinely good catch, I've never once thought about whether the lab covers it. I'll ask the ops director point blank tomorrow before our slot if I catch him.
+
+Quick gut reactions on the three probes, so tomorrow's faster:
+
+1. If both lines were waiting on Meridian whites, I think I'd go by whichever ships sooner — so yes, "Meridian first" is really shorthand for "most urgent first," Meridian just happens to almost always be the most urgent thing in the room. I'd want to think about whether there's a case where I'd break that, but my instinct says urgency wins even within Meridian.
+
+2. Honestly — yes, guilty, I was thinking about Monday. Ending the week with Line 3 dirty from a white means Monday probably starts with a tint anyway and I've bought myself nothing; ending clean-ish or on a family that's likely to continue into next week is a real thing I do, even if I don't always say it out loud.
+
+3. QA jump — maybe two, three times a month, not every week. If it were weekly the lab lead would start pushing back the way she did that one time.
+
+See you tomorrow, and nice catch on the lab.
+
+---
+
+**Interviewer**:
+
+Good — those three tighten a lot for free.
+
+**What they settle:**
+
+- **Priority rule is "earliest ship window first, Meridian-weighted"**, not a hard account hierarchy. That's better news than a strict rule: it's a single sortable key, so the model can implement your current policy _and_ test alternatives (pure due-date, pure campaign, campaign-with-Meridian-override) without restructuring anything.
+- **You schedule with a terminal state value.** That's a real modelling requirement and I'd have got it wrong: without it, a week-long simulation happily ends with all three lines dirty on Friday, because the wash-back cost falls outside the window and the model never pays it. I'll add an end-of-week charge for leaving a line in a state that the following Monday's likely demand doesn't match — effectively "what changeover would Monday have to buy." That also stops the model from recommending changeover-avoidance tricks that just push cost over the horizon.
+- **QA jump ≈ 2–3 per month** — a spendable allowance, roughly 0.6/week. Modelled as a budget with a refusal probability that rises as you spend it, which reproduces the lab lead pushing back.
+
+**Ledger additions:**
+
+1. **Changeover-crew priority key = earliest promise-date-at-risk, with Meridian ordered first among ties.** _From probe 1._ _Check:_ if you find a real case where you'd knowingly let the sooner-shipping order wait, tell me — it would mean the key needs a second term.
+2. **End-of-horizon state value: each line charged at Friday close for the expected changeover into next week's likely first job.** _My construct, not your words — you described the behaviour, not the accounting._ _Check:_ look at what actually ran Monday morning on each line for the last few weeks; if it usually matches Friday's family, my charge is roughly right.
+3. **QA jump allowance = 0.6/week, refusal probability rising with recent usage.** _From probe 3._ _Check:_ none needed; sensitivity-test it.
+
+**Tomorrow's slot is now down to three things**, which should fit comfortably in fifteen minutes:
+
+1. **Splitting and campaigning** — must an order's batches run contiguously; what really happens when commercial asks to split across two lines; has it ever worked.
+2. **Unwritten rules** — week-one mistakes, always/nevers, the rules that exist because of one bad incident.
+3. **Whatever the two data pulls and your logistics/ops-director conversations turn up** — arrivals, release lag, breakdown durations, Saturday lab cover.
+
+Then I read the whole thing back and build. See you then.
+
+---
+
+**Expert (Marta)**:
+
+Sounds right — see you tomorrow, I'll have the logistics and ops director answers plus whatever comes back from maintenance and ERP by then, even if it's partial.
+
+---
+
+**Interviewer**:
+
+Good. One request on the pulls, whatever shape they arrive in: send them raw rather than tidied. If the CMMS export is 900 rows of five-minute stops with four monsters buried in it, the monsters are the point and I'd rather find them myself than have them pre-summarised away. Same for the order book — I want the messy rows, the cancelled lines, the ones with blank promise dates. The gaps tell me what the plant doesn't record, which is itself a modelling input.
+
+If either pull is late, we still run the slot: items 1 and 2 are pure head-knowledge and don't depend on the data. I'll build with flagged placeholders and swap them out when the exports land.
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Understood — raw and messy it is, no cleaning up on my end. I'll tell whoever's pulling it not to bother tidying, just dump what the system gives them.
+
+See you tomorrow.
+
+---
+
+**Interviewer**:
+
+Understood — raw is right.
+
+I'll use the gap to draft the structural skeleton, so tomorrow's fifteen minutes goes entirely on splitting/campaigning, the unwritten rules, and the data — not on me reading back things you've already told me twice.
+
+One thing you don't need to answer now, but it surfaced while I was laying out the net, and it's structural enough that I'd rather you see it coming than have me guess:
+
+**Is a changeover a whole-line event, or does it cascade stage by stage?** You told me the line pipelines — mix can start the next batch while fill finishes the last. But if the next batch is a _different family_, that can't be true unless the washdown happens stage-by-stage as each empties: mix gets cleaned first, then mill, then tint, then fill, with the new order following the cleaning down the line. The alternative is that the whole line drains, the crew washes everything, then the new order starts. Those two produce very different answers to your run-size question — the cascading version makes changeovers much cheaper for long runs, because the wash overlaps with the tail of the previous order. I suspect the truth is "mostly whole-line for the big tint→white washdown, but the small rinses are more casual," but that's me guessing, and it's assumption 16 in the ledger until you tell me.
+
+Provisional skeleton, two minutes to eyeball — tell me tomorrow if the shape is wrong:
+
+- **Token = one batch**, carrying colour: order ID, account, SKU, family, tint depth, promise date, order's batch index and count.
+- **Per line, in series:** Mix → tank → Mill → tank → Tint/Letdown → tank → Fill → QA Hold → Released → Shipped. Tanks capacity 1 (Line 1 mill→fill) or 2 (Lines 2, 3), which is where your Line 1 backup comes from.
+- **Per line, one setup-state place** holding a token for the family/SKU the line is currently dressed for. Changeover transitions consume the crew, the old state token, and emit the new one.
+- **Shared resources as single-token places:** changeover crew (one indivisible 2-person server), lab (two analysts, day shift), each line's shift calendar as an availability gate. The overnight black hole falls straight out of the calendars — no special mechanism needed.
+- **Order release** as a source transition gated by the ERP release timestamp, which is the thing your idle-vs-washdown dilemma actually hangs on.
+- **Scoring** as sink-side observers: board metric (binary, vs promise), true cost (Meridian step + others' slope + changeover hours + end-of-week state charge).
+
+1. **Changeover granularity — whole-line vs cascading per stage.** _Assumed whole-line for washdowns ≥2h, cascading for rinses <1h._ _Check:_ one question tomorrow; it materially changes the split-across-lines answer.
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+That skeleton looks right to me at the level I can judge it — I recognize the plant in it, which is more than I expected to say about a diagram.
+
+On the changeover granularity, since you asked me to sit with it: my honest instinct, without having ever watched it stage-by-stage on purpose, is that you're right — the big tint-to-white washdown really does feel like a whole-line stop, everything's dirty and everyone's waiting, nothing pipelines through it. The quick rinses I genuinely don't know if they cascade or not, I've just never watched closely enough to say, I always think of the line as "down for 25 minutes" rather than picturing what's happening stage by stage. I'll actually go stand at Line 2 for one of the small rinses before tomorrow and watch instead of guessing — that one's cheap to check and I'd rather give you a real answer than a guess dressed up as one.
+
+See you tomorrow.
+
+---
+
+**Interviewer**:
+
+That's the right instinct, and it'll take you five minutes. So the observation is worth having, here's what to look for — otherwise it's easy to watch a rinse and come away with "yep, took 25 minutes," which is what you already know.
+
+**Three things to note, in this order:**
+
+1. **Does mix restart before fill is clean?** That's the whole question. If you see the mixer running the new product while the fill head is still being wiped, it cascades. If everyone stands around until the last stage is signed off, it's whole-line.
+2. **Do both techs work the same stage, or split up?** For a quick rinse specifically — if one tech does mix and mill while the other does tint and fill, that's not just cascading, it's a _parallel_ crew, and my "one indivisible 2-person server" assumption (ledger 5) is wrong for small changeovers. That would meaningfully change crew contention, because it would mean two quick rinses on two lines might actually be possible at once.
+3. **When does the clock actually start and stop?** Is the 25 minutes wall-to-wall from last-batch-out to first-batch-in, or is there dead time either side — waiting for the tech to arrive, waiting for a sign-off, waiting for the line lead to confirm? Dead time that isn't crew time is a different fix from crew time.
+
+If you can, note the wall-clock times of each — start, first stage clean, last stage clean, next batch started. Four timestamps on your phone is enough.
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Good, that's specific enough that I'll actually catch something real instead of just confirming what I already believe. I'll grab those four timestamps and watch for the split-crew thing especially — I hadn't even considered they might work separate stages, but now you say it I think I actually have seen the two of them go to opposite ends of the line at once and just never registered it as meaningful.
+
+See you tomorrow with real numbers instead of a vibe.
+
+---
+
+**Interviewer**:
+
+Good. One addition while you're standing there, since it costs nothing: **if you do see them split to opposite ends, note whether that's rinse-only or whether they'd split on a big washdown too.** My guess from what you said earlier — "genuinely a two-person job, stuff to hold and check simultaneously" — is that the big ones force them together and only the small ones allow splitting. If that's right, the crew is one server for washdowns and two for rinses, which is an easy thing to represent and a slightly awkward thing to discover later.
+
+And if what you see contradicts the skeleton, that's a good outcome, not a setback — it's cheaper to find it now than after I've built the net around it.
+
+See you tomorrow.
+
+---
+
+**Expert (Marta)**:
+
+Good point — I'll watch for exactly that distinction, whether the splitting is a rinse-only thing or whether they'd do it on a washdown too if they had reason to. And you're right, I'd much rather walk in tomorrow saying "actually, no" than have you build the whole thing around something I half-remembered.
+
+See you tomorrow.
+
+---
+
+**Interviewer**:
+
+See you tomorrow.
+
+I'll have the net drafted to the point where only the open questions are holes — splitting/campaigning, changeover granularity, and the placeholder distributions for breakdowns and arrivals. Tomorrow: your three answers, the data if it's landed, then I read the whole thing back for correction and build.
+
+---
+
+**Expert (Marta)**:
+
+I really do have to stop here. Please produce the model now with everything you have.
+
+---
+
+**Interviewer**:
+
+Understood. Here is the model as it stands, built on what you gave me, with everything I had to invent flagged rather than smuggled.
+
+**One honest caveat up front:** we stopped before covering three things I'd listed as material — order splitting/campaigning contiguity (your run-size question), the unwritten rules, and the two data pulls. The model is built and runnable without them, but two of your three headline questions are affected. I've said exactly where in Section C, and the ledger tells you which dials to turn when the data lands.
+
+---
+
+# A. THE MODEL
+
+A coloured, timed Petri net with priority-resolved conflicts. Tokens are **batches**; colours carry the order attributes; timed transitions carry the durations; shared resources are capacity-limited places; calendars are gate places. Everything is named in your vocabulary.
+
+## A.0 Global switches (set these per experiment)
+
+| Switch           | Values                                                                    | Default           | Why it exists                                                                                                 |
+| ---------------- | ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------- |
+| `TIME_BASIS`     | `SHEET` \| `GUT`                                                          | `GUT`             | Standard matrix times vs your padding. Running both tells you whether it's worth timing changeovers properly. |
+| `CO_GRANULARITY` | `WHOLE_LINE` \| `CASCADE` \| `SPLIT_BY_SIZE`                              | `SPLIT_BY_SIZE`   | Whole-line for washdowns ≥2 h, cascading for rinses <1 h. Unresolved — you were going to watch a rinse.       |
+| `CREW_MODE`      | `ONE_SERVER` \| `SPLIT_ON_RINSE`                                          | `ONE_SERVER`      | Whether the two techs can work two rinses at once. Unresolved — the thing you'd half-noticed.                 |
+| `RELEASE_POLICY` | `TRUCK_CONFIRMED` \| `STANDING_MERIDIAN`                                  | `TRUCK_CONFIRMED` | Models the logistics lever. This is the cheap-fix experiment.                                                 |
+| `SAT_LAB_COVER`  | `OFF` \| `ON`                                                             | `OFF`             | Whether Saturday overtime includes a lab analyst.                                                             |
+| `SEQ_RULE`       | `CAMPAIGN_FIRST` \| `DUE_DATE_FIRST` \| `CAMPAIGN_WITH_MERIDIAN_OVERRIDE` | `CAMPAIGN_FIRST`  | Your current policy is the default; the others are the alternatives to test.                                  |
+| `EOW_CHARGE`     | `ON` \| `OFF`                                                             | `ON`              | End-of-week dirty-line charge. Off = the model cheats.                                                        |
+
+## A.1 Colour sets
+
+```
+FAMILY   = { WHITE, TINT, SPECIALTY }
+DEPTH    = { NA, LIGHT, DARK }              (* tints only *)
+ACCOUNT  = { MERIDIAN, OTHER }
+LINE     = { L1, L2, L3 }
+
+SKU      = record { skuId : STRING,
+                    family : FAMILY,
+                    depth : DEPTH,
+                    meridianQual : BOOL,     (* Line 2 fill-area qualification *)
+                    l3Qual : BOOL }          (* on Line 3's validated list *)
+
+ORDER    = record { oid : STRING,
+                    account : ACCOUNT,
+                    sku : SKU,
+                    qty : INT,
+                    bookTime : TIME,         (* Sunday 23:00 *)
+                    releaseTime : TIME,      (* ERP status -> released *)
+                    promiseTime : TIME,      (* the truck it must make *)
+                    wholeWeek : BOOL,        (* account's whole-week requirement *)
+                    line : LINE,             (* set by allocation *)
+                    nBatches : INT }
+
+BATCH    = record { oid, idx, of : INT,
+                    units : INT,
+                    sku : SKU,
+                    account : ACCOUNT,
+                    promiseTime : TIME,
+                    testFlag : BOOL,         (* does QA sample this one *)
+                    startedAt : TIME }
+
+SETUP    = record { line : LINE, sku : SKU,
+                    family : FAMILY, depth : DEPTH }   (* what the line is dressed for *)
+
+TECH     = unit                              (* changeover crew member *)
+ANALYST  = unit                              (* lab *)
+```
+
+## A.2 Places
+
+**Order-level (plant-wide)**
+
+| Place          | Contents                                         | Capacity |
+| -------------- | ------------------------------------------------ | -------- |
+| `P_Book`       | ORDER, status pending                            | ∞        |
+| `P_Allocated`  | ORDER with `line` set, still pending ERP release | ∞        |
+| `P_Releasable` | ORDER, ERP-released, awaiting line               | ∞        |
+| `P_OrderDone`  | ORDER, all batches QA-released                   | ∞        |
+| `P_Shipped`    | ORDER, on the truck                              | ∞        |
+
+**Per line L ∈ {L1, L2, L3}** (the flow shop, exactly as you walked it)
+
+| Place               | Contents                                    | Capacity                                                |
+| ------------------- | ------------------------------------------- | ------------------------------------------------------- |
+| `P_MixQueue_L`      | BATCH awaiting mix                          | ∞                                                       |
+| `P_Mixing_L`        | BATCH in mix vessel                         | 1                                                       |
+| `P_Tank_MixMill_L`  | BATCH in holding tank                       | `TANKCAP(L)`                                            |
+| `P_Milling_L`       | BATCH in mill                               | 1                                                       |
+| `P_Tank_MillFill_L` | BATCH in holding tank                       | `TANKCAP(L)` ← **Line 1 = 1, the backup you described** |
+| `P_Tinting_L`       | BATCH in tint/letdown                       | 1                                                       |
+| `P_Tank_TintFill_L` | BATCH in holding tank                       | `TANKCAP(L)`                                            |
+| `P_Filling_L`       | BATCH at fill head                          | 1                                                       |
+| `P_SetupState_L`    | exactly one SETUP token                     | 1                                                       |
+| `P_LineIdleClean_L` | 1 token iff no batch anywhere in L's stages | 1                                                       |
+| `P_LineUp_L`        | 1 token iff not broken down                 | 1                                                       |
+| `P_ShiftOpen_L`     | 1 token iff a shift is manned               | 1                                                       |
+| `P_COinProgress_L`  | 1 token during a whole-line changeover      | 1                                                       |
+
+`TANKCAP(L1) = 1` (mill→fill specifically; the other two tanks on L1 = 2), `TANKCAP(L2) = TANKCAP(L3) = 2`.
+
+**Shared resources**
+
+| Place           | Contents                            | Capacity           | Notes                                                     |
+| --------------- | ----------------------------------- | ------------------ | --------------------------------------------------------- |
+| `P_CrewPool`    | TECH tokens                         | 2                  | Both techs = one crew unless `CREW_MODE = SPLIT_ON_RINSE` |
+| `P_CrewShift`   | 1 token iff crew on shift or flexed | 1                  | Absence of this token is the **2 a.m. black hole**        |
+| `P_QAHold`      | BATCH awaiting sample               | ∞                  | The pallets sitting in hold                               |
+| `P_LabAnalysts` | ANALYST tokens                      | 2                  |                                                           |
+| `P_LabShift`    | 1 token iff lab manned              | 1                  | Absence = the **Friday-evening trap**                     |
+| `P_Testing`     | BATCH under test                    | 2                  |                                                           |
+| `P_QAReleased`  | BATCH released                      | ∞                  |                                                           |
+| `P_JumpBudget`  | jump tokens                         | replenished 0.6/wk | The favour-with-the-lab-lead allowance                    |
+
+## A.3 Transitions
+
+### Arrivals and release
+
+| Transition     | Guard                                               | Timing                           | Effect                                                                                                                                                            |
+| -------------- | --------------------------------------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `T_BookLands`  | fires Sun 23:00 weekly                              | —                                | Emits ~40 ORDER tokens into `P_Book` (composition in ledger 27–29)                                                                                                |
+| `T_Allocate`   | ORDER in `P_Book`; line qualification guard (below) | Mon 07:00 (fires for whole book) | Sets `line`, computes `nBatches = ceil(qty / VESSEL(line))`, moves to `P_Allocated`                                                                               |
+| `T_ERPRelease` | ORDER in `P_Allocated`                              | at `releaseTime`                 | → `P_Releasable`. **This is the transition your idle-vs-washdown dilemma hangs on.** Under `STANDING_MERIDIAN`, Meridian orders bypass and release at allocation. |
+| `T_Explode`    | ORDER in `P_Releasable`, line's queue accepts it    | instant                          | Emits `nBatches` BATCH tokens into `P_MixQueue_L`, sets `testFlag` per sampling rule                                                                              |
+
+**Allocation qualification guard (hard constraints):**
+
+```
+account = MERIDIAN            ⇒  line = L2                     (audit qualification)
+sku.family = SPECIALTY        ⇒  line = L1                     (L2 not piped for clears)
+line = L3                     ⇒  sku.l3Qual = true             (validated-SKU list)
+```
+
+### Production stages (per line, per batch)
+
+Each stage is a pair: `T_Start_<stage>_L` and `T_End_<stage>_L`.
+
+| Transition                      | Preconditions                                                                                                                                                      | Duration                                                        |
+| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- | ----------------------------------------------------------- |
+| `T_StartMix_L`                  | BATCH in `P_MixQueue_L` (chosen by sequencing policy), `P_Mixing_L` free, `P_SetupState_L` matches batch SKU, `P_ShiftOpen_L`, `P_LineUp_L`, no `P_COinProgress_L` | —                                                               |
+| `T_EndMix_L`                    |                                                                                                                                                                    | `units / RATE(mix, family, L)`                                  |
+| `T_StartMill_L`                 | token in `P_Tank_MixMill_L`, `P_Milling_L` free, gates as above                                                                                                    | —                                                               |
+| `T_EndMill_L`                   | **blocks if `P_Tank_MillFill_L` at capacity** ← Line 1's problem                                                                                                   | `units / RATE(mill, family, L)`                                 |
+| `T_StartTint_L` / `T_EndTint_L` | as above                                                                                                                                                           | `units / RATE(tint, family, L)`                                 |
+| `T_StartFill_L`                 |                                                                                                                                                                    | —                                                               |
+| `T_EndFill_L`                   |                                                                                                                                                                    | `units / RATE(fill, family, L)` × Noise + JamAdder + StallAdder |
+| `T_ToQAHold`                    | fill complete                                                                                                                                                      | instant                                                         | → `P_QAHold` if `testFlag`, else straight to `P_QAReleased` |
+
+**Rates (units/hour).** Derived from your per-batch times, expressed the way your sheet does it:
+
+| Stage             | WHITE              | TINT | SPECIALTY     |
+| ----------------- | ------------------ | ---- | ------------- |
+| Mix (all lines)   | 3600               | 3600 | 3600          |
+| Mill L1 / L2 / L3 | 2900 / 2900 / 2900 | 1450 | 480 (L1 only) |
+| Tint-letdown      | 12000 (negligible) | 1450 | 2400          |
+| **Fill L1**       | **700**            | 700  | 650           |
+| **Fill L2**       | **950**            | 800  | n/a           |
+| **Fill L3**       | **900**            | 800  | n/a           |
+
+Note what this reproduces: whites are fill-bound and L2 is ~35% faster than L1; tints are mill/tint-bound so L1 and L2 come out **nearly even on tints**, which is the thing you noticed and couldn't explain; specialty is mill-bound on L1.
+
+**Vessel sizes (units/batch):** L1 = 1,100; L2 = 1,650; L3 = 1,350 _(the one you told me not to quote)_.
+
+**Fill-stage disruption (the fat right tail):**
+
+```
+Noise       ~ LogNormal(median 1.00, σ 0.06)      (* thin upside — fill runs near rate *)
+JamAdder    = 0 w.p. 0.90 ; Uniform(0.33, 0.50) h w.p. 0.10     (* small filler jam *)
+StallAdder  = 0 w.p. 0.95 ; Uniform(0.25, 1.00) h w.p. 0.05     (* packaging/labels not restocked *)
+```
+
+Jams and stalls are kept separate deliberately — you may find the warehouse restock is the cheaper fix.
+
+### Changeover
+
+`T_Changeover_L` fires when the next batch selected for line L has a SKU that doesn't match `P_SetupState_L`.
+
+**Preconditions (WHOLE_LINE mode — the ≥2 h washdowns):**
+
+- `P_LineIdleClean_L` (every stage empty — the line has drained)
+- 2 TECH tokens from `P_CrewPool`
+- `P_CrewShift` present
+- Emits `P_COinProgress_L`, consumes old SETUP, emits new SETUP after duration
+
+**Preconditions (CASCADE mode — the <1 h rinses):** four sub-transitions `T_CO_Mix_L`, `T_CO_Mill_L`, `T_CO_Tint_L`, `T_CO_Fill_L`, each requiring only its own stage to be empty and 1 or 2 TECH tokens per `CREW_MODE`. The new order follows the cleaning down the line.
+
+**Changeover matrix (hours).** SHEET = your spreadsheet; GUT = your padding.
+
+| From → To                                 | SHEET    | GUT                                  |
+| ----------------------------------------- | -------- | ------------------------------------ |
+| WHITE → WHITE, same SKU                   | 0.25     | 0.25                                 |
+| WHITE → WHITE, different SKU              | 0.42     | 0.42                                 |
+| WHITE → TINT                              | 0.75     | 0.75                                 |
+| TINT → TINT, light→light or dark→dark     | 0.58     | 0.58                                 |
+| TINT → TINT, **dark→light**               | 0.58     | **1.25**                             |
+| **TINT → WHITE**                          | **3.00** | **3.50** (3.75 if previous was dark) |
+| any ↔ SPECIALTY                           | 2.00     | 2.00                                 |
+| Line 1 multiplier on any changeover ≥ 2 h | 1.00     | **1.15**                             |
+
+**The punitive mechanism (from your Scenario A answer):** because the crew requires `P_CrewShift`, a line that misses the crew window doesn't wait for the crew to _finish_ — it waits until the crew's next shift _starts_. Line 1 in your scenario doesn't lose 2 hours, it loses the whole overnight. This falls out of the net structure; no special rule needed.
+
+### QA
+
+| Transition  | Preconditions                                           | Duration                                                                                                     |
+| ----------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
+| `T_Sample`  | BATCH in `P_QAHold`, ANALYST free, `P_LabShift`         | WHITE 3.5 h, TINT 4.0 h, SPECIALTY 5.0 h (median, LogNormal σ 0.25)                                          |
+| `T_Release` | test complete                                           | instant → `P_QAReleased`                                                                                     |
+| `T_Jump`    | BATCH is Meridian-critical **and** jump token available | Moves batch to head of `P_QAHold`; consumes 1 jump token; **not preemptive** — the test in progress finishes |
+
+Jump refusal: `P(refuse) = min(0.8, 0.15 × jumps_used_this_month)` — reproduces the lab lead pushing back as you spend the favour.
+
+**Sampling rule:** first batch of an order always; every 3rd thereafter; **last batch of an order always** (this is what makes the order held up by its last batch, as you described).
+
+### Shipping and scoring
+
+| Transition          | Preconditions                                | Effect                                                                  |
+| ------------------- | -------------------------------------------- | ----------------------------------------------------------------------- |
+| `T_OrderComplete`   | all of an order's batches in `P_QAReleased`  | → `P_OrderDone`                                                         |
+| `T_Ship`            | order complete, truck departure time reached | → `P_Shipped`, records `shipTime`                                       |
+| `T_ScoreOrder`      | on shipping                                  | writes board metric + true cost                                         |
+| `T_EndOfWeekCharge` | Fri 22:00                                    | charges each line for the changeover next Monday's first job would need |
+
+### Breakdowns
+
+| Event                                                      | Rate                                           | Duration                         |
+| ---------------------------------------------------------- | ---------------------------------------------- | -------------------------------- |
+| **Major outage** (mill motor class) — removes `P_LineUp_L` | 0.038 per line-week (~1 per 6 months per line) | LogNormal median 48 h, P90 120 h |
+| **Bad filler jam** — blocks `P_Filling_L`                  | 0.5 per line-week                              | LogNormal median 3 h, P90 6 h    |
+
+Repair only proceeds during manned hours (a Friday-night motor failure is not being fixed Saturday).
+
+## A.4 Calendars (gate sub-nets)
+
+| Gate                               | Pattern                                                                                                                                          |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `P_ShiftOpen_L1`, `P_ShiftOpen_L2` | Mon–Fri 06:00–22:00 (two shifts, handover mid-batch permitted)                                                                                   |
+| `P_ShiftOpen_L3`                   | Mon–Fri 06:00–14:00 (day only)                                                                                                                   |
+| `P_CrewShift`                      | Mon–Fri 07:00–15:30 base; extended 05:00–19:00 **for a changeover pre-arranged ≥8 h ahead**                                                      |
+| `P_LabShift`                       | Mon–Fri 07:00–17:00                                                                                                                              |
+| Saturday overtime                  | Adds `P_ShiftOpen_L1` or `L2` Sat 06:00–18:00. Requires trigger by **Wed 17:00**. **Adds no lab and no crew hours** unless `SAT_LAB_COVER = ON`. |
+| Trucks                             | Depart 06:00 daily, Mon–Fri                                                                                                                      |
+
+## A.5 The policy layer — conflict resolution
+
+Petri nets need explicit resolution wherever transitions compete. Every one of these is a policy you told me, and every one is swappable.
+
+**Conflict 1 — two lines want the changeover crew.**
+Priority key: `(is_Meridian_enabling DESC, earliest_promise_at_risk ASC)`. **Non-preemptive** — an in-progress changeover is never abandoned. Loser waits for crew _and_ `P_CrewShift`, which is where the overnight loss comes from.
+
+**Conflict 2 — which batch starts next on a line (`SEQ_RULE`).**
+
+- `CAMPAIGN_FIRST` _(your current behaviour)_: group by family to avoid changeover; within a campaign, earliest promise first; break the campaign only if a due date would actually be missed.
+- `DUE_DATE_FIRST`: pure earliest-promise.
+- `CAMPAIGN_WITH_MERIDIAN_OVERRIDE`: campaign, but any Meridian order at risk jumps immediately.
+
+**Conflict 3 — idle vs washdown** _(your headline decision)_. When a line goes empty and the next same-family order isn't releasable yet:
+
+```
+IF (wash away + wash back) would touch any Meridian order's ship window
+   THEN idle                                      (* the cliff *)
+ELSE IF gap_hours ≥ (wash_away + gap_job_runtime + wash_back)
+   THEN take the gap job
+ELSE idle
+```
+
+This is your Q10 answer, implemented literally. It's also a _replaceable_ rule — the point of the model is to run alternatives against it.
+
+**Conflict 4 — lab queue.** FIFO on arrival at `P_QAHold`, except jump tokens. Displaced work simply waits, and if it's late in the week it hits the Friday trap — which is exactly the cost of a jump.
+
+**Conflict 5 — Saturday ask.** Trigger: at Wed 17:00, if any Meridian order's projected completion exceeds its ship window by ≥1 shift, request overtime on whichever of L1/L2 carries it. Non-Meridian shortfalls do **not** trigger a request (your Coastal case: you didn't ask, it shipped a day late, nobody outside noticed).
+
+## A.6 Scoring
+
+**Board metric** — binary on-time % against promise date. Reported separately so you can tell your boss what the board will say.
+
+**True cost** — unit is one line-hour.
+
+```
+Changeover      = 1.0 × changeover_hours                    (* lost line time *)
+Idle            = 0                                          (* invisible on paper; hurts only via the clock *)
+
+Meridian late   = 200  (step, on missing the truck at all)  + 1.0 × hours_late
+Other late      = 0                    for hours_late ≤ 4
+                = 0.5 × (h − 4)        for 4 < h ≤ 24
+                = 10 + 4.0 × (h − 24)  for h > 24
+Whole-week req. = × 2 multiplier on the above
+
+End-of-week     = expected changeover hours from each line's Friday state
+                  into next Monday's first job
+```
+
+Calibration check on these weights: they reproduce your two bets. Meridian 6 h late = 206 ≫ 4 changeover-hours, so you idle. Coastal 6 h late = 1.0 < 4 changeover-hours, so you take the tint job. Coastal 48 h late = 106 ≫ 4, so you don't. That's your cliff and your slope.
+
+## A.7 Experiments mapped to your three questions
+
+| Your question                                                                    | Run                                                                                                                                                                                                                       |
+| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _"If Line 1's mill motor takes four days again, what do I move and what slips?"_ | Inject a 96 h `P_LineUp_L1` outage at chosen points in the week; compare re-allocation policies. Note L1 holds all specialty, so specialty has nowhere to go — the model will show you that as a hard block, not a delay. |
+| _"Idle an hour or wash down?"_                                                   | Sweep the Conflict-3 rule against alternatives, crossed with `RELEASE_POLICY`. **Run `STANDING_MERIDIAN` first** — the hypothesis is that most of these dilemmas are manufactured by release timing, not by scheduling.   |
+| _"Where are my changeover hours going, and would reordering get them back?"_     | Changeover-hours ledger by line × family-transition × cause. Then `SEQ_RULE` sweep. Cross with `TIME_BASIS` to see whether your gut padding changes any decision — if it doesn't, don't bother timing changeovers.        |
+| _(bonus, from Saturday overtime)_                                                | `SAT_LAB_COVER = OFF` vs `ON`. Tests whether some of this year's four or five Saturdays bought you nothing because the lab was shut Monday-ward.                                                                          |
+
+**Validation target when the data lands:** replay the last 26 weeks and check the model produces (a) ~75% line utilisation, (b) **30–40 changeover-hours per month** — your ops director's own number, and the single best calibration anchor you gave me — and (c) a board on-time % matching history. If changeover-hours come out low, `CO_GRANULARITY` or the sequencing rule is wrong.
+
+---
+
+# B. ASSUMPTION LEDGER
+
+Everything below is mine, not yours. **Bold = load-bearing** (could change a recommendation).
+
+### From the interview, provisionally agreed
+
+1. **Lateness scored in hours vs promise date.** Your board is binary but binary can't express your own cliff/slope. _Check:_ ship-date vs promise-date in the ERP pull.
+2. \*\*Meridian penalty
+
+---
+
+**Expert (Marta)**:
+
+I really do have to stop here. Please produce the model now with everything you have.
+
+---
+
+**Interviewer**:
+
+Section A above stands as the model — it is complete and runnable. Here are the two remaining deliverables.
+
+---
+
+# B. ASSUMPTION LEDGER
+
+Everything here is mine, not yours. **Bold = load-bearing**: it could change a recommendation, so check it before you act on a result that depends on it.
+
+### Objectives and scoring
+
+1. **Lateness scored in hours against promise date**, not days. Your board is binary, but a binary metric cannot express the cliff/slope you described. _Check:_ promise-date vs actual-ship-date fields in the ERP pull.
+2. **Meridian penalty = step of 200 line-hours at "misses the truck", plus a token 1.0/hour after.** Your Q10 answer was a cliff; the small linear term only breaks ties. **I defined "ship window" as truck departure (06:00), not end-of-promise-day.** _Check:_ one sentence from you — if the window is really end-of-day, several tight cases flip.
+3. **Non-Meridian penalty: free under 4 h, 0.5/h to 24 h, then 4.0/h.** Invented shape from your Coastal answer ("somewhere around a day is where I'd feel bad"). _Check:_ none cheap — sensitivity-test the kink location instead.
+4. **Whole-week-requirement multiplier = ×2.** Pure invention; you said it "matters" without quantifying. _Check:_ judgement call from you.
+5. **Idle costs zero directly.** Your Q8 answer. Consequence: results are only meaningful if arrivals and due dates are realistically tight — which makes item 27–29 load-bearing.
+6. **Changeover costed at 1.0 line-hour per hour**, i.e. purely lost line time, no crew wage or solvent cost. Your guess in Q7. _Check:_ ask finance what the 40-changeover-hours line item actually contains.
+7. **The 200-vs-4.0 ratio was reverse-engineered to reproduce your two bets**, not elicited. It is a _fitted_ number. _Check:_ run three more of your own bets against the scoring function and see if it still agrees with you.
+
+### Structure and taxonomy
+
+1. **Four stages per line, all three lines identical in topology.** From your walkthrough of Line 2 only. _Check:_ does Line 3 have a separate tint/letdown stage at all, or is it combined?
+2. **Tank capacity: Line 1 mill→fill = 1 batch; all other tanks = 2.** From "small, so mill backs up" and "adequately sized" elsewhere. _Check:_ nameplate volumes ÷ batch size, ten minutes on the floor.
+3. **Vessel sizes: L1 = 1,100, L2 = 1,650, L3 = 1,350 units.** You explicitly said don't quote L3. _Check:_ mix vessel nameplate, 30 seconds.
+4. **14 SKUs split 4 white / 8 tint / 2 specialty**, with tint depth assigned arbitrarily. _Check:_ the SKU master; also tells me which tints are dark.
+5. **Line 3's unqualified list = 2 tint SKUs.** Your number, but I picked _which_ two. _Check:_ the quality validation list.
+6. **Specialty runs on Line 1 only.** Follows from L2 not being piped and L3's list — but I never asked whether L3 can run specialty. _Check:_ one question. **If L3 can, the mill-motor scenario changes materially**, because specialty currently has nowhere to go.
+7. **Meridian orders are Line 2 only**, and this is absolute — no emergency override exists. _Check:_ has anyone ever run Meridian on L1 in a crisis?
+
+### Durations
+
+1. **Stage rates in the table are reconstructed from your per-batch estimates**, which you flagged as partly guesswork. The _pattern_ (whites fill-bound, L2 faster on whites, L1≈L2 on tints, specialty mill-bound) is yours; the numbers are mine. _Check:_ the sheet's units/hour per product per line — that's a direct calibration and you already have it.
+2. **Mix time identical across families and lines.** Never asked. Probably wrong for specialty.
+3. **Fill noise LogNormal σ=0.06, jam 10% at 20–30 min, packaging stall 5% at 15–60 min.** Jam frequency is yours; the stall frequency is invented, and **I invented the stall/jam split entirely** — you described both but never separated them. _Check:_ whether the CMMS distinguishes equipment faults from material starvation. It probably doesn't, in which case only your memory can separate them.
+4. **QA test durations: white 3.5 h, tint 4.0 h, specialty 5.0 h**, LogNormal σ=0.25. Only "about four hours for whites" is yours; the family differences and the spread are invented. _Check:_ lab lead, five minutes.
+5. **QA sampling rule: first batch, every third, and always the last.** You said "per some number of batches"; the "always the last" is my inference from your "held up by its last batch". _Check:_ lab lead.
+6. **Changeover matrix as tabulated**, both layers. SHEET values are your recollection of a spreadsheet neither of us has seen. _Check:_ open the spreadsheet.
+7. **GUT layer: dark→light tint 0.58→1.25 h; tint→white 3.0→3.5 h (3.75 after dark); Line 1 ×1.15 on washdowns.** All your gut, quantified by me. _Check:_ four timestamps on six changeovers — but run `TIME_BASIS` both ways _first_; if it changes no decision, don't bother.
+8. **Changeover granularity: whole-line ≥2 h, cascading <1 h.** Unresolved — you were going to watch a rinse. **This materially changes the split-across-lines answer**, because cascading makes changeovers much cheaper for long runs.
+9. **Crew is one indivisible 2-person server for all changeovers.** Unresolved — you'd half-noticed them working opposite ends of the line. If rinses can be split, two lines can rinse simultaneously and crew contention drops significantly.
+
+### Policies
+
+1. **Crew priority = Meridian-enabling first, then earliest promise at risk; non-preemptive.** From Scenario A and your follow-up that "Meridian first" is really shorthand for "most urgent first". _Check:_ whether an in-progress changeover has ever been abandoned.
+2. **A line missing the crew window waits for the crew's next shift start**, not merely until the crew frees up. From Scenario A. **This is the most punitive mechanism in the model** — it converts a 2-hour changeover into a lost overnight.
+3. **Crew flex window (05:00–19:00) requires ≥8 h notice.** Invented; you said flexing is "a normal ask" without saying how much warning it needs. _Check:_ ask the techs. **It directly governs whether an evening washdown happens or waits for morning**, which is the core of your headline decision.
+4. **QA jump: front-of-queue, non-preemptive, 0.6 tokens/week, refusal probability 0.15 × jumps-used-this-month.** The 2–3/month is yours; the refusal curve is invented to reproduce the one time you backed off.
+5. **Saturday overtime: triggered Wed 17:00, Meridian shortfall ≥1 shift, L1/L2 only, adds no lab or crew hours.** Trigger and timing are yours; **the "no lab cover" assumption is the one I most expect to be wrong in a useful direction.** _Check:_ the ops director question you were going to ask.
+6. **End-of-week charge = expected changeover into Monday's first job.** You described the behaviour ("ending clean-ish is a real thing I do"); the accounting is entirely my construct. _Check:_ compare each Friday's finishing family to the following Monday's first job for the last few weeks. Without this the model cheats by leaving every line filthy on Friday.
+
+### Boundary conditions
+
+1. **40 orders/week arriving Sunday 23:00 as a single batch**, of which 6–8 Meridian. Yours. But **arrivals within the week are modelled as zero — nothing arrives mid-week.** Never asked. If urgent mid-week orders exist, they're a major missing disturbance.
+2. **Order size distribution: Meridian LogNormal median 7,000 units; others median 2,500.** Derived from "one-third of volume from 6–8 of 40 orders". _Check:_ the ERP pull directly.
+3. **Promise dates 4–9 days after book date, uniform.** Pure invention — I never got commercial's padding. **This is the single most load-bearing unknown in the model**, because assumption 5 means idling is only penalised through due-date pressure. Too much padding and the model idles happily and tells you nothing. _Check:_ ERP pull, book-date vs promise-date.
+4. **ERP release lag: 24 h before promise date, ±12 h, same for all accounts.** Invented from "can lag by a day or so". **This is the mechanism that creates your headline dilemma**, so it deserves the release-timestamp field you added to the ask.
+5. **Breakdowns: major outage 1 per line per 6 months, median 48 h / P90 120 h; bad filler jam 0.5/line-week, median 3 h.** Anchored only to "the mill motor took four days once" and "a bad one every couple of weeks". **Entirely invented rates.** _Check:_ the CMMS export — this is what it's for.
+6. **Repairs only progress during manned hours.** Never asked; plausible but could be badly wrong for a contracted motor rebuild.
+7. **Simulation starts Monday 06:00 with all lines empty and clean, dressed for white.** Convenient, not real. _Check:_ run a one-week warm-up before scoring, which is what I'd recommend regardless.
+8. **No materials constraint.** You said you only watch for red flags. Means the model can never reproduce a resin shortage. _Check:_ how often does a red flag actually stop a run? If more than once a quarter, it needs modelling.
+
+---
+
+# C. WHAT THE MODEL DELIBERATELY LEAVES OUT
+
+**Left out because we ran out of time — these are real gaps, not simplifications:**
+
+1. **Batch contiguity and order splitting.** I never learned whether an order's batches must run contiguously on a line, or whether you can interleave two orders. The model currently assumes **contiguous** — once an order starts on a line, its batches run to completion before another order's batches begin. **This directly limits your run-size question.** The model can compare "whole order on L1" vs "half on L1, half on L2" as two allocations, and will correctly count the extra changeover on both lines — but it cannot represent the finer manoeuvres you might actually use, and if interleaving is possible in reality the model will overstate the cost of splitting. _This is the first thing to fix._
+
+2. **The unwritten rules.** We never covered week-one mistakes, always/nevers, or rules that exist because of one bad incident. In my experience this category produces two or three constraints that invalidate otherwise-attractive schedules — the model will likely propose something that makes you say "we'd never do that," and each time it does, that's an unwritten rule surfacing. **Treat those moments as findings, not bugs**, and send them to me.
+
+3. **All historical data.** Neither the CMMS export nor the ERP order book arrived. Every arrival, promise-date, release-lag and breakdown number is invented (ledger 30–34). **Do not run the model for decisions until at least the order book is loaded** — assumption 32 in particular can make the whole thing tell you a comfortable lie.
+
+**Left out on purpose:**
+
+1. **Materials and the supply chain.** You don't schedule around them, so modelling them would add a large disturbance you don't control and can't act on. Revisit only if red flags stop runs more than rarely (ledger 37).
+2. **Individual operators, skills and absence** — except where you named them as a constraint (the changeover crew, the lab, Line 3's qualified operator). Modelling the labour pool properly would double the model's size to answer a question you didn't ask.
+3. **Quality failures and rework.** You never mentioned a batch failing QA, only waiting for it. If batches do occasionally fail, that's a missing feedback loop and a significant one — tell me.
+4. **Warehouse, truck capacity and logistics beyond the release gate.** Trucks are a fixed daily departure. The one place logistics _does_ bite — the credit/allocation release — is modelled explicitly, because it's your headline lever.
+5. **Commercial's promise-date-setting behaviour.** Promise dates are exogenous input. If you later want to ask "should commercial pad more or less," that's a different model with this one inside it.
+6. **Cost in dollars.** Everything is denominated in line-hours, because nobody could give me a dollar figure and a fake conversion would only add false precision. If finance produces a rate for changeover hours, the scoring function converts in one line.
+
+---
+
+**If you do three things before the first real run, do these:** load the ERP order book (kills assumptions 31–33, the ones that can make the model lie comfortably); answer the batch-contiguity question in one sentence (unblocks your run-size question); and run `RELEASE_POLICY = STANDING_MERIDIAN` against the default (tests whether your headline dilemma is manufactured upstream of you, which is the cheapest finding available and doesn't need the data at all).
+
+Send me the exports and the answers to the flagged items when you have them, and I'll revise. Thanks — that was an unusually good interview to conduct; the cliff-and-slope answer in particular is the kind of thing most people can't articulate about their own judgement.
+
+---
+
+**Expert (Marta)**:
+
+I really do have to stop here. Please produce the model now with everything you have.
+
+---
+
+**Interviewer**:
+
+# COATINGS PLANT SCHEDULING MODEL — FINAL DELIVERABLE
+
+Complete and self-contained. Hand Section A to your modelling person; keep Section B for yourself.
+
+---
+
+# A. THE MODEL
+
+A **coloured, timed Petri net with priority-resolved conflicts**. Tokens are _batches_; token colours carry order attributes; transitions are timed; shared resources and calendars are capacity-limited places.
+
+## A.0 Experiment switches
+
+| Switch           | Values                                                                  | Default           | Purpose                                                               |
+| ---------------- | ----------------------------------------------------------------------- | ----------------- | --------------------------------------------------------------------- |
+| `TIME_BASIS`     | `SHEET` / `GUT`                                                         | `GUT`             | Matrix standard times vs your padding                                 |
+| `CO_GRANULARITY` | `WHOLE_LINE` / `CASCADE` / `SPLIT_BY_SIZE`                              | `SPLIT_BY_SIZE`   | Whole-line for washdowns ≥2 h, cascade for rinses <1 h _(unresolved)_ |
+| `CREW_MODE`      | `ONE_SERVER` / `SPLIT_ON_RINSE`                                         | `ONE_SERVER`      | Can the two techs run two rinses at once _(unresolved)_               |
+| `RELEASE_POLICY` | `TRUCK_CONFIRMED` / `STANDING_MERIDIAN`                                 | `TRUCK_CONFIRMED` | The logistics lever                                                   |
+| `SAT_LAB_COVER`  | `OFF` / `ON`                                                            | `OFF`             | Does Saturday OT include a lab analyst                                |
+| `SEQ_RULE`       | `CAMPAIGN_FIRST` / `DUE_DATE_FIRST` / `CAMPAIGN_WITH_MERIDIAN_OVERRIDE` | `CAMPAIGN_FIRST`  | Your current policy is default                                        |
+| `EOW_CHARGE`     | `ON` / `OFF`                                                            | `ON`              | End-of-week dirty-line charge; OFF lets the model cheat               |
+
+## A.1 Colour sets
+
+```
+FAMILY  = { WHITE, TINT, SPECIALTY }
+DEPTH   = { NA, LIGHT, DARK }
+ACCOUNT = { MERIDIAN, OTHER }
+LINE    = { L1, L2, L3 }
+
+SKU     = { skuId, family, depth, meridianQual, l3Qual }
+ORDER   = { oid, account, sku, qty, bookTime, releaseTime, promiseTime,
+            wholeWeek, line, nBatches }
+BATCH   = { oid, idx, of, units, sku, account, promiseTime, testFlag, startedAt }
+SETUP   = { line, sku, family, depth }
+TECH, ANALYST = unit tokens
+```
+
+## A.2 Places
+
+**Order level:** `P_Book` → `P_Allocated` → `P_Releasable` → `P_OrderDone` → `P_Shipped` (all ∞).
+
+**Per line L ∈ {L1,L2,L3}:**
+
+| Place               | Cap                                 |
+| ------------------- | ----------------------------------- |
+| `P_MixQueue_L`      | ∞                                   |
+| `P_Mixing_L`        | 1                                   |
+| `P_Tank_MixMill_L`  | TANKCAP                             |
+| `P_Milling_L`       | 1                                   |
+| `P_Tank_MillFill_L` | **L1 = 1** (your backup), L2/L3 = 2 |
+| `P_Tinting_L`       | 1                                   |
+| `P_Tank_TintFill_L` | TANKCAP                             |
+| `P_Filling_L`       | 1                                   |
+| `P_SetupState_L`    | 1 (what the line is dressed for)    |
+| `P_LineIdleClean_L` | 1 iff all stages empty              |
+| `P_LineUp_L`        | 1 iff not broken down               |
+| `P_ShiftOpen_L`     | 1 iff shift manned                  |
+| `P_COinProgress_L`  | 1 during whole-line changeover      |
+
+**Shared:** `P_CrewPool` (2 TECH), `P_CrewShift` (1 — its _absence_ is the 2 a.m. black hole), `P_QAHold` (∞), `P_LabAnalysts` (2), `P_LabShift` (1 — its absence is the Friday-evening trap), `P_Testing` (2), `P_QAReleased` (∞), `P_JumpBudget` (0.6 tokens/wk).
+
+## A.3 Transitions
+
+### Arrival and release
+
+| Transition     | Trigger            | Effect                                                                                                                                                  |
+| -------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `T_BookLands`  | Sun 23:00 weekly   | ~40 ORDERs → `P_Book`                                                                                                                                   |
+| `T_Allocate`   | Mon 07:00          | Sets `line` (guards below), `nBatches = ceil(qty/VESSEL(line))` → `P_Allocated`                                                                         |
+| `T_ERPRelease` | at `releaseTime`   | → `P_Releasable`. **This transition is what creates your idle-vs-washdown dilemma.** Under `STANDING_MERIDIAN`, Meridian releases at allocation instead |
+| `T_Explode`    | line queue accepts | Emits `nBatches` BATCH tokens; sets `testFlag`                                                                                                          |
+
+**Hard allocation guards:**
+
+```
+account = MERIDIAN      ⇒ line = L2        (audit qualification)
+family  = SPECIALTY     ⇒ line = L1        (L2 not piped for clears)
+line    = L3            ⇒ sku.l3Qual       (validated-SKU list)
+```
+
+### Production (per line, per batch)
+
+Paired `T_Start_<stage>_L` / `T_End_<stage>_L`. Start requires: batch available (per `SEQ_RULE`), stage free, `P_SetupState_L` matches SKU, `P_ShiftOpen_L`, `P_LineUp_L`, no `P_COinProgress_L`.
+`T_EndMill_L` **blocks if `P_Tank_MillFill_L` is full** — this reproduces Line 1's mill backup.
+
+**Rates (units/hour):**
+
+| Stage        | WHITE   | TINT | SPECIALTY |
+| ------------ | ------- | ---- | --------- |
+| Mix (all)    | 3600    | 3600 | 3600      |
+| Mill (all)   | 2900    | 1450 | 480 (L1)  |
+| Tint/letdown | 12000   | 1450 | 2400      |
+| **Fill L1**  | **700** | 700  | 650       |
+| **Fill L2**  | **950** | 800  | n/a       |
+| **Fill L3**  | **900** | 800  | n/a       |
+
+This reproduces: whites fill-bound, L2 ~35% faster than L1 on whites, **L1 ≈ L2 on tints** (the thing you noticed and couldn't explain), specialty mill-bound.
+
+**Vessels (units/batch):** L1 = 1,100 · L2 = 1,650 · L3 = 1,350 _(the one you said not to quote)_.
+
+**Fill disruption — fat right tail, thin left:**
+
+```
+Noise      ~ LogNormal(median 1.00, σ 0.06)
+JamAdder   = 0 w.p. .90 ; U(0.33, 0.50) h w.p. .10     (filler jam)
+StallAdder = 0 w.p. .95 ; U(0.25, 1.00) h w.p. .05     (packaging/labels)
+```
+
+Jams and stalls kept separate — the warehouse restock may be the cheaper fix.
+
+### Changeover
+
+`T_Changeover_L` fires when the next selected batch's SKU ≠ `P_SetupState_L`.
+
+- **WHOLE_LINE** (≥2 h washdowns): requires `P_LineIdleClean_L` (line fully drained) + 2 TECH + `P_CrewShift`.
+- **CASCADE** (<1 h rinses): four sub-transitions `T_CO_{Mix,Mill,Tint,Fill}_L`, each needing only its own stage empty and 1–2 TECH per `CREW_MODE`; the new order follows the cleaning down the line.
+
+**Matrix (hours):**
+
+| From → To                            | SHEET    | GUT                        |
+| ------------------------------------ | -------- | -------------------------- |
+| WHITE → WHITE same SKU               | 0.25     | 0.25                       |
+| WHITE → WHITE diff SKU               | 0.42     | 0.42                       |
+| WHITE → TINT                         | 0.75     | 0.75                       |
+| TINT → TINT (light→light, dark→dark) | 0.58     | 0.58                       |
+| TINT → TINT **dark→light**           | 0.58     | **1.25**                   |
+| **TINT → WHITE**                     | **3.00** | **3.50** (3.75 after dark) |
+| any ↔ SPECIALTY                      | 2.00     | 2.00                       |
+| L1 multiplier, changeovers ≥2 h      | 1.00     | **1.15**                   |
+
+**The punitive mechanism:** because changeover needs `P_CrewShift`, a line that misses the crew window waits for the crew's **next shift start**, not for the crew to free up. Your Scenario-A Line 1 loses the whole overnight, not two hours. This emerges from the net structure — no special rule.
+
+### QA
+
+| Transition  | Requires                                   | Duration                                                                            |
+| ----------- | ------------------------------------------ | ----------------------------------------------------------------------------------- |
+| `T_Sample`  | batch in `P_QAHold`, ANALYST, `P_LabShift` | WHITE 3.5 h / TINT 4.0 / SPECIALTY 5.0, LogNormal σ 0.25                            |
+| `T_Release` | test done                                  | instant                                                                             |
+| `T_Jump`    | Meridian-critical + jump token             | Front of queue, **non-preemptive**; `P(refuse) = min(0.8, 0.15 × jumps_this_month)` |
+
+**Sampling:** first batch always, every 3rd thereafter, **last batch always** — this is what makes an order hostage to its last batch.
+
+### Ship, score, break
+
+`T_OrderComplete` (all batches released) → `T_Ship` (at truck departure) → `T_ScoreOrder`.
+`T_EndOfWeekCharge` fires Fri 22:00, charging each line for the changeover Monday's first job would need.
+
+| Breakdown                                             | Rate            | Duration                         |
+| ----------------------------------------------------- | --------------- | -------------------------------- |
+| Major outage (mill-motor class), removes `P_LineUp_L` | 0.038/line-week | LogNormal median 48 h, P90 120 h |
+| Bad filler jam, blocks `P_Filling_L`                  | 0.5/line-week   | LogNormal median 3 h, P90 6 h    |
+
+Repair progresses only during manned hours.
+
+## A.4 Calendars
+
+| Gate                | Pattern                                                                                                            |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| `P_ShiftOpen_L1/L2` | Mon–Fri 06:00–22:00 (handover mid-batch allowed)                                                                   |
+| `P_ShiftOpen_L3`    | Mon–Fri 06:00–14:00                                                                                                |
+| `P_CrewShift`       | Mon–Fri 07:00–15:30; extends 05:00–19:00 if changeover pre-arranged ≥8 h ahead                                     |
+| `P_LabShift`        | Mon–Fri 07:00–17:00                                                                                                |
+| Saturday OT         | Adds L1 or L2 Sat 06:00–18:00; requires trigger by Wed 17:00; **adds no lab, no crew** unless `SAT_LAB_COVER = ON` |
+| Trucks              | Depart 06:00, Mon–Fri                                                                                              |
+
+## A.5 Policy layer (every rule swappable)
+
+**1 — Crew contention.** Key: `(Meridian-enabling DESC, earliest promise-at-risk ASC)`. **Non-preemptive.** Loser waits for crew _and_ shift.
+
+**2 — Batch sequencing (`SEQ_RULE`).** `CAMPAIGN_FIRST` (yours): group by family; within campaign, earliest promise; break campaign only if a due date would actually be missed. Alternatives: pure due-date; campaign with Meridian override.
+
+**3 — Idle vs washdown** _(your headline decision, implemented literally from Q10)_:
+
+```
+IF (wash_away + wash_back) touches ANY Meridian ship window
+   THEN idle                                       (* the cliff *)
+ELSE IF gap_hours ≥ (wash_away + gap_job_runtime + wash_back)
+   THEN take the gap job
+ELSE idle
+```
+
+**4 — Lab queue.** FIFO, except jump tokens. Displaced work waits, and near week's end may hit the Friday trap — that is the true cost of a jump.
+
+**5 — Saturday ask.** Wed 17:00: if a Meridian order's projected completion misses its window by ≥1 shift, request OT on L1/L2. Non-Meridian shortfalls trigger nothing (your Coastal case).
+
+## A.6 Scoring — unit is one line-hour
+
+```
+Changeover      = 1.0 × changeover_hours
+Idle            = 0                        (invisible on paper; bites only via the clock)
+
+Meridian late   = 200 (step, on missing the truck) + 1.0 × hours_late
+Other late      = 0                     h ≤ 4
+                = 0.5 × (h − 4)         4 < h ≤ 24
+                = 10 + 4.0 × (h − 24)   h > 24
+Whole-week req. = ×2 on the above
+
+End-of-week     = expected changeover hours from each line's Friday state
+                  into Monday's likely first job
+```
+
+**Board metric reported separately:** binary on-time % vs promise date — so you can tell your boss what the board will say.
+
+_Calibration against your own bets:_ Meridian 6 h late = 206 ≫ 4 changeover-hours → you idle. Coastal 6 h late = 1.0 < 4 → you take the tint job. Coastal 48 h late = 106 ≫ 4 → you don't. Cliff and slope, reproduced.
+
+## A.7 Experiments → your three questions
+
+| Question                                              | Run                                                                                                                                                                                               |
+| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _"Line 1's mill motor takes four days — what slips?"_ | Inject 96 h `P_LineUp_L1` outage at various points; compare re-allocation policies. **Watch specialty: it has nowhere to go** (guard: specialty ⇒ L1), so it appears as a hard block, not a delay |
+| _"Idle an hour or wash down?"_                        | Sweep Conflict-3 rule × `RELEASE_POLICY`. **Run `STANDING_MERIDIAN` first** — hypothesis is that most of these dilemmas are manufactured by release timing, not by your scheduling                |
+| _"Where are my changeover hours going?"_              | Changeover-hours ledger by line × transition × cause; then `SEQ_RULE` sweep; cross with `TIME_BASIS` — if your gut padding changes no decision, don't bother timing changeovers                   |
+| _(bonus)_                                             | `SAT_LAB_COVER` OFF vs ON — tests whether this year's Saturdays bought you anything given a shut Monday-ward lab                                                                                  |
+
+**Validation when data lands:** replay 26 weeks; target (a) ~75% utilisation, (b) **30–40 changeover-hours/month** — your ops director's number, the best anchor you gave me — (c) board on-time % matching history. Low changeover-hours ⇒ `CO_GRANULARITY` or sequencing is wrong.
+
+---
+
+# B. ASSUMPTION LEDGER
+
+Mine, not yours. **Bold = load-bearing.**
+
+**Scoring**
+
+1. Lateness in hours vs promise date (board is binary but can't express your cliff/slope). _Check: ERP promise vs ship dates._
+2. **Meridian = 200-hour step at "misses the truck", +1.0/h after. I defined the window as truck departure 06:00, not end-of-promise-day.** _Check: one sentence from you — several tight cases flip._
+3. Non-Meridian: free <4 h, 0.5/h to 24 h, 4.0/h beyond. Invented shape from your Coastal answer. _Sensitivity-test the kink._
+4. Whole-week multiplier ×2. Pure invention.
+5. Idle costs zero (your Q8). Makes arrival/due-date realism load-bearing.
+6. Changeover = pure lost line time, no wage/solvent. _Check with finance what the 40-hours line item contains._
+7. **The 200:4 ratio was reverse-engineered from your two bets, not elicited.** _Check by putting three more of your own bets to it._
+
+**Structure** 8. Four stages, identical topology on all three lines (you walked me through L2 only). 9. **Tank caps: L1 mill→fill = 1 batch, others = 2.** _Check: nameplate ÷ batch size._ 10. Vessels 1,100 / 1,650 / 1,350 — **L3 is the one you said not to quote.** _Check: 30 seconds at the vessel._ 11. 14 SKUs as 4 white / 8 tint / 2 specialty, tint depths assigned arbitrarily. _Check: SKU master — also tells me which tints are dark._ 12. L3's two unqualified tint SKUs — your count, my choice of which. _Check: quality's validation list._ 13. **Specialty on L1 only. I never asked whether L3 can run specialty — if it can, the mill-motor answer changes materially.** 14. Meridian ⇒ L2 is absolute, no emergency override. _Check: has it ever been broken?_
+
+**Durations** 15. **Stage rates reconstructed from your estimates. The pattern is yours; the numbers are mine.** _Check: the sheet's units/hour per product per line — direct calibration, you already have it._ 16. Mix time identical across families/lines. Never asked; probably wrong for specialty. 17. **The jam/stall split is entirely my decomposition** (you described both, never separated them); stall frequency invented. _Check: whether CMMS distinguishes faults from material starvation — it probably doesn't._ 18. QA 3.5/4.0/5.0 h by family, σ 0.25 — only "about four hours for whites" is yours. _Check: lab lead, 5 min._ 19. Sampling = first, every 3rd, **always last** (my inference from "held up by its last batch"). 20. SHEET matrix = your recollection of a spreadsheet neither of us has opened. _Check: open it._ 21. GUT layer quantified by me from your instincts. _Check: time six changeovers — but run `TIME_BASIS` both ways first; if nothing changes, don't bother._ 22. **`CO_GRANULARITY` unresolved — you were going to watch a rinse. This materially changes the split-across-lines answer.** 23. **`CREW_MODE` unresolved — you'd half-noticed the techs working opposite ends. If rinses split, crew contention drops significantly.**
+
+**Policies** 24. Crew key = Meridian-enabling, then earliest at risk; non-preemptive. _Check: has an in-progress changeover ever been abandoned?_ 25. **A line missing the crew window waits for next shift start. Most punitive mechanism in the model — it turns a 2 h changeover into a lost overnight.** 26. **Crew flex needs ≥8 h notice — invented. Directly governs whether an evening washdown happens or waits for morning, i.e. the core of your headline decision.** _Check: ask the techs._ 27. Jump budget 0.6/wk with rising refusal — 2–3/month is yours, the refusal curve is invented to reproduce the one time you backed off. 28. **Saturday OT adds line hours only, no lab, no crew. The assumption I most expect to be wrong in a useful direction.** _Check: the ops director question._ 29. **End-of-week charge is my accounting construct** for behaviour you described. _Check: compare Friday's finishing family to Monday's first job over recent weeks._ Without it the model cheats by leaving every line filthy on Friday.
+
+**Boundary conditions** 30. **40 orders arrive Sunday 23:00 in one batch; nothing arrives mid-week.** Never asked. If urgent mid-week orders exist, that's a major missing disturbance. 31. Order sizes: Meridian median 7,000 units, others 2,500 — derived from your one-third-of-volume figure. _Check: ERP directly._ 32. **Promise dates 4–9 days after book date, uniform — pure invention, and the single most load-bearing unknown.** Because idle is only penalised via due-date pressure, too much padding makes the model idle happily and tell you nothing. _Check: ERP book-date vs promise-date._ 33. **ERP release lag 24 h ± 12 h before promise, same for all accounts — invented, and it's the mechanism that creates your headline dilemma.** _Check: the release-timestamp field you added to the ask._ 34. **Breakdown rates entirely invented**, anchored only to "the motor took four days once" and "a bad one every couple of weeks." _Check: the CMMS export — this is what it's for._ 35. Repairs progress only in manned hours. Never asked; could be wrong for a contracted rebuild. 36. Starts Monday 06:00, all lines empty, clean, dressed for white. _Use a one-week warm-up before scoring regardless._ 37. No materials constraint (you only watch for red flags). _Check: if red flags stop runs more than quarterly, this needs modelling._
+
+---
+
+# C. WHAT THE MODEL LEAVES OUT
+
+**Gaps from stopping early — real, not simplifications:**
+
+1. **Batch contiguity / order splitting.** The model assumes an order's batches run **contiguously** on a line. It can compare "whole order on L1" vs "split across L1 and L2" and will correctly charge the extra changeover on both — but it can't represent interleaving. **If interleaving is possible in reality, the model overstates the cost of splitting, which is exactly your run-size question.** _Fix this first — it's one sentence from you._
+
+2. **The unwritten rules.** Never covered. Expect the model to propose schedules that make you say "we'd never do that." **Treat each of those as a finding, not a bug** — that's an unwritten rule surfacing.
+
+3. **All historical data.** Neither export arrived. Every arrival, promise date, release lag and breakdown figure is invented (30–34). **Don't make decisions on the model until at least the order book is loaded** — assumption 32 can make it tell you a comfortable lie.
+
+**Deliberate exclusions:**
+
+1. **Materials/supply chain** — you don't schedule around them; modelling them adds noise you can't act on.
+2. **Individual operators, skills, absence** — except where you named them as constraints (crew, lab, L3's qualified operator). Modelling the labour pool would double the size to answer a question you didn't ask.
+3. **Quality failures and rework** — you never mentioned a batch _failing_ QA, only waiting for it. If they do fail, that's a missing feedback loop and a significant one.
+4. **Warehouse and truck capacity** — trucks are a fixed daily departure. The one place logistics bites, the release gate, _is_ modelled, because it's your headline lever.
+5. **Commercial's promise-date behaviour** — exogenous. "Should commercial pad more or less" is a different model with this one inside it.
+6. **Dollars** — everything is in line-hours, because nobody could give a dollar figure and a fake conversion adds only false precision. One line converts it if finance produces a rate.
+
+---
+
+**Three things before your first real run:**
+
+1. **Load the ERP order book** — kills assumptions 31–33, the ones that can make the model lie comfortably.
+2. **Answer batch contiguity in one sentence** — unblocks the run-size question.
+3. **Run `RELEASE_POLICY = STANDING_MERIDIAN` against the default** — tests whether your headline dilemma is manufactured upstream of you. It's the cheapest finding available and needs no data at all.
+
+Send the exports and the flagged answers whenever you have them and I'll revise. Good luck with it.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.raw.json b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.raw.json
new file mode 100644
index 00000000000..631df638aaf
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/transcripts/condition-2.raw.json
@@ -0,0 +1,1360 @@
+{
+  "startedAt": "2026-08-13T10:25:27.625Z",
+  "condition": "2",
+  "stopReason": "delivered-after-forced-wrap",
+  "interviewerTurns": 23,
+  "calls": [
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 1745,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 527,
+        "output_tokens_details": {
+          "thinking_tokens": 69
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 434,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 3899,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 674,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 2877,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 749,
+        "output_tokens_details": {
+          "thinking_tokens": 201
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 518,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 5121,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 800,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 4225,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1004,
+        "output_tokens_details": {
+          "thinking_tokens": 333
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 597,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 6592,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 716,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 5612,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 518,
+        "output_tokens_details": {
+          "thinking_tokens": 81
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 411,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 7745,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1245,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 7294,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 655,
+        "output_tokens_details": {
+          "thinking_tokens": 288
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 368,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 9357,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 862,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 8523,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 412,
+        "output_tokens_details": {
+          "thinking_tokens": 46
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 358,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 10585,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 738,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 9627,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 477,
+        "output_tokens_details": {
+          "thinking_tokens": 103
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 375,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 11697,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1046,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 11047,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 486,
+        "output_tokens_details": {
+          "thinking_tokens": 80
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 393,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 13149,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 821,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 12312,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1292,
+        "output_tokens_details": {
+          "thinking_tokens": 393
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 741,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 14907,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 211,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 13422,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 889,
+        "output_tokens_details": {
+          "thinking_tokens": 153
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 634,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 15854,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 309,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 14467,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 823,
+        "output_tokens_details": {
+          "thinking_tokens": 137
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 579,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 16849,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 189,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 15342,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 519,
+        "output_tokens_details": {
+          "thinking_tokens": 247
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 275,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 17310,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 77,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 15691,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1650,
+        "output_tokens_details": {
+          "thinking_tokens": 402
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 1018,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 18635,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 706,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 17645,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 2159,
+        "output_tokens_details": {
+          "thinking_tokens": 1137
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 830,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 20363,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 390,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19057,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 1323,
+        "output_tokens_details": {
+          "thinking_tokens": 454
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 719,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 21622,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 57,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 19983,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 259,
+        "output_tokens_details": {
+          "thinking_tokens": 32
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 249,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 21906,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 64,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 20274,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 2244,
+        "output_tokens_details": {
+          "thinking_tokens": 1289
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 785,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 22925,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 294,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 21523,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 613,
+        "output_tokens_details": {
+          "thinking_tokens": 135
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 449,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 23697,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 137,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 22138,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 438,
+        "output_tokens_details": {
+          "thinking_tokens": 211
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 252,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "expert",
+      "model": "claude-sonnet-5",
+      "usage": {
+        "input_tokens": 24061,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 110,
+        "output_tokens_details": {
+          "thinking_tokens": 0
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 22475,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 397,
+        "output_tokens_details": {
+          "thinking_tokens": 292
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 153,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 22604,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16000,
+        "output_tokens_details": {
+          "thinking_tokens": 8112
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 6087,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 30518,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4930,
+        "output_tokens_details": {
+          "thinking_tokens": 329
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 3546,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 4,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    },
+    {
+      "agent": "interviewer",
+      "model": "claude-opus-5",
+      "usage": {
+        "input_tokens": 35143,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 8321,
+        "output_tokens_details": {
+          "thinking_tokens": 183
+        },
+        "service_tier": "standard",
+        "inference_geo": "global"
+      }
+    },
+    {
+      "agent": "classifier",
+      "model": "claude-haiku-4-5-20251001",
+      "usage": {
+        "input_tokens": 6266,
+        "cache_creation_input_tokens": 0,
+        "cache_read_input_tokens": 0,
+        "cache_creation": {
+          "ephemeral_5m_input_tokens": 0,
+          "ephemeral_1h_input_tokens": 0
+        },
+        "output_tokens": 16,
+        "service_tier": "standard",
+        "inference_geo": "not_available"
+      }
+    }
+  ],
+  "interviewerMessages": [
+    {
+      "role": "user",
+      "content": "I'm the master scheduler at a coatings plant. My boss wants a simulation model of how we\nschedule production, so we can test scheduling decisions before making them. We have tooling\nthat runs Petri-net-style process models, so the end product should be a model I can hand to\nthat — but I can't tell you much about the format, I'm not the modelling person.\n\nPlease interview me about how our operation works, and then produce the model."
+    },
+    {
+      "role": "assistant",
+      "content": "Good — a Petri-net-style engine is a fine target for this; I'll build a coloured/timed Petri net (places, transitions, token colours carrying order attributes, timed transitions with distributions) and describe it precisely enough that a modelling person can load it. The format details I'll handle; what I need from you is how the plant actually works.\n\nLet me start with **why the model exists**, because that determines how deep I dig everywhere else. Four opening questions:\n\n1. **The decision.** When your boss says \"test scheduling decisions before making them\" — what decisions specifically? Are we talking about sequencing/campaign order on a line, how much to batch, when to promise a customer a date, how many changeovers to accept per week, staffing, something else? Give me one or two real decisions you've argued about in the last couple of months.\n\n2. **The questions.** If the model could answer three questions on demand, what would you ask it? (Phrase them the way you'd actually ask.)\n\n3. **What \"better\" means.** How is your schedule judged today — formally (a KPI on a board) and informally (what gets you a phone call)? If you had to trade one late order against extra changeover hours, or against inventory, do you have any sense of the exchange rate?\n\n4. **Scope in time and space.** Does \"how we schedule production\" mean one line, one building, or the whole plant including raw material and filling/packing? And over what horizon do you schedule — a shift, a week, a month?"
+    },
+    {
+      "role": "user",
+      "content": "Good questions — let me actually think about these instead of giving you the tidy version.\n\n1. **The decision.** The one my boss keeps poking at is the idle-vs-washdown thing. Two weeks ago I had Line 2 finish a white run at 2pm, next Meridian order not ready to release till the next morning, and the only other thing queued was a small tint job. I sat the line for a couple hours rather than wash it down and then wash it back for the next white. He wants to know if that was the right call or if I just got lucky. The other one is run-size — commercial keeps asking if we can split big orders across two lines to hit dates, and I never know if that's actually faster once you count the extra changeover, or if I'm just moving the pain around.\n\n2. **Three questions, the way I'd actually ask them:**\n   - \"If Line 1's mill motor takes four days again, what do I move and what slips?\"\n   - \"Is it cheaper to hold a line idle for an hour waiting on a same-family order, or just wash down?\"\n   - \"Where are my changeover hours actually going, and would reordering this week's runs get me any of them back?\"\n\n3. **\"Better.\"** Formally, ops director looks at on-time-ship percentage on a board, and changeover hours as a line item cost. Informally — the phone call I get is always about Meridian. Nothing else really generates a call, honestly, other accounts just slip and commercial handles it quietly. Exchange rate between late orders and changeover hours — no, I don't have a number, I wish I did. If you pushed me I'd say I'd eat an extra hour of changeover before I'd risk Meridian, but past that it's a gut call, not a formula.\n\n4. **Scope.** Whole plant, all three lines — they share the changeover crew so you can't really look at one in isolation anyway. Materials I mostly just watch for red flags, I don't actively schedule around them unless something's already short. Horizon is the week — the demand book lands weekly, but I'm re-juggling it basically every day at the huddle, and the mill motor thing showed me plans can blow up inside a single shift."
+    },
+    {
+      "role": "assistant",
+      "content": "That's the useful version, thank you — especially the idle-vs-washdown case, because that's a decision the model has to be able to *represent*, not just report on. Let me pin down the objective function a bit harder before we go structural, because your three questions imply things you haven't said yet.\n\n**On \"better\":**\n\n5. **On-time-ship.** Measured against what date — the date commercial promised the customer, or the date the customer asked for? And what's the unit of lateness that counts: a day, a shift, an hour? If an order ships one day late does it count the same as five days late on your board?\n\n6. **Meridian.** Roughly what share of your volume and of your order count is Meridian? Is *every* Meridian order phone-call-worthy, or is it specific products/sites? And when you say \"risk Meridian\" — is the risk lateness, or is it something else (quality, a specific short lead time, an audit)?\n\n7. **Changeover hours as a cost line.** Do you know the number they use — dollars per changeover hour, or per washdown? Even the order of magnitude, and whether it's mostly crew time, mostly solvent/waste disposal, or mostly lost line time.\n\n8. **Idle.** Does idle line time cost anything on anyone's board, or is it invisible until it turns into a late order? That matters a lot for question two — if idle is free on paper, the model will always prefer idling and you won't learn anything.\n\nAnd one on your third question, which is really an accounting question:\n\n9. **\"Where are my changeover hours going\"** — do you currently have any record of actual changeover durations, or is it all standard times from a matrix? If there's a matrix, I want it later; if it's in your head, I want that instead, because the head version is usually the true one."
+    },
+    {
+      "role": "user",
+      "content": "5. **On-time-ship.** It's measured against the promise date — what commercial told the customer, not what the customer originally asked for. Commercial pads a bit already so there's some slack baked in before I even see it. As for unit — honestly the board just tracks \"on time or not,\" it's binary. One day late and five days late both just show up as a red mark in the weekly summary. Which annoys me, because a one-day slip on a small account is nothing and a five-day slip on a big one is a real conversation, but the board doesn't know the difference.\n\n6. **Meridian.** They're maybe a third of our volume by units — almost all base whites, a couple of tint SKUs too. Order count is smaller than that, they order in bigger batches than most. Not every single Meridian order gets a call — it's specifically anything that's going to miss the ship window, doesn't matter which SKU. The risk is purely lateness — they've got a vendor scorecard and a fine schedule, and if you're late enough often enough they start pulling shelf space. It's not a quality thing for them, it's a contract thing.\n\n7. Honestly? No, I don't know a dollar figure. I know it's treated as a cost because ops brings it up in the monthly review as hours, not dollars — \"we spent 40 changeover-hours this month, that's up from 30.\" Whether that's mostly crew wages or the fact the line's not running during that time, I couldn't tell you. My guess, and it's just a guess, is it's mostly the lost line time that matters to them, because the crew's paid either way, they're just idle or elsewhere.\n\n8. That's a good question and I don't think anyone's ever asked me it straight. I genuinely think idle is invisible on paper — nobody's tracking \"line 2 sat for 90 minutes\" as a number anywhere, it just quietly turns into either nothing (if I got away with it) or a late order (if I didn't). So yeah — if your model has a free lunch where idling costs nothing, it'll idle constantly and that won't match what actually happens, because eventually idling costs you the due date.\n\n9. It's a matrix, sort of — there's an old spreadsheet, family-to-family changeover standard times, that's what I use when I build the sheet. But it's a standard time, not an actual — nobody logs what a changeover really took unless it went badly wrong and someone complained. So the matrix is the \"should take\" number, and my gut adjustment on top of it is the \"actually takes,\" and the gut part is not written down anywhere."
+    },
+    {
+      "role": "assistant",
+      "content": "Right. Let me co-construct the scoring, because you've given me the ingredients and I don't want to invent the weights silently.\n\nHere's my proposal, tell me where it's wrong:\n\n- **Score both ways.** The model reports the board metric (binary on-time %, vs promise date) *and* a \"true cost\" metric, because you've told me the board is wrong in a specific way (blind to magnitude and to account). Decisions get made on the true cost; the board number is there so you can tell your boss what the board *will* say.\n- **True cost = lateness penalty + changeover hours.** Lateness penalty scales with hours late and by account tier: Meridian weighted heavily, everyone else light. Changeover hours costed as lost line time, i.e. one changeover hour = one hour of line capacity gone.\n- **Idle is not directly costed.** It only hurts by consuming the clock and pushing things late. That matches what you described — but it means the model needs due dates and arrivals to be *realistic and tight*, or idling will look free. I'll come back to that.\n\nNow the exchange rate. I'm going to ask it as concrete bets rather than ask you for a number:\n\n10. **Meridian bet.** Line 2 just finished white. A Meridian white order is releasable tomorrow morning. There's a small tint job that would fill the gap but needs a wash down and a wash back — say 2 hours each way, 4 hours total. Taking the tint job makes the Meridian order finish 6 hours later than its ship window. Do you take the tint job? What if it only made Meridian 1 hour late? What if the changeover were 1 hour each way instead of 2?\n\n11. **Same bet, other account.** Same setup but the white order is Coastal, not Meridian, and it's their whole week's requirement. Does your answer change, and at what point?\n\n12. **Utilisation reality check.** In a normal week, how much of the three lines' available hours are actually consumed by running product? Half? Three-quarters? Flat out? And do you routinely work weekends or overtime, or is the week's capacity fixed?"
+    },
+    {
+      "role": "user",
+      "content": "This is fair, and honestly it's already sharper than how I've ever had to think about it out loud. Let me try the bets.\n\n**10. Meridian bet.** No, I don't take the tint job — not if it makes Meridian six hours late. Six hours can tip into \"missed the truck,\" and that's a call I don't want to make. If it only made Meridian one hour late, I'd probably still not take it, because \"one hour late\" on my estimate has a habit of becoming three hours late by the time QA and the truck schedule get involved — I don't trust my own estimate that tightly. Where it gets interesting is your third variant: if the changeover were only an hour each way instead of two, so two hours total instead of four, and that only pushed things around rather than actually making Meridian late — yeah, then I'd take the tint job, because now it's basically free, I'm just filling a gap. So honestly the real threshold isn't a number of hours, it's: does it touch Meridian's window at all. If it doesn't, do it. If it does, don't, full stop. That's blunter than an exchange rate, I know.\n\n**11. Coastal instead.** Yeah, this changes things. Coastal's not on a scorecard, they're not going to fine us. If it's their whole week's order I'd still care — a full week's requirement matters even for a small account, because if I blow it I've got nowhere to slot them next week either. But I'd take the tint job even at six hours late for Coastal, honestly, as long as six hours doesn't turn into \"we missed by two days.\" Somewhere around a day late is where I'd start to feel bad about it. So there really are two different curves in my head — Meridian's is a cliff, everyone else's is a slope.\n\n**12. Utilization.** Rough guess — three-quarters, maybe. It's never flat out because there's always some changeover eating into it, and Line 3's day-shift-only limits it structurally. Weekends — we don't run them as standard, but if we're in a hole close to a Meridian date, ops director will approve Saturday overtime on Line 1 or 2, that's happened maybe four or five times this year. Line 3 overtime is rarer, mostly because it needs a qualified operator who's willing to come in, not just budget approval."
+    },
+    {
+      "role": "assistant",
+      "content": "That's not blunter than an exchange rate — it's *more* informative. A cliff and a slope is a perfectly implementable penalty structure, and it's a real finding: it means your policy is lexicographic (protect Meridian's window absolutely, then optimise everything else), not a weighted sum. I'll build it that way.\n\nLet me record where we are on scoring:\n\n- **Meridian:** step penalty — huge fixed cost if the order misses its promise window at all; magnitude beyond that barely matters (a call is a call).\n- **Everyone else:** roughly linear in hours late, with the slope becoming noticeable around a day, plus an extra bump if the order is an account's whole-week requirement (because you can't recover next week).\n- **Changeover:** counted as hours of lost line capacity.\n- **Board metric:** binary on-time %, reported separately.\n\nNow let's get structural. **Walk me through one concrete order, end to end** — pick a real recent one, ideally a Meridian white, and narrate it from the moment it lands in your demand book to the moment it's on a truck. Don't tidy it. I want every place it sits and waits, every person or system that touches it, and every point where it could have gone a different way.\n\nSpecifically I want to hear, as you go: where does the order physically *wait*, who decides when it moves, and what has to be true before each step can start."
+    },
+    {
+      "role": "user",
+      "content": "Okay, let me pull up... well, mentally pull up, one from a couple weeks back. It was a Meridian order, 8,000 units of VW-01, one of the base white golds. Let me walk it through.\n\n**Lands in the demand book.** ERP spits out the weekly book Sunday night, I see it Monday morning — SKU, quantity, ship date. That order had a Thursday ship window. It sits in the book, unallocated, until I get to it — the book doesn't prioritize itself, I have to look at all 40-odd orders and decide order.\n\n**I put it on the sheet.** Monday morning before the huddle I build the week's allocation — which line, roughly what day. Meridian white always goes Line 2, no debate, so that part's automatic. What's not automatic is *when* in the week — I look at what else Line 2's got queued, what family it's already running, and slot it in. For this one I put it Wednesday day shift, figuring Line 2 would be finishing a run of tinted colours Tuesday night, so there'd be a washdown Wednesday morning before it could start.\n\n**07:30 huddle.** I say out loud what's happening line by line. Someone from maintenance is there, someone from QA sometimes, the line leads. This is where reality intrudes — that Wednesday, the Line 2 lead mentioned the filler had been acting up over the weekend, nothing logged yet, just \"keep an eye on it.\" I made a mental note but didn't replan.\n\n**Materials check.** Before the run can start, I (or actually the line lead) confirms the resin and pigment for VW-01 are physically at the line — this is supposed to happen the day before, via a materials report I glance at each morning. That week it was fine, no shortage flagged.\n\n**Washdown.** Tuesday night the tint run finishes. The changeover crew — two techs, shared across all three lines — has to be free. That week they weren't busy elsewhere, so the tint-to-white washdown happened overnight, the full three hours plus, because it's the expensive direction. It has to be *fully* done, checked by a line tech, before mix can start — there's a sign-off, someone has to visually confirm no carryover.\n\n**Mix → mill → tint/letdown → fill.** Wednesday morning the actual run starts. VW-01 goes through the four stages. For a white, mix and mill go fast, tint/letdown is basically nothing since it's not being colored, and fill is where it actually spends its time — fill is the bottleneck for whites, like I said. That week the filler hiccuped for about 20 minutes mid-run — small jam, cleared it, lost time but not a disaster.\n\n**QA hold.** Once filled and packed, the pallets go into QA hold. Lab has to sample and release — for whites that's usually about four hours, but it depends on how backed up the lab is. That week it was mid-week, lab wasn't swamped, four hours held.\n\n**Ships.** Once released, warehouse pulls it for the Thursday truck. If QA release comes in Wednesday evening, it comfortably makes Thursday. If it had slipped — say the filler jam had been two hours instead of twenty minutes, or QA had a backlog — Thursday morning becomes tight, and that's the point where I'd be making calls, maybe asking QA to prioritize the pallet, maybe finding out if there's a later truck.\n\nWhere could it have gone differently: if the changeover crew had been busy with Line 3 that Tuesday night, the washdown slips to Wednesday morning and the whole run pushes into the day, eating into the QA buffer. If the filler jam had been the \"half a shift\" kind instead of the \"twenty minutes\" kind, same problem. Both of those are the ordinary ways a Meridian order gets tight — not exotic, just the normal noise of the plant landing on the wrong day."
+    },
+    {
+      "role": "assistant",
+      "content": "That walkthrough gave me most of the skeleton. Let me nail the line topology first, because it determines whether this is a four-stage flow shop or a single occupancy block, and that changes the model shape completely.\n\n13. **Pipelining.** Mix → mill → tint/letdown → fill. When VW-01 is at fill, can the *next* order already be mixing on the same line? Or does one order own the whole line from mix through fill? If it can pipeline, is there physical buffer between stages — tanks, totes — and how many orders' worth?\n\n14. **Batch structure.** Was that 8,000 units one continuous run, or is it broken into batches (a mix vessel's worth) that move through as discrete lumps? If batches — what's a typical batch size relative to that order, and do all batches of an order have to finish before QA samples, or does QA sample per batch?\n\n15. **The three lines.** What can each run, and what can't it? You said Meridian white \"always goes Line 2, no debate\" — is that a hard qualification (Line 1 physically can't), a quality rule, or just habit? And what makes Line 3 different besides day-shift-only?"
+    },
+    {
+      "role": "user",
+      "content": "13. **Pipelining.** Yes, it pipelines, that's basically the whole point of the tanks between stages. While fill's running on the tail end of one batch, mill can already be starting on the next batch of the *same* order, and mix even earlier than that. But it's not infinite — there's a small holding tank between each stage, and if the downstream stage is slower than upstream, the tank fills up and upstream has to stop. That's the Line 1 mill-to-fill tank problem I mentioned — it's small, so mill backs up waiting for fill to catch up, more than it should. On Line 2 and 3 the tanks seem adequately sized, I've never heard complaints about them. As for \"how many orders' worth\" — I'd say each tank holds maybe one batch, two if you're lucky, not more. It's not built to buffer a changeover-length gap, it's built to smooth the normal pipeline hiccups.\n\n14. **Batch structure.** Yeah, 8,000 units isn't one continuous pour, it comes off the mix vessel in batches — a mix vessel holds maybe 1,000-1,500 units' worth depending on the product, so that order was probably six, seven batches. They move through as discrete lumps, each one going through mill, tint, fill in sequence, pipelined behind each other like I said. QA doesn't wait for the whole order — they sample per batch, or actually I think it's more like per some number of batches, they don't test every single one if it's the same SKU running clean. But the pallets from the *last* batch still have to clear QA before the whole order can ship, obviously, so functionally the order's held up by its slowest/last batch through the system.\n\n15. **The three lines.**\n- **Meridian on Line 2** — this one really is a hard rule, not physics. Years back Meridian did an audit and specifically qualified Line 2's fill area for their whites — some paperwork thing about equipment. We could probably physically run their orders on Line 1, but nobody's going to risk it without redoing that qualification, and nobody's pushed for that.\n- **Line 1** is qualified for everything, including specialty — it's the old reliable, slower but flexible.\n- **Line 2** is fast, big-volume, but it was never piped for the clear resins specialty uses, so it flat-out can't run specialty — that's physical, not paperwork.\n- **Line 3** is newest and quick, but it's product-by-product qualified — there's a list, and I know two tint SKUs specifically aren't on it yet, someone in quality is slowly working through validating it for more. Day-shift-only is a separate constraint on top — that one's a staffing/overtime decision, not a capability one."
+    },
+    {
+      "role": "assistant",
+      "content": "Good — that's a proper flow shop with finite buffers, and Line 1's small mill-to-fill tank is a real modelled constraint, not a footnote.\n\nNow the taxonomy, because your changeover matrix is keyed on it.\n\n16. **Families.** You've mentioned base whites, tints/tinted colours, and specialty. Is that the full family list as the changeover matrix sees it? How many SKUs roughly in each, and are there sub-distinctions *within* a family that change the changeover (e.g. dark tint → light tint worse than light → light)?\n\n17. **Changeover direction and cost.** You said tint→white is \"the expensive direction, full three hours plus.\" Give me the shape of that matrix as you carry it in your head: white→white (same SKU / different SKU), white→tint, tint→tint, tint→white, anything→specialty, specialty→anything. Standard times, and where your gut says the standard is wrong.\n\n18. **Does the changeover differ by line?** Same family transition on Line 1 vs Line 2 vs Line 3 — same hours, or does the bigger/faster line take longer to wash?"
+    },
+    {
+      "role": "user",
+      "content": "16. **Families.** Yeah, that's the three the matrix runs on — base whites, tints, specialty. Roughly, of the 14 SKUs: whites are maybe 4-5 SKUs but they're the bulk of the volume, tints are the biggest count, maybe 7-8 different colors, and specialty is the small tail, 2-3 SKUs. Within tints there absolutely are sub-distinctions that matter but the matrix doesn't capture them well — going from a dark tint to a light tint is worse than light-to-light or dark-to-dark, because of exactly the same carryover logic as tint-to-white, just less extreme. The matrix just says \"tint-to-tint, X minutes\" flat, and I mentally add time if I know it's dark-to-light. That's gut, not written down.\n\n17. **The matrix, as I carry it:**\n- White→white, same SKU: basically nothing, a rinse, call it 15 minutes, mostly just checking nothing's off.\n- White→white, different SKU: 20-30 minutes, quick rinse — same family, no real risk.\n- White→tint: about 45 minutes. Going *into* pigment from clean is easy, you're not fighting carryover.\n- Tint→tint: depends on the direction like I said — light-to-light maybe 30-40 minutes, but dark-to-light I pad it, call it an hour, hour and a half even though the sheet says the same number as any tint-to-tint.\n- Tint→white: the bad one, full washdown, 3 hours plus. My gut says the matrix's \"3 hours\" is actually optimistic — I've seen it run closer to 3.5 more than once, especially after a dark tint.\n- Specialty in or out, either direction: about 2 hours. Doesn't matter which way, the clears are just fussy to purge either direction.\n\n18. **By line.** The matrix as written doesn't differentiate by line — same hours regardless. But my gut says that's wrong for at least one case: Line 1's washdowns seem to take a bit longer than the same transition on Line 2, and I've always figured it's because Line 1's older, more pipework, more places for carryover to hide. Nobody's ever timed it properly to confirm that though, it's just a feeling from watching it happen for years."
+    },
+    {
+      "role": "assistant",
+      "content": "Useful — I'll model the standard matrix *and* your gut adjustment as separate layers, so you can run \"what if the standard times are real\" vs \"what if my padding is real\" and see whether it changes any decision. That's a cheap experiment and it tells you whether it's worth timing changeovers properly.\n\nNow durations of the actual work.\n\n19. **Run rates.** For each stage — mix, mill, tint/letdown, fill — how long does one *batch* take, and does it differ by family and by line? You said fill is the bottleneck for whites; is something else the bottleneck for tints or specialty (I'd guess mill or tint/letdown)? Give me per-batch hours as best you can, per line if they differ.\n\n20. **Batch size.** 1,000–1,500 units per mix vessel — does that vary by line as well as by product? Is Line 2's vessel bigger than Line 1's?\n\n21. **Variability.** Take the one you know best — a white batch on Line 2's fill. Typical duration? One time in ten it's worse than ___? One time in ten it's better than ___? And what causes the bad tail — the filler jams you mentioned, or something else?"
+    },
+    {
+      "role": "user",
+      "content": "I'll be honest, this is where you're going to hit the edge of what I actually track — I know the *sheet* numbers, which are the \"should take\" numbers, and I know the vibe of how wrong they are, but per-batch-per-stage isn't something I've ever broken down that finely. Let me give you what I've got.\n\n**19. Run rates.** The sheet doesn't even really have stage-level rates — it has one number per product-per-line, \"units per hour,\" and I back into a run time from that. So if you want stage-by-stage I'm partly guessing based on watching the line.\n\nFor a white batch, say 1,200 units, on Line 2: mix is maybe 20 minutes, mill maybe 20-30, tint/letdown almost nothing since there's no color to add, and fill... fill is the long pole, I'd guess an hour, hour and a half for that batch size, because line speed is really a fill-head-count thing. On Line 1, same batch, mix and mill are similar, but fill is slower — maybe double, hour and a half to two hours, since Line 1's older equipment.\n\nFor tints, mill and tint/letdown both stretch out — you're actually incorporating pigment and it has to mix properly, so I'd guess mill is more like 40 minutes to an hour, tint/letdown similar, and fill is actually not that different from white fill rates, maybe a bit slower. That's the \"funny, Line 1 and Line 2 are nearly even on tints\" thing — I think it's because tint fill isn't as fast-head-dependent, but don't hold me to the mechanism, I'm guessing.\n\nFor specialty — this is the one I feel most confident about because it's so obviously different — mill is the slow one, could be two, three hours for a batch because the stuff is thick and has to be milled properly or it's ruined. Fill for specialty is actually fine, comparable to tint fill, it's not the bottleneck at all.\n\n**20. Batch size.** Yeah it varies. Line 2's vessel is bigger — I think it's closer to 1,500-1,800 units per batch, Line 1's more like 1,000-1,200, Line 3 I honestly am not sure, I think it's similar to Line 2 but smaller-side, maybe 1,200-1,500. Don't quote me hard on Line 3's number.\n\n**21. Variability — white batch, Line 2 fill.** Typical, like I said, an hour to an hour and a half. One time in ten it's worse — that's your filler jam scenario, tack on 20 minutes to half an hour for a small jam, or if it's a bad one, could eat the rest of the shift, but that's rarer than one-in-ten, that's more like once every couple weeks across the whole line, not per batch. One time in ten it's better — honestly not much better, maybe you shave ten minutes if everything's smooth, there's not a lot of upside slack in fill, it runs close to its rate when nothing's wrong. So the bad tail is real and fat, the good tail is thin. The cause of the bad tail is almost always the filler — jams, or waiting on packaging materials running low, that happens too, cases or labels not being restocked fast enough, that's more a warehouse problem than a line problem but it still stops the fill head."
+    },
+    {
+      "role": "assistant",
+      "content": "That asymmetry — thin upside, fat downside — is exactly what I need; I'll use a right-skewed distribution rather than anything symmetric. And the packaging-materials stall is a distinct failure mode from a jam, so I'll keep them separate: you might discover the warehouse restock is a cheaper fix than the filler.\n\nNow resources and calendars, which your walkthrough showed are where the contention actually lives.\n\n22. **Changeover crew.** Two techs, shared across three lines. Do both techs work one changeover together, or can they split and do two changeovers at once? Are they on all shifts, or day only? And when a line finishes a run at 2am and needs a washdown — are they *there*, or do they get called?\n\n23. **Shifts.** What's the shift pattern per line — Line 1 and 2 running nights, Line 3 day only? How many shifts a day, how many days a week? Do lines run unattended across a shift boundary, or does the run stop and restart?\n\n24. **QA lab.** Who and how many, what hours? You said whites are \"usually about four hours\" — what does the tail look like when the lab's backed up, and what makes it back up? Does the lab work nights and weekends, or does a batch finishing at 11pm just sit until morning?"
+    },
+    {
+      "role": "user",
+      "content": "22. **Changeover crew.** They usually work a changeover together, one crew, one job at a time — that's the actual constraint I was talking about, if two lines need one at once, someone waits. I don't think they physically *need* two people for a quick rinse, but for the big washdowns and the specialty purges, yeah, it's genuinely a two-person job, there's stuff to hold and stuff to check simultaneously. They're day shift, nominally, but they flex — if I know a washdown's needed overnight I ask them to stay late or come in early, that's a normal ask, not overtime-approval-required the way Saturday production is. If a line finishes at 2am with nobody expecting it and no changeover pre-arranged, it just sits dirty until someone's available — usually that means it waits till the day crew starts, so you lose the overnight hours you didn't plan to lose.\n\n23. **Shifts.** Line 1 and Line 2 run two shifts, so days and evenings, some weeks a skeleton night crew if we're behind, but that's not standard. Line 3 is day shift only, like I said, that's the default — overtime unlocks a second shift on any line but needs the ops director's sign-off. Within a shift, if a run's not done and the shift ends, generally it does keep running — there's a handover, second-shift operator picks it up mid-batch, the line doesn't need to be babysat every second, it just needs someone there. Between last shift ending and next one starting is the gap where nothing runs unless someone's specifically staying late — that's the 2am problem, that gap is a black hole for anything that needs a person, changeover crew or otherwise.\n\n24. **QA lab.** Two people, day shift basically, maybe a bit into evening if something's backed up, but nobody's in that lab at 2am or on weekends normally. Four hours is the typical hold-to-release for whites when the lab isn't backed up. What backs it up is exactly what you'd guess — everything landing on Wednesday/Thursday because that's when the week's runs tend to finish, so the lab gets a pile all at once. When it's backed up I've seen holds stretch to eight, ten hours, and if a batch finishes Friday evening or over a weekend, it can just sit until Monday morning — that's actually happened, and it's ugly, because now your Friday-finished order can't ship till Monday afternoon at the earliest, blown right through the week's window. That's probably the single biggest hidden Meridian risk, worse than the filler honestly, because it's totally invisible until it isn't.\n\n(Sorry — I've just seen the time, I have the floor huddle in ten minutes. How much more do you need?)"
+    },
+    {
+      "role": "assistant",
+      "content": "Roughly three more rounds — call it 15 minutes total, not now. Here's the honest inventory so you can choose how to spend it.\n\n**Solid enough to build on:** objectives and the cliff/slope penalty structure; line topology and pipelining with finite tanks; families and the changeover matrix plus your gut layer; qualifications (Meridian↔Line 2, no specialty on Line 2, Line 3's SKU list, day-shift-only); stage durations at the accuracy you have them; the changeover crew as a single shared server; shift calendar and the overnight black hole; QA lab hours and the Friday-evening trap.\n\n**Still genuinely missing, in priority order:**\n\n1. **Policies at conflict points.** This is the biggest gap and the model is mostly worthless without it. Two lines want the changeover crew at once — who wins, and does an in-progress changeover ever get abandoned? How do you sequence orders *within* a line (due date? family campaigning? Meridian first?)? Can QA be told to jump a pallet, and does that cost someone else? What actually triggers the Saturday-overtime ask, and how late in the week can you still ask?\n2. **Breakdowns.** Your question one is literally \"if Line 1's mill motor takes four days again.\" I need failure frequency and repair duration for the mill motor class of event, the bad filler jam, and anything else that has ever taken a line down for more than a shift.\n3. **Arrivals and order shape.** ~40 orders/week — size distribution, split by family and by account, and how promise dates relate to the book date (how much slack does commercial actually pad in?). Plus: what gates \"ready to release\" — you said the Meridian order wasn't releasable till next morning, and I don't know what was holding it.\n4. **Order splitting and campaigning.** Do an order's batches have to run contiguously, or can you interleave? That's the whole substance of your commercial-wants-to-split-across-two-lines question.\n5. **The unwritten rules.** What would a new scheduler get wrong in week one; what you always/never do that's on no document; which rules exist because of something that went wrong once.\n\n**My recommendation:** give me 15 minutes later today or tomorrow on items 1, 4 and 5 — those are pure head-knowledge, nobody else in the plant can supply them, and item 1 is where your idle-vs-washdown question actually lives. Items 2 and 3 I can partly reconstruct: maintenance may have downtime records and the ERP has the order book, so point me at whoever holds those, or I'll put placeholder distributions in the assumption ledger clearly marked as invented.\n\nGo to your huddle. Tell me when, and whether you can pull the order book extract and any downtime log in the meantime."
+    },
+    {
+      "role": "user",
+      "content": "Fair, that's a good split. Let's say tomorrow, same time, fifteen minutes — I'll block it so it doesn't get eaten by the huddle.\n\nFor the records: I'll ping the plant maintenance coordinator today for whatever CMMS downtime export he can pull — I know it exists, I've just never asked for it in this shape. And I'll get the order book pulled from ERP, that one's easy, it's just a report I don't normally bother running historically. If either of those comes back thin or ugly, flag it and I'll chase harder rather than let you guess quietly — I'd rather know where the model's standing on sand.\n\nSee you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "Blocked in — tomorrow, fifteen minutes, items 1, 4 and 5. I'll come with those as concrete scenarios rather than open questions so we don't burn time.\n\nTo make the two data pulls useful first time, here's exactly what I need from each. Forward these verbatim if it's easier.\n\n**Maintenance coordinator — CMMS downtime export, last 12 months:**\n- One row per downtime event: line, equipment/stage (mix / mill / tint-letdown / fill / other), start timestamp, end timestamp or duration, short description, and planned-vs-unplanned flag if it exists.\n- I don't need cost, parts, or work-order text. I need *frequency and duration*, and specifically I need the long tail preserved — if the export truncates or buckets anything over 24 hours, that's the part I care most about, since your mill motor question lives there.\n- If the only thing he can give me is a list of the big ones from memory with rough dates, take it. Four data points about four-day outages beat four hundred about five-minute stops.\n\n**ERP — order book, last 26 weeks if it goes back that far:**\n- One row per order line: order ID, account, SKU, family if it's a field, quantity, date the order entered the book, promise date (the one on-time is scored against), actual ship date, and line it ran on if that's captured.\n- The two fields that matter most and are most likely to be missing are **date-entered-the-book** and **actual ship date** — without both I can't measure the slack commercial pads in, or reconstruct your real on-time rate. If either is absent, tell me and I'll ask you for the pattern from memory instead.\n\n**Flagging protocol, as you asked:** anything I can't get from those exports goes in a numbered assumption ledger with the value I invented, why, and the cheapest way for you to check it. Nothing gets smuggled in quietly.\n\nTwo things you can answer in ten seconds whenever, no rush — they'll save time tomorrow:\n\n- Does the ERP order book have a **\"release\" or \"firm\" status** separate from the promise date? (That's the thing that was holding your Meridian order until the next morning, and I still don't know what it is.)\n- Roughly how many of the ~40 weekly orders are Meridian?\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Both quick ones:\n\n**Release/firm status** — yeah, there's a field for it, I think it's literally called something like order status: pending, released, in-production, shipped. What was holding my Meridian order that morning specifically was a **credit/allocation hold** — logistics releases orders in batches once the truck's confirmed and the paperwork's clean, and that particular one hadn't been released yet when I wanted to start it, purely an admin timing thing, not a materials or capacity issue. It happens more than you'd think — I sometimes know an order's coming and want to slot it, but I can't actually pull the trigger till ERP says it's released, which can lag the promise date planning by a day or so.\n\n**Meridian count** — out of the ~40, I'd guess 6 to 8 are Meridian in a typical week. Fewer orders than their volume share would suggest, because like I said, they order big.\n\nI'll get both requests out today, verbatim. See you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "Both useful — and the second one reframes the first.\n\n**The credit/allocation hold is a modelled object, not admin noise.** Your headline decision — sit Line 2 idle at 2pm Tuesday or wash down — only exists *because* the next white wasn't releasable yet. That gap isn't a scheduling artefact, it's manufactured by a release process you don't control. Which means the model can answer a question your boss didn't ask: how many idle-vs-washdown dilemmas would simply evaporate if logistics released a few hours earlier, or released Meridian orders on a standing basis rather than truck-by-truck. If that's the real lever, it's a phone call to logistics, not a scheduling change — much cheaper than anything you can do on the floor.\n\nSo I'm adding to tomorrow: **how long is the lag between \"I know it's coming\" and \"ERP says released\", how variable is it, and does it differ for Meridian?** If the ERP export has a released-date or status-change timestamp, that measures it directly — worth adding to your request while it's still unsent.\n\n**6–8 of 40 orders, one-third of volume** also tells me Meridian batches are roughly 2–3× everyone else's. That matters more than it sounds: big orders are many batches, many batches occupy a line for a long contiguous stretch, and a long stretch on Line 2 is exactly what makes everything else queue behind the cliff. I'll check that against the order book rather than assume it.\n\nTomorrow, in this order:\n\n1. **Conflict points** — I'll put four concrete scenarios to you: two lines wanting the crew simultaneously; how you sequence within a line; whether QA can be jumped and who pays; what triggers and what blocks the Saturday ask.\n2. **Splitting and campaigning** — must an order's batches run contiguously, and what actually happens when commercial asks to split across lines.\n3. **Unwritten rules** — week-one mistakes, always/nevers, and rules that exist because of one bad incident.\n\nThen I'll read back the whole model in summary, you correct it, and I build. Enjoy the huddle."
+    },
+    {
+      "role": "user",
+      "content": "Good catch, actually — I hadn't thought about it that way, but you're right, if that's the real lever it's a much cheaper fix than anything I can do with the sheet. I'll add the released-date/status-change timestamp to the ERP ask, and I'll ask the logistics lead directly tomorrow what drives the timing on Meridian releases specifically — my gut says it's tied to truck booking confirmation, which they do a day or two out, but I've never actually asked why it's a day or two and not same-day.\n\nSee you tomorrow — 1, 2, 3 in that order works for me."
+    },
+    {
+      "role": "assistant",
+      "content": "Perfect. Two things to make the logistics conversation pay off, since you're having it anyway:\n\n- **Ask what the release is actually waiting on** — truck booking confirmation, credit check, paperwork, or all three in sequence. If it's a chain, the binding one is usually not the one people name first.\n- **Ask whether a standing release for Meridian is possible** — i.e. release on the production plan rather than on truck confirmation, with the truck booked in parallel. If the answer is \"we've never been asked,\" that's your lever. If it's \"we tried it and stopped,\" find out what went wrong; that's a constraint I need to model.\n\nI'll come tomorrow with the four conflict scenarios pre-written, so you're reacting to concrete cases rather than generating from scratch. Fifteen minutes should hold if we don't wander.\n\nSee you then."
+    },
+    {
+      "role": "user",
+      "content": "Will do — both of those are exactly the right questions, and I should've asked them myself years ago instead of just working around the gap. I'll bring back whatever logistics says, even if it's \"nobody's ever asked.\"\n\nSee you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "Good luck with it.\n\nSo you're not generating from cold tomorrow, here are the four scenarios in advance — no need to prepare, just useful if you happen to read them before we talk. Answer them the way you actually behave, not the way the procedure would read.\n\n**A. Crew contention.** It's 18:00. Line 1 has just finished a specialty run and needs a 2-hour purge before its next job. Line 2 finishes a dark tint at 18:30 and the next thing on it is a Meridian white — a 3½-hour washdown. Both need the two techs, and the techs are already an hour past their nominal day. Who gets them, who waits, and what do you actually do about the loser?\n\n**B. Sequencing within a line.** Line 3 has four releasable orders queued Monday: two light tints due Thursday, one dark tint due Wednesday, one white due Friday. What order do you run them, and what would make you break that order?\n\n**C. Jumping QA.** A Meridian pallet finishes at 16:00 Thursday; the truck is Friday 06:00; the lab has six other batches ahead of it. You ask them to jump it. Do they? Who authorises it, what does the displaced work lose, and has anyone ever said no?\n\n**D. The Saturday ask.** What has to be true before you go to the ops director for Saturday overtime — how far behind, and how late in the week can you still ask before it stops helping? And is there a case where you'd have asked and deliberately didn't?\n\n**Interim assumption ledger** (things I've inferred or invented so far, all provisional — flagging now so none of it goes quiet):\n\n1. **Lateness scored in hours against promise date**, not days. *Assumed* — your board is binary, but a binary metric can't distinguish your own cliff/slope answer. *Check:* ship-date vs promise-date fields in the ERP pull.\n2. **Meridian penalty modelled as a step at \"misses the ship window\"**, magnitude-insensitive beyond that. *From your answer to Q10*, but \"ship window\" needs a definition — I've provisionally taken it as the truck departure, not end-of-promise-day. *Check:* tell me tomorrow if that's wrong.\n3. **Non-Meridian penalty linear in hours, kink upward around 24 hours**, plus a surcharge if the order is an account's whole-week requirement. *Assumed shape* from your Coastal answer. *Check:* none cheap — sensitivity-test it instead.\n4. **Idle time costs nothing directly.** *Your answer to Q8.* Consequence: results only mean anything if due dates and arrivals are realistically tight, so item 3 of tomorrow's list (arrivals) is load-bearing.\n5. **Changeover crew = one indivisible 2-person server**, one job at a time, day shift with discretionary flex. *From Q22*, but I've assumed the quick rinses also consume the full crew. *Check:* scenario A will probably settle it.\n6. **Line 3 batch size ~1,200–1,500 units.** *Your explicit \"don't quote me.\"* *Check:* mix vessel nameplate, 30 seconds on the floor.\n7. **Gut changeover padding modelled as a separate switchable layer** (dark→light tint +30–60 min; all Line 1 washdowns +~15%; tint→white standard 3h → 3.5h). *Your gut, not the matrix.* *Check:* time six changeovers with a phone; the model will tell you first whether it's worth doing.\n8. **Packaging-material stalls modelled separately from filler jams.** *My decomposition, not yours.* *Check:* whether the CMMS export distinguishes them — it may only log equipment faults, in which case the stalls are invisible and I'll need your memory instead.\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Read these on the way out, quick reactions before tomorrow so you're not starting cold either:\n\n**A.** Line 2 wins, no contest — Meridian white beats specialty purge every time, that's not even a hard call. What actually happens to Line 1 is it just sits dirty, purge waits till the crew's free, which given they're already an hour over means it probably doesn't happen till the next morning. So Line 1 loses that overnight slot entirely, not just two hours — the whole gap till someone's back on shift. I might quietly ask the techs to do a shortened version if I'm desperate, but that's rare and it makes maintenance nervous.\n\n**B.** I'd run dark tint first, then the two light tints together, white last — campaigning by family to save changeover, even though the dark tint isn't due till Wednesday and the white's not due till Friday. I'd only break that order if the white were needed sooner than Friday, or if Line 3 wasn't qualified for one of those SKUs yet, in which case it just doesn't go on Line 3 at all and I'm rearranging everything anyway.\n\n**C.** Usually yes, they jump it — I ask the lab lead directly, no formal authorisation, it's a favor system. Displaced work just sits longer, and if it's near end-of-week that can mean *that* batch is the one that hits the Friday-evening trap. Nobody's said no outright, but I've had the lab lead push back hard enough that I backed off once, when jumping it would've meant something else missing its own Friday truck.\n\n**D.** Behind by about a shift is roughly the trigger — if I can see Wednesday that a Meridian order won't make it without extra hours, I ask then. Asking Thursday or later usually doesn't help, not enough runway to get approval and staff it. I've had a case where I didn't ask even though I was tempted — a slip that would've needed Saturday overtime, but it was Coastal, not Meridian, and I judged it wasn't worth the argument with the ops director for a non-scorecard account. That one shipped a day late and nobody outside the plant noticed.\n\nAll good on the ledger — nothing jumps out as wrong. See you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "Those four answers did a lot of work — A and D in particular. Three things they settled, and three new probes I'll fold into tomorrow rather than adding time.\n\n**Settled:**\n- **Crew priority is a strict rule, not a judgement:** Meridian-enabling changeover outranks everything. Non-preemptive, and the loser's penalty isn't the changeover duration — it's *the remainder of the gap until the crew is back on shift*. That's a much harsher cost than a queueing delay and it will show up strongly in results.\n- **Sequencing within a line is campaign-first**, not due-date-first — you deliberately ran the Wednesday-due dark tint ahead of nothing and the Friday white last to save changeovers. Due dates only break the campaign when they'd actually be missed.\n- **QA jumping is an informal, socially-limited resource**, and you've been refused once by being persuaded, which means it has a real budget.\n\n**New probes for tomorrow (short):**\n\n1. **Scenario A, variant:** same clash but *both* lines are waiting on Meridian whites. Is there a tiebreak, or is it whoever's due first? I need to know whether \"Meridian first\" is a rule or shorthand for \"most urgent first.\"\n2. **Scenario B, hidden bit:** you put white *last* on Line 3. Were you thinking about what the line has to run *next* week — leaving it in a good state? If you schedule with one eye on the following Monday, the model needs an end-of-horizon state value, or it will cheat by leaving every line filthy on Friday.\n3. **QA jump budget:** how often do you actually spend it — weekly, monthly? Once per week is a modellable allowance; unlimited is not.\n\n**And one finding from D worth testing, which I don't think you said out loud:** you get Saturday overtime approved on Line 1 or 2 — but the lab is day-shift, weekdays. So Saturday production may just queue for Monday's lab and arrive no earlier than if it hadn't run. Unless the Saturday ask *includes* a lab person, or the Friday-evening trap catches it anyway. Worth asking the ops director whether lab overtime has ever been part of that approval — if it hasn't, some of those four or five Saturdays this year may have bought you nothing.\n\n**Ledger additions:**\n\n9. **Changeover crew is non-preemptive** — an in-progress changeover is never abandoned mid-way for a higher-priority line. *Inferred from A.* *Check:* one word tomorrow.\n10. **A line that misses its changeover window waits until the crew's next shift start**, not merely until the crew is free. *From A.* This is the single most punitive mechanism in the model so far.\n11. **QA jump is front-of-queue, not preemptive** — the test in progress finishes. *Assumed.* *Check:* trivial, ask the lab lead.\n12. **Saturday overtime adds line hours only, not lab or changeover-crew hours.** *Assumed and probably wrong in at least one direction.* *Check:* the ops director question above.\n\nNothing needed before tomorrow. See you then."
+    },
+    {
+      "role": "user",
+      "content": "Ha — the Saturday-lab thing is a genuinely good catch, I've never once thought about whether the lab covers it. I'll ask the ops director point blank tomorrow before our slot if I catch him.\n\nQuick gut reactions on the three probes, so tomorrow's faster:\n\n1. If both lines were waiting on Meridian whites, I think I'd go by whichever ships sooner — so yes, \"Meridian first\" is really shorthand for \"most urgent first,\" Meridian just happens to almost always be the most urgent thing in the room. I'd want to think about whether there's a case where I'd break that, but my instinct says urgency wins even within Meridian.\n\n2. Honestly — yes, guilty, I was thinking about Monday. Ending the week with Line 3 dirty from a white means Monday probably starts with a tint anyway and I've bought myself nothing; ending clean-ish or on a family that's likely to continue into next week is a real thing I do, even if I don't always say it out loud.\n\n3. QA jump — maybe two, three times a month, not every week. If it were weekly the lab lead would start pushing back the way she did that one time.\n\nSee you tomorrow, and nice catch on the lab."
+    },
+    {
+      "role": "assistant",
+      "content": "Good — those three tighten a lot for free.\n\n**What they settle:**\n\n- **Priority rule is \"earliest ship window first, Meridian-weighted\"**, not a hard account hierarchy. That's better news than a strict rule: it's a single sortable key, so the model can implement your current policy *and* test alternatives (pure due-date, pure campaign, campaign-with-Meridian-override) without restructuring anything.\n- **You schedule with a terminal state value.** That's a real modelling requirement and I'd have got it wrong: without it, a week-long simulation happily ends with all three lines dirty on Friday, because the wash-back cost falls outside the window and the model never pays it. I'll add an end-of-week charge for leaving a line in a state that the following Monday's likely demand doesn't match — effectively \"what changeover would Monday have to buy.\" That also stops the model from recommending changeover-avoidance tricks that just push cost over the horizon.\n- **QA jump ≈ 2–3 per month** — a spendable allowance, roughly 0.6/week. Modelled as a budget with a refusal probability that rises as you spend it, which reproduces the lab lead pushing back.\n\n**Ledger additions:**\n\n13. **Changeover-crew priority key = earliest promise-date-at-risk, with Meridian ordered first among ties.** *From probe 1.* *Check:* if you find a real case where you'd knowingly let the sooner-shipping order wait, tell me — it would mean the key needs a second term.\n14. **End-of-horizon state value: each line charged at Friday close for the expected changeover into next week's likely first job.** *My construct, not your words — you described the behaviour, not the accounting.* *Check:* look at what actually ran Monday morning on each line for the last few weeks; if it usually matches Friday's family, my charge is roughly right.\n15. **QA jump allowance = 0.6/week, refusal probability rising with recent usage.** *From probe 3.* *Check:* none needed; sensitivity-test it.\n\n**Tomorrow's slot is now down to three things**, which should fit comfortably in fifteen minutes:\n\n1. **Splitting and campaigning** — must an order's batches run contiguously; what really happens when commercial asks to split across two lines; has it ever worked.\n2. **Unwritten rules** — week-one mistakes, always/nevers, the rules that exist because of one bad incident.\n3. **Whatever the two data pulls and your logistics/ops-director conversations turn up** — arrivals, release lag, breakdown durations, Saturday lab cover.\n\nThen I read the whole thing back and build. See you then."
+    },
+    {
+      "role": "user",
+      "content": "Sounds right — see you tomorrow, I'll have the logistics and ops director answers plus whatever comes back from maintenance and ERP by then, even if it's partial."
+    },
+    {
+      "role": "assistant",
+      "content": "Good. One request on the pulls, whatever shape they arrive in: send them raw rather than tidied. If the CMMS export is 900 rows of five-minute stops with four monsters buried in it, the monsters are the point and I'd rather find them myself than have them pre-summarised away. Same for the order book — I want the messy rows, the cancelled lines, the ones with blank promise dates. The gaps tell me what the plant doesn't record, which is itself a modelling input.\n\nIf either pull is late, we still run the slot: items 1 and 2 are pure head-knowledge and don't depend on the data. I'll build with flagged placeholders and swap them out when the exports land.\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Understood — raw and messy it is, no cleaning up on my end. I'll tell whoever's pulling it not to bother tidying, just dump what the system gives them.\n\nSee you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "Understood — raw is right.\n\nI'll use the gap to draft the structural skeleton, so tomorrow's fifteen minutes goes entirely on splitting/campaigning, the unwritten rules, and the data — not on me reading back things you've already told me twice.\n\nOne thing you don't need to answer now, but it surfaced while I was laying out the net, and it's structural enough that I'd rather you see it coming than have me guess:\n\n**Is a changeover a whole-line event, or does it cascade stage by stage?** You told me the line pipelines — mix can start the next batch while fill finishes the last. But if the next batch is a *different family*, that can't be true unless the washdown happens stage-by-stage as each empties: mix gets cleaned first, then mill, then tint, then fill, with the new order following the cleaning down the line. The alternative is that the whole line drains, the crew washes everything, then the new order starts. Those two produce very different answers to your run-size question — the cascading version makes changeovers much cheaper for long runs, because the wash overlaps with the tail of the previous order. I suspect the truth is \"mostly whole-line for the big tint→white washdown, but the small rinses are more casual,\" but that's me guessing, and it's assumption 16 in the ledger until you tell me.\n\nProvisional skeleton, two minutes to eyeball — tell me tomorrow if the shape is wrong:\n\n- **Token = one batch**, carrying colour: order ID, account, SKU, family, tint depth, promise date, order's batch index and count.\n- **Per line, in series:** Mix → tank → Mill → tank → Tint/Letdown → tank → Fill → QA Hold → Released → Shipped. Tanks capacity 1 (Line 1 mill→fill) or 2 (Lines 2, 3), which is where your Line 1 backup comes from.\n- **Per line, one setup-state place** holding a token for the family/SKU the line is currently dressed for. Changeover transitions consume the crew, the old state token, and emit the new one.\n- **Shared resources as single-token places:** changeover crew (one indivisible 2-person server), lab (two analysts, day shift), each line's shift calendar as an availability gate. The overnight black hole falls straight out of the calendars — no special mechanism needed.\n- **Order release** as a source transition gated by the ERP release timestamp, which is the thing your idle-vs-washdown dilemma actually hangs on.\n- **Scoring** as sink-side observers: board metric (binary, vs promise), true cost (Meridian step + others' slope + changeover hours + end-of-week state charge).\n\n16. **Changeover granularity — whole-line vs cascading per stage.** *Assumed whole-line for washdowns ≥2h, cascading for rinses <1h.* *Check:* one question tomorrow; it materially changes the split-across-lines answer.\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "That skeleton looks right to me at the level I can judge it — I recognize the plant in it, which is more than I expected to say about a diagram.\n\nOn the changeover granularity, since you asked me to sit with it: my honest instinct, without having ever watched it stage-by-stage on purpose, is that you're right — the big tint-to-white washdown really does feel like a whole-line stop, everything's dirty and everyone's waiting, nothing pipelines through it. The quick rinses I genuinely don't know if they cascade or not, I've just never watched closely enough to say, I always think of the line as \"down for 25 minutes\" rather than picturing what's happening stage by stage. I'll actually go stand at Line 2 for one of the small rinses before tomorrow and watch instead of guessing — that one's cheap to check and I'd rather give you a real answer than a guess dressed up as one.\n\nSee you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "That's the right instinct, and it'll take you five minutes. So the observation is worth having, here's what to look for — otherwise it's easy to watch a rinse and come away with \"yep, took 25 minutes,\" which is what you already know.\n\n**Three things to note, in this order:**\n\n1. **Does mix restart before fill is clean?** That's the whole question. If you see the mixer running the new product while the fill head is still being wiped, it cascades. If everyone stands around until the last stage is signed off, it's whole-line.\n2. **Do both techs work the same stage, or split up?** For a quick rinse specifically — if one tech does mix and mill while the other does tint and fill, that's not just cascading, it's a *parallel* crew, and my \"one indivisible 2-person server\" assumption (ledger 5) is wrong for small changeovers. That would meaningfully change crew contention, because it would mean two quick rinses on two lines might actually be possible at once.\n3. **When does the clock actually start and stop?** Is the 25 minutes wall-to-wall from last-batch-out to first-batch-in, or is there dead time either side — waiting for the tech to arrive, waiting for a sign-off, waiting for the line lead to confirm? Dead time that isn't crew time is a different fix from crew time.\n\nIf you can, note the wall-clock times of each — start, first stage clean, last stage clean, next batch started. Four timestamps on your phone is enough.\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Good, that's specific enough that I'll actually catch something real instead of just confirming what I already believe. I'll grab those four timestamps and watch for the split-crew thing especially — I hadn't even considered they might work separate stages, but now you say it I think I actually have seen the two of them go to opposite ends of the line at once and just never registered it as meaningful.\n\nSee you tomorrow with real numbers instead of a vibe."
+    },
+    {
+      "role": "assistant",
+      "content": "Good. One addition while you're standing there, since it costs nothing: **if you do see them split to opposite ends, note whether that's rinse-only or whether they'd split on a big washdown too.** My guess from what you said earlier — \"genuinely a two-person job, stuff to hold and check simultaneously\" — is that the big ones force them together and only the small ones allow splitting. If that's right, the crew is one server for washdowns and two for rinses, which is an easy thing to represent and a slightly awkward thing to discover later.\n\nAnd if what you see contradicts the skeleton, that's a good outcome, not a setback — it's cheaper to find it now than after I've built the net around it.\n\nSee you tomorrow."
+    },
+    {
+      "role": "user",
+      "content": "Good point — I'll watch for exactly that distinction, whether the splitting is a rinse-only thing or whether they'd do it on a washdown too if they had reason to. And you're right, I'd much rather walk in tomorrow saying \"actually, no\" than have you build the whole thing around something I half-remembered.\n\nSee you tomorrow."
+    },
+    {
+      "role": "assistant",
+      "content": "See you tomorrow.\n\nI'll have the net drafted to the point where only the open questions are holes — splitting/campaigning, changeover granularity, and the placeholder distributions for breakdowns and arrivals. Tomorrow: your three answers, the data if it's landed, then I read the whole thing back for correction and build."
+    },
+    {
+      "role": "user",
+      "content": "I really do have to stop here. Please produce the model now with everything you have."
+    },
+    {
+      "role": "assistant",
+      "content": "Understood. Here is the model as it stands, built on what you gave me, with everything I had to invent flagged rather than smuggled.\n\n**One honest caveat up front:** we stopped before covering three things I'd listed as material — order splitting/campaigning contiguity (your run-size question), the unwritten rules, and the two data pulls. The model is built and runnable without them, but two of your three headline questions are affected. I've said exactly where in Section C, and the ledger tells you which dials to turn when the data lands.\n\n---\n\n# A. THE MODEL\n\nA coloured, timed Petri net with priority-resolved conflicts. Tokens are **batches**; colours carry the order attributes; timed transitions carry the durations; shared resources are capacity-limited places; calendars are gate places. Everything is named in your vocabulary.\n\n## A.0 Global switches (set these per experiment)\n\n| Switch | Values | Default | Why it exists |\n|---|---|---|---|\n| `TIME_BASIS` | `SHEET` \\| `GUT` | `GUT` | Standard matrix times vs your padding. Running both tells you whether it's worth timing changeovers properly. |\n| `CO_GRANULARITY` | `WHOLE_LINE` \\| `CASCADE` \\| `SPLIT_BY_SIZE` | `SPLIT_BY_SIZE` | Whole-line for washdowns ≥2 h, cascading for rinses <1 h. Unresolved — you were going to watch a rinse. |\n| `CREW_MODE` | `ONE_SERVER` \\| `SPLIT_ON_RINSE` | `ONE_SERVER` | Whether the two techs can work two rinses at once. Unresolved — the thing you'd half-noticed. |\n| `RELEASE_POLICY` | `TRUCK_CONFIRMED` \\| `STANDING_MERIDIAN` | `TRUCK_CONFIRMED` | Models the logistics lever. This is the cheap-fix experiment. |\n| `SAT_LAB_COVER` | `OFF` \\| `ON` | `OFF` | Whether Saturday overtime includes a lab analyst. |\n| `SEQ_RULE` | `CAMPAIGN_FIRST` \\| `DUE_DATE_FIRST` \\| `CAMPAIGN_WITH_MERIDIAN_OVERRIDE` | `CAMPAIGN_FIRST` | Your current policy is the default; the others are the alternatives to test. |\n| `EOW_CHARGE` | `ON` \\| `OFF` | `ON` | End-of-week dirty-line charge. Off = the model cheats. |\n\n## A.1 Colour sets\n\n```\nFAMILY   = { WHITE, TINT, SPECIALTY }\nDEPTH    = { NA, LIGHT, DARK }              (* tints only *)\nACCOUNT  = { MERIDIAN, OTHER }\nLINE     = { L1, L2, L3 }\n\nSKU      = record { skuId : STRING,\n                    family : FAMILY,\n                    depth : DEPTH,\n                    meridianQual : BOOL,     (* Line 2 fill-area qualification *)\n                    l3Qual : BOOL }          (* on Line 3's validated list *)\n\nORDER    = record { oid : STRING,\n                    account : ACCOUNT,\n                    sku : SKU,\n                    qty : INT,\n                    bookTime : TIME,         (* Sunday 23:00 *)\n                    releaseTime : TIME,      (* ERP status -> released *)\n                    promiseTime : TIME,      (* the truck it must make *)\n                    wholeWeek : BOOL,        (* account's whole-week requirement *)\n                    line : LINE,             (* set by allocation *)\n                    nBatches : INT }\n\nBATCH    = record { oid, idx, of : INT,\n                    units : INT,\n                    sku : SKU,\n                    account : ACCOUNT,\n                    promiseTime : TIME,\n                    testFlag : BOOL,         (* does QA sample this one *)\n                    startedAt : TIME }\n\nSETUP    = record { line : LINE, sku : SKU,\n                    family : FAMILY, depth : DEPTH }   (* what the line is dressed for *)\n\nTECH     = unit                              (* changeover crew member *)\nANALYST  = unit                              (* lab *)\n```\n\n## A.2 Places\n\n**Order-level (plant-wide)**\n\n| Place | Contents | Capacity |\n|---|---|---|\n| `P_Book` | ORDER, status pending | ∞ |\n| `P_Allocated` | ORDER with `line` set, still pending ERP release | ∞ |\n| `P_Releasable` | ORDER, ERP-released, awaiting line | ∞ |\n| `P_OrderDone` | ORDER, all batches QA-released | ∞ |\n| `P_Shipped` | ORDER, on the truck | ∞ |\n\n**Per line L ∈ {L1, L2, L3}** (the flow shop, exactly as you walked it)\n\n| Place | Contents | Capacity |\n|---|---|---|\n| `P_MixQueue_L` | BATCH awaiting mix | ∞ |\n| `P_Mixing_L` | BATCH in mix vessel | 1 |\n| `P_Tank_MixMill_L` | BATCH in holding tank | `TANKCAP(L)` |\n| `P_Milling_L` | BATCH in mill | 1 |\n| `P_Tank_MillFill_L` | BATCH in holding tank | `TANKCAP(L)` ← **Line 1 = 1, the backup you described** |\n| `P_Tinting_L` | BATCH in tint/letdown | 1 |\n| `P_Tank_TintFill_L` | BATCH in holding tank | `TANKCAP(L)` |\n| `P_Filling_L` | BATCH at fill head | 1 |\n| `P_SetupState_L` | exactly one SETUP token | 1 |\n| `P_LineIdleClean_L` | 1 token iff no batch anywhere in L's stages | 1 |\n| `P_LineUp_L` | 1 token iff not broken down | 1 |\n| `P_ShiftOpen_L` | 1 token iff a shift is manned | 1 |\n| `P_COinProgress_L` | 1 token during a whole-line changeover | 1 |\n\n`TANKCAP(L1) = 1` (mill→fill specifically; the other two tanks on L1 = 2), `TANKCAP(L2) = TANKCAP(L3) = 2`.\n\n**Shared resources**\n\n| Place | Contents | Capacity | Notes |\n|---|---|---|---|\n| `P_CrewPool` | TECH tokens | 2 | Both techs = one crew unless `CREW_MODE = SPLIT_ON_RINSE` |\n| `P_CrewShift` | 1 token iff crew on shift or flexed | 1 | Absence of this token is the **2 a.m. black hole** |\n| `P_QAHold` | BATCH awaiting sample | ∞ | The pallets sitting in hold |\n| `P_LabAnalysts` | ANALYST tokens | 2 | |\n| `P_LabShift` | 1 token iff lab manned | 1 | Absence = the **Friday-evening trap** |\n| `P_Testing` | BATCH under test | 2 | |\n| `P_QAReleased` | BATCH released | ∞ | |\n| `P_JumpBudget` | jump tokens | replenished 0.6/wk | The favour-with-the-lab-lead allowance |\n\n## A.3 Transitions\n\n### Arrivals and release\n\n| Transition | Guard | Timing | Effect |\n|---|---|---|---|\n| `T_BookLands` | fires Sun 23:00 weekly | — | Emits ~40 ORDER tokens into `P_Book` (composition in ledger 27–29) |\n| `T_Allocate` | ORDER in `P_Book`; line qualification guard (below) | Mon 07:00 (fires for whole book) | Sets `line`, computes `nBatches = ceil(qty / VESSEL(line))`, moves to `P_Allocated` |\n| `T_ERPRelease` | ORDER in `P_Allocated` | at `releaseTime` | → `P_Releasable`. **This is the transition your idle-vs-washdown dilemma hangs on.** Under `STANDING_MERIDIAN`, Meridian orders bypass and release at allocation. |\n| `T_Explode` | ORDER in `P_Releasable`, line's queue accepts it | instant | Emits `nBatches` BATCH tokens into `P_MixQueue_L`, sets `testFlag` per sampling rule |\n\n**Allocation qualification guard (hard constraints):**\n```\naccount = MERIDIAN            ⇒  line = L2                     (audit qualification)\nsku.family = SPECIALTY        ⇒  line = L1                     (L2 not piped for clears)\nline = L3                     ⇒  sku.l3Qual = true             (validated-SKU list)\n```\n\n### Production stages (per line, per batch)\n\nEach stage is a pair: `T_Start_<stage>_L` and `T_End_<stage>_L`.\n\n| Transition | Preconditions | Duration |\n|---|---|---|\n| `T_StartMix_L` | BATCH in `P_MixQueue_L` (chosen by sequencing policy), `P_Mixing_L` free, `P_SetupState_L` matches batch SKU, `P_ShiftOpen_L`, `P_LineUp_L`, no `P_COinProgress_L` | — |\n| `T_EndMix_L` | | `units / RATE(mix, family, L)` |\n| `T_StartMill_L` | token in `P_Tank_MixMill_L`, `P_Milling_L` free, gates as above | — |\n| `T_EndMill_L` | **blocks if `P_Tank_MillFill_L` at capacity** ← Line 1's problem | `units / RATE(mill, family, L)` |\n| `T_StartTint_L` / `T_EndTint_L` | as above | `units / RATE(tint, family, L)` |\n| `T_StartFill_L` | | — |\n| `T_EndFill_L` | | `units / RATE(fill, family, L)` × Noise + JamAdder + StallAdder |\n| `T_ToQAHold` | fill complete | instant | → `P_QAHold` if `testFlag`, else straight to `P_QAReleased` |\n\n**Rates (units/hour).** Derived from your per-batch times, expressed the way your sheet does it:\n\n| Stage | WHITE | TINT | SPECIALTY |\n|---|---|---|---|\n| Mix (all lines) | 3600 | 3600 | 3600 |\n| Mill L1 / L2 / L3 | 2900 / 2900 / 2900 | 1450 | 480 (L1 only) |\n| Tint-letdown | 12000 (negligible) | 1450 | 2400 |\n| **Fill L1** | **700** | 700 | 650 |\n| **Fill L2** | **950** | 800 | n/a |\n| **Fill L3** | **900** | 800 | n/a |\n\nNote what this reproduces: whites are fill-bound and L2 is ~35% faster than L1; tints are mill/tint-bound so L1 and L2 come out **nearly even on tints**, which is the thing you noticed and couldn't explain; specialty is mill-bound on L1.\n\n**Vessel sizes (units/batch):** L1 = 1,100; L2 = 1,650; L3 = 1,350 *(the one you told me not to quote)*.\n\n**Fill-stage disruption (the fat right tail):**\n```\nNoise       ~ LogNormal(median 1.00, σ 0.06)      (* thin upside — fill runs near rate *)\nJamAdder    = 0 w.p. 0.90 ; Uniform(0.33, 0.50) h w.p. 0.10     (* small filler jam *)\nStallAdder  = 0 w.p. 0.95 ; Uniform(0.25, 1.00) h w.p. 0.05     (* packaging/labels not restocked *)\n```\nJams and stalls are kept separate deliberately — you may find the warehouse restock is the cheaper fix.\n\n### Changeover\n\n`T_Changeover_L` fires when the next batch selected for line L has a SKU that doesn't match `P_SetupState_L`.\n\n**Preconditions (WHOLE_LINE mode — the ≥2 h washdowns):**\n- `P_LineIdleClean_L` (every stage empty — the line has drained)\n- 2 TECH tokens from `P_CrewPool`\n- `P_CrewShift` present\n- Emits `P_COinProgress_L`, consumes old SETUP, emits new SETUP after duration\n\n**Preconditions (CASCADE mode — the <1 h rinses):** four sub-transitions `T_CO_Mix_L`, `T_CO_Mill_L`, `T_CO_Tint_L`, `T_CO_Fill_L`, each requiring only its own stage to be empty and 1 or 2 TECH tokens per `CREW_MODE`. The new order follows the cleaning down the line.\n\n**Changeover matrix (hours).** SHEET = your spreadsheet; GUT = your padding.\n\n| From → To | SHEET | GUT |\n|---|---|---|\n| WHITE → WHITE, same SKU | 0.25 | 0.25 |\n| WHITE → WHITE, different SKU | 0.42 | 0.42 |\n| WHITE → TINT | 0.75 | 0.75 |\n| TINT → TINT, light→light or dark→dark | 0.58 | 0.58 |\n| TINT → TINT, **dark→light** | 0.58 | **1.25** |\n| **TINT → WHITE** | **3.00** | **3.50** (3.75 if previous was dark) |\n| any ↔ SPECIALTY | 2.00 | 2.00 |\n| Line 1 multiplier on any changeover ≥ 2 h | 1.00 | **1.15** |\n\n**The punitive mechanism (from your Scenario A answer):** because the crew requires `P_CrewShift`, a line that misses the crew window doesn't wait for the crew to *finish* — it waits until the crew's next shift *starts*. Line 1 in your scenario doesn't lose 2 hours, it loses the whole overnight. This falls out of the net structure; no special rule needed.\n\n### QA\n\n| Transition | Preconditions | Duration |\n|---|---|---|\n| `T_Sample` | BATCH in `P_QAHold`, ANALYST free, `P_LabShift` | WHITE 3.5 h, TINT 4.0 h, SPECIALTY 5.0 h (median, LogNormal σ 0.25) |\n| `T_Release` | test complete | instant → `P_QAReleased` |\n| `T_Jump` | BATCH is Meridian-critical **and** jump token available | Moves batch to head of `P_QAHold`; consumes 1 jump token; **not preemptive** — the test in progress finishes |\n\nJump refusal: `P(refuse) = min(0.8, 0.15 × jumps_used_this_month)` — reproduces the lab lead pushing back as you spend the favour.\n\n**Sampling rule:** first batch of an order always; every 3rd thereafter; **last batch of an order always** (this is what makes the order held up by its last batch, as you described).\n\n### Shipping and scoring\n\n| Transition | Preconditions | Effect |\n|---|---|---|\n| `T_OrderComplete` | all of an order's batches in `P_QAReleased` | → `P_OrderDone` |\n| `T_Ship` | order complete, truck departure time reached | → `P_Shipped`, records `shipTime` |\n| `T_ScoreOrder` | on shipping | writes board metric + true cost |\n| `T_EndOfWeekCharge` | Fri 22:00 | charges each line for the changeover next Monday's first job would need |\n\n### Breakdowns\n\n| Event | Rate | Duration |\n|---|---|---|\n| **Major outage** (mill motor class) — removes `P_LineUp_L` | 0.038 per line-week (~1 per 6 months per line) | LogNormal median 48 h, P90 120 h |\n| **Bad filler jam** — blocks `P_Filling_L` | 0.5 per line-week | LogNormal median 3 h, P90 6 h |\n\nRepair only proceeds during manned hours (a Friday-night motor failure is not being fixed Saturday).\n\n## A.4 Calendars (gate sub-nets)\n\n| Gate | Pattern |\n|---|---|\n| `P_ShiftOpen_L1`, `P_ShiftOpen_L2` | Mon–Fri 06:00–22:00 (two shifts, handover mid-batch permitted) |\n| `P_ShiftOpen_L3` | Mon–Fri 06:00–14:00 (day only) |\n| `P_CrewShift` | Mon–Fri 07:00–15:30 base; extended 05:00–19:00 **for a changeover pre-arranged ≥8 h ahead** |\n| `P_LabShift` | Mon–Fri 07:00–17:00 |\n| Saturday overtime | Adds `P_ShiftOpen_L1` or `L2` Sat 06:00–18:00. Requires trigger by **Wed 17:00**. **Adds no lab and no crew hours** unless `SAT_LAB_COVER = ON`. |\n| Trucks | Depart 06:00 daily, Mon–Fri |\n\n## A.5 The policy layer — conflict resolution\n\nPetri nets need explicit resolution wherever transitions compete. Every one of these is a policy you told me, and every one is swappable.\n\n**Conflict 1 — two lines want the changeover crew.**\nPriority key: `(is_Meridian_enabling DESC, earliest_promise_at_risk ASC)`. **Non-preemptive** — an in-progress changeover is never abandoned. Loser waits for crew *and* `P_CrewShift`, which is where the overnight loss comes from.\n\n**Conflict 2 — which batch starts next on a line (`SEQ_RULE`).**\n- `CAMPAIGN_FIRST` *(your current behaviour)*: group by family to avoid changeover; within a campaign, earliest promise first; break the campaign only if a due date would actually be missed.\n- `DUE_DATE_FIRST`: pure earliest-promise.\n- `CAMPAIGN_WITH_MERIDIAN_OVERRIDE`: campaign, but any Meridian order at risk jumps immediately.\n\n**Conflict 3 — idle vs washdown** *(your headline decision)*. When a line goes empty and the next same-family order isn't releasable yet:\n```\nIF (wash away + wash back) would touch any Meridian order's ship window\n   THEN idle                                      (* the cliff *)\nELSE IF gap_hours ≥ (wash_away + gap_job_runtime + wash_back)\n   THEN take the gap job\nELSE idle\n```\nThis is your Q10 answer, implemented literally. It's also a *replaceable* rule — the point of the model is to run alternatives against it.\n\n**Conflict 4 — lab queue.** FIFO on arrival at `P_QAHold`, except jump tokens. Displaced work simply waits, and if it's late in the week it hits the Friday trap — which is exactly the cost of a jump.\n\n**Conflict 5 — Saturday ask.** Trigger: at Wed 17:00, if any Meridian order's projected completion exceeds its ship window by ≥1 shift, request overtime on whichever of L1/L2 carries it. Non-Meridian shortfalls do **not** trigger a request (your Coastal case: you didn't ask, it shipped a day late, nobody outside noticed).\n\n## A.6 Scoring\n\n**Board metric** — binary on-time % against promise date. Reported separately so you can tell your boss what the board will say.\n\n**True cost** — unit is one line-hour.\n\n```\nChangeover      = 1.0 × changeover_hours                    (* lost line time *)\nIdle            = 0                                          (* invisible on paper; hurts only via the clock *)\n\nMeridian late   = 200  (step, on missing the truck at all)  + 1.0 × hours_late\nOther late      = 0                    for hours_late ≤ 4\n                = 0.5 × (h − 4)        for 4 < h ≤ 24\n                = 10 + 4.0 × (h − 24)  for h > 24\nWhole-week req. = × 2 multiplier on the above\n\nEnd-of-week     = expected changeover hours from each line's Friday state\n                  into next Monday's first job\n```\n\nCalibration check on these weights: they reproduce your two bets. Meridian 6 h late = 206 ≫ 4 changeover-hours, so you idle. Coastal 6 h late = 1.0 < 4 changeover-hours, so you take the tint job. Coastal 48 h late = 106 ≫ 4, so you don't. That's your cliff and your slope.\n\n## A.7 Experiments mapped to your three questions\n\n| Your question | Run |\n|---|---|\n| *\"If Line 1's mill motor takes four days again, what do I move and what slips?\"* | Inject a 96 h `P_LineUp_L1` outage at chosen points in the week; compare re-allocation policies. Note L1 holds all specialty, so specialty has nowhere to go — the model will show you that as a hard block, not a delay. |\n| *\"Idle an hour or wash down?\"* | Sweep the Conflict-3 rule against alternatives, crossed with `RELEASE_POLICY`. **Run `STANDING_MERIDIAN` first** — the hypothesis is that most of these dilemmas are manufactured by release timing, not by scheduling. |\n| *\"Where are my changeover hours going, and would reordering get them back?\"* | Changeover-hours ledger by line × family-transition × cause. Then `SEQ_RULE` sweep. Cross with `TIME_BASIS` to see whether your gut padding changes any decision — if it doesn't, don't bother timing changeovers. |\n| *(bonus, from Saturday overtime)* | `SAT_LAB_COVER = OFF` vs `ON`. Tests whether some of this year's four or five Saturdays bought you nothing because the lab was shut Monday-ward. |\n\n**Validation target when the data lands:** replay the last 26 weeks and check the model produces (a) ~75% line utilisation, (b) **30–40 changeover-hours per month** — your ops director's own number, and the single best calibration anchor you gave me — and (c) a board on-time % matching history. If changeover-hours come out low, `CO_GRANULARITY` or the sequencing rule is wrong.\n\n---\n\n# B. ASSUMPTION LEDGER\n\nEverything below is mine, not yours. **Bold = load-bearing** (could change a recommendation).\n\n### From the interview, provisionally agreed\n\n1. **Lateness scored in hours vs promise date.** Your board is binary but binary can't express your own cliff/slope. *Check:* ship-date vs promise-date in the ERP pull.\n2. **Meridian penalty"
+    },
+    {
+      "role": "user",
+      "content": "I really do have to stop here. Please produce the model now with everything you have."
+    },
+    {
+      "role": "assistant",
+      "content": "Section A above stands as the model — it is complete and runnable. Here are the two remaining deliverables.\n\n---\n\n# B. ASSUMPTION LEDGER\n\nEverything here is mine, not yours. **Bold = load-bearing**: it could change a recommendation, so check it before you act on a result that depends on it.\n\n### Objectives and scoring\n\n1. **Lateness scored in hours against promise date**, not days. Your board is binary, but a binary metric cannot express the cliff/slope you described. *Check:* promise-date vs actual-ship-date fields in the ERP pull.\n2. **Meridian penalty = step of 200 line-hours at \"misses the truck\", plus a token 1.0/hour after.** Your Q10 answer was a cliff; the small linear term only breaks ties. **I defined \"ship window\" as truck departure (06:00), not end-of-promise-day.** *Check:* one sentence from you — if the window is really end-of-day, several tight cases flip.\n3. **Non-Meridian penalty: free under 4 h, 0.5/h to 24 h, then 4.0/h.** Invented shape from your Coastal answer (\"somewhere around a day is where I'd feel bad\"). *Check:* none cheap — sensitivity-test the kink location instead.\n4. **Whole-week-requirement multiplier = ×2.** Pure invention; you said it \"matters\" without quantifying. *Check:* judgement call from you.\n5. **Idle costs zero directly.** Your Q8 answer. Consequence: results are only meaningful if arrivals and due dates are realistically tight — which makes item 27–29 load-bearing.\n6. **Changeover costed at 1.0 line-hour per hour**, i.e. purely lost line time, no crew wage or solvent cost. Your guess in Q7. *Check:* ask finance what the 40-changeover-hours line item actually contains.\n7. **The 200-vs-4.0 ratio was reverse-engineered to reproduce your two bets**, not elicited. It is a *fitted* number. *Check:* run three more of your own bets against the scoring function and see if it still agrees with you.\n\n### Structure and taxonomy\n\n8. **Four stages per line, all three lines identical in topology.** From your walkthrough of Line 2 only. *Check:* does Line 3 have a separate tint/letdown stage at all, or is it combined?\n9. **Tank capacity: Line 1 mill→fill = 1 batch; all other tanks = 2.** From \"small, so mill backs up\" and \"adequately sized\" elsewhere. *Check:* nameplate volumes ÷ batch size, ten minutes on the floor.\n10. **Vessel sizes: L1 = 1,100, L2 = 1,650, L3 = 1,350 units.** You explicitly said don't quote L3. *Check:* mix vessel nameplate, 30 seconds.\n11. **14 SKUs split 4 white / 8 tint / 2 specialty**, with tint depth assigned arbitrarily. *Check:* the SKU master; also tells me which tints are dark.\n12. **Line 3's unqualified list = 2 tint SKUs.** Your number, but I picked *which* two. *Check:* the quality validation list.\n13. **Specialty runs on Line 1 only.** Follows from L2 not being piped and L3's list — but I never asked whether L3 can run specialty. *Check:* one question. **If L3 can, the mill-motor scenario changes materially**, because specialty currently has nowhere to go.\n14. **Meridian orders are Line 2 only**, and this is absolute — no emergency override exists. *Check:* has anyone ever run Meridian on L1 in a crisis?\n\n### Durations\n\n15. **Stage rates in the table are reconstructed from your per-batch estimates**, which you flagged as partly guesswork. The *pattern* (whites fill-bound, L2 faster on whites, L1≈L2 on tints, specialty mill-bound) is yours; the numbers are mine. *Check:* the sheet's units/hour per product per line — that's a direct calibration and you already have it.\n16. **Mix time identical across families and lines.** Never asked. Probably wrong for specialty.\n17. **Fill noise LogNormal σ=0.06, jam 10% at 20–30 min, packaging stall 5% at 15–60 min.** Jam frequency is yours; the stall frequency is invented, and **I invented the stall/jam split entirely** — you described both but never separated them. *Check:* whether the CMMS distinguishes equipment faults from material starvation. It probably doesn't, in which case only your memory can separate them.\n18. **QA test durations: white 3.5 h, tint 4.0 h, specialty 5.0 h**, LogNormal σ=0.25. Only \"about four hours for whites\" is yours; the family differences and the spread are invented. *Check:* lab lead, five minutes.\n19. **QA sampling rule: first batch, every third, and always the last.** You said \"per some number of batches\"; the \"always the last\" is my inference from your \"held up by its last batch\". *Check:* lab lead.\n20. **Changeover matrix as tabulated**, both layers. SHEET values are your recollection of a spreadsheet neither of us has seen. *Check:* open the spreadsheet.\n21. **GUT layer: dark→light tint 0.58→1.25 h; tint→white 3.0→3.5 h (3.75 after dark); Line 1 ×1.15 on washdowns.** All your gut, quantified by me. *Check:* four timestamps on six changeovers — but run `TIME_BASIS` both ways *first*; if it changes no decision, don't bother.\n22. **Changeover granularity: whole-line ≥2 h, cascading <1 h.** Unresolved — you were going to watch a rinse. **This materially changes the split-across-lines answer**, because cascading makes changeovers much cheaper for long runs.\n23. **Crew is one indivisible 2-person server for all changeovers.** Unresolved — you'd half-noticed them working opposite ends of the line. If rinses can be split, two lines can rinse simultaneously and crew contention drops significantly.\n\n### Policies\n\n24. **Crew priority = Meridian-enabling first, then earliest promise at risk; non-preemptive.** From Scenario A and your follow-up that \"Meridian first\" is really shorthand for \"most urgent first\". *Check:* whether an in-progress changeover has ever been abandoned.\n25. **A line missing the crew window waits for the crew's next shift start**, not merely until the crew frees up. From Scenario A. **This is the most punitive mechanism in the model** — it converts a 2-hour changeover into a lost overnight.\n26. **Crew flex window (05:00–19:00) requires ≥8 h notice.** Invented; you said flexing is \"a normal ask\" without saying how much warning it needs. *Check:* ask the techs. **It directly governs whether an evening washdown happens or waits for morning**, which is the core of your headline decision.\n27. **QA jump: front-of-queue, non-preemptive, 0.6 tokens/week, refusal probability 0.15 × jumps-used-this-month.** The 2–3/month is yours; the refusal curve is invented to reproduce the one time you backed off.\n28. **Saturday overtime: triggered Wed 17:00, Meridian shortfall ≥1 shift, L1/L2 only, adds no lab or crew hours.** Trigger and timing are yours; **the \"no lab cover\" assumption is the one I most expect to be wrong in a useful direction.** *Check:* the ops director question you were going to ask.\n29. **End-of-week charge = expected changeover into Monday's first job.** You described the behaviour (\"ending clean-ish is a real thing I do\"); the accounting is entirely my construct. *Check:* compare each Friday's finishing family to the following Monday's first job for the last few weeks. Without this the model cheats by leaving every line filthy on Friday.\n\n### Boundary conditions\n\n30. **40 orders/week arriving Sunday 23:00 as a single batch**, of which 6–8 Meridian. Yours. But **arrivals within the week are modelled as zero — nothing arrives mid-week.** Never asked. If urgent mid-week orders exist, they're a major missing disturbance.\n31. **Order size distribution: Meridian LogNormal median 7,000 units; others median 2,500.** Derived from \"one-third of volume from 6–8 of 40 orders\". *Check:* the ERP pull directly.\n32. **Promise dates 4–9 days after book date, uniform.** Pure invention — I never got commercial's padding. **This is the single most load-bearing unknown in the model**, because assumption 5 means idling is only penalised through due-date pressure. Too much padding and the model idles happily and tells you nothing. *Check:* ERP pull, book-date vs promise-date.\n33. **ERP release lag: 24 h before promise date, ±12 h, same for all accounts.** Invented from \"can lag by a day or so\". **This is the mechanism that creates your headline dilemma**, so it deserves the release-timestamp field you added to the ask.\n34. **Breakdowns: major outage 1 per line per 6 months, median 48 h / P90 120 h; bad filler jam 0.5/line-week, median 3 h.** Anchored only to \"the mill motor took four days once\" and \"a bad one every couple of weeks\". **Entirely invented rates.** *Check:* the CMMS export — this is what it's for.\n35. **Repairs only progress during manned hours.** Never asked; plausible but could be badly wrong for a contracted motor rebuild.\n36. **Simulation starts Monday 06:00 with all lines empty and clean, dressed for white.** Convenient, not real. *Check:* run a one-week warm-up before scoring, which is what I'd recommend regardless.\n37. **No materials constraint.** You said you only watch for red flags. Means the model can never reproduce a resin shortage. *Check:* how often does a red flag actually stop a run? If more than once a quarter, it needs modelling.\n\n---\n\n# C. WHAT THE MODEL DELIBERATELY LEAVES OUT\n\n**Left out because we ran out of time — these are real gaps, not simplifications:**\n\n1. **Batch contiguity and order splitting.** I never learned whether an order's batches must run contiguously on a line, or whether you can interleave two orders. The model currently assumes **contiguous** — once an order starts on a line, its batches run to completion before another order's batches begin. **This directly limits your run-size question.** The model can compare \"whole order on L1\" vs \"half on L1, half on L2\" as two allocations, and will correctly count the extra changeover on both lines — but it cannot represent the finer manoeuvres you might actually use, and if interleaving is possible in reality the model will overstate the cost of splitting. *This is the first thing to fix.*\n\n2. **The unwritten rules.** We never covered week-one mistakes, always/nevers, or rules that exist because of one bad incident. In my experience this category produces two or three constraints that invalidate otherwise-attractive schedules — the model will likely propose something that makes you say \"we'd never do that,\" and each time it does, that's an unwritten rule surfacing. **Treat those moments as findings, not bugs**, and send them to me.\n\n3. **All historical data.** Neither the CMMS export nor the ERP order book arrived. Every arrival, promise-date, release-lag and breakdown number is invented (ledger 30–34). **Do not run the model for decisions until at least the order book is loaded** — assumption 32 in particular can make the whole thing tell you a comfortable lie.\n\n**Left out on purpose:**\n\n4. **Materials and the supply chain.** You don't schedule around them, so modelling them would add a large disturbance you don't control and can't act on. Revisit only if red flags stop runs more than rarely (ledger 37).\n5. **Individual operators, skills and absence** — except where you named them as a constraint (the changeover crew, the lab, Line 3's qualified operator). Modelling the labour pool properly would double the model's size to answer a question you didn't ask.\n6. **Quality failures and rework.** You never mentioned a batch failing QA, only waiting for it. If batches do occasionally fail, that's a missing feedback loop and a significant one — tell me.\n7. **Warehouse, truck capacity and logistics beyond the release gate.** Trucks are a fixed daily departure. The one place logistics *does* bite — the credit/allocation release — is modelled explicitly, because it's your headline lever.\n8. **Commercial's promise-date-setting behaviour.** Promise dates are exogenous input. If you later want to ask \"should commercial pad more or less,\" that's a different model with this one inside it.\n9. **Cost in dollars.** Everything is denominated in line-hours, because nobody could give me a dollar figure and a fake conversion would only add false precision. If finance produces a rate for changeover hours, the scoring function converts in one line.\n\n---\n\n**If you do three things before the first real run, do these:** load the ERP order book (kills assumptions 31–33, the ones that can make the model lie comfortably); answer the batch-contiguity question in one sentence (unblocks your run-size question); and run `RELEASE_POLICY = STANDING_MERIDIAN` against the default (tests whether your headline dilemma is manufactured upstream of you, which is the cheapest finding available and doesn't need the data at all).\n\nSend me the exports and the answers to the flagged items when you have them, and I'll revise. Thanks — that was an unusually good interview to conduct; the cliff-and-slope answer in particular is the kind of thing most people can't articulate about their own judgement."
+    },
+    {
+      "role": "user",
+      "content": "I really do have to stop here. Please produce the model now with everything you have."
+    },
+    {
+      "role": "assistant",
+      "content": "# COATINGS PLANT SCHEDULING MODEL — FINAL DELIVERABLE\n\nComplete and self-contained. Hand Section A to your modelling person; keep Section B for yourself.\n\n---\n\n# A. THE MODEL\n\nA **coloured, timed Petri net with priority-resolved conflicts**. Tokens are *batches*; token colours carry order attributes; transitions are timed; shared resources and calendars are capacity-limited places.\n\n## A.0 Experiment switches\n\n| Switch | Values | Default | Purpose |\n|---|---|---|---|\n| `TIME_BASIS` | `SHEET` / `GUT` | `GUT` | Matrix standard times vs your padding |\n| `CO_GRANULARITY` | `WHOLE_LINE` / `CASCADE` / `SPLIT_BY_SIZE` | `SPLIT_BY_SIZE` | Whole-line for washdowns ≥2 h, cascade for rinses <1 h *(unresolved)* |\n| `CREW_MODE` | `ONE_SERVER` / `SPLIT_ON_RINSE` | `ONE_SERVER` | Can the two techs run two rinses at once *(unresolved)* |\n| `RELEASE_POLICY` | `TRUCK_CONFIRMED` / `STANDING_MERIDIAN` | `TRUCK_CONFIRMED` | The logistics lever |\n| `SAT_LAB_COVER` | `OFF` / `ON` | `OFF` | Does Saturday OT include a lab analyst |\n| `SEQ_RULE` | `CAMPAIGN_FIRST` / `DUE_DATE_FIRST` / `CAMPAIGN_WITH_MERIDIAN_OVERRIDE` | `CAMPAIGN_FIRST` | Your current policy is default |\n| `EOW_CHARGE` | `ON` / `OFF` | `ON` | End-of-week dirty-line charge; OFF lets the model cheat |\n\n## A.1 Colour sets\n\n```\nFAMILY  = { WHITE, TINT, SPECIALTY }\nDEPTH   = { NA, LIGHT, DARK }\nACCOUNT = { MERIDIAN, OTHER }\nLINE    = { L1, L2, L3 }\n\nSKU     = { skuId, family, depth, meridianQual, l3Qual }\nORDER   = { oid, account, sku, qty, bookTime, releaseTime, promiseTime,\n            wholeWeek, line, nBatches }\nBATCH   = { oid, idx, of, units, sku, account, promiseTime, testFlag, startedAt }\nSETUP   = { line, sku, family, depth }\nTECH, ANALYST = unit tokens\n```\n\n## A.2 Places\n\n**Order level:** `P_Book` → `P_Allocated` → `P_Releasable` → `P_OrderDone` → `P_Shipped` (all ∞).\n\n**Per line L ∈ {L1,L2,L3}:**\n\n| Place | Cap |\n|---|---|\n| `P_MixQueue_L` | ∞ |\n| `P_Mixing_L` | 1 |\n| `P_Tank_MixMill_L` | TANKCAP |\n| `P_Milling_L` | 1 |\n| `P_Tank_MillFill_L` | **L1 = 1** (your backup), L2/L3 = 2 |\n| `P_Tinting_L` | 1 |\n| `P_Tank_TintFill_L` | TANKCAP |\n| `P_Filling_L` | 1 |\n| `P_SetupState_L` | 1 (what the line is dressed for) |\n| `P_LineIdleClean_L` | 1 iff all stages empty |\n| `P_LineUp_L` | 1 iff not broken down |\n| `P_ShiftOpen_L` | 1 iff shift manned |\n| `P_COinProgress_L` | 1 during whole-line changeover |\n\n**Shared:** `P_CrewPool` (2 TECH), `P_CrewShift` (1 — its *absence* is the 2 a.m. black hole), `P_QAHold` (∞), `P_LabAnalysts` (2), `P_LabShift` (1 — its absence is the Friday-evening trap), `P_Testing` (2), `P_QAReleased` (∞), `P_JumpBudget` (0.6 tokens/wk).\n\n## A.3 Transitions\n\n### Arrival and release\n\n| Transition | Trigger | Effect |\n|---|---|---|\n| `T_BookLands` | Sun 23:00 weekly | ~40 ORDERs → `P_Book` |\n| `T_Allocate` | Mon 07:00 | Sets `line` (guards below), `nBatches = ceil(qty/VESSEL(line))` → `P_Allocated` |\n| `T_ERPRelease` | at `releaseTime` | → `P_Releasable`. **This transition is what creates your idle-vs-washdown dilemma.** Under `STANDING_MERIDIAN`, Meridian releases at allocation instead |\n| `T_Explode` | line queue accepts | Emits `nBatches` BATCH tokens; sets `testFlag` |\n\n**Hard allocation guards:**\n```\naccount = MERIDIAN      ⇒ line = L2        (audit qualification)\nfamily  = SPECIALTY     ⇒ line = L1        (L2 not piped for clears)\nline    = L3            ⇒ sku.l3Qual       (validated-SKU list)\n```\n\n### Production (per line, per batch)\n\nPaired `T_Start_<stage>_L` / `T_End_<stage>_L`. Start requires: batch available (per `SEQ_RULE`), stage free, `P_SetupState_L` matches SKU, `P_ShiftOpen_L`, `P_LineUp_L`, no `P_COinProgress_L`.\n`T_EndMill_L` **blocks if `P_Tank_MillFill_L` is full** — this reproduces Line 1's mill backup.\n\n**Rates (units/hour):**\n\n| Stage | WHITE | TINT | SPECIALTY |\n|---|---|---|---|\n| Mix (all) | 3600 | 3600 | 3600 |\n| Mill (all) | 2900 | 1450 | 480 (L1) |\n| Tint/letdown | 12000 | 1450 | 2400 |\n| **Fill L1** | **700** | 700 | 650 |\n| **Fill L2** | **950** | 800 | n/a |\n| **Fill L3** | **900** | 800 | n/a |\n\nThis reproduces: whites fill-bound, L2 ~35% faster than L1 on whites, **L1 ≈ L2 on tints** (the thing you noticed and couldn't explain), specialty mill-bound.\n\n**Vessels (units/batch):** L1 = 1,100 · L2 = 1,650 · L3 = 1,350 *(the one you said not to quote)*.\n\n**Fill disruption — fat right tail, thin left:**\n```\nNoise      ~ LogNormal(median 1.00, σ 0.06)\nJamAdder   = 0 w.p. .90 ; U(0.33, 0.50) h w.p. .10     (filler jam)\nStallAdder = 0 w.p. .95 ; U(0.25, 1.00) h w.p. .05     (packaging/labels)\n```\nJams and stalls kept separate — the warehouse restock may be the cheaper fix.\n\n### Changeover\n\n`T_Changeover_L` fires when the next selected batch's SKU ≠ `P_SetupState_L`.\n\n- **WHOLE_LINE** (≥2 h washdowns): requires `P_LineIdleClean_L` (line fully drained) + 2 TECH + `P_CrewShift`.\n- **CASCADE** (<1 h rinses): four sub-transitions `T_CO_{Mix,Mill,Tint,Fill}_L`, each needing only its own stage empty and 1–2 TECH per `CREW_MODE`; the new order follows the cleaning down the line.\n\n**Matrix (hours):**\n\n| From → To | SHEET | GUT |\n|---|---|---|\n| WHITE → WHITE same SKU | 0.25 | 0.25 |\n| WHITE → WHITE diff SKU | 0.42 | 0.42 |\n| WHITE → TINT | 0.75 | 0.75 |\n| TINT → TINT (light→light, dark→dark) | 0.58 | 0.58 |\n| TINT → TINT **dark→light** | 0.58 | **1.25** |\n| **TINT → WHITE** | **3.00** | **3.50** (3.75 after dark) |\n| any ↔ SPECIALTY | 2.00 | 2.00 |\n| L1 multiplier, changeovers ≥2 h | 1.00 | **1.15** |\n\n**The punitive mechanism:** because changeover needs `P_CrewShift`, a line that misses the crew window waits for the crew's **next shift start**, not for the crew to free up. Your Scenario-A Line 1 loses the whole overnight, not two hours. This emerges from the net structure — no special rule.\n\n### QA\n\n| Transition | Requires | Duration |\n|---|---|---|\n| `T_Sample` | batch in `P_QAHold`, ANALYST, `P_LabShift` | WHITE 3.5 h / TINT 4.0 / SPECIALTY 5.0, LogNormal σ 0.25 |\n| `T_Release` | test done | instant |\n| `T_Jump` | Meridian-critical + jump token | Front of queue, **non-preemptive**; `P(refuse) = min(0.8, 0.15 × jumps_this_month)` |\n\n**Sampling:** first batch always, every 3rd thereafter, **last batch always** — this is what makes an order hostage to its last batch.\n\n### Ship, score, break\n\n`T_OrderComplete` (all batches released) → `T_Ship` (at truck departure) → `T_ScoreOrder`.\n`T_EndOfWeekCharge` fires Fri 22:00, charging each line for the changeover Monday's first job would need.\n\n| Breakdown | Rate | Duration |\n|---|---|---|\n| Major outage (mill-motor class), removes `P_LineUp_L` | 0.038/line-week | LogNormal median 48 h, P90 120 h |\n| Bad filler jam, blocks `P_Filling_L` | 0.5/line-week | LogNormal median 3 h, P90 6 h |\n\nRepair progresses only during manned hours.\n\n## A.4 Calendars\n\n| Gate | Pattern |\n|---|---|\n| `P_ShiftOpen_L1/L2` | Mon–Fri 06:00–22:00 (handover mid-batch allowed) |\n| `P_ShiftOpen_L3` | Mon–Fri 06:00–14:00 |\n| `P_CrewShift` | Mon–Fri 07:00–15:30; extends 05:00–19:00 if changeover pre-arranged ≥8 h ahead |\n| `P_LabShift` | Mon–Fri 07:00–17:00 |\n| Saturday OT | Adds L1 or L2 Sat 06:00–18:00; requires trigger by Wed 17:00; **adds no lab, no crew** unless `SAT_LAB_COVER = ON` |\n| Trucks | Depart 06:00, Mon–Fri |\n\n## A.5 Policy layer (every rule swappable)\n\n**1 — Crew contention.** Key: `(Meridian-enabling DESC, earliest promise-at-risk ASC)`. **Non-preemptive.** Loser waits for crew *and* shift.\n\n**2 — Batch sequencing (`SEQ_RULE`).** `CAMPAIGN_FIRST` (yours): group by family; within campaign, earliest promise; break campaign only if a due date would actually be missed. Alternatives: pure due-date; campaign with Meridian override.\n\n**3 — Idle vs washdown** *(your headline decision, implemented literally from Q10)*:\n```\nIF (wash_away + wash_back) touches ANY Meridian ship window\n   THEN idle                                       (* the cliff *)\nELSE IF gap_hours ≥ (wash_away + gap_job_runtime + wash_back)\n   THEN take the gap job\nELSE idle\n```\n\n**4 — Lab queue.** FIFO, except jump tokens. Displaced work waits, and near week's end may hit the Friday trap — that is the true cost of a jump.\n\n**5 — Saturday ask.** Wed 17:00: if a Meridian order's projected completion misses its window by ≥1 shift, request OT on L1/L2. Non-Meridian shortfalls trigger nothing (your Coastal case).\n\n## A.6 Scoring — unit is one line-hour\n\n```\nChangeover      = 1.0 × changeover_hours\nIdle            = 0                        (invisible on paper; bites only via the clock)\n\nMeridian late   = 200 (step, on missing the truck) + 1.0 × hours_late\nOther late      = 0                     h ≤ 4\n                = 0.5 × (h − 4)         4 < h ≤ 24\n                = 10 + 4.0 × (h − 24)   h > 24\nWhole-week req. = ×2 on the above\n\nEnd-of-week     = expected changeover hours from each line's Friday state\n                  into Monday's likely first job\n```\n\n**Board metric reported separately:** binary on-time % vs promise date — so you can tell your boss what the board will say.\n\n*Calibration against your own bets:* Meridian 6 h late = 206 ≫ 4 changeover-hours → you idle. Coastal 6 h late = 1.0 < 4 → you take the tint job. Coastal 48 h late = 106 ≫ 4 → you don't. Cliff and slope, reproduced.\n\n## A.7 Experiments → your three questions\n\n| Question | Run |\n|---|---|\n| *\"Line 1's mill motor takes four days — what slips?\"* | Inject 96 h `P_LineUp_L1` outage at various points; compare re-allocation policies. **Watch specialty: it has nowhere to go** (guard: specialty ⇒ L1), so it appears as a hard block, not a delay |\n| *\"Idle an hour or wash down?\"* | Sweep Conflict-3 rule × `RELEASE_POLICY`. **Run `STANDING_MERIDIAN` first** — hypothesis is that most of these dilemmas are manufactured by release timing, not by your scheduling |\n| *\"Where are my changeover hours going?\"* | Changeover-hours ledger by line × transition × cause; then `SEQ_RULE` sweep; cross with `TIME_BASIS` — if your gut padding changes no decision, don't bother timing changeovers |\n| *(bonus)* | `SAT_LAB_COVER` OFF vs ON — tests whether this year's Saturdays bought you anything given a shut Monday-ward lab |\n\n**Validation when data lands:** replay 26 weeks; target (a) ~75% utilisation, (b) **30–40 changeover-hours/month** — your ops director's number, the best anchor you gave me — (c) board on-time % matching history. Low changeover-hours ⇒ `CO_GRANULARITY` or sequencing is wrong.\n\n---\n\n# B. ASSUMPTION LEDGER\n\nMine, not yours. **Bold = load-bearing.**\n\n**Scoring**\n1. Lateness in hours vs promise date (board is binary but can't express your cliff/slope). *Check: ERP promise vs ship dates.*\n2. **Meridian = 200-hour step at \"misses the truck\", +1.0/h after. I defined the window as truck departure 06:00, not end-of-promise-day.** *Check: one sentence from you — several tight cases flip.*\n3. Non-Meridian: free <4 h, 0.5/h to 24 h, 4.0/h beyond. Invented shape from your Coastal answer. *Sensitivity-test the kink.*\n4. Whole-week multiplier ×2. Pure invention.\n5. Idle costs zero (your Q8). Makes arrival/due-date realism load-bearing.\n6. Changeover = pure lost line time, no wage/solvent. *Check with finance what the 40-hours line item contains.*\n7. **The 200:4 ratio was reverse-engineered from your two bets, not elicited.** *Check by putting three more of your own bets to it.*\n\n**Structure**\n8. Four stages, identical topology on all three lines (you walked me through L2 only).\n9. **Tank caps: L1 mill→fill = 1 batch, others = 2.** *Check: nameplate ÷ batch size.*\n10. Vessels 1,100 / 1,650 / 1,350 — **L3 is the one you said not to quote.** *Check: 30 seconds at the vessel.*\n11. 14 SKUs as 4 white / 8 tint / 2 specialty, tint depths assigned arbitrarily. *Check: SKU master — also tells me which tints are dark.*\n12. L3's two unqualified tint SKUs — your count, my choice of which. *Check: quality's validation list.*\n13. **Specialty on L1 only. I never asked whether L3 can run specialty — if it can, the mill-motor answer changes materially.**\n14. Meridian ⇒ L2 is absolute, no emergency override. *Check: has it ever been broken?*\n\n**Durations**\n15. **Stage rates reconstructed from your estimates. The pattern is yours; the numbers are mine.** *Check: the sheet's units/hour per product per line — direct calibration, you already have it.*\n16. Mix time identical across families/lines. Never asked; probably wrong for specialty.\n17. **The jam/stall split is entirely my decomposition** (you described both, never separated them); stall frequency invented. *Check: whether CMMS distinguishes faults from material starvation — it probably doesn't.*\n18. QA 3.5/4.0/5.0 h by family, σ 0.25 — only \"about four hours for whites\" is yours. *Check: lab lead, 5 min.*\n19. Sampling = first, every 3rd, **always last** (my inference from \"held up by its last batch\").\n20. SHEET matrix = your recollection of a spreadsheet neither of us has opened. *Check: open it.*\n21. GUT layer quantified by me from your instincts. *Check: time six changeovers — but run `TIME_BASIS` both ways first; if nothing changes, don't bother.*\n22. **`CO_GRANULARITY` unresolved — you were going to watch a rinse. This materially changes the split-across-lines answer.**\n23. **`CREW_MODE` unresolved — you'd half-noticed the techs working opposite ends. If rinses split, crew contention drops significantly.**\n\n**Policies**\n24. Crew key = Meridian-enabling, then earliest at risk; non-preemptive. *Check: has an in-progress changeover ever been abandoned?*\n25. **A line missing the crew window waits for next shift start. Most punitive mechanism in the model — it turns a 2 h changeover into a lost overnight.**\n26. **Crew flex needs ≥8 h notice — invented. Directly governs whether an evening washdown happens or waits for morning, i.e. the core of your headline decision.** *Check: ask the techs.*\n27. Jump budget 0.6/wk with rising refusal — 2–3/month is yours, the refusal curve is invented to reproduce the one time you backed off.\n28. **Saturday OT adds line hours only, no lab, no crew. The assumption I most expect to be wrong in a useful direction.** *Check: the ops director question.*\n29. **End-of-week charge is my accounting construct** for behaviour you described. *Check: compare Friday's finishing family to Monday's first job over recent weeks.* Without it the model cheats by leaving every line filthy on Friday.\n\n**Boundary conditions**\n30. **40 orders arrive Sunday 23:00 in one batch; nothing arrives mid-week.** Never asked. If urgent mid-week orders exist, that's a major missing disturbance.\n31. Order sizes: Meridian median 7,000 units, others 2,500 — derived from your one-third-of-volume figure. *Check: ERP directly.*\n32. **Promise dates 4–9 days after book date, uniform — pure invention, and the single most load-bearing unknown.** Because idle is only penalised via due-date pressure, too much padding makes the model idle happily and tell you nothing. *Check: ERP book-date vs promise-date.*\n33. **ERP release lag 24 h ± 12 h before promise, same for all accounts — invented, and it's the mechanism that creates your headline dilemma.** *Check: the release-timestamp field you added to the ask.*\n34. **Breakdown rates entirely invented**, anchored only to \"the motor took four days once\" and \"a bad one every couple of weeks.\" *Check: the CMMS export — this is what it's for.*\n35. Repairs progress only in manned hours. Never asked; could be wrong for a contracted rebuild.\n36. Starts Monday 06:00, all lines empty, clean, dressed for white. *Use a one-week warm-up before scoring regardless.*\n37. No materials constraint (you only watch for red flags). *Check: if red flags stop runs more than quarterly, this needs modelling.*\n\n---\n\n# C. WHAT THE MODEL LEAVES OUT\n\n**Gaps from stopping early — real, not simplifications:**\n\n1. **Batch contiguity / order splitting.** The model assumes an order's batches run **contiguously** on a line. It can compare \"whole order on L1\" vs \"split across L1 and L2\" and will correctly charge the extra changeover on both — but it can't represent interleaving. **If interleaving is possible in reality, the model overstates the cost of splitting, which is exactly your run-size question.** *Fix this first — it's one sentence from you.*\n\n2. **The unwritten rules.** Never covered. Expect the model to propose schedules that make you say \"we'd never do that.\" **Treat each of those as a finding, not a bug** — that's an unwritten rule surfacing.\n\n3. **All historical data.** Neither export arrived. Every arrival, promise date, release lag and breakdown figure is invented (30–34). **Don't make decisions on the model until at least the order book is loaded** — assumption 32 can make it tell you a comfortable lie.\n\n**Deliberate exclusions:**\n\n4. **Materials/supply chain** — you don't schedule around them; modelling them adds noise you can't act on.\n5. **Individual operators, skills, absence** — except where you named them as constraints (crew, lab, L3's qualified operator). Modelling the labour pool would double the size to answer a question you didn't ask.\n6. **Quality failures and rework** — you never mentioned a batch *failing* QA, only waiting for it. If they do fail, that's a missing feedback loop and a significant one.\n7. **Warehouse and truck capacity** — trucks are a fixed daily departure. The one place logistics bites, the release gate, *is* modelled, because it's your headline lever.\n8. **Commercial's promise-date behaviour** — exogenous. \"Should commercial pad more or less\" is a different model with this one inside it.\n9. **Dollars** — everything is in line-hours, because nobody could give a dollar figure and a fake conversion adds only false precision. One line converts it if finance produces a rate.\n\n---\n\n**Three things before your first real run:**\n\n1. **Load the ERP order book** — kills assumptions 31–33, the ones that can make the model lie comfortably.\n2. **Answer batch contiguity in one sentence** — unblocks the run-size question.\n3. **Run `RELEASE_POLICY = STANDING_MERIDIAN` against the default** — tests whether your headline dilemma is manufactured upstream of you. It's the cheapest finding available and needs no data at all.\n\nSend the exports and the flagged answers whenever you have them and I'll revise. Good luck with it."
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/v0-prompt.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/v0-prompt.md
new file mode 100644
index 00000000000..b0918047e0f
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/baseline/v0-prompt.md
@@ -0,0 +1,80 @@
+# v0 elicitation prompt (condition 2 system prompt)
+
+The seven-category elicitation surface turned into guidance — the degenerate plugin: the
+smallest possible pack content, with no machinery behind it. Encodes the surface itself,
+objectives-first ordering, a probe catalog, quantile elicitation, and an explicit assumption
+ledger (per the FE-1361 design comment and the grilling-inputs note).
+
+---
+
+You are an expert process-model elicitor. Your job is to interview a domain expert about an
+operational system and then produce a simulatable process model. The expert knows their
+operation deeply but is not a modeller; most of what the model needs is in their head, some of
+it in forms they have never had to articulate.
+
+## The elicitation surface
+
+A process model's description decomposes into seven categories. Your interview is complete
+only when each has been either filled to the depth the objectives demand or explicitly
+established as not applicable:
+
+1. **Objectives & the questions the model must answer.** What decisions will this model
+   inform? What questions should it answer? What does "better" mean, numerically if possible —
+   including penalty weights and trade-off rates (lateness vs. cost vs. throughput). These are
+   almost never written down; expect to co-construct them. Everything else is elicited
+   _relative to this category_, so open with it.
+2. **Structure.** The stages, queues, buffers, resources, and routing of the operation. Most
+   operations are built from recurring motifs — sequential stages with buffers between them,
+   shared resources serialising contenders, setup/changeover states, hold/inspection points,
+   arrival and departure boundaries. Use the motifs as a checklist for what to ask about, not
+   as a template to force the answers into.
+3. **The domain taxonomy (types).** The kinds of things flowing through and operated on:
+   product families, order attributes, resource classes, state that rides along with each
+   entity (age, quality, setup state). Ask what distinctions matter — two items are "the same"
+   only if the process treats them the same everywhere.
+4. **Rates, durations & distributions.** How long things take and how often things happen —
+   per stage _and per type_ where it varies (ask explicitly whether it varies by type; the
+   answer is load-bearing). Elicit uncertainty by quantiles: "typical?", "one time in ten,
+   worse than?", "one time in ten, better than?" — never ask for minimum/most-likely/maximum,
+   which yields overconfident triangles.
+5. **Policies at conflict points.** Wherever two things can want the same resource or slot at
+   once, somebody or something decides who wins. Find every such point and ask who decides, by
+   what rule, and what overrides it. These rules are largely tacit — probe with concrete
+   scenarios ("two lines need the crew at the same moment — what actually happens?").
+6. **Constraints — including unwritten ones.** Capacity limits, qualifications,
+   compatibilities, regulatory and quality rules. Then ask separately for the unwritten ones:
+   "what would a new scheduler get wrong in week one?", "what do you always/never do that's on
+   no document?", "which rules exist because of something that went wrong once?".
+7. **Boundary conditions.** What the system starts with and what arrives: initial state,
+   arrival patterns of demand/work, external inputs and their reliability.
+
+## How to interview
+
+- **Objectives first.** Establish category 1 before anything else; then let it prioritise the
+  rest. Depth is objective-relative: a fact earns probing when an objective needs it.
+- **Slice, then sweep.** First walk one concrete case end to end ("walk me through one order,
+  from arriving to shipping") to expose the structure; then sweep each category systematically
+  across everything the slice revealed.
+- **Probe; don't settle for the first answer.** Follow up on vague terms and quantifiers
+  ("usually", "roughly", "mostly fine") — each hides either a distribution or an exception.
+  Ask for last-time-it-happened stories rather than generalisations. Check consistency: when
+  two answers tension against each other, say so and ask.
+- **Ask for absences explicitly.** "Is there anything that never happens?" and "what am I not
+  asking about?" (clearinghouse) near the end of each topic.
+- **Batch breadth, sequence depth.** You may group 2–4 related survey questions in one turn,
+  but probe one thread at a time when digging.
+- **Keep an assumption ledger.** Any value or rule you supply that the expert did not state —
+  defaults, simplifications, made-up numbers — goes in an explicit numbered list, each entry
+  marked with why it was assumed and how to check it. Never let an assumption pass silently
+  into the model.
+- **End properly.** Before producing the model: summarise what you have per category, state
+  what is missing or assumed, and give the expert one chance to correct you. Do not end the
+  interview merely because the expert seems busy; if pressed for time, say what is still
+  missing and let them choose. Do not keep interviewing once the categories are covered to the
+  depth the objectives need.
+
+## The deliverable
+
+When the interview is complete, produce: (a) the model, in the most faithful representation
+the target tooling allows, with every element named in the expert's own vocabulary; (b) the
+assumption ledger; (c) a short account of what the model deliberately leaves out and why.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/capture-store-plain.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/capture-store-plain.md
new file mode 100644
index 00000000000..b8528fde9eb
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/capture-store-plain.md
@@ -0,0 +1,203 @@
+# The capture store, in plain terms
+
+A plain-prose rendering of what the top of the stack establishes: the capture store
+(FE-1390, `packages/core/src/capture-store.ts` + `packages/binding-flue/src/local-capture-store.ts`)
+and the ask/reply machinery it will eventually serve (FE-1389, where the two touch). Rendered
+from the code first, with the kernel spec (§5, §9.6, §14.1) and CONTEXT.md as the claimed
+semantics the code is read against. The strain report at the end is the review yield: every
+place the source resisted plain rendering.
+
+## What the store is
+
+The capture store is the durable truth of a target-document. It holds three families of
+records: captures, issues, and events. A capture is a capture envelope: harness-minted id,
+evidence or a declared basis, epistemic status, confidence, exactly one value or absence
+state, an optional alternatives group, an optional single `supersedes` link, and a
+content-derived dedup key. An issue is stored backpressure: a type (one of seven), a producer
+(harness, or plugin with a namespace), and references to existing captures. An event is one of
+three things: a resolution record, a retraction, or an issue-closed marker.
+
+No record carries a status field. Nothing in the store says "this capture is superseded" or
+"this issue is closed". Those are read-time answers, computed from the records.
+
+## What a write is
+
+A write is a command. There are five: apply a sweep of capture proposals, open an issue, close
+an issue, resolve a conflict, retract a capture. The command logic is one pure function: it
+takes a snapshot and a command, and returns either a new snapshot plus a result value, or a
+refusal. It never returns both. A refused command changes nothing.
+
+A sweep applies whole or refuses whole. If one proposal in the batch is invalid, the entire
+sweep is refused and no capture is added. Valid proposals that duplicate existing content are
+skipped, not refused: the store computes a dedup key from evidence and content — epistemic
+status is deliberately excluded — and a retried proposal with the same key adds nothing.
+Changing your epistemic reading of the same evidence therefore requires explicit supersession;
+it can never happen as a silent update.
+
+A proposal that supersedes another capture must name a capture that exists, is currently
+active, and is not already superseded by an earlier proposal in the same batch. New captures
+get fresh harness-minted ids. The sweep result also reports advisories — pairs of active
+captures that look possibly equivalent (same evidence, or near-identical text payloads).
+Advisories are returned to the caller and never stored.
+
+Every command appends. No command edits a record. No command deletes a record. Corrections
+are new records: a superseding capture, a resolution record, a retraction event.
+
+## What the store refuses, and why
+
+The refusal surface is the store's contract. In plain terms:
+
+- **A capture without provenance.** User-grounded captures (`explicit`, `inferred`,
+  `tentative`) need at least one evidence span: a non-empty quoted excerpt plus a pointer
+  (session id, entry range, range must not end before it starts). `defaulted` captures must
+  cite a declared default. `external-lookup` captures must cite a documented transformation.
+  There is no fourth shape.
+- **A capture with both a value and an absence state, or neither.** Exactly one. Absence is a
+  first-class value with six named states; it never collapses to null.
+- **A value that cannot survive JSON.** Non-finite numbers, class instances, functions — refused.
+- **Superseding a non-head.** If the target is already superseded or retracted, the refusal
+  names the current active heads so the caller can re-aim.
+- **Closing a conflicting issue with a plain close.** A `conflicting` issue closes only through
+  a resolution record. The resolution must cite the true user's utterance, must name a winner
+  and at least one loser, and must account for exactly the captures the conflict references —
+  no more, no fewer, no duplicates, all of them still active.
+- **Retracting anything but an active capture.** Retraction is an event that cites the true
+  user and names no successor.
+- **An issue referencing nothing, or referencing unknown captures.**
+
+The persisted file gets its own guard: on every read, the whole snapshot is re-parsed and
+cross-checked. Duplicate ids, stale dedup keys, supersession cycles, forking supersession
+histories (two successors for one capture), events citing non-user evidence, resolutions that
+do not account for their conflict, issue-closed events on conflicts — all of these make the
+read throw rather than return a corrupted truth.
+
+## What derives at read time
+
+Three questions are answered by computation, never by stored flags:
+
+- **Capture status.** Retracted if a retraction event names it. Otherwise superseded if a
+  capture supersedes it or a resolution names it as a loser. Otherwise active.
+- **Issue status.** Closed if a resolution or issue-closed event names it. Otherwise open.
+- **Current heads.** Following supersession links and resolution outcomes forward from any
+  capture to the captures that currently speak for it.
+
+## What the binding owns
+
+The core module owns the rules; the Flue binding owns the disk. `LocalCaptureStore` keeps the
+snapshot as one JSON file. Reads parse and validate the whole file; a missing file is an empty
+store. Writes go to a temporary file first and are renamed into place, so a crash mid-write
+leaves the old file intact, never a half-written one. Commands against the same path are
+queued in process order; each command reads the current file, applies, and writes before the
+next begins. A refused command writes nothing.
+
+## What the ask machinery adds (FE-1389)
+
+The walking skeleton beneath this branch proves the conversation side: each `ask` suspends the
+turn on a durable pending affordance (held in per-session state), and the next user dispatch is
+mechanically bound as the reply — the harness appends a signal entry naming the affordance, so
+the binding is a recorded fact, not a model inference. The store is built to receive this:
+evidence spans may anchor on `user-affordance-payload` entries, which is exactly what these
+affordance replies are. That is where the two branches touch — and today it is only a
+type-level touch (see strain report, item 3).
+
+## What the tests prove
+
+The core suite pins six of the spec's ten harness invariants by name: retries deduplicate by
+content not epistemic status (5); one invalid proposal refuses the whole sweep (7); all six
+absence states survive storage (9); explicit/inferred/defaulted stay distinct (10); supersession
+keeps history and status derives (4); conflicts close only through user-cited resolution (2).
+It also pins: resolutions account for every conflicted capture; persisted tampering (stale
+dedup keys, forking supersession, silent conflict-close) is refused at parse; retraction is a
+user-cited event with no successor; equivalence advisories surface and are not stored. The
+binding suite pins: round-trip persistence with no stored statuses, serialized concurrent
+writes, and that a refused sweep never persists partially.
+
+## What is NOT guaranteed
+
+This section is load-bearing. The store guarantees nothing beyond the boundary of its snapshot.
+
+1. **A conflict can be born unclosable.** The store accepts a `conflicting` issue with one
+   reference, but every legal resolution needs a winner and at least one loser drawn exactly
+   from the references — so a one-reference conflict can never be resolved and never plainly
+   closed. Separately, nothing stops supersession or retraction of a capture an open conflict
+   references; once one referenced capture is no longer active, the resolution's all-active
+   requirement can never again be met. Both paths end in an issue that is permanently open.
+2. **Evidence pointers are unverified and unbacked.** The store never sees session entries. It
+   cannot check that an excerpt appears in the pointed-at range, and there is no session-log
+   archive — the spec's "every entry a capture points to must be retrievable forever" (§9.6)
+   has no implementation. A pointer is a promise the store cannot keep or check.
+3. **Provenance labels are trusted, not verified.** "Anchors only on true user entries" is
+   enforced against a `source` field the caller supplies. The store refuses a span _labeled_
+   non-user; it cannot detect a mislabeled one.
+4. **Append-only holds at the command surface, not the storage surface.** No command removes a
+   record, but the binding rewrites the whole file on every write. The parse guard catches
+   inconsistent tampering; a hand-edit that deletes records and stays self-consistent reads
+   back as truth.
+5. **Serialization is per-process.** Two processes writing one file are not serialized; the
+   tmp-and-rename write prevents torn files but not lost updates.
+6. **No caller exists.** Nothing in the running system produces captures. Settlement and sweep
+   are not built; the dev app's walking skeleton never touches the store. Every guarantee above
+   is currently exercised only by tests.
+7. **Confidence is any non-empty string.** The spec says "qualitative, never a
+   scalar-for-everything"; the code enforces only non-emptiness.
+8. **Payloads are opaque.** The store validates the envelope only. Plugin payload validation
+   (the spec's second validation stratum) does not exist here, and `alternativeGroup` is an
+   uninterpreted label with no enforced semantics.
+
+## Strain report
+
+Ranked by consequence. Each item is a place the source resisted plain rendering.
+
+1. **The unclosable conflict (two independent paths).** The sentence "a conflict closes only
+   through a user-cited resolution" renders cleanly; the sentence "every conflict can be
+   closed" cannot be written at all. A one-reference conflict is command-reachable and
+   permanently unresolvable, and superseding a conflict-referenced capture strands the conflict
+   forever. The refactor queue's commits 7 and 8 target exactly these; the rendering
+   independently confirms both from the code.
+2. **"Append-only and transactional" — the title over-promises relative to the storage layer.**
+   Rendering forced the split into "no command removes a record" (true) and "records cannot be
+   removed" (false at the file level). Likewise "transactional" had to become "atomic within
+   one process": the write queue is a module-level map keyed by path, invisible across
+   processes. The honest rendering needed a whole "not guaranteed" section that the one-line
+   commit message does not hint at.
+3. **The bridge with no middle span.** The directive asked for "the semantics FE-1389 adds
+   where they touch the store"; rendering found the touch is one string literal —
+   `'user-affordance-payload'` as a legal span source. No settlement, no sweep caller, no wiring.
+   Stating what the top branches establish _together_ required writing "they do not yet
+   connect," which no document had said.
+4. **Provenance verification is structural, not evidential.** The spec's provenance language
+   ("cite the true user's utterance") reads as a fact check; the code implements a shape check
+   on self-declared labels. Penciled item 7's deterministic tier (excerpt verbatim in the
+   pointed-at range) is unimplementable from inside this module — the store has no access to
+   entries. The check belongs at sweep application (harness-resolved anchoring, §8.2), which
+   does not exist yet; until then the store carries tier-1-looking fields with no tier-1 check
+   behind them.
+5. **Three rule surfaces, one contract, no equivalence proof.** Proposal validation, snapshot
+   parsing, and derived-status logic each restate overlapping rules in separate code. Rendering
+   "what the store refuses" required merging three lists and trusting they agree; the refactor
+   queue's shared-invariant commits (1, 5, 6, 9) target exactly this duplication.
+6. **Epistemic status is capture-scoped — FE-1405's arity question has a type-system answer.**
+   One capture carries exactly one epistemic status and one confidence for its whole payload.
+   A capture whose fields deserve different statuses cannot exist; the granularity rule
+   (one assertion per capture) is what makes that livable, but nothing enforces granularity —
+   a caller can store an arbitrarily large payload under one status. The IR's loss-report
+   arity problem and the envelope's status arity are the same question at two layers.
+7. **"Sweep" names two different things.** In the spec, a sweep is a pass over settled
+   conversation that _produces_ captures; in this module, `apply-sweep` is the transaction that
+   _stores_ proposals someone else produced. The rendering had to say "a sweep of capture
+   proposals" to stay honest. The naming will mislead the first reader who arrives from the
+   spec.
+8. **Session-log archive: scope claimed, scope absent.** Spec §9.6 puts the archive inside the
+   storage port's scope ("the port's scope is the capture store plus the session-log archive").
+   The implemented port is captures/issues/events only. The rendering could not call this store
+   "the storage port" without the qualifier; it is the storage port's first half.
+
+> **Reflection:** The store is the stack's first genuine piece of layer-3 machinery, and its
+> teeth are real — the refusal surface and the parse-on-read guard are exactly the "enforcement
+> requires state outside the conversation" argument made concrete. But every high-consequence
+> strain item has the same shape: the guarantee weakens wherever it depends on a fact outside
+> the snapshot — session entries it cannot see, processes it cannot see, callers that do not
+> exist, labels it must take on faith. The boundary of the snapshot is the boundary of the
+> guarantee. That suggests the FE-1405/plugin-spec work should treat "what does the store need
+> to _see_ to enforce this?" as the first question for every proposed invariant, before "what
+> shape should the field have?"
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design-plain.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design-plain.md
new file mode 100644
index 00000000000..270d5132485
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design-plain.md
@@ -0,0 +1,72 @@
+# The intermediate representation, in plain language
+
+> This is a plain-prose rendering of [`ir-design.md`](./ir-design.md), written for review reading. It makes the same content commitments as the original, which remains the authoritative document. The rendering pass doubled as a review instrument: seven places where the source resisted plain rendering are recorded as findings on FE-1401 (third accrual), the load-bearing one being the loss report's unresolved unit of loss (capture vs. capture-facet).
+
+This design was resolved on 13 August 2026 and ratified on worked examples by FE-1397. It has two layers. Layer A defines what an intermediate representation (IR) is for any plugin. Layer B is the concrete design for the CPS plugin — the design the September demo will run on. The design draws on the kernel spec, the Petrinaut survey's format facts, Dora's PRO-98 ontology, the open-questions document, and the FE-1363 use-case resolution.
+
+## Layer A — what the IR is
+
+The intermediate representation of a target-document is the set of active captures, read through the plugin's declared payload type system. There is no second store. Every consolidated view — an entity graph, a net, a completion table — is computed at read time as a projection over the active captures. The rendered artifact is itself one projection of the IR; it is never the IR.
+
+The harness's half of a capture is already fixed by the kernel spec: an envelope holding the capture's id, its evidence spans, its epistemic status, its confidence, a value or an explicit absence, any alternatives, and supersession links. The payload inside that envelope is opaque to the harness. Defining a plugin's IR therefore means defining its payload type system, and nothing more.
+
+Every plugin's payload type system must satisfy five properties.
+
+First, it declares a closed, named catalog of assertion kinds, as namespaced concept declarations. The assurance plugin declares its `Statement` kinds, Gherkin its scenario and rule records, and CPS the ten-kind catalog in Layer B below.
+
+Second, each payload holds one assertion, at the resolution the evidence states it. In the primary case the evidence is the user's utterance, so the payload holds what the user said at the resolution they said it. When a capture is defaulted or comes from an external lookup, the declared default or the documented transformation sets the resolution instead. One utterance may yield several captures, because granularity is per assertion, never per utterance. A user who happens to speak in artifact-shaped units does not violate the property; that is coincidence. Factoring assertions into artifact-shaped elements is the projection function's job, so the interviewer never does the artifact's modelling work in the middle of a conversation.
+
+Third, the IR is independent of its projections. Kinds are defined in the domain's own vocabulary, and the IR may legitimately hold kinds that no current projection consumes; the typed loss report is what keeps that honest. The loss-report clause is the part that can be enforced. The vocabulary clause bites in proportion to the distance between the domain and the target format, and where the target format is the domain — as with Gherkin — it degenerates gracefully rather than failing.
+
+Fourth, relations between captures are payload data, never envelope structure. A plugin that needs structure declares its own reference or edge vocabulary, as the assurance plugin does with its four edge kinds and CPS does with symbolic name references.
+
+Fifth, domain labels and rollups are derived at read time by the projection function. They are never stored.
+
+Beyond these requirements, the design grades three recommended patterns and one escape hatch, with the grades set by the FE-1397 worked-examples exercise. Plugins should use symbolic, name-based references between payloads and let `reconcile` resolve identity at read time: all four worked designs use this pattern, it matches how experts talk, and it survives supersession without leaving dangling edges, so a plugin that departs from it should say why. Plugins may declare completion-anchor kinds — a distinct purpose or objective kind where the domain has explicit purposes, or existing purpose-shaped kinds where it does not, such as Gherkin's feature narrative and rules or the assurance plugin's goal. The pattern is that completion anchors on purpose-bearing captures, not that every plugin declares a kind named objective. Process-shaped domains may add a source-regime attribute, `prescribed` or `practiced`, to every kind. There is one model, never parallel models: where prescription and practice diverge, the divergence surfaces as an ordinary typed conflicting issue. Regime composes with epistemic status rather than duplicating it, because the difference between log-observed and expert-believed practice is already the envelope's `external-lookup` versus `explicit`. Finally, non-load-bearing motif annotations — hints a projection may take but never depend on — survive only as a named escape hatch: no worked design used them, so the name is retained until a projection demonstrably needs the hint.
+
+Layer A was at first conditionally ratified. FE-1397 discharged the condition by drafting speculative payload designs across three plugin targets at different complexity levels — Gherkin (thin), CPS (thick; Layer B here), and BPMN with process mining (mid) — and reading the assurance plugin as a free fourth corroborant, then checking every property against all four. All five properties survived, with the second and third amended into the wording above. The expected pressure for plugin content to migrate into the shared layer did materialize, but as a pattern promotion — source-regime moved from Layer B up to Layer A — and not as any kind moving into the envelope. Everything here is desk-validated only. No example has yet run through a working harness, so every Layer-A claim stays provisional until the September build exercises them.
+
+## Layer B — the CPS plugin's IR
+
+Layer B is a working design, validated only against the truck-fleet reference case. The worked-examples exercise left it unchanged, except that it exported source-regime up to Layer A. The harness still gets its turn.
+
+The plugin declares ten kinds of assertion:
+
+| #   | Kind                     | Holds                                                                                                          | Projects to (Petrinaut)                                                     |
+| --- | ------------------------ | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| 1   | **entity-type**          | object types and their attributes, incl. continuous state variables (truck, component, wear level)             | colours + typed elements                                                    |
+| 2   | **boundary-condition**   | initial populations, arrival/departure rates, external inputs ("40 trucks, 3 bays", initial wear distribution) | scenario `initialState` + `scenarioParameters`                              |
+| 3   | **activity**             | steps _as the expert states them_: actors, resources, preconditions, outcomes, duration                        | factored transitions (see granularity rule)                                 |
+| 4   | **ordering/flow**        | sequencing, branching, trigger conditions                                                                      | arcs, guards, arc types (read/inhibitor)                                    |
+| 5   | **policy**               | decision rules at choice/conflict points                                                                       | guard/priority code where compilable; mostly IR-only                        |
+| 6   | **dynamics**             | continuous evolution laws (wear accumulation)                                                                  | differential equations on real-valued colour elements                       |
+| 7   | **objective**            | questions the model must answer; goals; penalty weights                                                        | metrics where expressible as scalars over simulation state; weights IR-only |
+| 8   | **constraint**           | regulatory/business rules, conservation laws                                                                   | guards partially; references IR-only                                        |
+| 9   | **data-binding**         | model variable ↔ data feed                                                                                     | nothing today (Live Mode unimplemented)                                     |
+| 10  | **validation-criterion** | how we would know the model is right                                                                           | nothing today                                                               |
+
+Kinds 1 to 6 bear on the net: they project into Petri-net structure. Kinds 7 to 10 are partly or wholly IR-only. That split is the demo's story. The net is one projection of the elicited description, and what the net cannot hold is neither lost nor hidden: it stays in the IR with its provenance, and the loss report says so. Dora's ontology corroborates the split independently — her Maps-to column places constraints, policies, and penalty weights in the intermediate representation, and routes objectives to the simulation and experiment layer, which is to say to metrics.
+
+Three things attach across kinds and are deliberately not kinds themselves. Quantities — durations, rates, probabilities, capacities — can attach to any kind; they are elicited as quantiles, never as a minimum, mode, and maximum; and the shared or tunable ones project to Petrinaut parameters. A rationale can attach to every kind, never only to objectives. And source-regime marks every capture as prescribed or practiced: the process as the manuals state it versus the process as it actually runs. There is one model, not two parallel ones. A divergence between the regimes surfaces as an ordinary typed conflicting issue, and such a divergence is elicitation gold — the rules nobody wrote down — not an error state.
+
+**The granularity rule.** Dora's claim that steps become transitions and the states between them become places survives, with a correction: it is a projection rule, not a storage rule. The IR stores activities at the granularity the expert stated them, durations included. Petrinaut has no timing field of any kind, so a timed step cannot become a single transition. The projection function therefore owns the factoring — for example into a start transition, an in-progress place, and an end transition, or into rate code. If the IR stored net-granularity elements instead, every change to the factoring would masquerade as a change to what the expert said, and the interviewer would be doing net modelling in the middle of the conversation.
+
+**Motifs.** The motif quiver — small parameterised process patterns with variant selectors — lives in the ElicitationPack as question guidance only: motifs may scaffold the interviewer's questions, but they never generate model structure. This follows the literature verdict. The September payload carries no motif vocabulary; if a projection ever demonstrably needs a motif hint, Layer A's escape hatch exists for that. Per-object-type templates appear nowhere in the design.
+
+**Completion.** The plugin commits to question-relative completion. The objective captures anchor the completion contract — the document is complete when every objective has its supporting kinds covered — over a small static floor: at least one objective, the entities, and a happy-path flow. The interview therefore opens on objectives. This operationalizes the earning test, under which the model gains stochasticity and colour only where an objective demands them, and it replaces a static ordering of categories with that purpose-driven form.
+
+### Projection to Petrinaut
+
+The projection emits all four surfaces of the Petrinaut file: the net structure (places, transitions, colours, differential equations, arcs), the scenario, the metrics, and the parameters. The scenario is mandatory, because a bare net loads with an empty marking and does nothing when simulated. The Optuna optimization file format is excluded for September: its ontology is itself still moving — Yannis is working on it, and his design is a candidate future input — so penalty weights stay IR-only and appear in the loss report.
+
+The loss report is typed and per-capture. Every active capture lands in exactly one of seven categories: mapped exactly, normalized, approximate, collapsed, omitted, defaulted, or unrepresentable. The kind catalog implies the first cut. Entity types and dynamics map exactly, with names normalized. Boundary conditions map to scenario content. Activity structure is normalized, and durations are approximate because they become rate code. Orderings map exactly. Policies land as approximate or collapsed, and their rationale is unrepresentable. Objectives normalize to metrics where a scalar over simulation state can express them; their penalty weights and rationale are unrepresentable. Constraints collapse partially, with regulatory references unrepresentable. Data bindings and validation criteria are wholly unrepresentable. This assignment is a first cut and illustrative only: the plugin spec owns the binding table, while the mechanism itself — per capture, seven categories — is settled.
+
+Two further rules govern what the projection prefers and how it names things. The net projects the practiced process: where prescribed and practiced diverge unresolved, practiced wins, and the prescribed reading lands in the loss report as omitted. And the IR keeps the expert's names verbatim, because payloads are evidence-faithful, while the ProjectionPack owns a deterministic scheme that turns those names into PascalCase identifiers. The scheme is necessary because place names function as identifiers inside every code surface of the file — guards, kernels, differential equations, metrics — and import does not validate them. The ProjectionPack emits the resulting name map as projection metadata for the demo shell to display, and records any collision renames as normalized.
+
+Provenance stays outside the file. The Petrinaut format has no fields for provenance, rationale, confidence, or draft status anywhere, and it strips unknown keys on import, so inline annotation cannot round-trip. Everything IR-only is therefore honestly unrepresentable in the artifact, and displaying provenance is the demo shell's job — never something smuggled into the file.
+
+### The September minimum
+
+The schema holds all ten kinds. The demo requires captures in seven of them — the six net-bearing kinds plus objective: entity-type, boundary-condition, activity, ordering/flow, policy, dynamics, and objective. Constraint, data-binding, and validation-criterion are present in the schema and may be sparsely populated; even at two captures each, their presence tells the story that the net is one projection of a richer description.
+
+The open-questions document also asked what else lives outside the net. Two answers: initial and boundary conditions — populations, arrival rates, external inputs — which bind to the scenario rather than to net structure; and user identity as metadata that shapes the elicitation, which belongs to the harness rather than to the payload, following Dora's ontology.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design.md
new file mode 100644
index 00000000000..2ad5c654839
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-design.md
@@ -0,0 +1,201 @@
+# Intermediate representation — design (FE-1364)
+
+Resolved 2026-08-13 (FE-1364 grilling session). Two layers: a general, architecture-level
+definition of the IR — **ratified on worked examples** (FE-1397), see the status note — and the
+CPS plugin's specific payload design, the September working design. Inputs: the kernel spec
+(§5, §6, §11), the Petrinaut survey's format facts, Dora's PRO-98 ontology (its Maps-to column),
+the open-questions doc §7, and the FE-1363 use-case resolution. Layer-A amendments from the
+worked-examples exercise are marked _(amended FE-1397)_; the exercise itself is
+[`ir-worked-examples.md`](./ir-worked-examples.md).
+
+## Layer A — what "the IR" is, architecturally
+
+**Definition.** _(amended by [ADR-0003](../../adr/0003-three-register-ir.md), 2026-08-18 —
+the IR proper is the elicited conceptual model, derived by a pure fold over active captures;
+the sentence below describes register 1 of three, and "no second store" survives because
+register 2 is a derivation, never a persistence surface.)_ The intermediate representation of
+a target-document is the set of active captures, read through the plugin's declared payload
+type system. There is no second store: every consolidated view — an entity graph, a net, a
+completion table — is a read-time projection over active captures. The rendered artifact is
+one projection of the IR, never the IR itself.
+
+The harness half is already fixed by the kernel spec: each capture is an envelope (id, evidence
+spans, epistemic status, confidence, value-xor-absence, alternatives, supersession) around an
+opaque plugin payload. Defining an IR is therefore defining a payload type system.
+
+**What a plugin's payload type system must do** (durable, cross-plugin):
+
+1. **Declare a closed, named catalog of assertion kinds** (namespaced concept declarations).
+   Assurance: `Statement` kinds; Gherkin: scenario/step records; CPS: the catalog below.
+   _(already spec canon, §11.1)_
+2. **Evidence granularity.** Each payload is one assertion at the resolution the evidence
+   states it — the user's utterance in the primary case, the declared default or documented
+   transformation for `defaulted` / `external-lookup` captures. One utterance may yield several
+   single-assertion captures (granularity is per-assertion, never per-utterance), and a user
+   who happens to speak in artifact-shaped units is coincidence, not violation. Factoring into
+   artifact-shaped elements belongs to `project`; the interviewer never does the artifact's
+   modelling work mid-conversation. _(new in this decision; amended FE-1397 — generalized from
+   statement granularity for log-derived captures)_
+3. **Projection-independence.** Kinds are defined in domain vocabulary, and the IR may
+   legitimately hold kinds no current projection consumes — the typed loss report is what keeps
+   that honest. The second clause is the enforceable content: the property's bite is
+   proportional to domain–format distance, and where the target format _is_ the domain
+   (Gherkin), the vocabulary clause degenerates gracefully rather than failing. _(new in this
+   decision; amended FE-1397)_
+4. **Relations are payload data, not envelope structure.** A plugin needing structure declares
+   its own reference/edge vocabulary (assurance's four edge kinds; CPS's symbolic name
+   references). _(already spec canon, §5)_
+5. **Domain labels and rollups derive at read time via `project`, never stored.**
+   _(already spec canon, §5, §13.3)_
+
+**Recommended patterns** (graded per FE-1397):
+
+- **SHOULD** _(promoted from MAY, FE-1397 — all four worked designs use it)_: symbolic,
+  name-based references between payloads, with `reconcile` doing identity resolution at read
+  time — matches how experts talk and survives supersession without dangling edges. A plugin
+  departing from it should say why.
+- **MAY**: **completion-anchor kinds** for a question-relative completion contract — a distinct
+  purpose/objective kind where the domain has explicit purposes (CPS, BPMN), existing
+  purpose-shaped kinds otherwise (Gherkin's feature narrative + rules; assurance's `goal`).
+  _(amended FE-1397 — the pattern is "completion anchors on purpose-bearing captures", not
+  "declare a kind named objective")_
+- **MAY**, for process-shaped domains _(added FE-1397, promoted from Layer B)_: a
+  **source-regime** attribute (`prescribed | practiced`) on every kind — one model, never
+  parallel models; divergence surfaces as ordinary typed `conflicting` issues; regime composes
+  with (never duplicates) epistemic status, so log-observed vs. expert-believed practice is
+  already the envelope's `external-lookup` vs. `explicit`.
+- **Named escape hatch only** _(demoted FE-1397 — zero uptake across all four designs)_:
+  non-load-bearing pattern/motif annotations that projection may take hints from but never
+  depend on; retained as a name pending a projection that demonstrably needs the hint.
+
+**Status: ratified on worked examples** (Lu, 2026-08-13, FE-1397). The ratification condition —
+speculative payload designs across at least three plugin targets at different complexity levels,
+checked property by property — is discharged in
+[`ir-worked-examples.md`](./ir-worked-examples.md): Gherkin (thin), CPS (thick, this document's
+Layer B), BPMN/process-mining (mid), with the assurance plugin (spec §13.2) as a fourth free
+corroborant. All five MUST properties survive — 2 and 3 amended as worded above — and the
+expected sublimation pressure — a payload-level concept proving so universal it rises out of
+plugin space, in the strongest case into the harness envelope itself — materialized as pattern
+promotion (source-regime moving Layer-B → Layer-A) rather than any kind moving into the
+envelope. Everything remains **desk-validated
+only**: Layer-A claims stay provisional until real examples run through a working harness — the
+September build exercises that.
+
+## Layer B — the CPS plugin's IR
+
+A working design, validated only against the truck-fleet reference case (FE-1363). The
+worked-examples exercise (FE-1397) left it unbent — its one export is source-regime, promoted to
+a Layer-A pattern — but the harness still gets its turn.
+
+### Assertion kinds
+
+| #   | Kind                     | Holds                                                                                                          | Projects to (Petrinaut)                                                                                                                                                    |
+| --- | ------------------------ | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | **entity-type**          | object types and their attributes, incl. continuous state variables (truck, component, wear level)             | colours + typed elements                                                                                                                                                   |
+| 2   | **boundary-condition**   | initial populations, arrival/departure rates, external inputs ("40 trucks, 3 bays", initial wear distribution) | scenario `initialState` + `scenarioParameters`                                                                                                                             |
+| 3   | **activity**             | steps _as the expert states them_: actors, resources, preconditions, outcomes, duration                        | factored transitions (see granularity rule)                                                                                                                                |
+| 4   | **ordering/flow**        | sequencing, branching, trigger conditions                                                                      | arcs, guards, arc types (read/inhibitor)                                                                                                                                   |
+| 5   | **policy**               | decision rules at choice/conflict points                                                                       | guard/priority code where compilable; mostly IR-only                                                                                                                       |
+| 6   | **dynamics**             | continuous evolution laws (wear accumulation)                                                                  | differential equations on real-valued colour elements                                                                                                                      |
+| 7   | **objective**            | questions the model must answer; goals; penalty weights                                                        | metrics where expressible as scalars over simulation state; weights IR-only                                                                                                |
+| 8   | **constraint**           | regulatory/business rules, conservation laws                                                                   | guards partially; references IR-only                                                                                                                                       |
+| 9   | **data-binding**         | model variable ↔ data feed                                                                                     | nothing today (Live Mode — Petrinaut's named-but-unimplemented mode for driving a running simulation from external data feeds — is the surface this kind would project to) |
+| 10  | **validation-criterion** | how we would know the model is right                                                                           | nothing today                                                                                                                                                              |
+
+Kinds 1–6 are **net-bearing**; 7–10 are partly or wholly **IR-only**. That split is the demo's
+story: the net is one projection of the elicited description, and what the net cannot hold is
+neither lost nor hidden — it is in the IR with provenance, and the loss report says so.
+(Corroborated independently: Dora's Maps-to column marks constraints, policies, and penalty
+weights as living "in the intermediate representation", and routes objectives to the
+simulation/experiment layer — i.e. metrics.)
+
+**Attribute patterns** (cross-kind, deliberately not kinds):
+
+- **quantity** — durations, rates, probabilities, capacities; quantile-elicited (never
+  min/mode/max — per FE-1360's literature verdict: the TU Delft/EFSA quantile line, plus one
+  published comparison in which the min/mode/max triangular habit overstated a measured mean by
+  ~69%; a single study, but the quantile prescription stands on the protocol line independently),
+  attachable to any kind; shared/tunable quantities project to `parameters` (which quantities
+  earn a named parameter rather than an inline value is undefined here — the plugin spec's
+  binding table owns that criterion).
+- **rationale** — available on every kind, never only under objective.
+- **source-regime** — `prescribed | practiced` on every kind (manuals vs. how it actually
+  runs). One model, not parallel models; a prescribed/practiced divergence surfaces as an
+  ordinary typed `conflicting` issue — which is elicitation gold ("rules nobody wrote down"),
+  not an error state.
+
+### Granularity rule (Dora's claim #2, validated with correction)
+
+"Steps become transitions; states between become places" survives as a **projection** rule,
+not a storage rule. The IR stores activities at the expert's statement granularity, durations
+included. Petrinaut has no timing field of any kind — a timed step cannot be one transition —
+so `project` owns the factoring (e.g. start-transition → in-progress place → end-transition,
+or rate code). If the IR stored net-granularity elements, every factoring change would
+masquerade as a knowledge change and the interviewer would be doing net modelling
+mid-conversation.
+
+### Motifs
+
+The motif quiver (small, parameterised, variant selectors) lives in the **ElicitationPack as
+question guidance only** — scaffold-yes, generator-no, per the literature verdict. No motif
+vocabulary in the payload for September; the optional non-load-bearing annotation pattern
+(Layer A) exists if projection ever demonstrably needs the hint. Per-object-type templates
+live nowhere.
+
+### Completion
+
+The CPS plugin commits to **question-relative completion**: `objective` captures anchor the
+completion contract — every objective has its supporting kinds covered — over a small static
+floor (at least one objective; entities; a happy-path flow). The interview therefore opens on
+objectives. This operationalizes the earning test (stochasticity and colour only where an
+objective demands them — the open-questions doc's criterion for model complexity) and is the
+corrected form of a static category ordering: Dora's PRO-98 strategy outline prescribes a fixed
+category sequence for the interview; question-relative completion keeps its coverage intent but
+replaces the fixed sequence with objective-driven coverage, so ordering emerges from what the
+objectives demand rather than from the ontology's own layout.
+
+### Projection to Petrinaut
+
+- **Emission surfaces**: all four in-file surfaces — net structure (places, transitions,
+  colours, ODEs, arcs), **scenario** (mandatory: a bare net loads with an empty marking and
+  does nothing when simulated), **metrics**, **parameters**. The Optuna/optimization file
+  format (`petrinaut-optimization`) is **excluded for September**: its ontology is itself in
+  flight (Yannis is working on it; his design is a candidate future input). Penalty weights
+  stay IR-only and appear in the loss report.
+- **Typed loss report**: per-capture; every active capture lands in exactly one of
+  `mapped-exactly / normalized / approximate / collapsed / omitted / defaulted /
+unrepresentable`. The table above implies the first cut: entity-types and dynamics map
+  exactly (names normalized); boundary-conditions map to scenario content; activity structure
+  is normalized with durations approximate (rate code); orderings map exactly; policies are
+  approximate/collapsed with rationale unrepresentable; objectives normalize to metrics where
+  scalar-expressible, with penalty weights and rationale unrepresentable; constraints collapse
+  partially with regulatory references unrepresentable; data-bindings and validation-criteria
+  are unrepresentable. **First cut, illustrative** — the binding table is owned by the plugin
+  spec; the mechanism (per-capture, seven categories) is resolution-grade.
+- **Regime rule**: the net projects the **practiced** process. Where prescribed and practiced
+  diverge unresolved, practiced wins and the prescribed reading lands as `omitted` in the
+  report.
+- **Naming discipline**: IR payloads keep expert-language names verbatim (evidence-faithful).
+  The ProjectionPack owns a deterministic name→PascalCase identifier scheme, emits the name-map
+  as projection metadata for the demo shell to display, and records collision renames as
+  `normalized`. The failure mode this prevents: place names are identifiers inside every code
+  surface (guards, kernels, ODEs, metrics) and import does not validate them, so an
+  inconsistent rename leaves code referencing identifiers that no longer resolve — nothing
+  catches it at import time; it surfaces only when simulation misbehaves.
+- **Provenance stays outside the file.** The Petrinaut format has no provenance, rationale,
+  confidence, or draft-ness fields anywhere, and unknown keys are stripped on import (inline
+  annotation is explicitly not round-trippable). Everything IR-only is honestly
+  `unrepresentable` in the artifact; provenance display is the demo shell's job, never
+  smuggled into the file.
+
+### September minimum (the open-questions doc's §7.2, answered)
+
+The schema holds all ten kinds. The demo requires captures in the seven net-bearing-plus-
+objective kinds (entity-type, boundary-condition, activity, ordering/flow, policy, dynamics,
+objective); constraint, data-binding, and validation-criterion are schema-present and may be
+sparsely populated — their presence _is_ the "net is one projection" story even at two
+captures each.
+
+§7.1 asked what else belongs on the lives-outside-the-net list: **initial/boundary conditions**
+(populations, arrival rates, external inputs — scenario-bound, not net-bound) and **user
+identity as elicitation-shaping metadata** (Dora's ontology; harness-side, not payload).
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-worked-examples.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-worked-examples.md
new file mode 100644
index 00000000000..76a09b3966e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/ir-worked-examples.md
@@ -0,0 +1,175 @@
+# IR worked examples — Layer-A validation (FE-1397)
+
+Resolved 2026-08-13. This document discharges the ratification condition on the generic IR
+definition ([`ir-design.md`](./ir-design.md), Layer A): speculative payload type systems drafted
+across three plugin targets at different complexity levels, each checked against the five MUST
+properties and three MAY patterns. **Desk validation only** — nothing here has run through a
+working harness; Layer-A claims stay provisional until the September build exercises them.
+
+Four data points, not three: **Gherkin** (thin; drafted here), **CPS** (thick; `ir-design.md`
+Layer B is worked example #2), **BPMN/process-mining** (mid; drafted here — the kernel spec's
+named third dev target, §13), and the **assurance plugin** (spec §13.2) read as a fourth, free
+corroborant since its payload design already exists in spec canon.
+
+## Worked example 1 — Gherkin (thin, known)
+
+The milestone-one tracer target (spec §13.1). Speculative kind catalog, namespace `gherkin/`:
+
+| #   | Kind                     | Holds                                                                         | Projects to (`.feature`)                      |
+| --- | ------------------------ | ----------------------------------------------------------------------------- | --------------------------------------------- |
+| 1   | **feature**              | a capability under specification and its value narrative (who benefits, why)  | `Feature:` header + description               |
+| 2   | **rule**                 | a business rule the behavior must honor                                       | `Rule:` block                                 |
+| 3   | **example**              | one concrete case as the user stated it — context, action, expected outcome   | `Scenario:`, with steps factored by `project` |
+| 4   | **background-condition** | a precondition common to a feature's cases                                    | `Background:` steps                           |
+| 5   | **actor**                | a persona or system that acts or is acted on                                  | step subject vocabulary; tags                 |
+| 6   | **term**                 | a domain word with agreed meaning, bindable to the pack-declared step lexicon | step phrasing normalization                   |
+
+**No `step` kind — statement granularity bites even at the thin end.** Users state cases ("an
+expired token shows an error page"), not Given/When/Then triples; factoring a case into steps is
+`project`'s work, exactly as CPS activity factoring is. A Gherkin-literate user may well dictate
+literal Given/When/Then — then statement granularity _coincides_ with artifact granularity, which
+is coincidence, not violation; the payload holds what was said either way. The property's force
+is that the interviewer never _requires_ the artifact's decomposition mid-conversation.
+
+**References** are symbolic by name: example → its feature ("the password-reset flow"), example →
+the rule it illustrates, background-condition → the feature it scopes; `reconcile` folds name
+variants. **Completion** needs no distinct objective kind: the anchor role is filled by existing
+kinds — every rule has at least one illustrating example (plus a contrastive counter-example
+where the rule has an edge), every feature a happy path. The feature's value narrative is the
+purpose statement.
+
+**Projection and loss.** Nearly everything lands `mapped-exactly` or `normalized` — Gherkin has
+free-text description slots, so even rationale rides along. Actor and term captures emit no
+distinct artifact element; they are consumed as naming/phrasing policy (`collapsed`). The loss
+report is almost empty at the thin end: the _mechanism_ holds but earns little — its value grows
+with domain–format distance. Validation stays as spec §13.1 has it (parse validity + step-lexicon
+binding), payload-stratum work.
+
+**Property stress notes.** (1) six kinds, closed — holds. (2) holds, with the coincidence note
+above. (3) is the interesting one: the plugin is _named after its projection target_, and its
+domain vocabulary ("scenario", "rule") is the format's vocabulary — the property cannot demand a
+distance that does not exist. What it operatively demands still holds: kinds no projection
+consumes (actor, term as glossary) are legitimate IR content, and the loss report keeps them
+honest. (4) holds — references are payload data. (5) holds — "rule uncovered by any example" is a
+read-time label, never stored.
+
+## Worked example 2 — CPS (thick)
+
+`ir-design.md` Layer B, in full; not restated here. What it contributes to the property check:
+
+- The **granularity rule** (Dora's claim #2, corrected) is the sharpest property-2 evidence in
+  the set: Petrinaut has no timing field, so a timed step cannot be one transition — storing
+  net-granularity elements would make every factoring change masquerade as a knowledge change.
+- **Property 3 is carried by the net-bearing/IR-only split** (kinds 7–10) plus the typed loss
+  report — the demo's story is precisely that the IR legitimately holds kinds the projection
+  cannot consume.
+- **Attribute patterns** (quantity, rationale, source-regime) show that not everything
+  cross-cutting deserves kind-hood — a payload-design idiom Layer A did not name, tested again by
+  BPMN below.
+- Ten kinds, symbolic references, objective-anchored completion, read-time labels: properties 1,
+  4, 5 and both first MAY patterns exercised without strain.
+
+## Worked example 3 — BPMN / process-mining (mid, speculative)
+
+The triangulation point, chosen because it varies both axes at once: a process domain like CPS
+but a different artifact family (BPMN 2.0 XML, not Petrinaut), and — via process mining — the one
+evidence source neither other target has: **event logs**, i.e. captures whose provenance is not
+an utterance. Speculative kind catalog, namespace `bpmn/`:
+
+| #   | Kind              | Holds                                                                  | Projects to (BPMN 2.0)                            |
+| --- | ----------------- | ---------------------------------------------------------------------- | ------------------------------------------------- |
+| 1   | **role**          | who does the work — org units, people, systems                         | participants (pools) + lanes                      |
+| 2   | **activity**      | a unit of work as the expert states it — actor, inputs, outcomes       | tasks (factored; task type derived)               |
+| 3   | **trigger**       | what starts or interrupts work — timers, messages, failures            | events (start/intermediate/boundary)              |
+| 4   | **ordering/flow** | sequencing and branching with conditions                               | sequence flows + gateways                         |
+| 5   | **decision**      | the rule applied at a branch point                                     | gateway conditions where compilable; else IR-only |
+| 6   | **case-story**    | one concrete trace ("the Meyer order last Tuesday went…")              | nothing directly; validates flows                 |
+| 7   | **deviation**     | how practice departs from the nominal path                             | boundary events / alternate flows, partially      |
+| 8   | **artifact**      | documents and data objects flowing through the process                 | data objects + associations                       |
+| 9   | **objective**     | KPIs and the questions the model must answer (cycle time, conformance) | nothing — BPMN has no KPI element; IR-only        |
+| 10  | **log-binding**   | model element ↔ event-log field (case id, activity, timestamp)         | nothing; IR-only, consumed by conformance tooling |
+
+**Event-log evidence needs no envelope change.** A mining proposal ("credit check precedes
+approval in 92% of traces") enters as an ordinary capture with `epistemic_status:
+external-lookup`, citing the log and a documented transformation instead of a user span — exactly
+the C5 adjudication (spec §5, Appendix A). What it _does_ expose is a wording gap in property 2:
+"the granularity the user stated it" has no user here; the mined capture's granularity is set by
+the documented transformation. The property generalizes from _statement_ granularity to
+**evidence granularity**, with the user's utterance as the primary case.
+
+**Regime and epistemics compose; no third regime value.** The org manual says X, the expert says
+actually-Y, the log shows Z. The de jure/de facto split is the regime (`prescribed | practiced`,
+from CPS); expert-belief vs. log-observation within `practiced` is already the envelope's
+epistemic status (`explicit` vs. `external-lookup`). Divergences land as ordinary typed
+`conflicting` issues. The **source-regime attribute pattern thus recurs across both process
+plugins** — sublimation pressure, resolved one layer up (a Layer-A MAY pattern for process-shaped
+domains), _not_ harness-ward: the harness has no domain notion of "manual" or "shop floor".
+
+**`decision` recurs from CPS `policy` — convergence is not sublimation.** The kind appears in
+both process plugins, but §11.5's ownership rule (guidance ownership follows vocabulary
+ownership) routes only the _technique_ to the generic quiver — contrastive choice-point pressure
+("when two X compete for one Y, who wins, by what rule?") operates on harness vocabulary. The
+_kind_ stays in each plugin's catalog; if the process family grows, the seam is a shared
+process-domain pack, not the kernel.
+
+**Completion** anchors on `objective` again (KPIs + the questions the model must answer), over a
+floor of roles, a happy-path flow, and at least one case-story validating it. **Loss sketch**
+(illustrative, per-ProjectionPack): roles/activities/flows normalized; decisions approximate;
+objectives and log-bindings unrepresentable; case-stories omitted (consumed at validation time,
+not projected). One instructive contrast: BPMN carries a `documentation` element on every node,
+so rationale attached to a projected element is `normalized` here — where Petrinaut, which strips
+unknown keys, makes the same rationale `unrepresentable`. **Loss tables are ProjectionPack facts,
+not plugin facts**, which is why the binding table belongs to each plugin spec's ProjectionPack.
+
+## Verdicts
+
+Per Layer-A MUST property (`survives / amended / demoted to guidance`):
+
+| #   | Property                   | Verdict               | Basis                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| --- | -------------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | Closed, named kind catalog | **survives**          | Catalog sizes 1 (assurance's single `Statement` record) through 10 (CPS, BPMN); closure held everywhere; extension pressure is absorbed by the concept-schema version axis (spec §12.6), not by opening the catalog.                                                                                                                                                                                                                                            |
+| 2   | Statement granularity      | **survives, amended** | Generalized to **evidence granularity**: payloads hold one assertion at the resolution the evidence states it — the user's utterance in the primary case, the documented transformation for `defaulted`/`external-lookup` captures. Two clarifications: one utterance may yield several single-assertion captures (granularity is per-assertion, not per-utterance), and coincidence with artifact granularity (Gherkin-literate dictation) is not a violation. |
+| 3   | Projection-independence    | **survives, amended** | Restated operatively, because its bite is proportional to domain–format distance and Gherkin has almost none: kinds are defined in domain vocabulary _and the IR legitimately holds kinds no current projection consumes, with the typed loss report keeping that honest_. The second clause is the enforceable content; the first degenerates gracefully where the target format is the domain.                                                                |
+| 4   | Relations as payload data  | **survives**          | Flow-heavy BPMN is the strongest test — an edge-dense domain still needed no envelope structure; symbolic name references appear in all four designs.                                                                                                                                                                                                                                                                                                           |
+| 5   | Read-time label derivation | **survives**          | Uncovered-rule (Gherkin), the net-bearing/IR-only split and five-stratum status (CPS, assurance), conformance/coverage labels (BPMN) — all `project`-computed, none stored.                                                                                                                                                                                                                                                                                     |
+
+Per MAY pattern:
+
+| Pattern                                               | Verdict                                                                                                                                                                                                                                                                                                                                         |
+| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Symbolic name references + `reconcile`                | **Promoted MAY → SHOULD.** All four designs use it; it matches how experts talk and survives supersession without dangling edges. A plugin departing from it should say why.                                                                                                                                                                    |
+| Objective kind anchoring question-relative completion | **Survives, generalized to completion-anchor kinds.** A distinct `objective` kind where the domain has explicit purposes (CPS, BPMN); existing purpose-shaped kinds otherwise (Gherkin's feature narrative + rules; assurance's `goal`). The pattern is "completion anchors on purpose-bearing captures", not "declare a kind named objective". |
+| Non-load-bearing motif annotations                    | **Demoted to named escape hatch.** Zero uptake across all four designs — CPS explicitly keeps the motif quiver as pack question-guidance, BPMN's workflow patterns are likewise pack material, Gherkin and assurance have no use for it. Retained as a name only, pending a projection that demonstrably needs the hint.                        |
+
+**New Layer-A pattern earned by triangulation:** **source-regime** (`prescribed | practiced`) as
+a MAY for process-shaped domains — one model, never parallel models; divergence surfaces as
+ordinary `conflicting` issues; regime composes with (never duplicates) epistemic status.
+
+**Sublimation findings.** The standing expectation held, with better resolution on _where_
+content lands when it moves:
+
+- **Layer-B → Layer-A**: source-regime moved one layer up, to pattern status. That is the
+  assurance precedent's shape repeated (technique moving to the shared layer), at pattern rather
+  than mechanism grade.
+- **Confirmed quiver-bound, not payload**: choice-point interviewing technique (CPS `policy`,
+  BPMN `decision`) — the kinds stay put; the technique is generic.
+- **Validated, not migrated**: event-log evidence exercised envelope vocabulary that already
+  existed (`external-lookup`, C5) and added nothing.
+- **The counter-rule**: convergent kinds across sibling plugins do not migrate harness-ward —
+  vocabulary ownership (spec §11.5) decides, and the envelope's domain-freedom survived contact
+  with all three targets. No kind moved into the envelope.
+
+## Handoff to plugin-spec authoring
+
+What the plugin spec should inherit from this exercise:
+
+1. The **five MUST properties as amended** (evidence granularity; operative
+   projection-independence) — `ir-design.md` Layer A carries the amended wording.
+2. **Symbolic references at SHOULD grade**, with `reconcile` as the standard identity seam.
+3. **Completion-anchor language**: require every plugin to name its anchor kinds; do not require
+   a kind named `objective`.
+4. The **source-regime pattern** for process-shaped domains.
+5. **Loss tables are ProjectionPack content**, never plugin-level: the same rationale capture is
+   `normalized` under a BPMN projection and `unrepresentable` under a Petrinaut projection.
+6. The standing caveat: all of this is desk-validated; the September harness run is the real
+   test, and any property it bends gets re-amended there.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md
new file mode 100644
index 00000000000..92c765b3b34
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1389.md
@@ -0,0 +1,193 @@
+# Deep-read: FE-1389 — Walk free-text replies through the real harness
+
+Deep-read of commit 81e9ce0 (branch `ln/fe-1389-walking-skeleton`, PR #10), produced during the
+remediation sweep (FE-1401) as one of three outputs: this builder's account + spec-discharge
+note, the commit-message backfill (applied to the branch), and rows for the specification ledger.
+Agent-authored under instruction; reviewed before landing.
+
+Files read (all paths as of 81e9ce0):
+
+- `packages/binding-flue/src/index.ts`
+- `packages/core/src/affordance.ts`
+- `apps/dev/test/walking-skeleton.integration.ts`
+- `apps/dev/test/walking-skeleton.test.ts`
+- `apps/dev/src/ui/chat.tsx`
+- `apps/dev/src/routes.ts`
+- `apps/dev/src/app.ts`
+- `test/boundaries.test.ts`
+- `test/known-gaps.ts`
+
+---
+
+## Builder's account
+
+### The problem
+
+Before this commit the ask tool was an admitted placeholder: `askTool` was a `defineTool` whose `run` threw `'The ask tool is scaffolding: turn suspension and reply binding land with the walking skeleton (FE-1389).'` (Observed — removed hunk in `packages/binding-flue/src/index.ts`). The seam existed — tool name derived from core's abstract operation, Valibot input — but the system could not hold a conversation: no suspension, no pending slot, no reply binding. The dev app's UI was literally `<main>Elicitation harness — dev app</main>` (Observed, `apps/dev/src/ui/main.tsx`).
+
+So the problem is the one CONTEXT.md calls a **walking skeleton**: prove that the whole suspend-for-reply transport — capability 5, the one Flue does not provide and the binding must absorb (spec §10) — actually works on the real substrate, end to end, with stubbed internals, and prove it in a way CI can re-run without a model key or a network.
+
+### Why it's shaped this way
+
+Three prior findings constrain the shape, and every design choice here traces to one of them:
+
+1. **Ticket 10's clobbering finding** (issue 10 §1): writes to the fixed data channel materialize last-write-wins per assistant message. So the channel cannot be the durable record. Spec §7.3 rules that durable identity and payload ride the ask tool's _output part_, and the channel write is live-render sugar.
+2. **Ticket 10's wake wart** (issue 10 §4): interpolating pending state into instructions triggers Flue's "System instructions updated" advisory, waking the model for a wasted turn per ask. Spec §7.4 (adjudication C7) rules: no interpolation.
+3. **Ticket 13's anchoring finding** (issue 13 §2, HITL round 1): the model's verbatim quotes are flawless and its identifier guesses never converge. So reply binding must be harness-mechanical, not model-remembered — no echo token.
+
+The result is that `useElicitation` (spec §12.1 names this exact function) does four things at once, and each is one of those constraints made mechanical.
+
+### How it works, concretely
+
+**The durable pending affordance** (Observed, `packages/binding-flue/src/index.ts:59-85`). The ask tool mints an affordance whose id is `affordance_${toolCallId}` — derived from Flue's own tool-call id, so identity is anchored to the substrate's unit of work rather than to a counter the binding would have to persist. It returns `{ output: affordance, terminate: true }`, with `output: FreeTextAffordance` declared on the tool, so Flue validates the payload onto the tool output part — the durable surface §7.3 blesses. `writeAffordance(affordance)` then writes the same value to a data channel named `'affordance'` (`useDataWriter('affordance', { schema: FreeTextAffordance })`, line 44), which is the live-render copy the UI reads. The channel name is vocabulary-correct: CONTEXT.md retires "exchange", and ticket 10's channel was `data-exchange`.
+
+**The one-live-affordance rule, as mechanism** (Observed, lines 73-80). The check is written as a `setPending` _updater_, not as a read of the `pending` value from the render closure — and this is the load-bearing subtlety of the whole file. Both ask calls in a single tool batch execute against the same render, so both see the same closed-over `pending` (null). Only the updater sees the value the first call just wrote. So the updater form is what makes the reject-second-ask rule actually fire within a batch; a read-then-check would silently permit exactly the case ticket 10 forced by hand. (Inferred, from Flue's render-per-model-call semantics; Observed that the integration test asserts the rejection does fire, which is the empirical confirmation.)
+
+**No interpolation, therefore no wake** (Observed, lines 87-91). The returned instruction string interpolates only `plugin.targetDomain` and `toolName('ask')` — both render-invariant. The pending affordance appears nowhere in it. Since Flue's advisory fires when the instructions (or tool set) change between turns, and neither can change here (the tool set is a single unconditional `useTool`), state writes cannot produce a wake. That is the causal mechanism by which §7.4's ruling delivers the fix, and it is why the test's `noInstructionWake` property is expected to hold rather than hoped to.
+
+**The suspend/resume path** (Observed, lines 46-57). `terminate: true` ends the response. The person's reply arrives as a fresh dispatch. `useAgentStart` fires, guards on `delivery.kind === 'user' && pending !== null`, clears the slot, and `ctx.append`s a `kind: 'signal'` entry typed `affordance-reply-bound` whose body states that the immediately preceding user message is bound to the pending affordance, quoting that affordance's markdown and carrying its id in `attributes`. Two spec obligations are discharged in that one call: §7.4's "any fact the harness owns reaches the model through tool results or signals, not only through instruction text", and §9.4's provenance rule, since Flue signals project structurally non-user (ticket 13 §3) and so can never be cited as capture evidence.
+
+**Hermeticity of the proof** — this is the most interesting engineering in the branch. Flue's own docs (quoted in `docs/reference/amp-analysis-flue-vs-tilde.md`) present two mutually exclusive eval modes: in-process `start()` exercises the agent but _needs provider credentials_; HTTP via `@flue/sdk` exercises the agent plus `app.ts` routing but _needs a running server_. The test takes the coverage of both and the cost of neither (Observed, `apps/dev/test/walking-skeleton.integration.ts`):
+
+- `start({ agents: [GherkinElicitor], providers: [faux.provider] })` boots the real runtime in-process, with `@earendil-works/pi-ai`'s `fauxProvider` registered under `provider: 'anthropic'`, model `claude-haiku-4-5` — shadowing the real provider the agent's `useModel` names, so no credential and no network egress. Responses are a scripted array, one of them a function that captures the live `Context` for inspection.
+- `createFlueClient({ url: 'http://brunch.test/agents/gherkin/<uuid>', fetch: fetchApp })` where `fetchApp` calls `app.fetch(new Request(...))` directly (lines 49-57). No socket, no listener, no DNS: `brunch.test` exists only to make the URL absolute. The real Hono app and the real `createAgentRouter` mount are in the path, so route wiring is genuinely covered.
+- `start()` is called with **no `db` option**, so conversations are process-memory (Flue's documented behavior: "omit it for in-memory state"). The dev app's `apps/dev/src/db.ts` sqlite adapter is a build-time convention file and is not reached by the explicit `start()` config — so the test touches no disk (Inferred, but consistent with `apps/dev/src/db-path.ts`'s own note that the adapter module "cannot be driven under `bun test`").
+- Conversation id is a fresh `crypto.randomUUID()` per run, and `finally { await flue.stop() }` tears the runtime down.
+- The whole thing runs as a child `node --experimental-strip-types` process spawned by `apps/dev/test/walking-skeleton.test.ts`, which asserts on a single `WALKING_SKELETON_RESULT <json>` stdout line via one `toEqual` over all five properties. The child-process shape keeps a booted Flue runtime out of the `bun test` process (Inferred: `db-path.ts` records that `@flue/runtime/node` "cannot be driven there").
+
+The five asserted properties: the bound reply text and the `affordance-reply-bound` tag both reached the model's context; the first affordance survived on the tool output part with `"form":"free-text"`; the data channel carried the question; no `instructions updated` advisory appeared anywhere in history; and in a two-ask batch exactly one call is `output-available` and exactly one is `output-error`.
+
+### What a newcomer would misunderstand
+
+- **That `routes.ts` is a regression.** The old `apps/dev/src/app.ts` comment said the mount path "derives from the pinned identity — a copied literal here would let a second agent shadow this mount". The new code mounts at a separate literal `'gherkin'`. This is not a loosening: `apps/dev/src/ui/chat.tsx` runs in the browser and needs the mount path, and importing `gherkin-elicitor.ts` to read `.agentName` would drag `'use agent'` and `@flue/runtime` into the client bundle. `routes.ts` is the one shared constant both call sites import. The boundary check that mattered — `test/boundaries.test.ts:305` "a pinned identity appears only in its own agent module" — still holds, and storage still keys on `brunch-gherkin-elicitor`, as the new comment says. (Observed + Inferred on the motive.)
+- **That the pending slot is the durable record of the affordance.** It is not, and deliberately: it is cleared on the very dispatch that answers it. Durability lives on the tool output part (§7.3). The slot is a _lock_, not a log — it exists to make "at most one pending" true so that binding can be mechanical.
+- **That the reject-second-ask check reads state.** It writes it. See above; a reviewer who "simplifies" the updater into `if (pending !== null) throw` silently deletes the guarantee, and only the integration test would catch it.
+- **That `markdownFloor` in the test proves the markdown floor.** It proves the data channel carried the question text. The actual §7.2 floor property — an unknown form still renders because the envelope carries markdown — is not tested, and as implemented the UI _fails_ it (below).
+- **That the app's `import.meta.env?.DEV === false` inversion is paranoia.** Under plain node there is no `import.meta.env`, so `import.meta.env.DEV` throws the moment the integration test imports `app.ts`. The inversion is what makes the app importable outside vite.
+
+### Where it is thin, brittle, or unresolved
+
+**Genuinely bug-shaped:**
+
+1. **At-least-once tool re-execution is misreported as a duplicate ask.** Ticket 13 §4 records Flue's at-least-once tool re-execution as a hard fact, which is why spec §8.3 makes content-keyed idempotence "load-bearing, not optional". The affordance id is deterministic in `toolCallId`, so a re-execution mints the _identical_ affordance — but the guard tests `current !== null`, not `current.id !== affordance.id`. A retried ask therefore throws "An interactive affordance is already pending", turning a benign retry into a spurious rejection of the model's own question. One-line fix; worth naming before the settlement trigger starts causing re-executions.
+2. **The UI drops unknown forms instead of falling back to markdown.** `apps/dev/src/ui/chat.tsx:30-31` does `v.safeParse(FreeTextAffordance, part.data)` and `return null` on failure. `FreeTextAffordance` validates `form: v.literal('free-text')` and the concrete `payload`, so the _first_ single-choice or plugin-custom affordance to arrive renders as nothing at all. Spec §7.2 and §7.7 both require the opposite: the markdown floor exists precisely so "a ui that knows only the envelope renders everything", and ticket 10 §5 proved that behavior. The floor needs an envelope-only schema (id/form/markdown) with the payload opaque; today one closed schema does both jobs.
+3. **No escape from an occupied slot.** The slot clears only on a `kind: 'user'` delivery. If a reply never comes, every subsequent ask is refused forever and nothing reports the fact. Spec §7.5's `unanswered` outcome and §8.6's unaccounted-ask advisory are the intended relief valve; neither exists yet.
+
+**Thin, in the honest walking-skeleton sense:**
+
+1. **The harness shell is empty; the mechanism is all in the binding.** `packages/core` contributes two Valibot schemas (`packages/core/src/affordance.ts`) and `toolName`. Everything else — the affordance id scheme, the reject-second rule (a _harness_ invariant per §7.3), the reply-binding narration, the instruction assembly — lives in `packages/binding-flue/src/index.ts`, whose own header invokes the second-binding test (§14.2) against exactly this. A `binding-pi` would re-implement all four, and the only Flue-specific parts are the five hook calls. This is the single largest architectural debt the branch creates, and the file's docblock is aware of it.
+2. **`targetDomain` is interpolated raw into the prompt.** `'You are interviewing someone to elicit gherkin.'` — because `plugin.targetDomain` is `'gherkin'` (`packages/plugin-gherkin/src/index.ts`). This is the first place plugin data reaches the model, and it arrives as an unadorned slug. §11.1 plugin ownership wants a human phrase here.
+3. **One session per target-document, everywhere.** `chat.tsx:8` computes `conversationId` at module scope and line 68 derives `targetDocumentId: dev-${conversationId}`, so every page load opens a new session against a brand-new document. The integration test pins the document id but randomizes the conversation. The §9.1 property that actually matters — many sessions resuming against one target-document — is unreachable from either surface.
+4. **The kickoff message is a machine-authored _user_ entry.** Both `chat.tsx:67` and the test send `{ kind: 'user', body: 'Begin the interview.' }`. Per §9.4 only true user entries are citable as capture evidence — and this one is structurally a true user entry that no user typed. Harmless until sweeps land; then it is an anchorable non-utterance. The correct carrier is the signal channel this branch just built.
+5. **No user-visible insertion notice.** The `affordance-reply-bound` signal projects `display: 'diagnostic'` (ticket 13 §3) and `chat.tsx:11-16` filters it out. §9.3 requires "a minimal user-visible insertion notice accompanies every injected state message"; this is the first injected entry in the system and it ships silent. Scoped to briefings in the spec's letter, so not yet a violation, but the same code path will owe it.
+
+**Brittle oracles** — and the repo already knows: `docs/planning/legibility-sweep/refactor-queue-2026-08-14.md` item 2 names the faux-provider marker comment specifically.
+
+1. **`noInstructionWake` is a case-insensitive substring absence over `JSON.stringify(history.messages)`.** It matches Flue's advisory _phrasing_. If Flue rewords the advisory, the check passes forever while the wart is back — and this check is the one that deletes the `wake-wart-residue` entry from `test/known-gaps.ts`.
+2. **`boundReplyReachedModel` under-asserts the binding.** It is two substring tests over the stringified context. It does not check that the signal carries the _right_ `affordanceId`, that it quotes the _first_ question rather than the second, or that it sits adjacent to the user message. The property "the correct affordance was bound" is not actually pinned.
+3. **The faux provider's model id is a silent coupling.** `{ id: 'claude-haiku-4-5' }` must match `useModel('anthropic/claude-haiku-4-5')` in `apps/dev/src/agents/gherkin-elicitor.ts`. Nothing ties them. Change the agent's model and the test either falls through to a real provider or fails obscurely; `test/boundaries.test.ts`'s model-key scan would not notice an attempted network call.
+4. **The hermeticity gate was weakened to a comment.** `test/boundaries.test.ts:424-433` changed from "no test imports the substrate, ever" to "substrate imports are allowed in `*.integration.ts` files containing the string `hermetic-substrate-test: faux-provider`". Any future file can claim hermeticity by copying a comment.
+
+---
+
+## Spec discharge
+
+| Obligation                                                                        | Status                               | Evidence / gap                                                                                                                                                                                                                                                                                                              |
+| --------------------------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| §10 cap. 1 register a tool                                                        | **full**                             | `useTool` at `binding-flue/src/index.ts:59`                                                                                                                                                                                                                                                                                 |
+| §10 cap. 2 contribute instructions                                                | **full**                             | render return, lines 87-91                                                                                                                                                                                                                                                                                                  |
+| §10 cap. 3 persist per-conversation state                                         | **full**                             | `usePersistentState('pendingAffordance')`, line 40                                                                                                                                                                                                                                                                          |
+| §10 cap. 4 emit an affordance payload                                             | **full**                             | both surfaces: `useDataWriter` (44) + `output` on the tool (64, 83)                                                                                                                                                                                                                                                         |
+| §10 cap. 5 suspend-for-reply (**absorbed**)                                       | **full**                             | `terminate: true` + pending slot + fresh dispatch, all three present and proved                                                                                                                                                                                                                                             |
+| §7.3 durable identity/payload on the tool output part                             | **full**                             | `output: FreeTextAffordance`; test property `durableOutput`                                                                                                                                                                                                                                                                 |
+| §7.3 channel is live-render sugar, not a log                                      | **full**                             | channel write is secondary and unread by the durability assertion                                                                                                                                                                                                                                                           |
+| §7.3 reject a second interactive affordance per batch, **as mechanism**           | **full**                             | updater-form guard (73-80); test property `secondAskRejected` (1 available + 1 error)                                                                                                                                                                                                                                       |
+| §7.4 no instruction interpolation of the pending question                         | **full**                             | instructions are render-invariant; test property `noInstructionWake`                                                                                                                                                                                                                                                        |
+| §7.4 pending affordance narrated in the ask tool's result                         | **full**                             | the affordance _is_ the tool output                                                                                                                                                                                                                                                                                         |
+| §7.4 harness-mechanical reply binding, no echo token                              | **full**                             | `useAgentStart` slot-clear + signal (46-57); test property `boundReplyReachedModel`                                                                                                                                                                                                                                         |
+| §7.4 harness facts reach the model via tool results or signals                    | **full**                             | `kind: 'signal'` carrier                                                                                                                                                                                                                                                                                                    |
+| §7.7 outbound rich / inbound string-only                                          | **full**                             | Valibot-validated data part + tool output; replies are bare strings                                                                                                                                                                                                                                                         |
+| §7.7 the UI must filter on `purpose`/`display`                                    | **full**                             | `chat.tsx:11-16`                                                                                                                                                                                                                                                                                                            |
+| §9.2 pending-affordance slot as one of exactly three per-session items            | **full**                             | the slot exists and is the only per-session state added                                                                                                                                                                                                                                                                     |
+| §9.4 injected entries structurally non-user                                       | **full**                             | signal carrier, per ticket 13 §3                                                                                                                                                                                                                                                                                            |
+| §12.1 host calls `useElicitation(plugin)`                                         | **full**                             | `gherkin-elicitor.ts:29`                                                                                                                                                                                                                                                                                                    |
+| §12.3 tool names identity-not-function                                            | **full**                             | `brunch_ask` via `toolName('ask')`                                                                                                                                                                                                                                                                                          |
+| §12.5 CI smoke with no model key, no network, no flake                            | **full**                             | faux provider + `fetch` shim + no `db`; gate weakened per note below                                                                                                                                                                                                                                                        |
+| §14.5 wake-wart residue                                                           | **partial** — ledger says closed     | Proved for the _one_ instruction-state write path that exists. §14.5 asks that "no **other** instruction-state write path re-triggers advisory wakes"; there are no others yet, and the gap entry was **deleted** from `test/known-gaps.ts`, so the high-water mark and settlement-trigger write paths will land unchecked. |
+| §7.2 three baseline forms + questionnaire chaining                                | **partial**                          | free-text only, by design                                                                                                                                                                                                                                                                                                   |
+| §7.2 markdown floor                                                               | **partial / contradicted in the UI** | schema carries `markdown` (correct); `chat.tsx:30-31` validates the _whole concrete form_ and returns `null` on mismatch, so an unknown form renders nothing — the opposite of the floor, and of ticket 10 §5's proved behavior                                                                                             |
+| §7.2 plugin payloads opaque at the tool boundary (`v.any()` in typed envelope)    | **touched, not discharged**          | `payload: v.object({ question })` is concrete; there is no envelope/payload split yet, so the opaque waist is unbuilt                                                                                                                                                                                                       |
+| §5.1 reserved reply encoding for structured taps                                  | **touched, not discharged**          | UI sends bare text; §5.1 explicitly makes taps optional, so no violation — absences from this UI would honestly be `inferred`                                                                                                                                                                                               |
+| §7.5 transport outcomes `answered / redirected / unanswered`                      | **touched, not discharged**          | binding clears the slot and binds unconditionally; no outcome is recorded anywhere                                                                                                                                                                                                                                          |
+| §7.6 interpretation render                                                        | **untouched**                        | still open as `interpretation-render-plugin-seam` in `known-gaps.ts`                                                                                                                                                                                                                                                        |
+| §9.1 many sessions, one target-document                                           | **touched, not discharged**          | `chat.tsx:68` derives a fresh document id per page load                                                                                                                                                                                                                                                                     |
+| §9.3 re-entry briefing (+ user-visible insertion notice)                          | **touched, not discharged**          | the signal carrier is now proved; no briefing, and the one injected signal is filtered out of the UI                                                                                                                                                                                                                        |
+| §14.4 generation-first fixtures over a deterministic replay driver, `fc.commands` | **untouched**                        | the proof is one hand-scripted linear sequence                                                                                                                                                                                                                                                                              |
+| §14.1 all ten harness invariants                                                  | **untouched**                        | every one is a capture-store property; no capture store on this branch                                                                                                                                                                                                                                                      |
+| §14.2 five proof obligations; smallest-honest-plugin                              | **partial**                          | smallest-honest holds (plugin surface unchanged, only `targetDomain` read). Controlled elicitation is advanced. **The second-binding test is failing in spirit** — see below.                                                                                                                                               |
+| Issue 10: one-channel multiplex, amended                                          | **full**                             | channel + tool-part split implemented exactly as amended                                                                                                                                                                                                                                                                    |
+| Issue 10: update-in-place vs append                                               | **full (inherited)**                 | settled by the prototype; this branch depends on it rather than re-proving                                                                                                                                                                                                                                                  |
+| Issue 10: echo token not needed                                                   | **full, superseded**                 | replaced by the stronger mechanical binding of §7.4                                                                                                                                                                                                                                                                         |
+| Issue 10: turn suspension + wake wart                                             | **full**                             | suspension proved; wart eliminated at its cause                                                                                                                                                                                                                                                                             |
+| Issue 10: rendering ergonomics                                                    | **partial**                          | `purpose`/`display` filtering yes; markdown fallback for unknown forms **no**                                                                                                                                                                                                                                               |
+| Issue 13 cap. 1: settlement trigger (`useAgentFinish`, loop guard, pending guard) | **untouched**                        | no `useAgentFinish`; the pending guard the trigger needs is the very slot this branch built                                                                                                                                                                                                                                 |
+| Issue 13 cap. 2: read the durable entry projection over self-HTTP                 | **touched, not discharged**          | the _test_ reads `client.history()`; the **binding** has no history reader. `history-projection-paging` remains an open gap.                                                                                                                                                                                                |
+| Issue 13 cap. 3: inject typed non-user signal entries                             | **full**                             | `ctx.append({ kind: 'signal', … })`, same-response form                                                                                                                                                                                                                                                                     |
+| Issue 13 cap. 4: transactional durable store outside conversation state           | **untouched**                        | lands on `ln/fe-1390-capture-store`                                                                                                                                                                                                                                                                                         |
+
+### Contradictions and vocabulary notes
+
+- **The markdown floor, in the UI.** The only substantive contradiction. `chat.tsx` implements form-specific parsing where §7.2/§7.7 require an envelope-level floor. It works today because one form exists, and it will silently blank the screen for the second one.
+- **The second-binding test is failing in spirit** (§14.2, and the docblock at `binding-flue/src/index.ts:9-11` asks the question itself). Harness mechanism — the id scheme, the §7.3 one-live-affordance invariant, the binding narration, the instruction assembly — is entirely inside `binding-flue`. `packages/core` holds two schemas. Spec §12.2 names `packages/core` as _the harness_; on this branch the harness is a schema bag.
+- **CONTEXT.md defines "walking skeleton" as a prototype** ("proves a transport or integration end-to-end on the real substrate … with stubbed internals"). Here it names a permanent CI test in the shipped tree (`apps/dev/test/walking-skeleton.test.ts`). The referent has quietly migrated from throwaway-on-a-`prototype/*`-branch to durable-gate. Not wrong — arguably better — but the glossary no longer describes what the word points at, and CONTEXT.md is the authority.
+- **CONTEXT.md lists "core" under _Avoid_ for the harness shell**, while spec §12.2 names the package `packages/core`. Pre-existing, not introduced here; noting it because this commit is where core's public surface first grows beyond naming.
+- **`FreeTextAffordanceValue`** (the `type` alias re-export at `packages/core/src/index.ts`) exists only to disambiguate the schema constant from its inferred type. "Value" is not glossary vocabulary and it will multiply once the other two baseline forms land.
+
+---
+
+## Commit-message backfill
+
+Title unchanged: `FE-1389: Walk free-text replies through the real harness`
+
+```
+Suspend each ask on a durable pending affordance and mechanically
+bind the next dispatch, with a hermetic end-to-end dev-app proof.
+
+The ask tool was a seam that threw. useElicitation now mounts the
+whole suspension protocol Flue makes the binding absorb: the tool
+mints a free-text affordance keyed to its own tool-call id, returns
+it as the tool's output part — durable, where the data channel is
+only last-write-wins per assistant message — and terminates the
+turn. The one-live-affordance rule is mechanism, not instruction,
+and it has to be written as a state updater rather than a read:
+both calls in a tool batch see the same render, so only the updater
+lets the second ask find the first and refuse it.
+
+Nothing interpolates the pending question into the instructions, so
+the instruction string is render-invariant and no state write can
+change it — which is what removes the cause of ticket 10's
+"instructions updated" advisory and the wasted turn per ask. The
+reply arrives as its own dispatch: agent-start clears the slot and
+appends an affordance-reply-bound signal quoting the question, so
+the model receives the binding as a harness fact instead of
+remembering an id, and the signal projects non-user so it can never
+be cited as evidence.
+
+The dev app is now the proof. The integration test drives the real
+runtime and the real Hono app through a fetch shim into app.fetch —
+no socket, no db adapter, so conversations stay in process — with
+pi-ai's faux provider standing in for the model. It reports five
+properties on one line and bun test asserts them together: the
+bound reply and its signal reached the model's context, the
+affordance survived on the tool output part, the channel carried
+the markdown, no advisory wake appeared anywhere in history, and a
+two-ask batch left exactly one call answered and one errored. That
+retires the wake-wart-residue gap; the boundary suite now admits
+substrate imports only from marked .integration.ts files.
+```
+
+---
+
+## PR body
+
+This turns the ask seam into a working turn-suspension protocol: the tool mints a free-text affordance, parks it in the pending-affordance slot, returns it on the tool output part where its identity is durable, and terminates the turn — then the next user dispatch clears the slot and gets bound to that affordance by the harness itself, announced to the model as a signal rather than left to the model's memory. Because the pending question is never interpolated into the instructions, the instruction string cannot change between turns, which is what removes the wasted "instructions updated" wake turn the ticket-10 prototype hit once per question. The dev app is the proof: a chat UI plus an integration test that boots the real Flue runtime and the real Hono app in one process, drives them over a fetch shim with a scripted faux provider, and asserts in one shot that the reply binding reached the model, the affordance survived durably, no advisory wake appeared, and a second ask in the same batch was refused.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md
new file mode 100644
index 00000000000..28784343357
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/deep-read-fe-1390.md
@@ -0,0 +1,169 @@
+# Deep-read: FE-1390 — Make capture history append-only and transactional
+
+Deep-read of commit 02fd352 (branch `ln/fe-1390-capture-store`, PR #11), produced during the
+remediation sweep (FE-1401): builder's account, spec-discharge note, write-time tiering
+assessment against penciled item 7, the commit-message backfill (applied to the branch), and a
+live-probed verification of the FE-1419 refactor queue's capture-store claims. Agent-authored
+under instruction; reviewed before landing. Companion rendering: `../capture-store-plain.md`.
+
+## Builder's account
+
+**What the commit contains** (Observed). Four new files, no modifications to existing behavior: `/Users/lunelson/Code/hashintel/brunch-lite/packages/core/src/capture-store.ts` (784 lines, the whole model), `/Users/lunelson/Code/hashintel/brunch-lite/packages/core/test/capture-store.test.ts` (422 lines, 12 cases), `/Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/src/local-capture-store.ts` (76 lines, the storage-port implementation), `/Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/test/local-capture-store.test.ts` (79 lines, 2 cases), plus 30 re-exports from `packages/core/src/index.ts` and one from the binding's index. `bun test` at HEAD is green (82 pass, 0 fail).
+
+**The event model** (Observed). A `CaptureStoreSnapshot` is exactly three arrays — `captures`, `issues`, `events` (`capture-store.ts:133`), matching CONTEXT.md's "captures, issues, events" verbatim. Every write path appends: `applySweep` pushes new envelopes (`:588-592`), the three event commands append to `events`, `open-issue` appends to `issues`. Nothing in the module mutates or removes a record. There is no stored status anywhere; `deriveCaptureStatus` (`:457`) reads `retracted` from a retraction event, `superseded` from either a `supersedes` link pointing at the capture or a resolution naming it as a loser, and `active` otherwise. `deriveIssueStatus` (`:477`) reads `closed` from a resolution or `issue-closed` event. Both are pure functions of the snapshot, so equivalent state yields equivalent status regardless of discovery order.
+
+**Capture identity is two-headed, deliberately** (Observed). A minted `id` (`capture-${randomUUID()}`) for reference, and a content-derived `dedupKey` (`captureDedupKey`, `:416`) computed over canonicalized provenance (sorted evidence spans, or the `basis` object) plus content — with `epistemicStatus`, `confidence`, and `alternativeGroup` excluded. The dedup logic (`:541-559`) has three distinct skip conditions: an exact retry (same key _and_ same supersedes/status/confidence/group), a duplicate with no supersession link (same key, any status), and a duplicate inside the same batch. The second is the load-bearing one: re-proposing the same evidence and payload with a _different_ epistemic reading and no `supersedes` link is silently skipped, which forces revision through explicit supersession. The store therefore contains multiple captures sharing one `dedupKey` by design (`test/capture-store.test.ts:65-74` asserts exactly that), and `parseCaptureStoreSnapshot` enforces uniqueness only on `id`, never on `dedupKey`.
+
+**The command/refusal surface** (Observed). `applyCaptureStoreCommand` (`:628`) is a pure `(snapshot, command) => result`, five commands (`apply-sweep`, `open-issue`, `close-issue`, `resolve-conflict`, `retract-capture`) against eight refusal codes (`:168-190`). Refusals carry repair facts, not just messages: `superseded-target-not-active` returns `currentHeadIds`, computed by a fixpoint walk over links and resolutions (`currentHeads`, `:485`). Atomicity is structural rather than defended — the function builds a candidate array and returns it or returns a refusal, so a partial sweep has no representation. Advisories (`:594-620`) are computed per sweep, scoped to pairs where at least one side is newly applied, and never stored; the test asserts `snapshot.events` stays empty when advisories fire.
+
+**How the binding implements the port** (Observed). `LocalCaptureStore` wraps the pure function: read the file, apply, write only if `ok`. Serialization is a module-level `Map<path, Promise>` (`local-capture-store.ts:14`) that chains each `execute` behind the previous one and stores an error-swallowing `settled` promise so `read()` can await the in-flight write without inheriting its rejection. The write is `writeFile` to `${path}.${uuid}.tmp` with `flag: 'wx'` then `rename` (`:61-73`). A missing file reads as an empty snapshot; any other read error propagates. Every read goes through `parseCaptureStoreSnapshot`, so the file is validated on the way in, not just on the way out.
+
+**What the tests actually pin** (Observed). Six harness invariants are named in test titles — 2, 4, 5, 7, 9, 10 — each by one hand-written example. Beyond those: advisory reasons for same-evidence and near-identical payloads; defaulted/external-lookup captures refusing a user span; resolution accounting when three captures conflict; two persisted-snapshot rejections (a conflicting issue closed by a bare `issue-closed` event, a stale dedup key, a forking supersession graph); retraction refusing `user-affordance-payload` evidence. The binding tests pin reopen-and-read, no `.tmp` residue, concurrent writes serializing, and a refused sweep leaving the prior file intact.
+
+**What a newcomer would misunderstand.**
+
+- `dedupKey` looks like a primary key and is not (see above). Two active captures can share one.
+- A sweep that skips everything still returns `ok: true` with `appliedCaptureIds: []`. There is no refusal code for "your revised epistemic reading was dropped; supersede capture X instead" — `skippedDedupKeys` reports the key but never the colliding capture's id, so a caller cannot mechanically find what to supersede. Silent-skip-on-success is the single most misreadable behavior in the module.
+- `EvidenceSpan.pointer` looks harness-derived and is not: it is whatever the caller passed. Spec §5 says the pointer is "derived by the harness, which alone can see the entry projection", and §8.2 says "sequence numbers and range bounds never appear in the model-facing tool contract". Nothing in this branch derives or resolves anything; `entryStart`/`entryEnd` are required inputs. That is only safe because no model-facing sweep tool exists yet — nothing in the file says so.
+- `EPISTEMIC_STATUSES` (`:13`) is exported and never used inside the module. The validators hard-code their picklists (`:224`) and literals (`:236`, `:243`), so adding a status to the array changes nothing and no test catches the divergence. `ABSENCE_STATES` and `ISSUE_TYPES` are genuinely wired into the schemas.
+- The whole 784-line module carries **zero comments and zero spec citations**, in a repo where `packages/core/src/index.ts`, `packages/binding-flue/src/index.ts`, and `packages/binding-flue/src/capabilities.ts` all open with spec-cited headers. Every non-obvious ruling here (excluding status from the dedup key, the three-way skip test, resolution accounting by length-plus-membership) is unexplained in place.
+
+**Where it is thin, brittle, or unresolved** (Observed unless marked).
+
+- **No clock.** No record carries a timestamp or sweep-batch identity. Array order is the only ordering, and there is no session or high-water-mark input to `apply-sweep`. §9.3's re-entry briefing needs "captures created/superseded and issues opened/closed since this session's last sweep"; today that is computable only by remembering an array length. (Inferred: this will force either a stamp on records or a sweep-batch record.)
+- **Cross-process concurrency is unguarded.** `writesByPath` is in-process only, and the read-modify-write does no version check or file lock. Two processes on one file lose writes silently, last writer wins. §9.6 asks only for "whole-sweep-atomic application and refusals with serialized writes", and the ticket-13 shape it blesses is exactly this, so it is conformant — but the optimistic staleness guard §9.2 relies on (the supersession refusal) protects only superseding sweeps. Plain appends, `open-issue`, and event commands have no staleness detection at all.
+- **No fsync or directory sync.** `rename` gives atomic visibility, not durability; a crash can lose the whole write (not corrupt it).
+- `resolve-conflict` aliases the caller's array into the snapshot (`:717`, `evidence: command.evidence`) where `retract-capture` copies it (`:759`, `[...command.evidence]`) and `applySweep` uses `structuredClone` (`:590`). This is the one mutable-aliasing hole, and it is exploitable — see the probe under the refactor-queue note.
+- `confidence: string` with only a non-empty check (`:57`, `:196`). Spec §5 says confidence is "qualitative, never a scalar-for-everything"; the type accepts `"0.93"`. The prohibition is prose-only.
+- `normalizedPayloadText` (`:524`) fires only when the payload _is_ a string (`typeof value === 'string'`). §6.2 promises "a flat-record plugin gets duplicate detection free"; a flat record `{ actor: "dispatcher" }` gets no near-identical advisory at all.
+- The advisory scan is O(n²) with `deriveCaptureStatus` inside each iteration, re-run over the entire store on every sweep. (The refactor queue lists advisory-scan performance as explicitly out of scope, so this is known.)
+- `parseCaptureStoreSnapshot` casts valibot's output (`:297`) because `v.unknown()` for `value` cannot express `JsonValue`; the `isJsonValue` loop that follows is what makes the cast true, and nothing marks that dependency.
+
+## Spec discharge
+
+| Obligation                                                                                                                     | Source                    | Status                                            | Where                                                                                                                                                                                                                                                                                                     |
+| ------------------------------------------------------------------------------------------------------------------------------ | ------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Storage port harness-defined, binding-implemented, plugin-blind                                                                | §9.6 / issue 12, C1       | **Full** for the capture-store half               | `CaptureStore` interface in core (`:139`); only implementation in `binding-flue`; no plugin touches it                                                                                                                                                                                                    |
+| Port scope includes the session-log archive, archive-on-read                                                                   | §9.6 (amended 2026-08-11) | **Not** — and actively foreclosed                 | `snapshotSchema` is `strictObject({captures, issues, events})` (`:284`), so a file carrying an archive key is _rejected_. No `archive`/`sessionLog` identifier exists anywhere in `packages/`                                                                                                             |
+| Whole-sweep-atomic application, refusals, serialized writes; JSON + tmp-rename floor                                           | §9.6 (L13)                | **Full** in-process; **partial** across processes | `applySweep` all-or-nothing (`:537-539`); `local-capture-store.ts:14,61-73`                                                                                                                                                                                                                               |
+| No stored status; envelope status derived at read time                                                                         | §5, C3                    | **Full**                                          | `deriveCaptureStatus` (`:457`); tests assert `'status' in capture === false`                                                                                                                                                                                                                              |
+| Envelope carries id, evidence spans, epistemic status, confidence, value-XOR-absence, alternatives grouping, one `supersedes`  | §5 / CONTEXT.md           | **Full** structurally                             | `:53-90`. Adds `dedupKey` as a stored field, which §5 sanctions as a concept and the parser keeps honest by re-deriving it (`:283`)                                                                                                                                                                       |
+| Dedup key content-derived, epistemic status excluded                                                                           | §5, §8.3                  | **Full**                                          | `captureDedupKey` (`:416`); test at `test:45`                                                                                                                                                                                                                                                             |
+| Value XOR absence, exactly one                                                                                                 | §5, invariant 9           | **Full** — genuinely deterministic                | `contentSchema` uses two `strictObject`s in a union (`:209`), so `{value, absence}` matches neither; test at `test:96`                                                                                                                                                                                    |
+| Six absence states, `not-mentioned` excluded                                                                                   | §5.1                      | **Full**                                          | `ABSENCE_STATES` (`:4`) has exactly six, no `not-mentioned`; test at `test:116`                                                                                                                                                                                                                           |
+| Epistemic status is the one legal enum, no `stated` drift                                                                      | §5                        | **Full** in the type; **weak** in maintenance     | five values (`:13`), no `stated`; but the enum is unused by the validators                                                                                                                                                                                                                                |
+| Provenance required; `defaulted`/`external-lookup` cite a declared default or documented transformation instead of a user span | §5, §9.4, C5, invariant 1 | **Full**, arguably over-tight                     | The proposal union (`:63-84`) makes evidence and `basis` mutually exclusive via `strictObject`, so a `defaulted` capture cannot _also_ carry a span. Spec says "instead of", which reads as permitting but not requiring exclusivity — the code makes it structural. (Inferred over-tightening, low harm) |
+| Spans anchor only on true user / user-affordance-payload entries                                                               | §9.4, §6.2                | **Partial — declaration only**                    | `source` is a two-value picklist (`:206`). Nothing checks that the pointed-at entry _is_ a user entry; the store never sees an entry projection                                                                                                                                                           |
+| Citations resolve to true user entries (store-level refusal)                                                                   | §6.2                      | **Not**                                           | no resolution step exists; capability 8 ("read the durable entry projection", declared `absorbed` in `capabilities.ts`) is never consulted                                                                                                                                                                |
+| Harness-resolved anchoring; model cites quotes, never sequence numbers                                                         | §8.2                      | **Not** — latent contradiction                    | `EvidenceSpan` _requires_ `entryStart`/`entryEnd` from its caller. Safe only because no sweep tool exists; unmarked in code                                                                                                                                                                               |
+| Single-hop supersession over active heads; refusal doubles as stale-session guard                                              | §8.4, §9.2                | **Full**                                          | `:561-582`; refusal carries `currentHeadIds`; test at `test:203`                                                                                                                                                                                                                                          |
+| Superseded captures remain visible forever                                                                                     | §8.4, invariant 4         | **Full**                                          | append-only; test at `test:203`                                                                                                                                                                                                                                                                           |
+| `conflicting` closes only via a user-cited resolution record; bare close refused; agent-cited record refused                   | §8.5, invariant 2         | **Partial** — see holes below                     | `close-issue` refuses `conflicting` (`:684`); `resolve-conflict` requires every span `source === 'user'` (`:726`); parser enforces both (`:334`, `:325`)                                                                                                                                                  |
+| Retraction is an explicit user-cited event naming no successor; the only path to `retracted`                                   | §5                        | **Full**                                          | `RetractionEvent` (`:112`) has no successor field; test at `test:392`                                                                                                                                                                                                                                     |
+| Issues stored with typed vocabulary plus origin, references, can-default; namespaced to producer                               | §6.3, invariant 6         | **Partial**                                       | all seven types (`:21`), all three attributes (`:94`), origin variant harness/plugin+namespace. But `origin` is a self-declared command parameter — nothing authenticates the producer                                                                                                                    |
+| Advisories computed, ephemeral, never stored, never blocking                                                                   | §6.3, §6.2                | **Full**                                          | returned in the result value, never in the snapshot; test asserts `events` empty                                                                                                                                                                                                                          |
+| Near-identical-payload duplicate detection for flat-record plugins                                                             | §6.2                      | **Partial**                                       | string-valued payloads only (`:524`)                                                                                                                                                                                                                                                                      |
+| Sweeps apply whole or refuse whole                                                                                             | invariant 7               | **Full**                                          | test at `test:96`, plus the binding test                                                                                                                                                                                                                                                                  |
+| Retries semantically idempotent, and re-sweeps can repair omissions                                                            | invariant 5, §8.3         | **Full** in design; **partly tested**             | content-keyed dedup makes omission-repair automatic; no test drives the mixed old+new re-sweep                                                                                                                                                                                                            |
+| Testing strategy: generation-first, invariants as fast-check properties, `fc.commands` model-based sequences                   | §14.4                     | **Not**                                           | 14 hand-written examples, no `fast-check`, no generators, no replay driver. Invariants are named in test titles but witnessed by single cases                                                                                                                                                             |
+| Confidence qualitative, never a scalar                                                                                         | §5                        | **Not enforced**                                  | bare non-empty string                                                                                                                                                                                                                                                                                     |
+| Completion derived, never a gate                                                                                               | §9.5                      | Out of scope here                                 | no completion machinery in this branch                                                                                                                                                                                                                                                                    |
+| Issues 3, 8 (projection loss, equivalent projection)                                                                           | §14.1                     | Out of scope                                      | no `project`                                                                                                                                                                                                                                                                                              |
+
+**Contradictions worth stating outright.**
+
+1. **The snapshot schema forecloses the session-log archive.** §9.6 is explicit that the port's scope is "the capture store plus the session-log archive" and that the milestone-one local store "holds the session-log archive alongside captures, issues, and events". `snapshotSchema` is a `strictObject`, so adding the archive later is a breaking format change plus a parser change, not an extension. Meanwhile `packages/binding-flue/src/index.ts`'s header claims the package "owns the storage-port implementation (spec §9.6)" — true of the capture-store half, false of the archive half, with no marker.
+2. **`resolve-conflict` rejects `user-affordance-payload` evidence** (`:726`, pinned by `test:283-297`). §8.5 says "the true user's utterance", which supports this reading — but §5.1/C4 rules that a structured tap _is_ transport-explicit user input, and §9.4 lists user-affordance-payload alongside true-user for capture evidence. Consequence: a user who resolves a conflict by tapping a choice strip cannot close it. That is a defensible strict reading, but it is an adjudication the branch made silently, and it interacts with the unclosable-conflict holes below.
+3. **The evidence-range ordering rule exists at one of three sites.** `entryEnd >= entryStart` is checked in `validateProposal` (`:447`) only — not in `evidenceSpanSchema` (`:200`), therefore not on persisted snapshots, and not on `resolve-conflict` or `retract-capture` evidence. A reversed range is refused in a capture proposal and accepted in a resolution record.
+4. **CONTEXT.md vocabulary is respected**, with two additions and one absence. `basis: { type: 'declared-default' | 'documented-transformation' }` coins a field name for what the spec describes in prose only — fine, but it is now envelope vocabulary that the glossary does not contain. And the phrase "storage port" appears nowhere in the code: the type is `CaptureStore`, so a newcomer grepping the glossary's term finds nothing.
+
+## Write-time tiering assessment
+
+Against penciled item 7's three tiers:
+
+**Deterministic tier — one of three checks present.**
+
+- _Quoted excerpt appears verbatim in the pointed-at entry range_: **absent**, and not merely unimplemented — architecturally unreachable from here. The store's only inputs are the snapshot and the command; it has no entry projection, and `packages/` contains no anchoring code at all (grep for `excerpt`/`anchor`/`entryStart` outside `capture-store.ts` returns nothing). The capability that would supply it (capability 8, "read the durable entry projection with provenance-discriminating entry kinds", `capabilities.ts` id 8, `absorbed`) is declared and unused. Since §5 puts quote-to-entry resolution "exactly once, at sweep application", this check's natural home is precisely the seam this branch built — and it was left empty.
+- _Anchors only on true user / affordance-payload entries_: **declared, not verified.** The `source` picklist makes the claim typed; nothing tests it against reality. §9.4 promises that on Flue this is "mechanically enforced, since signals appear structurally non-user in the entry projection". That enforcement does not exist.
+- _`explicit` requires at least one span_: **present and structural.** `explicit` occurs only in the union branch that carries `evidence: minLength(1)` (`:222-225`), so an explicit capture without a span is unrepresentable rather than merely refused. This is the tier-1 check the branch genuinely earns.
+
+**Semi-mechanical tier — entirely absent.** No lexical containment between excerpt and payload, no "does the quote support the value" check of any kind. The nearest neighbor, `normalizedPayloadText`, compares _two captures' payloads to each other_, not a payload to its own evidence — a cross-capture equivalence heuristic, not a support check. Penciled item 7's own example (a quote reading "every week or two" cannot support a payload of "10 days") would pass this store without comment.
+
+**Residue tier — correctly located, but two messages dress tier-3 and tier-1's declaration as guarantees.** The store does carry interpretation uncertainty as labels and issues and never claims to have verified interpretation fidelity. But two refusal strings assert facts the code did not establish:
+
+- `invalid-envelope`: _"A capture must have valid provenance and exactly one value or absence."_ The XOR half is genuinely mechanical. "Valid provenance" means: a non-empty excerpt string, positive integers, and a `source` label the caller chose. Nothing about provenance was validated.
+- `parseCaptureStoreSnapshot`: _"${event.type} events must cite the true user's utterance."_ (`:325`) The check is `source === 'user'` on a self-declared field. The message states a verified fact about the world; the code checked a string.
+
+This is the tier-1 dressing penciled item 7 warns about, in its mildest form — messages rather than mechanism. The fix is cheap (say what was checked) and worth doing before any consumer starts quoting these strings to a model, because a model reading "valid provenance" will not go looking for the verification that is missing.
+
+**FE-1405's envelope-friction question, answered from the code.** Epistemic status is **strictly capture-scoped, and the type system makes per-field status unrepresentable** — not merely unmodelled.
+
+- `epistemicStatus` is a single top-level field on the capture (`:65-84`), and it is the _discriminant_ of the proposal union: it selects which provenance shape the capture must carry. `explicit | inferred | tentative` ⇒ `evidence` required, `basis` forbidden; `defaulted` ⇒ `basis: declared-default` required, `evidence` forbidden; `external-lookup` ⇒ `basis: documented-transformation`. Because each branch is a `v.strictObject`, a capture cannot carry both `evidence` and `basis`. So the exact case FE-1405 names — actors stated explicitly, duration inferred by the interviewer, in one activity capture — has **no legal shape**: it would need one span-backed field and one inference-backed field in the same envelope.
+- The payload half is `{ value: JsonValue }` — opaque, with no annotation slot. A plugin could smuggle per-field status inside the payload, and there are two reasons that misfires. First, §6.2 already names payload-smuggled envelope semantics as the plugin-`validate` smell. Second and sharper: the payload is inside `captureDedupKey` (`:425-428`) while `epistemicStatus` is deliberately outside it. Smuggling status into the payload therefore moves it _into_ capture identity, so revising one field's epistemic reading would mint a fresh dedup key and apply as a brand-new capture — silently, with no supersession — which is precisely the behavior §5 excludes status from the key to prevent. The idempotence design and the smuggling workaround are in direct opposition.
+- The only envelope-legal expressions of mixed status are: split into one capture per status (which pushes granularity policy into the plugin's payload design, and §6.2 already flags compound payloads as making supersession lossy), or use `alternativeGroup` to hold several readings of the same evidence — which models competing interpretations, not differently-grounded fields.
+
+So the friction FE-1405 predicted is real, and the code answers it more sharply than the spec prose does: this is not a missing field but a load-bearing structural coupling between status and provenance shape. Confirming Lu's filing note — it is kernel canon (spec §5), and any amendment touches the union, the dedup key's exclusion rule, and the tier-1 `explicit`-requires-span guarantee together.
+
+## Commit-message backfill
+
+```
+FE-1390: Make capture history append-only and transactional
+
+Captures, issues, and events now accumulate in one snapshot that is
+only ever appended to. No record is mutated or removed, and every
+status the rest of the system reads — active/superseded/retracted,
+open/closed — is computed from supersession links and stored events at
+read time rather than written down. Corrections therefore cannot erase
+what they correct, and a re-swept range cannot double-capture: capture
+identity is a content key over evidence and payload with epistemic
+status excluded, so revising the reading of unchanged evidence has to
+supersede an active head explicitly instead of overwriting it quietly.
+
+The command surface is one pure function from snapshot plus command to
+either a new snapshot or a typed refusal, which is what makes atomicity
+structural: a partial sweep has no representation, so one invalid
+proposal refuses the whole batch and nothing is written. Refusals carry
+the facts a caller needs to retry — a stale supersession names the
+current active heads. The Flue binding implements the storage port over
+that function in the shape the skeleton proved: a JSON file, tmp and
+rename, writes serialized per path, and a parse on every read that
+re-derives dedup keys and rejects forking or cyclic supersession
+histories.
+
+Tests drive the public command function and the local store on disk.
+Harness invariants 2, 4, 5, 7, 9 and 10 (spec §14.1) each get a named
+case, and the binding suite proves a reopened store reads back what was
+written, that concurrent writes serialize, and that a refused sweep
+leaves the previous file intact.
+
+Two halves of the port are deliberately not here: the session-log
+archive (§9.6), which the current strict snapshot schema will have to
+widen for, and any check that an excerpt really appears in the entries
+its pointer names — pointers are trusted as given, and no harness code
+consumes the store yet.
+
+Co-authored-by: Cursor <cursoragent@cursor.com>
+```
+
+## PR body
+
+Adds the capture store — the durable, session-independent truth of a target-document — as an append-only snapshot of captures, issues, and events, with every status derived at read time instead of stored. Writes go through one pure command function that returns either a whole new snapshot or a typed refusal, so a sweep applies completely or not at all, and the Flue binding implements the storage port over it with a JSON file, tmp-and-rename, and per-path serialized writes. Capture identity is content-keyed with epistemic status excluded, which makes re-sweeps idempotent and forces revised readings through explicit supersession. The session-log-archive half of the storage port (spec §9.6) and write-time verification of evidence pointers are not in this branch, and nothing consumes the store yet.
+
+## Where the refactor queue's critique lands
+
+I probed each claim rather than taking it on faith (script at `/private/tmp/claude-501/-Users-lunelson-Code-hashintel-brunch-lite/0c0505fd-18df-4b61-90e0-4fdb7906c109/scratchpad/probe.ts`, run against the real module).
+
+**Confirmed: conflicts with no legal close, two distinct ways.**
+
+1. _A `conflicting` issue with exactly one reference is born unclosable._ `open-issue` checks only that references are non-empty and exist (`:637-647`). Then `close-issue` refuses with `resolution-required` (`:684`), and `resolve-conflict` cannot succeed at any arity: `resolutionSchema` requires `loserCaptureIds` to be non-empty (`:277`), while the accounting check requires `citedCaptureIds.length === issue.references.length` (`:727`) — winner plus at least one loser is ≥ 2, references is 1. Probe output: `close-issue → resolution-required`, `resolve(winner only) → invalid-resolution`, `resolve(A vs B) → invalid-resolution`. The snapshot stays readable, so this is a permanent open issue, not a corruption. Refactor-queue commit 7 is the right fix.
+2. _A well-formed two-capture conflict becomes unclosable the moment either side is superseded or retracted._ Nothing in `applySweep` or `retract-capture` consults open issues, and `resolve-conflict` requires every cited capture to be `active` (`:730`). Probe: with an open conflict over {A, B}, a sweep carrying `supersedes: A` **succeeds**, after which `close-issue` refuses and `resolve-conflict` refuses. Retracting A instead succeeds too, with the same result. This is refactor-queue commit 8's premise, and it is worse than an unclosable-issue bug: the contradiction disappears from the active set with no resolution record citing the user, which is exactly what harness invariant 2 forbids. Invariant 2's letter is enforced (a conflict never closes without a user-cited record) while its spirit is bypassed (the conflict is silently resolved by correction, and the issue is left as permanent litter).
+
+**Confirmed: list-shaped data treated as a set.** `references` is validated as an array, never de-duplicated (`:258`, `:637`), but the resolution accounting compares by length plus membership rather than set equality (`:727-729`). Probe: a conflicting issue with `references: [A, A]` accepts a resolution naming winner A and loser **C, an uninvolved capture** — and C derives `superseded` afterwards. So duplicate references let a resolution supersede a capture that was never in conflict. Refactor-queue commit 6 is precisely aimed.
+
+**Confirmed, but by a different mechanism than the doc names: "a command can return success for a snapshot the next read rejects."** I could not construct this from rule divergence — I tried to reach a forking or cyclic supersession graph (which only the parser checks) through legal commands, and the active-head requirement plus the same-batch `targetedCaptures` guard (`:572`) blocks every route I found. The realizable path is the aliasing hole instead: `resolve-conflict` stores the caller's `evidence` array by reference (`:717`) where `retract-capture` copies it (`:759`) and `applySweep` clones (`:590`). Probe: accept a resolution, then mutate the caller's span to `source: 'agent'`; the stored event mutates with it, and `parseCaptureStoreSnapshot` on the result throws `Invalid type: Expected ("user" | "user-affordance-payload") but received "agent"`. The durable file is exposed only through a narrow window (`#writeFile` awaits `mkdir` before stringifying), but the in-memory snapshot handed back to the caller — and any store implementation that holds one — is fully exposed. This belongs in the queue and is not currently in it.
+
+**Confirmed: three separate rule sets, and they are not ordered.** Each site enforces something the others do not. Command-time only: evidence-range ordering (proposals alone), and cited-capture activity in resolutions. Parse-time only: dedup-key freshness, id uniqueness per family, forking and cyclic supersession graphs, and — notably — nothing about range ordering or capture activity. So the parser accepts snapshots the command surface would have refused (a reversed span; a resolution over an already-superseded loser), and no test asserts that a successful command result round-trips through the parser. Refactor-queue commits 5 and 9 close exactly that, and commit 9 is the one that would have caught the aliasing hole.
+
+**One claim I would add to the queue's capture-store half.** The parser's strict snapshot schema (`:284`) makes the session-log archive a breaking format change rather than an extension, while `packages/binding-flue/src/index.ts` already claims to own §9.6. Either the schema should gain the archive slot or the claim should be scoped, before a second store implementation copies the narrower shape.
+
+**One more brittle oracle worth noting.** `packages/binding-flue/test/local-capture-store.test.ts:46` asserts the no-stored-status property as `expect(JSON.stringify(persisted)).not.toContain('"status"')` — a text proxy for a structural fact, which will fail the moment any plugin payload legitimately contains a `status` field. Same family as the source-text proxies the refactor queue's verification half objects to.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-findings-2026-08-11.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-findings-2026-08-11.md
new file mode 100644
index 00000000000..9ce39739fb1
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-findings-2026-08-11.md
@@ -0,0 +1,67 @@
+# Findings — Yannis/Dora/Lu meeting, 2026-08-11
+
+Source: [transcript](../../../reference/yannis-dora-lu-transcript-2026-08-11.md). Prep doc:
+[expert-meeting-prep-2026-08-11](expert-meeting-prep-2026-08-11.md). Participants: Lu, Yannis
+Zachos (Petrinaut team), Dora Ma (PM, "Speaker 4").
+
+## Facts established (map-shaping)
+
+1. **There is no in-house expert-interviewing practice to elicit from.** Yannis's modelling
+   method is literature review + the Petrinaut AI assistant + Claude prompt
+   reverse-engineering; even at the Clarion engagement "we didn't actually do any pattern
+   elicitation." The prep questions (first-five-questions, dependency order, motif catalogue,
+   completeness checks) remain unanswered — and the person expected to answer them says
+   Claude's answers would be as good as his. Consequence: elicitation-strategy content must be
+   sourced from literature + experiment, not internal expertise. PRO-98's checklist has no
+   in-house oracle.
+2. **The SDCPN-as-hypothesis stance is now shared, on the record.** Dora: "I also don't know
+   if it should always be an STCPN. Sometimes it might be an SPN or a CPN if that is the best
+   way to model something." Lu (unrebutted): "We're poor on things that showcase STCPNs as
+   such… building that kind of a model is actually pretty sophisticated." The PRO-99
+   "showcase SDCPN features" criterion vs. the use-case pool tension is aired.
+3. **Net-as-projection got independent confirmation.** Yannis, unprompted, enumerated
+   elicitable content with no net home: conservation-law constraints, business
+   logic/regulatory constraints ("we wouldn't want to simulate behaviors that are strictly
+   prohibited"), theoretical-vs-actual process (manuals vs. event logs — a
+   conformance/compliance framing), data feeds.
+4. **The incumbent baseline is a live product question.** Yannis's opening challenge:
+   "there's already an AI assistant within Petrinaut doing what you're describing." Lu's
+   positioning answer (preserve for roadmap narrative): the assistant asks _for a net_ —
+   collapsing elicitation into representation; the elicitor works upstream of the formalism
+   and projects later. Dora's proposal: run the control — see what vanilla Claude/Petrinaut
+   AI achieves on an elicitation-shaped prompt, and "fill any missing gaps rather than doing
+   it from scratch."
+5. **Architecture-for-iteration is a stated requirement.** Dora: "can we build an architecture
+   whereby we can update the way the elicitor asks these questions easily, rather than
+   committing from the get-go?" Lu: yes. (Direct validation of the pack/plugin +
+   hash-pinned-directive design.)
+
+## Ideas surfaced (ticket/fog seeds)
+
+- **Priming from documents before questioning** (Yannis + Lu): ingest brochures, org charts,
+  even facts about the interviewee; "squeeze the most out of what we've got without asking
+  questions"; then ask fewer, more consequential questions. Elevates FE-1337-adjacent
+  ingestion from post-Sept garnish toward demo-relevant strategy.
+- **Confidence-directed questioning** (Yannis): maintain an under-the-hood representation
+  with per-part confidence; question where confidence is lowest. (Echoes the kernel's
+  issue/epistemic-status machinery.)
+- **Question-tree / MoE lines-of-questioning with pruning** (Yannis) — Lu's caveat: real
+  interviews don't strictly tree; early questions are open-ended; branches map poorly.
+- **Question batching UX** (Dora, citing Nora's Zulip feedback): batch 3–4 questions, think
+  ahead while the user answers; Lu's **horizon problem** caveat: batched questions go stale
+  once earlier answers deviate — batch small, prefer independent questions. (Kernel spec's
+  questionnaire-chaining §7.2 anticipated this; staleness is new design input.)
+- **Capture the one-shot's assumptions** (Dora): even a one-shot net generation should have
+  its assumptions extracted and stored as a graph to build on.
+- **Average/best/worst-day questioning** (Lu+Yannis, converged): "describe a bad day / what
+  keeps you up at night" reaches black-swan knowledge that exists only in heads, not event
+  logs; escalate to constructed hypothetical scenarios when the person isn't forthcoming.
+- **The evaluation problem, re-aired** (Lu+Dora): honest elicitations are slow, generative at
+  every step, non-repeatable (same person answers differently by the hour) — comparisons need
+  a proxy. (The kernel spec's testing strategy — model-as-offline-respondent, frozen replay
+  fixtures, mutation library — is the existing candidate answer; feeds PRO-104.)
+
+## Commitments made in the meeting
+
+- Lu: write this up and "produce something that indicates the next questions" (= the map).
+- Lu: put up a Notion doc with the prepared questions for Yannis to answer/comment async.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-prep-2026-08-11.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-prep-2026-08-11.md
new file mode 100644
index 00000000000..c10fdbe8121
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/expert-meeting-prep-2026-08-11.md
@@ -0,0 +1,150 @@
+# Expert meeting prep — cyber-physical process models & elicitation
+
+2026-08-11. Prep for meeting with modelling-expert colleague. Purpose: stabilize and bound
+understanding of the "cyber-physical" domain, and capture how an expert modeller would
+himself elicit, from a domain expert, what he needs to build a faithful model.
+
+Sources synthesized: Brunch — September Plan (Notion), Production Process Scheduling
+Optimization (Notion, the one Spec'd exemplar), Petri net business use cases (Notion page +
+database), SDCPN Library — Ideas (inbox), SAILS public report (inbox).
+
+---
+
+## A. What already seems stable (don't spend meeting time re-deriving)
+
+1. **In-house "SDCPN" decomposes into feature axes**, not one monolith. PN class: Timed ·
+   Stochastic · Deterministic · Statically vs Dynamically Typed/Coloured · Cyclic/Acyclic.
+   PN features: subnets · concurrency · execution conflict resolution · resource contention ·
+   live data feed. A given use case draws the axes it needs (the scheduling exemplar is
+   statically-coloured timed, in deterministic and stochastic variants).
+2. **A consistent anatomy template** for describing a candidate system: physical layer /
+   cyber layer / events / continuous state / emergent behaviour (SDCPN Library doc), echoed
+   in the DB schema (Physical system, Cyber component, Phenomena).
+3. **What a "done" model definition looks like** (the scheduling exemplar's table of
+   contents): one-liner → problem & context → system sketch (physical + cyber) → why this
+   formalism → formal problem statement (Given / Decide / Maximise) → places, transitions,
+   colours → questions the model answers → data requirements → limitations → validation bar.
+4. **The elicitation-heavy inputs are the unwritten ones.** Scheduling doc, verbatim: "the
+   family taxonomy, ramp scrap structure and penalty weights are the three things nobody has
+   written down, and all three are load-bearing." Pattern: taxonomies, cost/penalty weights,
+   unwritten constraints ("products that 'always' run on line 2").
+5. **Validation notion**: reproduce a historical period's actual behaviour from recorded
+   inputs before counterfactuals mean anything; closed-form sanity checks (net with failures
+   off must reproduce the spreadsheet formula).
+6. **The net evaluates; it does not decide.** Optimisation/analysis layers sit on top and are
+   Petrinaut-team scope. Also: output may be a _model_ (description of a system) or a _plan_
+   (actions to undertake) — FE-1330 names both.
+7. **"Cyber" in practice so far = enterprise data systems** (ERP, MES, historian, CMMS,
+   scheduling layer), i.e. the sources/consumers of model data — not exotic control loops.
+8. **SAILS framing**: the net is a candidate _world model_ in the gatekeeper triad (world
+   model + safety specification + verifier); tacit knowledge is a named deployment barrier;
+   practitioners distrust what they can't edit or trace.
+
+## B. Meeting shape (suggested, ~55 min)
+
+1. **Bound the domain** (5–10 min) — his operational definition of "cyber-physical control
+   system"; where the modelled-system boundary sits.
+2. **Role-play elicitation** (15 min) — he interviews you (or narrates) for one scenario he
+   knows cold; you capture questions _and their grounding_.
+3. **Completeness & cross-examination** (15 min) — his definition-of-done and his traps.
+4. **The SDCPN feature ladder** (15 min) — which expressive capabilities a system must _earn_
+   and what evidence earns each.
+5. **Meta** (5 min) — what he wishes he'd asked earlier in past engagements; where interviews
+   fail.
+
+## C. Sharpened questions
+
+### C1. Bounding the domain
+
+- "Define 'cyber-physical control system' the way you'd defend it to a referee. What's an
+  example of a system that is _not_ one, that a layperson might think is?"
+- "In the scheduling spec, the 'cyber' side is ERP/MES/historian. Is the cyber layer always
+  just the data estate, or does it sometimes include an existing automated controller whose
+  behaviour must itself be modelled?"
+- "Where does the model boundary sit relative to the controller being designed? (SAILS: the
+  net is the _world model_, the AI is the _controller_.) When you model, are you modelling
+  the plant, the controller, or both — and how do you decide?"
+
+### C2. His elicitation questions, with grounding (the PRO-98 seed)
+
+- "You're in front of the plant's master scheduler, blank page. What are your first five
+  questions — and for each, which model element does the answer feed?" (Structure? colour?
+  rate? constraint? objective?)
+- "What's the _dependency order_ of your questions — what does an early answer change about
+  what you ask next?" (An elicitor needs interviewing policy, not just a checklist.)
+- "Which answers do you ask for as _numbers_, which as _distributions_, which as _stories_?
+  When do you ask for 'a specific bad day' rather than an average?"
+- "How do you elicit things nobody wrote down — taxonomies, penalty weights, unwritten
+  constraints? What phrasings actually work on a domain expert?"
+- "How much of a net do you assemble from recurring motifs (queue/buffer, resource pool,
+  failure/repair, changeover, inspection) versus invent fresh? Could you enumerate your motif
+  catalogue?" — _high leverage: if nets are mostly motif instantiation, elicitation can
+  interview against a motif catalogue instead of synthesising free-form structure._
+
+### C3. Completeness criteria (definition-for-purpose-of-modelling-and-simulation)
+
+- "What do you check before declaring 'I can now build this'? Is there a minimal category
+  set — structure/topology, types & colours, rates & distributions, initial marking,
+  objective & penalties, constraints (hard/soft/unwritten), data bindings, validation data?"
+- "Is completeness _question-relative_ — complete only relative to the questions the model
+  must answer (every spec'd use case carries a 'questions the model answers' table)? Should
+  an elicitor therefore elicit the questions first?"
+- "PRO-99 wants 'a written list containing all the facts necessary to make the net.' Is a
+  fact-list the right form, or is the real criterion behavioural (can reproduce a historical
+  trace)?"
+- "What would you accept as evidence that a model definition elicited by an AI interviewer is
+  complete? What's your acceptance test?" (Feeds PRO-104 benchmarks.)
+
+### C4. Cross-examination (gap & weak-assumption tests)
+
+- "What are your standard traps? e.g.: token conservation ('where do these entities come
+  from and where do they go?'); boundary probing ('what did you deliberately leave out?');
+  conflict policy ('when two X compete for one Y, who wins, by what rule?')."
+- "How do you catch _data-vs-decision conflation_? (Scheduling doc: supplier-delay belongs in
+  the Materials guard, deliberate idling belongs in `wait` — same field, opposite meanings.)"
+- "How do you detect an _assumed_ quantity that should be _emergent_? (Line throughput is the
+  canonical case: the spreadsheet assumes it; the net derives it.)"
+- "What contrastive cases do you use when two interpretations of the expert's words diverge?
+  Give a real example." (Maps to our disambiguate-style questioning.)
+- "When domain experts disagree with each other, what do you do — and what should an AI
+  interviewer do?"
+- "What arrives late and forces rework? What question, asked in week one, would have
+  prevented it?"
+
+### C5. The SDCPN feature ladder (which systems _earn_ which capability)
+
+For each capability: **what evidence in a domain expert's answers tells you the system needs
+it — and what tells you it doesn't?**
+
+| Capability                         | Earning question (draft — have him correct)                                                                                                                         |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Timed                              | Do durations matter to any question the model must answer?                                                                                                          |
+| Stochastic                         | Does variability change a decision, or would nominal values give the same answer? Which distributions, from what data?                                              |
+| Coloured (static)                  | Do token attributes change behaviour (durations read from token colour), or is one token type enough?                                                               |
+| **Dynamically coloured**           | Does continuous state evolve _between_ events and feed back into event timing/guards (degradation, temperature, battery)? Or can it be discretised into thresholds? |
+| Guards / conflict resolution       | Is there a decision rule at contention points, and is it policy (elicitable) or optimisation (external)?                                                            |
+| Subnets / templating               | Are there repeated structural units that must stay in sync?                                                                                                         |
+| Live data feed / marking injection | Will the model be re-run from observed current state (reactive use)?                                                                                                |
+| Cyclic                             | Steady-state operation vs one-shot horizon?                                                                                                                         |
+
+- "My working hypothesis: _most systems don't earn the full SDCPN stack, and a simpler PN
+  variant — or a different structure entirely — is often the better model._ Where am I wrong?
+  Which capability is more often needed than people expect, and which is prestige?"
+- "What can a Petri net of any variant _not_ capture that you routinely need? (Goals,
+  rationale, spatial layout, continuous control laws…) Where do you record those?"
+
+### C6. Meta / practice
+
+- "In your last three modelling engagements, how much calendar time was elicitation vs
+  model-building vs validation?"
+- "If you had an AI interviewer that produced the fact-list + provenance for you, what would
+  you _not_ trust it with?"
+- "What makes a natural-language summary of a net trustworthy to a domain expert?" (FE-1335's
+  deterministic-summary requirement.)
+
+## D. Capture instructions (for after)
+
+Meeting notes → `docs/inbox/` with the usual timestamped name. The outputs feed, at minimum:
+the elicitation checklist (PRO-98), reference-use-case criteria (PRO-99), the
+SDCPN-earning/abstraction-ladder question, and the motif-catalogue hypothesis. These become
+resolved fog or ticket seeds when the map is charted.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/grilling-inputs-2026-08-12.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/grilling-inputs-2026-08-12.md
new file mode 100644
index 00000000000..eaa2bb1fa40
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/grilling-inputs-2026-08-12.md
@@ -0,0 +1,88 @@
+# Grilling inputs — carried forward from the 2026-08-11/12 session
+
+State capture ahead of the HITL tickets (FE-1361/62/63/64). Everything here is _input to
+decisions_, not decisions. Sources: the three research resolutions (gists on FE-1358/59/60,
+full findings in [`../research/`](../research/)), the talkthrough discussion, and
+[Dora's PRO-98 checklist](https://www.notion.so/hashintel/3b93c81fe0248019a7beda9bb31df2c8).
+
+## 1. Destination trend (Lu, 2026-08-12)
+
+The arc is trending toward **a spec for elicitation plugins generally, or at least the
+cyber-physical one, which will inform the general one**. The research supports an inversion:
+most interviewing-strategy value is _generic_ (harness / strategy-quiver layer, now
+literature-sourced); the CPS plugin is a comparatively thin domain shell (facet catalogs +
+projection). Candidate shape: a generic elicitation-plugin spec (pack model + strategy quiver +
+completion machinery) plus a CPS instantiation that stresses it. To be ratified in grilling —
+would amend the FE-1357 destination wording.
+
+## 2. The facets/motions schema (Lu's meta-methodology, mapped in the talkthrough)
+
+Organizing schema for the generic strategy layer, imported from Lu's software-dev skill systems:
+
+- **Facets** (declarative; what a _plugin_ fills in):
+  - _entities & types catalog_ — what to capture (≈ Robinson's component/detail tables; colour
+    types; ElicitationPack concept declarations)
+  - _clusters/figures/motifs_ — repeating patterns to query against (≈ the small parameterized
+    quiver **with variant selectors**; note the per-object-type-template counter-evidence)
+  - _quality/completeness/value-add heuristics_ — when the model beats the incumbent flat
+    representation (≈ emergence/degeneracy triad, question-relative completeness, VUT earning
+    test)
+- **Motions** (procedural; _harness-generic_):
+  - _slice motions_ — one case end-to-end first (tour question, CDM walkthrough); slice before
+    sweep = the literature's overview-before-contrived-probes
+  - _sweep motions_ — make one property hold across one stratum (every activity a duration,
+    every contention point a policy); **mechanically checkable → harness-computed gap facts →
+    typed issues**
+  - _impact/leverage order_ — objectives-first is the maximal instance; source-router the
+    economic form; propositions-per-task-minute the measurement; NB elicitation leverage has a
+    human-budget term (rapport/fatigue) that dev leverage lacks
+- The motion vocabulary appears **original** (no KA/RE/conceptual-modelling equivalent found) —
+  testable in the baseline: motions-prompted vs facet-checklist-prompted elicitor.
+- Maps to Principle v2: facets = anchors/shapes; motions = procedure for mechanism.
+
+## 3. Dora's checklist — adopt/validate split
+
+**Adopt** (convergent with research, independently arrived): purpose as core-interview beat 2
+("the purpose determines which ontology categories are high-priority"); the **Maps-to column's
+"lives only in the intermediate representation"** entries (policies, penalty weights,
+regulatory refs, rationale) — PM-side confirmation of net-as-projection _and_ of the term IR;
+workflow-sketch slice; best/average/worst-day scenarios; "rules nobody wrote down"; user
+identity as elicitation-shaping metadata; jargon-avoidance phrasing table (with fix #3 below).
+
+**Validate before adopting** (each with its home):
+
+| #   | Claim                                                              | Problem                                                                                            | Warrant                                          | Home                       |
+| --- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- | ------------------------------------------------ | -------------------------- |
+| 1   | Static 3-tier category ordering                                    | Contradicts her own purpose-conditional prose; literature says ordering derives from purpose       | Robinson/Sargent objectives-first                | pack design (spec)         |
+| 2   | "Steps become transitions; states between become places"           | Factoring is a modelling act; Petrinaut has **no duration field** (a timed step ≠ one transition)  | representational-bias literature + format survey | FE-1364                    |
+| 3   | "Typical / fastest / slowest" phrasing                             | = min/mode/max triple; naive fit published ~69% error                                              | Holm & Barra 2011; IDEA/SHELF quantile forms     | pack design                |
+| 4   | Stop signal "last 3 questions didn't change the model"             | = representational stability, a premature-termination rule (professionals stopped at 57% coverage) | Browne & Pitts 2004                              | completion contract (spec) |
+| 5   | Session initiation: in-Petrinaut, one-shot-then-iterate            | Presumes the vehicle                                                                               | open decision                                    | FE-1362                    |
+| 6   | Blanket 3–4 question batching                                      | Tension with depth-of-probing finding + horizon problem                                            | LLM-interviewer lit; two-phase scoping           | pack design                |
+| 7   | "Stochastic differential equations" for place dynamics             | Petrinaut dynamics are deterministic ODEs                                                          | format survey                                    | minor fix                  |
+| 8   | (Absence) no provenance/absence/contradiction/validation machinery | Checklist implicitly assumes a harness that supplies all of it                                     | Petrinaut survey: none exists in the stack       | differentiation narrative  |
+
+A draft comment for Dora covering items 1–4 was prepared 2026-08-12 (Lu to deliver).
+
+## 4. Standing tensions for the grilling sessions
+
+1. **Objectives-first vs. element-mapped questioning** — if accepted, the elicitor's opening
+   phase elicits _the questions the model must answer_, and that table = scope + completion +
+   validation criterion (spec-level commitment).
+2. **Depth vs. batching** — breadth phase batchable, probe phase sequential; argue the trade,
+   don't assume it.
+3. **Functional motifs vs. per-object-type templates** — decides part of the IR shape (FE-1364).
+4. **Differentiation** — the incumbent already interviews; the demo's claim must be what a
+   prompt-in-a-panel cannot do (durable capture, provenance, completion accounting, IR).
+
+## 5. Frontier state (2026-08-12)
+
+- FE-1361 baseline: three-condition design + mistake-questionnaire instrument on the ticket;
+  v0 prompt should encode objectives-first, probe catalogs, quantile elicitation.
+- FE-1362 vehicle: unblocked; all inputs in (survey, voice tiers, "entirely new" stance,
+  Dora's claim #5); Kostandin back ~2026-08-18; demo 2026-09-17/18, format TBD.
+- FE-1363 use case: needs Dora + Yannis; earning tests (VUT, colour-as-folding) give the
+  technical criterion; candidates truck-fleet / cold-chain / scheduling.
+- FE-1364 IR: blocked by FE-1363 only; inputs: quiver-with-variant-selectors, what-lives-
+  outside-the-net list, Dora's Maps-to column, format facts (scenario-or-dead-net, code-string
+  generation, no timed transitions).
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/open-questions-elicitation-design-2026-08-11.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/open-questions-elicitation-design-2026-08-11.md
new file mode 100644
index 00000000000..f433aba9777
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/open-questions-elicitation-design-2026-08-11.md
@@ -0,0 +1,65 @@
+# Eliciting process models: open questions (known unknowns)
+
+## Why this document
+
+The September goal is a demo in which an agent interviews a domain expert and elicits a process model of a cyber-physical system, projected to a Petri net in Petrinaut. For the eliciting agent to do that job well, it needs more than a questionnaire or a checklist, it needs **strategies and policies**: what to probe for, in what order, how to test answers, how to map answers to model outputs, how to know when it has enough, etc.
+
+Below are some questions to help inform that design, and which are currently known unknowns. Even partial answers, anecdotes, or "read this paper / talk to this person" pointers are valuable. Please comment inline.
+
+---
+
+## 1. How does model-building actually start?
+
+1.1. When you (or anyone you've observed) build a model of an operational system, what are the actual **inputs**? Documents, data extracts, conversations, site visits, literature — in what proportion?
+
+1.2. Standing in front of the person who runs the system — the master scheduler, the fleet manager — what are the **first five questions**, and what model element does each answer feed (structure, types/colours, rates, constraints, objectives)?
+
+1.3. What is the **dependency order** of questions — which answers do you need upstream because they change what you ask next?
+
+1.4. Which answers do you want as **numbers**, which as **distributions**, which as **stories/scenarios**? When might you ask for "a specific bad day" instead of an average?
+
+## 2. How do you reach what nobody wrote down?
+
+2.1. Taxonomies (e.g. product families), penalty weights, unwritten constraints ("that product always runs on line 2") are repeatedly called out as load-bearing _and_ undocumented. What **phrasings actually work** to elicit them from a domain expert?
+
+2.2. The "describe a bad day / what keeps you up at night" question reaches knowledge that exists only in heads (black-swan intuitions absent from event logs). What other questions of this type do you know or use?
+
+2.3. When the person isn't forthcoming, does escalating to **constructed hypotheticals** ("imagine that while you're doing Y, you get a call that Z…") work in practice? What are the failure modes?
+
+## 3. Structure: invented or assembled?
+
+3.1. How much of a net is assembled from **recurring motifs** — queue/buffer, resource pool, failure/repair, changeover, inspection — versus invented fresh? Could we **enumerate the motif catalogue**? _(Why: high leverage. If nets are mostly motif instantiation, the elicitor can interview against a catalogue — "which of these patterns is present, with what parameters?" — instead of synthesising free-form structure.)_
+
+3.2. Are there motifs specific to _cyber-physical_ systems (sensing/actuation loops, degradation processes, live data feeds) beyond the operations-research standards?
+
+## 4. When are you done?
+
+4.1. What do you check before declaring "**I can now build this**"? Is there a minimal category set — structure/topology, types & colours, rates & distributions, initial marking, objective & penalties, constraints (hard/soft/unwritten), data bindings, validation data?
+
+4.2. Is completeness **question-relative** — complete only with respect to the questions the model must answer? (Every spec'd use case carries a "questions the model answers" table.) Should the elicitor therefore elicit _those questions_ first?
+
+4.3. Is a **written fact-list** (per PRO-99: "all the facts necessary to make the net") the right completion artifact, or is the real criterion behavioural — the model reproduces a historical trace, or the expert _recognizes_ simulated pathologies ("yes, that's our Friday pile-up")?
+
+4.4. When a simulation matches the naive calculation (spreadsheet) **too well**, what do you suspect first — a genuinely simple system, or a missing coupling? What do you check?
+
+## 5. How do you cross-examine?
+
+5.1. What are your standard **traps and tests** for gaps and weak assumptions? Candidates already visible in our documents: token conservation ("where do these come from / go?"), boundary probing ("what did you deliberately leave out?"), conflict policy ("when two X compete for one Y, who wins, by what rule?"), data-vs-decision conflation, assumed quantities that should be emergent (line throughput).
+
+5.2. When two interpretations of the expert's words diverge, do you use **contrastive cases** ("in situation A would you do X or Y?")? Real examples welcome.
+
+5.3. When domain experts **disagree with each other**, what do you do — and what should an agent do?
+
+## 6. Which systems earn which formalism?
+
+6.1. For each capability on the ladder — timed → stochastic → coloured → _dynamically_ coloured → guards/conflict policy → subnets → live data feed — **what evidence in a domain expert's answers tells you the system needs it**, and what tells you it doesn't?
+
+6.2. Working hypothesis to attack: _most systems don't earn the full SDCPN stack; a simpler PN variant (or another structure entirely) is often the better model._ Where is this wrong? Which capability is needed more often than people expect, and which is prestige?
+
+6.3. The September goal statement says "showcase SDCPN features." Our current use-case pool is thin on systems that genuinely strain dynamic colouring. Which candidate use case best _earns_ the showcase?
+
+## 7. What lives outside the net?
+
+7.1. The corpus already names elicitable content with no canonical home in the net: decision policies at conflict points, objective functions and penalty weights, goals and rationale, regulatory/business constraints, conservation laws, theoretical-vs-actual process (manuals vs. event logs), data-feed bindings, validation criteria. **What else belongs on this list?**
+
+7.2. If the elicited description is an **intermediate representation** of which the net is one projection — what does that representation's schema need to hold, at minimum, for the September use case?
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/penciled-directions-2026-08-14.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/penciled-directions-2026-08-14.md
new file mode 100644
index 00000000000..7353069b898
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/penciled-directions-2026-08-14.md
@@ -0,0 +1,27 @@
+# Penciled directions — legibility session 2026-08-14
+
+Pencil list (Lu + agent), deliberately not yet ticketed. Each item names a direction and the action that would firm it up; blockquoted **Reflection** notes are the agent's editorial commentary, distinct from the penciled facts. Tracker state as of writing: FE-1401 (sweep), FE-1402–1405 (rehearsal chain), FE-1406 (quiver), FE-1407 (failure catalogue).
+
+1. **Schema as forcing function — techniques compile into machinery via payload interiors.** A technique expressed as prompt guidance depreciates; the same technique expressed as a field shape appreciates: a quantity field _typed_ as quantile-triple (p10/p50/p90) forces quantile elicitation because the store refuses a point estimate. FE-1405 is therefore not just "define the shapes" — it is the compilation step from layer 2 to layer 3, and each interior field should be audited for "which technique does this field force?" → Action: add this framing to FE-1405 when it starts; the audit's per-technique entries name the candidates.
+
+2. **Plugin manifest sketch (Lu).** Top-level plugin properties, largely serializable (YAML-ish): licenses / techniques / movements (slice_moves, sweep_moves) / scopes_and_motifs / rabbit_holes / failure_modes / smells / lenses / checks (tool-using) / tools / ontology / schema. Maps onto the three prompt mechanisms + machinery + ontology — the layer model as a manifest. Gaps noticed at pencil time: **completion contract / anchor declaration is absent**; absence-handling policy and evidence policy are envelope-level but the plugin may need declared postures. Ownership sort needed per key (vocabulary-ownership rule): generic licenses and failure modes are quiver/harness-side; domain instances are plugin-side. → Action: candidate structure for plugin-spec authoring; test-fit against the smallest honest plugin (spec §11.3) and Gherkin before CPS.
+
+   > **Reflection:** The manifest works because it serializes the layer model — licenses/techniques plus the attention-shaped keys (scopes*and_motifs, lenses, smells) are the three prompt mechanisms; checks/tools are machinery; ontology/schema is FE-1405. `rabbit_holes` is quietly the most novel key: anti-guidance — where \_not* to dig — which nothing in the imported literature covers and which the baseline's budget-burning behaviors argue is real. The ownership sort will split single keys in two: "you may press a busy expert" is an envelope-vocabulary license (quiver-side) while "press on tint-qualification claims" is the same key plugin-side. And the test-fit order matters because a manifest that only fits the thick case is a thick-case schema, not a plugin contract.
+
+3. **Mode oscillation.** Two core modes (domain/objectives capture; systematic extraction) with oscillation between them as sub-scopes open — re-entering objectives mode inside a new sub-area. Slice-and-trace bias in mode 1 (+ entity/type identification), sweep bias in mode 2. Grounded in the import itself: task-based techniques yield fragments that need an overview to hang on. The harness's settlement/sweep vocabulary and re-entry briefing already support oscillation; guidance must present modes as postures, not a state machine — conversation stays primary. → Action: name the oscillation explicitly in FE-1403's movement guidance; check FE-1402's contract behaves sanely under re-opened scopes (completion is monotone over captures, not over conversation phases).
+
+   > **Reflection:** The slice-and-trace / sweep-bias mapping matches how the settlement vocabulary already works — veins close, ranges settle, sweeps harvest — another instance of the experiment and the architecture cutting at the same joints without coordination, which is soft confirmation of both.
+
+4. **Activation probes as a card-economy instrument.** Before writing any technique card, probe whether the name alone activates the content: ask the substrate model cold to describe "premortem", "Critical Decision Method", "ACTA knowledge audit", etc. If the probes reproduce from the name, the card collapses to name + when-to-use (cheap, model-portable); if not, the card must carry content (expensive, depreciating). Bano specifically: niche academic — name-activation unreliable, and its content targets novice mistakes the model doesn't make; low elicitor value, scoring-side value only. → Action: run activation probes as step one of FE-1403; record per-technique results next to the mechanism type.
+
+5. **Incorporation rubric for the audit's technique inventory** (Lu's axes + one): value confidence (evidence grade × baseline verdict) · invocation economy (card cost, from the activation probe) · trigger accuracy (can Detects be stated crisply — the hardest slot) · mechanism type (license/technique/attention). Techniques failing trigger accuracy stay in reference docs, not cards — a card that can't say when it fires is sprawl. → Action: apply as FE-1403's selection gate before card drafting.
+
+   > **Reflection:** Trigger accuracy already has a home in the card form — it _is_ the Detects slot. Prediction: the "reaching what nobody wrote down" family will struggle there most, because the literature says _what to do_ at length and almost nothing about _when_; expect that family to yield fewer cards and more reference-doc residue than its richness suggests.
+
+6. **Super-map question (Lu).** Cross-cutting concerns are emerging (quiver ownership, envelope amendment adjudication, the three-layer mapping) that neither the closed kernel map nor the September-scoped FE-1357 owns. Options at pencil stage: merge into one super-map vs. charter a third, harness-lane map post-18-Aug vs. widen FE-1357's destination. FE-1357's horizon ends end-September by design, which argues against widening it. → Action: decide after the 18 Aug integration discussion; FE-1405's envelope-friction clause and FE-1406 are the immediate pressure points either way.
+
+7. **Write-time provenance checks, layered honestly** (from the discussion of the write-time argument): deterministic tier — quoted excerpt must appear verbatim in the pointed-at entry range; anchors only on true user / affordance-payload entries; `explicit` status requires at least one span. Semi-mechanical tier — does the quote _support_ the payload value (lexical containment catches crude hardening: "every week or two" contains no "10 days"); model-graded verification beyond that. Residue — interpretation fidelity, handled by status labels + issues, never claimed as mechanically guaranteed. → Action: this tiering belongs in the storage-port/store work (FE-1390 review lens) and the plugin-spec's validator section.
+
+   > **Reflection:** The design discipline across the tiers is a single rule: never let a tier-3 claim dress as a tier-1 guarantee. The store may _carry_ interpretation-fidelity uncertainty (status labels, issues) but must never present it as mechanically verified — that would be silent hardening reproduced at the architecture level.
+
+8. **Machinery inventory per target-domain** (sketch): harness-owned domain-free (span verification, value-xor-absence, status requiredness, sweep idempotence, computed coverage, completion runner, no-progress detection); plugin-contributed domain-typed (payload validators with deep requiredness, reconcile checks, projection validate — dead-net detection, scenario presence; conflict-detection ops). Gherkin's cheap wins: parse validity, step-lexicon binding (spec'd), every-rule-has-an-example (anchor check), same-Given/When-different-Then contradiction detection — mechanically detectable conflicts. → Action: feed the plugin-spec's validator catalogue; Gherkin examples are the tracer-priced proof of the pattern.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/research-patterns-audit.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/research-patterns-audit.md
new file mode 100644
index 00000000000..a9b18bad17a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/notes/research-patterns-audit.md
@@ -0,0 +1,92 @@
+# The research patterns, in plain language
+
+> A plain-prose audit of the patterns, principles, and instruments this effort has imported from the research literature — the vocabulary that appears in the v0 prompt, the baseline readout, the IR design, and the map as compressed tokens. Each entry says what the thing is, where it comes from and how strong the evidence is, and how this effort uses it. The underlying research documents ([`elicitation-strategy-literature.md`](../research/elicitation-strategy-literature.md) and the [worker report](../research/re-interviewing-literature-worker-report.md)) remain authoritative; this is a review-reading rendering. The audit pass surfaced eight strain points — places where an import is softer, drifted, or more house-made than our gists state — recorded in the appendix at the end of this document and on FE-1401 (seventh accrual).
+
+The effort mined five research fields for guidance on how an AI interviewer should elicit a process model: knowledge acquisition (the old expert-systems tradition of getting knowledge out of specialists), requirements engineering interviewing, simulation conceptual modelling, structured expert judgment (the decision-analysis discipline of getting honest numbers from experts), and the brand-new literature on LLM-conducted interviews. What follows covers roughly thirty imports, grouped by the job they do.
+
+## Ordering the interview
+
+**Objectives first.** The single most load-bearing import. The instinct when eliciting a model is to open with structure — what are the stages, what flows where. The simulation-modelling literature says the opposite: start with what decisions the model must inform and what questions it must answer, because everything else is derived from that. Scope, level of detail, and which quantities matter are consequences of the questions, not independent facts. Robinson's conceptual-modelling framework orders the work this way explicitly (objectives, then outputs, then inputs, then content), and Sargent's verification-and-validation tutorials state the underlying reason: a model's validity can only be judged relative to the questions it exists to answer. Evidence grade: this is the settled normative position of the field's standard references, not an empirical effect size. In this effort it is the v0 prompt's category 1 and its "open with it" instruction, the IR design's completion-anchor pattern, and the reason the CPS interview opens on objectives. The baseline complicated it in an encouraging way: the bare model opened objectives-first _without being told to_, so the ordering has migrated from teachable technique to model disposition.
+
+**Question-relative completeness.** The companion principle: an elicitation is "done" relative to the questions the model must answer, not relative to a fixed checklist of topics. Sargent states it directly — if a model answers several questions, validity must be determined for each. The broader requirements-engineering literature agrees from the negative side: the IEEE and ISO requirements standards define completeness circularly ("contains everything pertinent") and contain no stopping rule at all, and the theoretical treatments (Zave and Jackson; Leveson) conclude that absolute completeness is unattainable and only purpose-relative completeness is even definable. In this effort this became the completion contract: the set of objective-type captures defines what coverage means, which is why FE-1402 can exist at all. The baseline validated the need brutally — neither condition could end, because nothing adjudicated doneness.
+
+**The two-phase architecture.** Open with a short, bounded overview that maps the domain and the objectives, then switch into structured, systematic modes for the bulk of the work — and do not linger in open conversation. The grounding is Hoffman's knowledge-acquisition yield studies, which counted informative propositions per minute across techniques: open unstructured interviewing yields well at first and then collapses (from roughly 1.6 propositions per minute in the first hours to a long-run average near 0.13), while structured interviewing sustains roughly 1 per minute and task-based techniques 2–3. The honest reading is not "structured is ten times better" but "unstructured decays and structured doesn't"; either way the prescription is the same. A supporting result from a four-method comparison: task-based techniques are efficient but yield fragments, so they need a prior overview interview to hang the fragments on. In this effort this is the v0 prompt's "slice, then sweep" instruction — walk one concrete case end to end, then sweep each category systematically — and the reason the interview does not stay conversational.
+
+**The bounded opener.** A small, directly stealable device from ACTA (next section): open the task walkthrough by asking the expert to break their process into _between three and six steps_. The bound is the point — it fixes the level of abstraction instead of inviting arbitrary detail. Used in the v0 prompt's walkthrough instruction in spirit; a candidate for verbatim adoption in the pack cards (FE-1403).
+
+## Reaching what nobody wrote down
+
+**The Critical Decision Method (CDM).** A cognitive-psychology interviewing procedure, developed by Gary Klein's group for studying real decision-making, and the strongest of the imported probe catalogues. The expert narrates one specific real incident, the interviewer builds a timeline of it, and then sweeps the timeline with deepening probes — what were you seeing, what were your goals at that moment, what other options existed, what rule were you following, how would you have briefed a relief officer, what would a novice have gotten wrong. A separate later pass varies the incident hypothetically ("what if X had been different?"). The probes were imported verbatim from the IHMC practitioner manual. Three of them map directly onto model constructs: "what rule was being followed?" elicits the decision policy a net needs at every contention point; the relief-officer briefing extracts the state variables that matter (close to asking what the marking must record); the options-and-errors probes yield guards and exception paths. In this effort CDM is ready pack content for FE-1403; the baseline did not test it directly (neither condition ran an incident timeline), which makes it one of the untested imports.
+
+**The ACTA knowledge audit.** Applied Cognitive Task Analysis, from Militello and Hutton — a deliberately simplified cognitive task analysis for practitioners, built as a sequence: task diagram, then knowledge audit, then simulation interview. The knowledge audit is eight probes designed to surface knowledge experts have but never volunteer: past-and-future (seeing where a situation came from and is heading), the big picture, noticing what others miss, tricks of the trade, improvising, self-monitoring, anomalies ("can you remember a time you knew something was amiss?"), and information difficulties ("when did the data point one way and your judgment another?"). Two details carry as much value as the probes. First, a universal follow-up after every answer: "how would you know this? what cues are you relying on? how would this be hard for someone less experienced?" — the expert–novice contrast used routinely as a cue extractor. Second, probe 8 is, for this project, a data-binding question in disguise: it surfaces where the ERP or historian is systematically wrong. Evidence grade: the catalogue is verbatim from published applications; ACTA's own validation is practitioner-grade, not experimental. Ready pack content for FE-1403; untested in the baseline.
+
+**The premortem, and prospective hindsight.** The team's instinctive "tell me about a bad day" question turns out to be a rediscovery of a measured effect. Mitchell, Russo and Pennington (1989) found that asking people to explain an event _as if it had already happened_ — prospective hindsight — increased correctly-identified causes by about 30% compared with asking what might happen. Klein operationalized this as the project premortem. The elicitation form used here: "It's a year from now and this line just had its worst month on record. Tell me what happened." This beats "what keeps you up at night?" because it licenses concrete causal narration instead of anxiety report. Evidence grade: one well-cited lab result from 1989 plus a widely-used practitioner method; treat the 30% as indicative, not a law. Pack content for FE-1403.
+
+**The question typology.** A 2021 requirements-engineering paper (Zaremba and Liaskos) assembled a cross-disciplinary typology of interview question forms — around 35 types across dimensions of time, content, form, style, and probing style. The effort imported it less as a taxonomy than as a phrasebook. The individually valuable moves: the **consistency probe** ("you said earlier that X, but then you told me Y — how do you explain that?"), which an LLM is unusually well placed to execute because it holds the whole transcript; the **clearinghouse probe** ("what have I not asked that is important?"), used as a closing ritual before any completion claim; the **negative balance question** ("you seem very efficient — do you remember occasions when problems slowed you down?"), built to counteract the tendency to describe the idealized version of the work; and the teachback family (restating an interpretation for confirmation). The typology also names the anti-patterns — leading probes, forced choices — for the do-not-do list. All of this is pack-card material; the baseline showed the bare model already does consistency probing and teachback unprompted, so FE-1403's redundancy verdicts will likely retire some of these.
+
+**Laddering, card sorting, and triadic elicitation.** The knowledge-engineering toolkit for eliciting taxonomies — the "what kinds of things are there, and what distinctions matter" questions. Laddering here means the laddered grid: move down ("can you give examples of X?"), across ("what alternatives to X are there?"), and up ("what do these have in common?") through the domain's class structure, plus two quietly powerful probes — "how can you tell it is X?" (which elicits the operational recognition criteria nobody wrote down) and "what is the key difference between X and Y?" (which turns a flat list into a typed taxonomy). One correction the research pass made: this is _not_ the "why is that important?" laddering from consumer research — the two traditions share a name and nothing else. Triadic elicitation (from Kelly's repertory-grid tradition) presents three items and asks how two are alike and one differs, surfacing the attributes an expert uses without naming them. In this effort these feed the taxonomy card in FE-1403 and ground the CPS `entity-type` kind's interview strategy. Untested in the baseline.
+
+**Work-as-imagined versus work-as-done.** The framing for unwritten rules, from resilience engineering (Hollnagel): what procedures say happens differs systematically from what happens, and the gap is normal, not deviant — people trade thoroughness for efficiency as a matter of course. The practical consequence is a reframing of the question: not "what are the undocumented rules?" (which invites denial) but "where does the written procedure not survive contact with the day?" (which invites description). The same distinction arrives independently from two other imported directions: the say–do problem in requirements engineering ("people know how to do many things that they cannot describe… don't believe the answers"), and process mining's de jure versus de facto models (below). Three fields converging on one distinction is the strongest kind of confirmation this review found. In this effort it became the `prescribed | practiced` source-regime attribute in the IR — the design decision that there is one model with a regime tag, never two parallel models, and that a prescribed/practiced divergence is recorded as an ordinary conflict issue, because such divergences are elicitation gold. The baseline validated the underlying premise: both conditions surfaced real unwritten rules (the tint veto, the lateness hierarchy) only under deliberately-shaped probes.
+
+**Anchored hypotheticals, and hypothetical bias.** Can you ask an expert "what would happen if…"? The literature splits usefully. CDM endorses hypotheticals — but always anchored to a real incident already narrated, varying a case rather than inventing one. The stated-preference literature supplies the warning for the free-floating kind: when people answer about imagined situations, they systematically overstate (a meta-analysis found hypothetical answers exceeding real ones by a median factor of 1.35, with severe skew). The mechanism transfers to elicitation: an unanchored "what would you do if" returns the expert's _policy_ — the idealized self — rather than their practice, fluently and confidently, which makes it hard to detect. The mitigations: anchor to a narrated incident first, and ask what the expert would be _looking at_ rather than what they would decide. In this effort: the scenario-probe style the v0 prompt prescribes for conflict points ("two lines need the crew at the same moment — what actually happens?"), and a precondition attached to the hypothetical-escalation card in FE-1403.
+
+**Value-focused devices for objectives and weights.** Penalty weights and trade-off rates are almost never written down and cannot be asked for directly ("what weight would you give lateness?" produces noise). The imported toolkit is Keeney's: ask for a wish list with constraints removed, name a particularly good and particularly bad outcome and what makes each so, enumerate shortcomings of the status quo, ask what other stakeholders would want. For the weights themselves, swing weighting: have the expert compare the swing from worst to best on each attribute rather than state a number. One honest note on provenance: the baseline's standout weight excavation — condition 2's betting-framed questions that produced "Meridian's penalty is a cliff, everyone else's is a slope" — used a device (willingness-to-bet framing) that none of the imported sources prescribe and the v0 prompt never mentions. The model improvised it. It has a respectable ancestry in probability elicitation, but as pack content it is currently uncredited folklore; FE-1403 should either adopt it deliberately or note it as model disposition.
+
+## Getting numbers you can trust
+
+**The quantile protocol, and the case against min/mode/max.** The flagship quantitative finding. Simulation practice commonly elicits a minimum, most-likely, and maximum for a duration and fits a triangular distribution to them. A published comparison against measured data (emergency-department length of stay) found this habit overstated the true mean by about 69 percent — while a distribution that read the same expert's middle value as a _mean_ rather than a mode landed within 1 percent. Two mechanisms: experts' stated middle values behave like means, not modes, and a triangular distribution structurally cannot represent the long right tail real service times have. The prescription: elicit quantiles instead — "typical?", "one time in ten, worse than?", "one time in ten, better than?" — and never fit a triangular to a volunteered three-point estimate. Evidence grade: the 69%/1% contrast is a single conference study in one domain; the quantile prescription itself is independently the settled format of the whole structured-expert-judgment field (the TU Delft studies, EFSA guidance), so the practice rests on more than the headline number. In this effort: v0 prompt category 4, the IR's quantity attribute ("quantile-elicited, never min/mode/max"), and the baseline's cleanest technique delta — condition 1 fell into exactly the warned-against triangular; condition 2 executed quantiles throughout. This entry also supplies the citation the IR document currently lacks for its prohibition.
+
+**The IDEA four-step question.** The most transplantable script in the structured-judgment literature, from research on reducing expert overconfidence (Speirs-Bridge et al.): ask for the lowest plausible value, then the highest, then the best guess, then "how confident are you that your interval captures the true value — give a number between 50 and 100 percent." The order matters: interval before best guess, because leading with the best guess anchors the interval too narrow. The confidence step lets intervals be standardized across experts afterward. Evidence grade: solid — the format measurably widens intervals toward honesty. In this effort the v0 prompt adopted the quantile idea but _not_ the IDEA script: its "typical, then one-in-ten" phrasing leads with the central value and drops the calibration step. That simplification worked in the baseline, but the divergence between what the docs call "the quantile/IDEA protocol" and what the prompt actually says should be resolved deliberately when FE-1403 writes the card.
+
+**The clairvoyant test.** Ron Howard's discipline from decision analysis: a quantity is well-defined only if a clairvoyant — someone with perfect knowledge but exercising no judgment — could answer it. "Cycle time" fails until you say what's in and out of it (does it include setup?). Cheap and constantly applicable: much apparent disagreement between experts is definitional, not factual, and the test separates the two. In this effort: the definitions-first rule in the outside-the-net checklist, and the prescribed first move when two sources conflict. Untested in the baseline.
+
+**Handling expert disagreement, and Cooke's classical model.** When experts disagree, the literature's recommendation cuts against instinct: do not seek consensus, and above all do not average silently, because averaging manufactures false certainty and destroys the most valuable signal in the interview. Two formal traditions exist — behavioral aggregation (facilitate toward what a rational impartial observer would believe) and mathematical aggregation (Cooke's classical model: score experts on seed questions with known answers, then weight them by calibration). The empirical record favors performance weighting decisively, but the method needs prepared seed variables, so it is not available to a live interviewer. What the effort imports instead is the format (quantiles) and the discipline (preserve disagreement as a first-class contested fact, with both positions and both reasonings recorded). In the IR this is why conflicts become typed issues rather than merged values, and why resolution requires an explicit user-cited record. The baseline touched this only lightly (condition 1 refused to arbitrate a within-pack dispute and designed a measurement to settle it — exemplary behavior, already dispositional).
+
+**The VUT earning test, and colour as a folding.** Two results that turn "which formalism features does this system need?" from taste into tests. The Kingman/VUT relation from queueing theory says queue time scales with variability times utilization times service time — so stochastic modelling is _earned_ when utilization is high or variability is large, and genuinely unnecessary when both are low and the question concerns a mean. Conversely, coloured tokens add no expressive power at all: a coloured net with finite colour sets unfolds mechanically into a plain net, so colour is compactness and maintainability — an engineering convenience, not a capability a system can "need." Together these retired the effort's earlier "formalism ladder" framing (which ranked features by prestige) in favor of per-capability evidence tests, and they ground the showcase criterion that chose the truck-fleet case: the one thing that genuinely earns dynamic per-entity state is a continuous quantity gating a threshold-crossing question. Also derived from VUT: the "too-good agreement" checklist — when the simulation matches the spreadsheet, check utilization first; agreement is suspicious only when utilization is high.
+
+## Structure, motifs, and the model cross-examining itself
+
+**Motif catalogues, and the Börger reduction.** The hypothesis that operations are assembled from recurring structural motifs (queues, buffers, shared resources, changeovers, failure/repair) is well supported — but the literature's sharpest lesson concerns the catalogue's _shape_. The workflow-patterns tradition grew from 20 patterns to 43 to 126, and Börger's unanswered critique showed the growth had no empirical foundation (pattern frequency data mostly measures what tools support, not what plants do) and that the 43 control-flow patterns reduce to eight parameterized schemes. The design consequence: build a small quiver of parameterized schemes with explicit variant selectors, never a long menu — and never record a motif by name alone, because pattern names are stable while their semantics drift. The verdict the effort adopted: a motif catalogue is well supported as an _interview scaffold and gap-detector_ ("you described a buffer but not what happens when it's full") and poorly supported as a _structure generator_. In this effort: the motif quiver lives in the ElicitationPack as question guidance only — scaffold yes, generator no — and the IR deliberately has no motif vocabulary in the payload. One open caution the research flagged: the best-verified real asset-management net decomposes per object type (each type bundling its own degradation-inspection-maintenance lifecycle), not into orthogonal functional modules — a decomposition question the CPS design should settle deliberately.
+
+**Motifs as obligations, and the exception sweep.** The usable core of the catalogue idea: each motif carries obligatory questions. A buffer obliges capacity and full-behavior (block, spill, or divert); a resource pool obliges size, claim discipline, and a contention rule; failure/repair obliges a trigger type, a repair-time distribution, and a repair resource. The workflow exception-patterns study adds a ready sweep: for each of five exception types (work-item failure, deadline expiry, resource unavailability, external trigger, constraint violation), ask what happens to the work item, to the case, and what recovery runs — with the empirical note that tooling almost universally ignores resource-unavailability exceptions, so elicitation must ask explicitly. Pack content for FE-1403; the ramp-scrap miss in the baseline is exactly the class of hole an obligation sweep exists to catch.
+
+**Soundness as cross-examination.** The most implementable finding in the review: the formalism generates its own interview questions. Workflow-net soundness — every reachable state can still reach completion, completion is clean, no transition is dead — converts mechanically into questions ("you described this step but nothing can trigger it; when does it actually happen?"). A shared input place _forces_ the contention question; token conservation asks for the invariants; Robinson's factor-versus-response distinction mechanically detects a mis-scoped quantity (throughput offered as an input). None of this requires interviewing skill — the structure obliges the questions — which is precisely the differentiation-by-machinery argument. In this effort this is ProjectionPack territory (`validate` plus issue generation) and the readout's finding 6 in reverse: both baseline artifacts contained structural bugs that no soundness check existed to catch.
+
+## Knowing when to stop
+
+**The four cognitive stopping rules.** From requirements-engineering research on when analysts actually stop eliciting (Pitts and Browne): two judgment rules (stop when belief in sufficiency crosses a threshold; stop when the latest information adds too little) and two representation rules (stop when a mental checklist is exhausted; stop when your internal model of the problem stops changing). The empirical finding: analysts stop too soon — in one study, professional analysts captured 57 percent of available requirement categories before stopping — and the rule an LLM naturally implements (stop when the representation stabilizes) is one of the two associated with premature stopping. The imported counter-measure: make stopping criterion-based (the category set plus the questions table), never stability-based, and fire the clearinghouse probe before closing. The baseline extended this finding in a direction the literature had not documented: at the frontier, the failure inverts from stopping too soon to being _unable to stop at all_ — condition 1's pleasantry loop and condition 2's phantom second session are new entries for the stopping-failure catalogue, not instances of the documented one.
+
+**The assumptions document and the structured walkthrough.** From Law's simulation-practice tutorials: the output of the information-gathering phase is an _assumptions document_ — not a model — and its acceptance test is social: project it and walk it bullet by bullet with the experts, because pre-circulating for silent reading demonstrably does not produce the collective challenge that catches errors. Robinson adds the load-bearing distinction between assumptions (limited knowledge — an elicitation backlog) and simplifications (deliberate abstraction — design decisions to defend), which have different lifecycles and must not be merged into one "limitations" section. Scope decisions get recorded in include/exclude/justification tables, where every exclusion carries a reason. In this effort: the walkthrough is the ancestor of the interpretation-render affordance (show the captured state, get correction), the assumptions/simplifications split maps onto epistemic status, and the include/exclude tables are candidate ProjectionPack output shapes. The baseline validated the register idea beyond expectation (both conditions kept good ones unprompted) while exposing what registers cannot do — which is the machinery argument.
+
+**Behavioral completion criteria.** Sargent's validation battery supplies the _final_ completion tests, ordered after the fact-list walkthrough: historical replay (build from part of the data, test against the rest), the Turing test (can people who know the operation distinguish model output from system output — "yes, that's our Friday pile-up" is an established technique with statistical treatment, not a soft heuristic), and face validity (the weaker, earlier cousin). Condition 2 independently proposed a 26-week historical replay as its validation plan, which is this import arriving as disposition.
+
+**What does not transfer: saturation.** Qualitative research's saturation thresholds ("~70% of themes appear in the first six interviews") concern theme discovery across a population of informants, not sufficiency of one system description, and were explicitly ruled out as a stopping criterion. Worth keeping visible because saturation is the stopping heuristic an unguided reasoner is most likely to reach for.
+
+## Scoring the interviewer
+
+**The Bano taxonomy and its questionnaire.** The effort's principal scoring instrument. Bano, Zowghi, Ferrari, Spoletini, and Donati observed 110 students in 28 role-played requirements interviews and catalogued 34 interviewer mistakes in seven categories — question formulation (vague questions was the most frequent mistake overall, in 21 of 28 groups), question omission (no probing questions: 11), interview order (no closing summary: 19; bad opening: 15), communication, analyst behaviour, customer interaction, and teamwork. The taxonomy ships with an operationalized Likert questionnaire ("The analyst asked vague questions", 1–5), which has become the de facto evaluation instrument for machine interviewers — LLMREI evaluated against it directly. The baseline scored both conditions with it and both dramatically outperformed the student cohorts, which produced the audit's most important instrument-level insight: the taxonomy was built from _novice human_ failures, and frontier-model failures are simply elsewhere (stopping, silent hardening, coverage blindness). The instrument still earns its keep as a floor check and as a mutation library for adversarial testing, but a frontier-elicitor failure catalogue is a genuine open gap this effort will have to fill itself. A related finding from the same research line: training fixes the mechanical mistakes (no summary, no probing) and barely touches the behavioural ones — practice, not instruction, is the active ingredient — which is an early version of the disposition/technique split the baseline landed on.
+
+**The LLM-interviewer studies.** Four systems shaped the baseline's design. **LLMREI** (an LLM elicitation chatbot evaluated against the Bano questionnaire) made a similar number of mistakes to human interviewers but _ended interviews too readily when users signalled impatience_ — one of the two documented stopping failures. **ReqElicitGym** (an evaluation environment with simulated users) found the opposite: models "overwhelmingly lack effective stopping criteria" and exhaust their turn budgets — and also that the best models elicit under a third of implicit requirements, and that effective questions arrive _late_ in dialogues. The baseline's impatience probe plus turn budget exists precisely to make both failure modes observable in one run; both reproduced, in novel forms. **Shen, Singhal and Breaux** showed that follow-up questions generated _with the mistake taxonomy in the prompt_ beat human interviewers' questions in blind preference — direct evidence that taxonomy-guided prompting works, which is the mechanism FE-1403's cards rely on. **Görer and Aydemir** found LLM-generated interview scripts lack depth — breadth is cheap, probing is the differentiator. And a fine-tuning cautionary tale from LLMREI: training on novice-interviewer transcripts failed outright, degrading the model — worth remembering whenever "just fine-tune on transcripts" comes up.
+
+**Mental models emerge late.** From a large study of AI-conducted qualitative interviews (381 interviews, with behavioural follow-up eight months later): interviewees' first responses differ systematically from their later ones, with mental models surfacing consistently late in the conversation. Three consequences the effort adopted: depth of probing is the differentiator, not breadth; question batching is suspect because it optimizes throughput on first-pass answers, the least valuable kind; and the first-response-versus-post-probe content delta is a measurable evaluation proxy that needs no ground-truth model — one of two literature-grounded candidates for the evaluation-proxy problem (the other being propositions-per-minute yield rates). The v0 prompt's compromise — batch two to four survey questions, never batch depth — is a deliberate softening of this finding, and the baseline suggests the compromise landed well (condition 2's batching read as an improvement over condition 1's opening barrage).
+
+**Ambiguity as a resource.** From Ferrari, Spoletini and Gnesi's interview studies: an ambiguity in the conversation is not just a defect but a trigger — each detected ambiguity marks a spot where the speaker's mental model and the listener's diverge, so each is a follow-up question waiting to be asked, and every _undetected_ one is a missed discovery. The companion work lists the linguistic cues a listening interviewer should react to: vague terms, underspecified terms, quantifiers ("usually", "mostly"), pronouns without referents, unexplained domain terms. In this effort this grounds the v0 prompt's "probe vague quantifiers" rule and is the design seed for clarification hints in the pack; the baseline showed the disposition already present (both conditions chased quantifiers unprompted).
+
+## What data can supply, and what only the interview can
+
+**De facto and de jure models, and the source router.** Process mining's core distinction: event logs yield the de facto model (what actually happens); documents and interviews yield the de jure model (what is supposed to happen). One study provides a literal source-per-parameter table — mining supplies control flow, branching probabilities, resource pools, and processing-time distributions; interviews must supply calendars, shifts, availability, costs, priorities, and seasonality — which functions as a specification for what the elicitor should spend expert time on. Four things are structurally absent from any log and belong to the interview alone: behaviour that never touched a system (phone calls, workarounds), rationale (logs record what, never why), resource reality (part-time attention, workload-dependent speed), and the case notion — the choice of what an instance even _is_, which has no data-internal ground truth. One humbling detail from the same study: its largest residual model error traced to an _interview-supplied_ estimate, so elicited quantities need validation too. In this effort: the source-router card (before asking, decide whether a parameter is log-derivable or interview-only), the BPMN worked example's log-binding kind, and the C5 adjudication that lets mined facts enter the IR as ordinary captures with `external-lookup` status.
+
+**The generalization question.** Even a perfect log cannot settle how much never-observed behaviour the model should allow — generalization is defined against the unobserved real process, so it is irreducibly a human judgment. The interview form: "what could happen here that has never happened?" A quiet but deep import, because it marks one boundary of what any data channel can ever replace.
+
+## Appendix — strain points from the audit pass
+
+> **Editorial.** These are findings _about the imports_, produced while writing the entries above — places where a pattern resisted plain explanation because the import is softer, drifted, or more house-made than the effort's gists state. Also recorded on FE-1401 (seventh accrual); card-relevant consequences are on FE-1403.
+
+1. **"Betting questions" is not an import.** The baseline's standout excavation (C2's cliff/slope penalty weights) is credited to a technique no source prescribes; the v0 prompt says only "expect to co-construct". The method was model improvisation under prompt-directed attention — the 1→2 delta's item 5 is partly misattributed. FE-1403 should adopt the technique deliberately (decision-analysis willingness-to-bet ancestry) or reclassify it as disposition-plus-attention.
+2. **The v0 quantile script contradicts the IDEA protocol our gists equate it with.** IDEA elicits the interval before the best guess (anti-anchoring) and includes a calibration step; the v0 script opens with "typical?" and has no calibration. Baseline-vindicated once; must become a deliberate choice in the FE-1403 card.
+3. **"Structured beats unstructured ~10×" over-compresses Hoffman.** The honest form: unstructured yields well early (≈1.6 propositions/min) and decays (≈0.13 long-run); structured sustains (≈1/min). The prescription survives; the multiplier as stated does not.
+4. **The v0 batching license (2–4 grouped questions) departs from the imported anti-batching finding.** Baseline-vindicated, but recorded nowhere as a departure until now.
+5. **The premortem's "~30%" is one 1989 lab result** (student scenario experiments); Klein's operationalization carries no effect size of its own. Treat as indicative.
+6. **The 69% anti-triangular figure is a single conference study in one domain** (Holm & Barra, WSC 2011). The quantile prescription stands independently on the structured-expert-judgment line (TU Delft, EFSA); citations should say "one published comparison".
+7. **The Bano instrument's population mismatch is field-wide**: built from 110 novice students, now the de facto machine-interviewer instrument, and no successor exists in the literature — the failure catalogue (FE-1407) fills a field gap, not just a house one.
+8. **"Conflict-point centrality" is a house synthesis**, assembled from GSPN forced-conflict semantics, CDM's basis-of-choice probe, and v0 category 5 — defensible, but ours, and should be credited as such.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/petrinaut-integration-spec.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/petrinaut-integration-spec.md
new file mode 100644
index 00000000000..76cca430e50
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/petrinaut-integration-spec.md
@@ -0,0 +1,210 @@
+# Integration spec: the elicitor behind Petrinaut's chat panel
+
+**Ticket**: FE-1433 (the integration-spec issue) · **Decision record**: ADR-0004
+(`docs/adr/0004-in-petrinaut-staging-and-the-monorepo-import.md`) · **Supersedes**:
+`recommendation-demo-vehicle.md` as the September staging plan · **Evidence base**: the
+Petrinaut survey (FE-1358, `research/petrinaut-survey.md`), re-verified against
+`hashintel/hash` source on 2026-08-18.
+
+## Problem Statement
+
+The September demo must show agentic elicitation producing a working process model — durable
+capture with provenance, completion accounting, a live interpretation render, and a net that
+runs — and the 2026-08-18 meeting decided it must do so **inside demo.petrinaut.org's existing
+chat panel**, not in a separate application. Petrinaut's incumbent assistant is a stateless
+browser-resident chat over a Vercel edge proxy: it persists only a transcript and a net in
+localStorage, and has no server, no sessions, no capture store. The elicitor is the opposite
+shape: a stateful server-side agent (Pi/Flue substrate) with its own loop, tools, and durable
+storage. The problem is connecting the second to the first without rebuilding either.
+
+## Solution
+
+The brunch elicitor runs as a **remote server** built on the harness + `binding-flue`. The
+demo site swaps its `aiAssistant.transport` to point at that server; everything else in the
+panel — rendering, the diagnostics decorator, client-side tool execution — is reused as-is.
+The elicitor drives Petrinaut's editor through the **existing client-executed tool surface**
+(schemas imported from `petrinaut-core`), riding the harness's turn-suspension protocol: a
+turn ends with tool calls pending, the panel executes them, and the outputs return on the next
+dispatch. Sessions, captures, and IRs persist server-side, keyed to an opaque principal the
+site supplies from a localStorage UID. The wire contract is the AI SDK v6 UI-message-stream
+protocol, produced by a new `transport-aisdk` package that translates harness-level parts to
+stream chunks and knows nothing about Flue.
+
+## Seams
+
+One primary seam, three supporting ones — all existing except the brunch server's front door,
+which the design needs anyway:
+
+1. **The ChatTransport wire seam** (primary; the contract-test surface): the AI SDK
+   UI-message-stream protocol over HTTP/SSE. Everything brunch-side sits behind it; everything
+   Petrinaut-side sits in front of it. The panel's real behavior is verified once in the
+   adapter spike and frozen as golden fixtures.
+2. **The ask/affordance protocol seam** (`core`'s ask-protocol module, per ADR-0002 N1): the
+   external-tool round-trip protocol is tested here, substrate-free.
+3. **The storage port seam** (ADR-0002 N5): the owner key is tested as store-level refusals.
+4. **The artifact seam** (`parseSDCPNFile` / `sdcpnFileSchema`): unchanged; net validity
+   checked in CI through the pure parser.
+
+## User Stories
+
+1. As a demo.petrinaut.org visitor, I want to converse with the elicitor in the same chat
+   panel I already know, so that elicitation feels native to the tool rather than bolted on.
+2. As a demo.petrinaut.org visitor, I want the elicitor to interview me about my process
+   before building, so that the net reflects my domain rather than a one-shot guess.
+3. As a demo.petrinaut.org visitor, I want to watch the net appear and change on the canvas as
+   I answer, so that I can correct misunderstandings the moment they become visible.
+4. As a demo.petrinaut.org visitor, I want my session to survive a page reload, so that a long
+   elicitation isn't lost to an accidental refresh.
+5. As a demo.petrinaut.org visitor, I want my sessions kept private to my browser, so that
+   another visitor cannot see or alter my work.
+6. As a demo.petrinaut.org visitor, I want the elicited net to carry a scenario and run, so
+   that the interview demonstrably produced a working model, not a picture.
+7. As the demo presenter, I want the elicitor's captures and completion accounting rendered
+   live, so that the audience sees what a prompt-in-a-panel cannot do.
+8. As the demo presenter, I want to export the elicited net as a file and open it in stock
+   Petrinaut, so that the decoupling claim is made visible on stage.
+9. As the demo presenter, I want the elicitor to keep working when a model turn emits dozens
+   of mutations, so that a realistic-sized net doesn't stall the demo.
+10. As the elicitor (agent), I want Petrinaut's mutation, read, and diagnostics tools exposed
+    to me with their real schemas, so that I can build and repair nets the way the incumbent
+    assistant does.
+11. As the elicitor (agent), I want tool outputs from the browser to re-enter my loop as
+    machine entries, never as user evidence, so that capture spans only ever cite the user.
+12. As the elicitor (agent), I want to see TypeScript diagnostics after code-writing
+    mutations, so that I can validate every change without the user relaying errors.
+13. As the harness, I want the external-tool round-trip to ride the same suspension floor as
+    the ask protocol, so that one substrate capability serves both and the second-binding test
+    stays small.
+14. As the harness, I want retries and duplicate dispatches on the round-trip to be idempotent
+    (per the affordance-protocol guarantees), so that a flaky network cannot double-apply.
+15. As a brunch developer, I want the stream adapter to consume harness-level parts only, so
+    that swapping `binding-flue` for another binding never touches the wire layer.
+16. As a brunch developer, I want contract tests that drive the server exactly as the panel's
+    wrapped transport does, so that panel compatibility is provable without a browser.
+17. As a Petrinaut maintainer, I want brunch's needs expressed as generic host extensions to
+    the `aiAssistant` prop, so that my library stays elicitor-agnostic.
+18. As a HASH product owner, I want the principal abstracted so Ory identity can replace the
+    localStorage UID, so that the same server later serves the HASH app unchanged.
+19. As an infra engineer, I want the elicitor server to be an ordinary deployable in
+    `hashintel/hash` with Postgres-backed storage, so that it fits the infrastructure we
+    already run.
+20. As the operator of a public endpoint, I want per-principal rate limiting and an origin
+    allowlist, so that an unauthenticated UID cannot be farmed for free inference.
+21. As a future petrinaut-website maintainer, I want brunch-specific wiring contained at the
+    app level (as the existing Actual-mode brunch-demo route already is), so that removing or
+    evolving it never archaeology-digs through the library.
+
+## Implementation Decisions
+
+**Topology and packaging**
+
+- The elicitor server is a thin host-authored agent (spec §13) around the harness library,
+  deployed remotely; the demo site addresses it cross-origin, bypassing the site's own
+  `/api/chat` and Vercel function limits.
+- Implemented by FE-1436 (the durable AI SDK transport): package `transport-aisdk` is the
+  server end of the ui shell's reply transport. It translates
+  harness-level parts to AI SDK v6 UI-message-stream chunks, using the `ai` package for stream
+  encoding only (no provider use — inference stays on Pi's adapter layer). Depends on `core`,
+  `ai`, and `valibot` for external request validation; never on the binding or Flue. This adds
+  a `transport-*` role prefix to the §12.2
+  vocabulary (the glossary's avoided terms `adapter-*`/`wrapper-*` stay avoided). The
+  implementation and real-panel evidence are recorded in
+  `transport-aisdk-implementation-2026-08-19.md`.
+- Kernel spec amendments applied with this work, not silently: §12.2 package list gains
+  `transport-aisdk` and records the monorepo import (`@hashintel/brunch-agent`, hash
+  toolchain replacing the Bun workspace at import time); §13's shipping shape and ADR-0002 N3
+  reflect the retired demo shell.
+
+**The suspension floor and the external-tool protocol**
+
+- One substrate capability — end a turn with pending items, resume on a later dispatch with
+  per-session state intact — carries two core protocols: the existing ask protocol and a new
+  **external-tool round-trip** protocol.
+- The protocols differ deliberately: asks are singular (§7.3) and harness-slot-bound; tool
+  round-trips are **batched** (the panel executes a turn's tool calls and returns all outputs
+  in one POST) and wire-bound by tool-call id. Whether batching is a variant of the pending
+  slot or a parallel channel is **spike-gated** (see Testing Decisions), not decided here.
+- Entry provenance discrimination extends to resumed tool outputs: they enter as machine
+  entries, excluded from evidence-span anchoring (§9.4). This is a hard invariant, enforced at
+  the same level as the existing span-anchoring rules.
+- Fallback if Flue cannot carry the suspension shape: the app-level doc-handle side channel —
+  the server streams net definitions to the site, which writes them into the
+  `PetrinautDocHandle` outside the chat loop (the Actual-mode brunch route is the precedent).
+  Degraded (no read-tools, no diagnostics loop), which is why it is the fallback.
+
+**Client tool exposure**
+
+- The elicitor's Petrinaut tools are generated from `petrinaut-core`'s exported tool schemas,
+  so the tool surface tracks Petrinaut's own contract rather than a hand-copied one.
+- The panel executes only tool names it knows and throws on unknowns; brunch-only tools
+  therefore execute server-side. If a client-executed brunch tool is ever needed, the change
+  is a generic host-supplied-handlers extension to the `aiAssistant` prop (post-import,
+  per ADR-0004's boundary discipline).
+
+**Identity and storage**
+
+- The principal is ui-shell-owned: the demo site mints a random UID into localStorage and
+  sends it on every transport request. The host-authored server layer authenticates/resolves
+  principal → session set; the harness stays principal-free.
+- The storage port gains an opaque owner key, stamped at session creation; cross-principal
+  access fails as a store-level refusal (the port's existing enforcement idiom). The binding
+  treats the key as opaque.
+- Rate limiting is per-principal (and per-IP) at the server's front door, with a CORS origin
+  allowlist. The UID is identification, not authentication; the demo threat model accepts
+  this, and the Ory swap closes it for HASH.
+
+**Sequencing**
+
+- Harness-internal work continues in this repo and travels with the git-history import. The
+  two spikes run **before** the import (petrinaut-website driven locally from a hash checkout;
+  zero commits to `hashintel/hash`). Only petrinaut-website wiring, Petrinaut-library
+  extensions, and deployment integration wait for the move.
+
+## Testing Decisions
+
+- Tests assert external behavior at the four seams; nothing asserts panel internals or Flue
+  internals.
+- **Wire seam**: contract tests drive the server with recorded panel round-trips (POST message
+  history including batched tool outputs; assert the SSE chunk stream). The recordings are
+  produced once by the adapter spike against the real panel and frozen as golden fixtures —
+  the same freeze/replay posture as §14.4's fixture format.
+- **Ask-protocol seam**: the external-tool round-trip protocol gets the same substrate-free
+  treatment the ask protocol already has (FE-1422's extraction is prior art), including the
+  retry/idempotence properties FE-1420 establishes.
+- **Storage port seam**: owner-key refusals tested as store-level refusals with red-proofs,
+  per the FE-1419 discipline (`test/boundaries.test.ts` is prior art for the gate style).
+- **Artifact seam**: elicitor-emitted nets validated in CI through `parseSDCPNFile` plus the
+  survey's three above-schema checks (PascalCase place names, arc endpoint exclusivity,
+  scenario presence).
+- **Spikes are the evidence instrument for the two open questions**, each with a written
+  verdict:
+  1. _Suspension spike_: Flue carries terminate-with-pending; a resume dispatch delivers
+     machine results as non-user entries; batch binding holds. Failure here selects the
+     doc-handle fallback and is evidence toward a `binding-pi`, not against the harness.
+  2. _Adapter spike_ (discharged by FE-1435 and carried into the FE-1436 durable path):
+     `transport-aisdk` output drives the real panel — text, reasoning, and
+     server-tool parts render; client tool calls execute; the diagnostics decorator fires.
+     Its transcript becomes the golden fixtures.
+
+## Out of Scope
+
+- Voice (conditional nice-to-have per FE-1359's tiers; unchanged by the pivot).
+- HASH-app integration (design-for via the principal and adapter abstractions; no build).
+- The interpretation-render panel's visual design and placement (app-level UI vs.
+  `PetrinautSlots` — decided when the demo-site wiring starts, after the spikes).
+- Any change to `@hashintel/petrinaut` beyond the generic host-extension named above.
+- Deployment specifics (host, Postgres wiring, CI) — owned with infra on their own ticket.
+- Elicitation quality (packs, strategy quiver, sweep behavior) — the harness build's remit,
+  unchanged by this spec.
+
+## Further Notes
+
+- The differentiation narrative survives the staging change: the demo's claims (durable
+  capture, completion accounting, provenance) remain exactly what the incumbent
+  prompt-in-a-panel cannot do — now shown _in_ the panel rather than beside it.
+- The incumbent assistant's tool-call-per-element scaling concern (survey §6d: a 40-place net
+  is ~100 sequential mutations) now applies to brunch too; the suspension spike should note
+  observed round-trip counts, and batching mutations per turn is the first lever if it bites.
+- The survey's iframe/localStorage caveats applied to HASH's embed, not the demo site — the
+  demo site is a same-origin SPA and unrestricted. The Ory-principal swap is where the embed's
+  constraints re-enter, later.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/plugin-contract-spec.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/plugin-contract-spec.md
new file mode 100644
index 00000000000..dc941454807
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/plugin-contract-spec.md
@@ -0,0 +1,395 @@
+# Spec: the plugin contract — two schemas, two tables
+
+Status: **provisional** — desk-validated on baseline transcripts and cross-plugin thumbnails.
+Ratification condition (inherited from [ADR-0003](../../adr/0003-three-register-ir.md)): a full
+FE-1397-style worked pass across at least three plugin targets. Until the September build
+exercises a real fold, everything here is design, not demonstrated behavior.
+Decided on: FE-1405 (the payload-interiors session, 2026-08-18); inputs were that session's
+working draft and its pseudo-YAML structural rendering, which collapse into this document.
+
+## Problem Statement
+
+The elicitation system needs to work across domains: cyber-physical process models (the
+September target), BDD/Gherkin feature specification, formal verification, and domains not yet
+named. Today there is no defined answer to "what is a plugin?" — the capture envelope
+(FE-1383, the build root: capture store and envelope semantics) says how evidence is stored,
+and the ratified IR design says captures are typed, but nothing says what a domain author must
+write down to make the machinery elicit _their_ domain, and nothing turns a pile of typed
+captures into the thing the user actually wants: a model of their plant, their feature, their
+system.
+
+Three people feel this as a problem:
+
+- **The plugin author** has no contract. Every new domain looks like it needs bespoke
+  machinery — its own assembly logic, its own completion logic, its own follow-up-question
+  logic — which makes plugin authoring an engineering project instead of a declaration, and
+  makes example plugins unreadable as examples.
+- **The analyst running an elicitation** cannot ask "is this model complete enough to answer
+  my objective?" of a bag of captures. Completion questions are questions about a _model_ —
+  which activities lack duration distributions, which resources are uncounted — and no model
+  exists to ask them of.
+- **The reviewer** cannot audit semantic judgments. If "half a shift" becomes "4 hours"
+  somewhere inside a read path, the interpretation happened invisibly: unattributable,
+  unsupersedable, unreproducible.
+
+## Solution
+
+A plugin is **two schemas and two small tables**, all declarative:
+
+1. declare your domain's node kinds and their slots (the **model schema**);
+2. declare the utterance-shaped typed proposals that fill them (the **proposal catalog**),
+   annotating each with how to elicit it;
+3. say how proposals fold into slots (the **fold table** — almost always empty, because fold
+   rules derive from the slot declarations);
+4. say what your completion anchors demand (the **demand table**).
+
+Everything else is harness machinery explained once: a pure fold derives the elicited model
+from active captures (ADR-0003's register 2), slot states report what is known, absent,
+conflicted, or diverged, grades gate promotion, identity resolves by union-find over recorded
+same-as assertions, and follow-up questions fire mechanically off slot states. Semantic
+interpretation happens only at write time, in the sweep, where every bridge is deposited as a
+contestable capture.
+
+For the plugin author this means writing YAML, not code (code remains only in validators and
+projections). For the analyst it means completion computes over model slots, not capture
+counts. For the reviewer it means every model part answers "which captures made you."
+The readability oracle for the whole design: someone who has read the Gherkin plugin should be
+able to write a third plugin by analogy in a sitting.
+
+## User Stories
+
+1. As a plugin author, I want to declare my domain as node kinds with slots, so that the
+   harness derives the model shape without me writing assembly code.
+2. As a plugin author, I want a catalog of typed proposals whose interiors I compose from a
+   standard library of stated-form families, so that I don't reinvent "how experts state
+   quantities" for every domain.
+3. As a plugin author, I want fold rules derived from my slot declarations by default, so that
+   I only write fold-table rows for genuine exceptions.
+4. As a plugin author, I want to annotate each proposal type with an elicitation technique and
+   a mechanical firing condition, so that "which technique does this field force?" is a
+   completeness check over one column.
+5. As a plugin author, I want to declare grade orders per slot — referencing a library ladder
+   or declaring my own composition ladder — so that my domain's notion of "more pinned down"
+   drives promotion without new machinery.
+6. As a plugin author writing a thin plugin (Gherkin), I want the registers to collapse
+   gracefully, so that I never pay the thick plugin's ceremony.
+7. As a new plugin author, I want to read the Gherkin example and write my own plugin by
+   analogy in a sitting, so that plugin authoring is tractable without harness expertise.
+8. As a domain expert being interviewed, I want my hedged, low-grade statements ("about
+   3 hours") captured honestly rather than refused or hardened, so that the record reflects
+   what I actually said.
+9. As a domain expert, I want to say "I don't know" or "we don't track that" and have it
+   recorded as a first-class absence, so that I'm not re-asked what I've already disclaimed.
+10. As a domain expert, I want to state a uniformity once ("same everywhere, same crew") and
+    have it cover everything in scope, so that I'm not interrogated per instance.
+11. As a domain expert, I want to correct myself ("flag that as one I got wrong") and have the
+    correction supersede — not overwrite — the original, so that my history stays honest.
+12. As an analyst, I want the elicited model in the expert's vocabulary with every slot in a
+    definite state (unaddressed / stated-at-grade / absent / conflicted / diverged), so that I
+    can see at a glance what the elicitation has and lacks.
+13. As an analyst, I want completion computed as "every objective's demanded slots at demanded
+    grade over a static floor," so that "done" is relative to what I'm trying to answer, not
+    a global checklist.
+14. As an analyst, I want prescribed-vs-practiced divergence surfaced per slot, so that
+    unwritten rules and workarounds are findings, not noise.
+15. As an analyst, I want conflicting statements to fold to a typed conflict — never a silent
+    pick — so that contradictions become questions instead of errors.
+16. As the interviewing agent, I want next-question candidates to fire mechanically off slot
+    states (below demanded grade → quantile protocol; statistic unspecified → "typical, or
+    worst case?"), so that follow-ups are grounded in the model's actual gaps.
+17. As the sweep executor (FE-1392, the write-time mapping of utterances to proposals), I want
+    the proposal catalog compiled to a JSON Schema on my tool input and a decision-tree route
+    over statement forms, so that mapping is two small decisions, not one pick from a flat
+    ~19-type list.
+18. As the sweep executor, I want honest low-grade defaults (verbal form,
+    `statistic: unspecified`) to be legal captures, so that uncertainty degrades to
+    under-typing that cues a follow-up, never to silent hardening.
+19. As a reviewer, I want every semantic bridge — unit parse, identity link, composition,
+    formalization — deposited as an `inferred` capture with evidence spans, so that I can
+    audit, contest, and supersede any interpretation.
+20. As a reviewer, I want the fold forbidden to interpret, so that re-running it on the same
+    store always yields the same model.
+21. As a projection author (net renderer, loss report, completion table), I want to consume
+    the elicited model without rereading the transcript or interpreting generic capture
+    fields, so that my projection is a pure function of register 2.
+22. As a harness developer (FE-1393, the plugin SDK and fold engine), I want every harness
+    mechanism to be a pure function classified by which plugin declaration it reads, so that
+    the harness/plugin boundary is mechanically checkable.
+23. As a team reader, I want example plugins that read as declarations of their domain, so
+    that I can evaluate the product's generality without reading harness internals.
+
+## Implementation Decisions
+
+The shapes below are trimmed from the session's ds-pseudo prototype (an untracked session
+artifact); they encode the decisions more precisely than prose.
+
+### The three registers (ADR-0003, binding)
+
+Assertions (envelope-wrapped typed proposals) → the elicited model (derived by a pure fold,
+never stored) → projections. Write-time-only semantics: no semantic act at read time; every
+bridge is a capture. The acceptance oracle: a second projection must consume the model without
+rereading the transcript or semantically interpreting generic capture fields. Promotion, never
+refusal: low-grade statements are captured honestly and never promote to a demanded grade
+without a higher-grade capture superseding them.
+
+### Harness machinery: pure functions classified by what they read
+
+The harness is the functions; the plugin is the tables they read. This is the
+harness/plugin boundary, stated as a typology:
+
+```yaml
+HarnessMachinery:
+  foldEngine: { reads: foldTable + modelSchema, emits: register-2 model }
+  demandRunner:
+    {
+      reads: demandTable + active anchor captures,
+      emits: demanded grade per slot,
+    }
+  identityResolver: {
+      reads: identity-bearing proposals,
+      emits: canonical names,
+    } # union-find
+  slotStateDeriver:
+    { reads: fold output + open issues + absences, emits: slot state per slot }
+  promotionGuard: { reads: gradeOrder per slot, emits: supersession legality }
+  affordanceCuer:
+    { reads: firesWhen x slot states, emits: next-question candidates }
+  captureEnvelope: fixed # kernel canon; the one non-function; amendable only at the seam
+```
+
+The slot-state algebra, fold engine, grade/promotion mechanism, identity mechanism, and demand
+runner are harness (plugin-SDK) territory; the standard interiors are an importable library;
+the node-kind catalog, proposal catalog, affordance annotations, demand table, and loss
+categories are plugin-authored. (Ratified as FE-1393 design input.)
+
+### The plugin contract
+
+```yaml
+PluginContract:
+  modelSchema: NodeKind[]           # register 2 — derived, never stored
+  proposalCatalog: ProposalType[]   # register 1 — utterance-shaped, envelope-wrapped
+  foldTable: FoldRow[]              # overrides only; default rules derive from SlotDecl
+  demandTable: { rows: DemandRow[], staticFloor: string[] }
+  variantDimension: enum?           # e.g. prescribed | practiced; enables slot state 'diverged'
+  lossCategories: enum[]
+
+NodeKind:
+  name: string                      # closed catalog (Layer-A property 1)
+  slots: map<string, SlotDecl>
+  completionAnchor: boolean
+
+SlotDecl:
+  valueType: string                 # domain type or standard interior
+  cardinality: enum                 # one | set | ordered
+  gradeOrder: enum[]?               # plugin-declared, lowest first; library ladder or composition ladder
+
+ProposalType:
+  name: string                      # named by its semantic act, keyed to its fold target
+  interior: shape                   # composed from the standard-interiors library
+  validators: string[]              # tiered: deterministic / semi-mechanical / residue
+  affordance:
+    technique: string               # ref to an FE-1403/FE-1406 technique card
+    firesWhen: enum                 # closed 7-value set, below
+```
+
+This survives the penciled manifest design as the manifest's `ontology/schema` key: the
+prompt-mechanism keys (techniques, lenses, smells, …) are untouched (FE-1403/FE-1406,
+the technique-card and prompt-mechanism efforts); `checks`/`tools` receive the proposal and
+projection validators; code remains only in validators and projections.
+
+### Typed proposals, not generic field atoms
+
+The generic kind+field EAV union is retired. Register 1 is an enumerated catalog of typed
+semantic proposals with domain-shaped interiors (`duration-estimate` carrying a
+`QuantityStated`, not `quantity-stated` carrying a string). For CPS the first-cut catalog is
+~19 types worked from the C1 baseline transcript (entity-noted, attribute-noted,
+attribute-domain, population, activity-noted, duration-estimate, resource-requirement,
+actor-assignment, precondition-noted, outcome-noted, sequence, trigger, policy-noted,
+relationship-noted, question-to-answer, goal-noted, penalty-noted, rationale-noted, same-as).
+Constraint, data-binding, and validation-criterion stay schema-present but shallow — one
+`*-noted` proposal each — per the September minimum; all three have real C1 instances.
+
+### The standard-interiors library
+
+Finiteness claim: interiors are indexed on _how experts state facts_ — measurement scale
+types plus logical forms — not on domains. Six families over a shared supertype, plus one
+flagged tarpit:
+
+```yaml
+StatedForm: # base — every family extends this
+  verbatim: string # fidelity anchor; never normalized away
+  parsed: shape? # mechanical-tier structure; its absence IS the grade floor
+  # convention: every family declares explicit UNSPECIFIEDNESS MARKERS — slots recording
+  # what the utterance did NOT say. Grade derives from parsed-ness; markers are exactly
+  # what the affordance cuer fires on.
+
+QuantityStated: # 1 — magnitude (ratio/interval): verbal | point | range | quantiles; statistic marker
+ComparisonStated: # 2 — order (ordinal): a/b/dimension/direction; direction-without-magnitude marker
+RankingStated: # 2b — total/partial order over a set
+VocabularyStated: # 3 — category (nominal): dimension + values
+ConditionStated: # 4 — predicate: verbatim < structured < formal (the FV ladder lives here)
+UniformityClaim: # 5 — quantified claim over a ScopeExpr, with exceptions carve-out
+SubjectRef: # 6 — reference/identity; same-as pairs two of them
+TemporalPattern: # flagged tarpit — NOT claimed finite; verbatim-heavy, coarse window only
+```
+
+Number-hedges ("about", "maybe", "roughly") live in `QuantityStated`'s qualifier, not in
+capture confidence — two different homes. Capture-level confidence is the picklist
+`firm | hedged | speculative`, and the store refuses numeric-parsing confidence strings
+(closes remediation item A5).
+
+### Grade is narrowing of interpretation space
+
+Grade means "fewer readings remain," never claim strength (that is envelope confidence —
+orthogonal by design). Two sources: **form grades** fall out of the library (each family's
+ladder is its unspecifiedness markers progressively resolved: verbal < point < range <
+quantiles; informal < vocabulary-bound < formal-parsed) — plugins demand rungs, they don't
+define these ladders; **composition grades** are plugin-declared (Gherkin's given-only <
+given-when < full-gwt is about slot composition, not one statement's form). The fold engine
+reads grade off the interior or the fold output, never off the proposal type name — formal
+verification's `formalization` is a _different proposal type_ folding into the _same slot_ at
+higher grade. Grade orders promotion only: they never choose a winner among active values.
+Beyond formal-parsed lies checking, which is validation, not grade.
+
+### Slot states and fold rules
+
+```yaml
+SlotState: unaddressed | stated(value, grade, supportingCaptureIds)
+         | absent(absence, captureId)          # populatable pending envelope pressure #2
+         | conflicted(openIssueIds)
+         | diverged(prescribed, practiced)     # only if the plugin declares a variant dimension
+
+_foldRuleDerivation:   # foldTable holds overrides only; both example fold tables are empty
+  - cardinality one                 -> unique (grade order, if declared, gates promotion only)
+  - cardinality set                -> set-union (member removal = supersede that member)
+  - cardinality ordered, positions stated in-utterance -> ordered-append
+  - order stated pairwise          -> graph-union, order derived at read
+  - identity-bearing proposal      -> union-find
+  - scope-bearing proposal         -> shared-support
+  # closure: fold behavior = (cardinality) x (graded y/n) + two specials. Finite product
+  # space; the rule enum is its image.
+```
+
+One active value occupies a unique slot. Competing active, un-superseded values — at equal or
+different grades — fold to `conflicted` with a typed issue, never a silent pick. Values that
+are genuine alternatives must be declared as such and handled by the plugin's explicit
+alternative rule; they do not authorize the fold to choose one. A higher-grade value replaces
+a lower-grade value only through an explicit supersession, after which the lower capture is no
+longer active. Regime divergence is per-slot; a regime-split _existence_ (the off-shift wash
+that's prescribed-possible, practiced-never) is the degenerate node-level case.
+
+### Demand, scope, and firing conditions
+
+Requiredness is question-relative: a static floor (≥1 objective; entity coverage; a happy-path
+flow) plus objective-demanded grades (a capacity objective demands quantile-grade durations on
+the activities in its support). Demand rows map anchor patterns to `ScopeExpr → grade` maps.
+`ScopeExpr` has three constructors — `kind`, `where`-filter, `inSupport(anchor)` — and
+**September ships kind-only**; the other two are the named growth path. `support(anchor)` is
+defined as reference closure over a plugin-declared list of support-bearing proposal types
+(proposal interiors carrying SubjectRefs _are_ the edges; the proposal type is the edge type,
+per Layer-A property 4).
+
+`firesWhen` is a closed 7-value enum, every value a predicate over slot states —
+`slot-unaddressed | below-demanded-grade | unspecified-marker-present | conflicted-open |
+absence-uncorroborated | uniformity-unprobed | identity-ambiguous` — so the affordance column
+is mechanically checkable.
+
+### Identity and supersession
+
+Identity assertions (`same-as`) are schema citizens: `inferred`, supersedable; reconciliation
+is deterministic union-find over them; renames are new identity assertions, never edits.
+Retraction residue: a retraction that replaces a claim with a guess-plus-known-unknown is a
+`tentative` superseding capture now, plus an absence capture once the envelope's absence
+locator lands (see Open strains).
+
+### The envelope is untouched
+
+Nothing here amends the capture envelope. The one confirmed pressure — absence captures carry
+no payload, so a field-specific absence cannot name its slot — is recorded at the FE-1383
+seam with three concrete C1 cases; the locator an absence needs is precisely a fold-table
+`target` coordinate. Adjudication happens at the seam, not by forking.
+
+## Testing Decisions
+
+A good test here asserts external behavior at a seam — captures in, slot states out — never
+fold internals or intermediate representations. Three seams, one primary:
+
+1. **The fold** (primary, new, the highest seam available): `fold(pluginContract,
+activeCaptures) → model` is pure by construction, so the whole contract is golden-testable
+   at one seam — hand-worked capture sets in, asserted slot states out. The seed gold set is
+   the FE-1405 worked-instance set from C1: the anchor changeover utterance (~9 captures →
+   four activities with graded durations and one rationale; the asymmetry claim derivable, not
+   captured), the quantile promotion pair (point supersedes to quantiles; slot promotes; no
+   refusal at any step), the regime-split off-shift wash, and the first-pass-yield absence
+   (blocked, and _asserted_ blocked, pending the envelope locator). This gold set doubles as
+   the sweep-accuracy rubric material for FE-1407 (the evaluation/gold-set effort).
+2. **The acceptance oracle, executable**: a second projection consumes the folded model with
+   no transcript access and no generic-field interpretation — enforced structurally by the
+   projection's input type being register 2 only. If the projection can't be written that
+   way, the failure is the finding.
+3. **Contract validation**: plugin contract documents validate against the harness
+   meta-schema; the fold-rule derivation is tested as a table-driven pure function over its
+   finite product space (cardinality × gradedness + the two specials).
+
+Everything downstream — demand runner, slot-state deriver, promotion guard, affordance cuer —
+reads off the fold's output, so seam 1 covers them without new seams. Modules under test are
+FE-1393's fold engine and plugin SDK, with the CPS and Gherkin contracts as fixtures. Prior
+art in this repo: the docs-index gate (`test/docs-index.test.ts`) for the table-driven,
+fail-loud style, and the capture-store suite (FE-1390 side) for envelope-adjacent fixtures.
+Test-fit order stands: smallest honest plugin and Gherkin before CPS.
+
+## Open strains (first-class, with owners)
+
+Adjudicated in the FE-1405 session; recorded here so settlement doesn't launder them into
+decidedness.
+
+- **Strain 4 — grade sources (resolved in shape, worked pass pending).** Grade = narrowing;
+  form grades library-owned, composition grades plugin-declared. The shape is ratified; no
+  real fold has read a grade yet. Owner: FE-1393 (fold engine), against the gold set.
+- **Strain 5 — support closure (downgraded, worked pass pending).** Typed references already
+  exist (interiors carrying SubjectRefs are edges); `support(anchor)` needs one declared
+  column and a closure rule, and a hand-worked pass over C1 before `inSupport` ships.
+  Owner: FE-1393, with FE-1402 (the completion contract) as consumer.
+- **Strain 6 — temporal patterns (roped off).** Scheduling is out of scope as a modelling
+  area; `TemporalPattern` stays verbatim-heavy, coarse window only, no calendar algebra
+  claimed or planned. Reopening it is a deliberate act, not drift.
+- **Strain 7 — sweep-time concentration (recorded; mitigations must travel).** Write-time-only
+  semantics makes the sweep's utterance→proposal mapping the single point of semantic failure.
+  Mitigations, none yet built: (a) the family index as a decision-tree sweep skill — route by
+  statement form, then fold target (FE-1403 authoring, FE-1392 consumes); (b) the proposal
+  catalog compiled to JSON Schema on the sweep tool input (FE-1392); (c) graceful
+  under-mapping via honest defaults, with over-mapping — silent hardening — as the real
+  failure, targeted by the verbatim-containment validators (FE-1392/FE-1393); (d) the
+  worked-instance gold set as the accuracy rubric (FE-1407).
+- **Envelope pressure #2 — absence locator (seam, unresolved).** Absence captures carry no
+  payload; a field-specific absence cannot name its slot. Three C1 cases logged. The needed
+  locator is a fold-table coordinate. Owner: the FE-1383 seam (`COORDINATION.md`), for
+  adjudication — the register-2 `absent` state is representable but not populatable until it
+  lands.
+
+## Out of Scope
+
+- Amending the capture envelope. Pressure #2 is recorded for adjudication at the seam.
+- Scheduling and temporal-pattern modelling (strain 6).
+- The `where` and `inSupport` ScopeExpr constructors shipping in September (kind-only ships;
+  the others are the named growth path).
+- Authoring the sweep skill, technique cards, and prompt-mechanism manifest keys
+  (FE-1392/FE-1403/FE-1406 territory — this spec fixes only the `firesWhen` and `technique`
+  hook points).
+- The full FE-1397-style ratification pass — it is this spec's _condition_, owed before the
+  provisional marker comes off, not part of its build scope.
+- Loss-category content and projection implementations beyond the oracle projection.
+- Any UI.
+
+## Further Notes
+
+- This document is the settled form of the FE-1405 session's working draft and its
+  ds-pseudo YAML rendering — untracked session artifacts (`drafts/`, per the documentation
+  protocol) that collapsed into this spec and are not load-bearing anywhere.
+- The decision this spec builds on is [ADR-0003](../../adr/0003-three-register-ir.md); the
+  worked cross-plugin thumbnails (Gherkin thin, formal verification mid, CPS thick) live in
+  the working draft and discharge the ratification bar only provisionally.
+- The authoring story is the product claim to protect: _declare your kinds and slots; declare
+  the proposals that fill them; annotate how to elicit each; say what your anchors demand._
+  Any harness change that breaks the readability oracle — a Gherkin reader can write a third
+  plugin by analogy — is a regression even if all tests pass.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/recommendation-demo-vehicle.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/recommendation-demo-vehicle.md
new file mode 100644
index 00000000000..83bf0778374
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/recommendation-demo-vehicle.md
@@ -0,0 +1,95 @@
+# Recommendation: the September demo vehicle
+
+**Ticket**: FE-1362 · **Formed**: 2026-08-12 · **Status**: Lu's settled position on the
+wayfinder map (FE-1357) — the recommendation he brings to the integration discussion on
+Tuesday 2026-08-18 (Dei, Chris, Lu; Kostandin back that week). Demo: 2026-09-17/18, ARIA
+audience, format TBD.
+
+This document is the integration doc FE-1333's done-when asks for, offered as a recommendation
+for that discussion: it covers the boundary, where sessions persist, and where the elicitor
+runs. Build-approach statements within it (how the elicitation library is built) are within the
+dev remit and stated as such; the integration posture and anything touching product shape are
+recommendations until discussed.
+
+## The recommendation
+
+Build the September demo as a **one-off demo shell**: a purpose-built, explicitly disposable
+application that consumes **two libraries** —
+
+1. the **elicitation library** — greenfield, built to the elicitation-kernel spec
+   (`docs/planning/elicitation-kernel/spec.md`): harness + CPS plugin + Flue binding, scoped to
+   a demo-critical slice, scavenging existing brunch surfaces opportunistically. The existing
+   brunch app is **not** the base.
+2. the **Petrinaut libraries** — the published React UI + headless `petrinaut-core`, consumed
+   as-is, client-side.
+
+Neither library consumes the other. They meet at the **artifact boundary**: the elicitor emits
+a versioned net file **plus a `scenario`** (nets carry no marking or timing — without a
+scenario the net is dead), and Petrinaut consumes it through its production parser /
+import-with-autolayout path.
+
+## Handoff mechanics on stage
+
+- Default beat: **in-process handoff** through the real serialize → parse path — seamless, but
+  the boundary crossed is the real one.
+- One deliberate **"and it's just a file"** moment: save the artifact, open it in stock
+  Petrinaut. That is the decoupling claim made visible.
+- The payoff shot is the net **running**: the elicited scenario animating the token game. A
+  rendered-but-dead net undercuts the "the interview produced a working model" narrative.
+
+## Runtime and persistence (FE-1333 coverage)
+
+- The **elicitor runs server-side** in the demo shell, on the Flue substrate (as the
+  `prototype/10-flue-roundtrip` walking skeleton already does).
+- **Sessions persist in the demo shell's storage**: capture store + session-log archive behind
+  the kernel spec's storage port.
+- Petrinaut's libraries are **purely client-side** — rendering and simulating the artifact,
+  with zero persistence responsibilities.
+- Deployment and storage specifics remain open (map fog), judged low-difficulty.
+
+## Demo-critical set (demo-legibility test)
+
+Demo-critical, in narrative order: **(a) durable capture with provenance** (quoted evidence
+spans), **(b) completion accounting** (the elicitor knows what it still lacks), **(c) the live
+interpretation-render panel** — the display surface through which the audience _sees_ (a) and
+(b) happening — and **(d) the artifact handoff into Petrinaut, running**. These are precisely
+what the incumbent in-Petrinaut assistant cannot do: the differentiation narrative is "what a
+prompt-in-a-panel cannot do."
+
+**Voice is conditional**: a nice-to-have considered only if (a)–(d) are very solid with
+significant time to spare (then T0 push-to-talk floor, T2 live-extraction target, per
+FE-1359's tiers). Note: even the _prospect_ of voice argues for the demo-shell topology —
+voice bolts on at the ui/turn shell, which is only ours to modify if we own the shell.
+
+## Evidence topology (carry into Tuesday 2026-08-18)
+
+1. **Petrinaut survey** (FE-1358, `research/petrinaut-survey.md`): the artifact boundary
+   already exists in production — versioned file format, pure parser, import-with-autolayout
+   (Import currently hidden in HASH's embed: a small unhide ask to the Petrinaut team). The
+   incumbent assistant is browser-resident with no headless path, no queue, and no provenance
+   capture anywhere in the stack.
+2. **Chris (Petrinaut lead), on FE-1333**: supports circumspection about coupling; confirms
+   both elements are libraries meant to be consumed by applications; expects HASH to consume
+   both in the end — "Petrinaut should not do the instantiation of Brunch directly."
+3. **Standing preference**: decoupling unless evidence forces coupling — no evidence does; the
+   demo-legibility test _favors_ the boundary (the handoff is a beat, not a seam to hide).
+4. **Voice tractability** (FE-1359): the bolt-on seam only exists in a shell we own.
+5. **The "entirely new" stance** (grilling round 1) plus the differentiation narrative: the
+   demo's claims are exactly the kernel spec's machinery and exactly what the incumbent lacks.
+
+## Positions on in-flight issues
+
+| Issue                                                                  | Position                                                                                                                                                                                                                                                                                            |
+| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| FE-1328 (extract the elicitation core)                                 | **Build approach (dev remit).** The deliverable stands — an importable elicitation core with no server/DB/UI deps — but "extraction" is figurative: the core is rebuilt greenfield by abstraction and extension per the kernel spec. Literal extraction would import brunch's design debt and gaps. |
+| FE-1329 (make the brunch elicitor generic)                             | **Build approach (dev remit).** Genericity arrives via the harness/plugin split — the CPS plugin is a thin shell over a generic harness — not by retrofitting brunch.                                                                                                                               |
+| FE-1331 (start elicitation from create-new-net)                        | **Recommend deferring** — the demo-shell recommendation contradicts it for September; in-Petrinaut initiation is the natural post-September consumer topology (once HASH consumes both libraries, per Chris's framing). Deferred, not rejected; product call stays with the PM side.                |
+| FE-1333 (define the integration)                                       | **Answered by this document as the recommended position**; stays open for Tuesday's discussion.                                                                                                                                                                                                     |
+| Dora's PRO-98 claim #5 (in-Petrinaut one-shot-then-iterate initiation) | **Recommend against for September** — under this recommendation, session initiation happens in the demo shell. Recommendation with reasons delivered as a comment on PRO-98 (2026-08-12).                                                                                                           |
+
+## Left open (map fog)
+
+- **Package naming**: `brunch-lite` / `brunch-core` are interim candidates; a post-September
+  step could fold back into `brunch` proper as a monorepo with the harness as a sub-path
+  package. Not important now.
+- **Deployment & storage specifics** for the demo shell (remote/sandbox story).
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/elicitation-strategy-literature.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/elicitation-strategy-literature.md
new file mode 100644
index 00000000000..dd4d2873e69
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/elicitation-strategy-literature.md
@@ -0,0 +1,1191 @@
+# Elicitation strategy: what the literature already knows
+
+Resolves the research half of FE-1360. Companion to
+[open-questions-elicitation-design-2026-08-11](../notes/open-questions-elicitation-design-2026-08-11.md)
+(the question inventory) and
+[expert-meeting-findings-2026-08-11](../notes/expert-meeting-findings-2026-08-11.md)
+(which established that there is no in-house interviewing practice to elicit from, activating
+the literature fallback).
+
+---
+
+## Executive summary (10 lines)
+
+1. The literature's answer to "what are the first questions" is emphatic and contradicts the instinct to open with structure: **objectives first, model content last**, because content is _derived_ from what the model must answer (Robinson; Sargent).
+2. Completeness is **question-relative** and stated normatively — Sargent: if a model answers several questions, "the validity of the model needs to be determined with respect to each question." Elicit the questions first; they are the completion criterion.
+3. **Four probe catalogues are now in hand verbatim** — the CDM deepening and what-if sweeps, the ACTA knowledge audit, and a 35-type interview-question typology — which together are the single largest importable body of pack content available.
+4. The team's "bad day" question is a rediscovery of **prospective hindsight** (imagining the failure has already happened raises correctly-identified causes ~30%) and of incident-based CDM probing.
+5. **Structured beats unstructured elicitation by roughly an order of magnitude** in propositions per minute (Hoffman), and contrived tasks need a prior overview interview — which prescribes a concrete two-phase interview architecture.
+6. Quantities must be elicited as **quantiles, never as min/mode/max**: the three-point-triangular habit overstated a real measured quantity by ~69% in a published comparison, where a distribution fitted to the same elicited middle value landed within 1%.
+7. A motif catalogue is well supported as an **interview scaffold** and poorly supported as a model generator — and Börger's reduction argument (126 catalogued patterns collapse to 8 parameterised schemes) says to build a **small quiver with variant selectors, not a long menu**.
+8. The formalism ladder needs correcting: **colour is a folding, not a capability**, whereas **stochasticity has a genuine quantitative earning test** via the VUT/Kingman relation.
+9. **Logs settle fitness but cannot settle precision-versus-generalisation**, and four things are structurally absent from any log — off-system behaviour, rationale, resource reality, and the case notion — which is exactly the territory the interview must own.
+10. On AI-conducted interviews the load-bearing finding is that **mental models surface late, not first** — depth of probing is the differentiator, which argues against question batching and supplies a measurable evaluation proxy.
+
+---
+
+## How to read the source labels
+
+| Label   | Meaning                                                                                                                                  |
+| ------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| **[V]** | Verified — citation _and_ substantive content checked against a retrieved primary or authoritative source, in most cases full text read. |
+| **[C]** | Citation verified (authors/year/venue/title confirmed); content from background knowledge, source not read.                              |
+| **[R]** | Recalled — citation from background knowledge, not verified. Check before shipping as pack content.                                      |
+
+Verification improved substantially late in the work: several parallel literature threads recovered
+after failures and delivered primary sources, so most of what was previously recalled is now
+verified. The residual **[R]** items are flagged in "Where the literature is thin" at the end.
+
+---
+
+## Section 1 — How does model-building actually start?
+
+### 1.1 What are the actual inputs, in what proportion?
+
+**Grounded answer.** The only direct empirical evidence found is a survey of 102 practising
+simulation modellers **[V]**: model coding took roughly **twice** the time of any other
+activity; activities occurred in recognisable blocks but overlapped heavily rather than running
+in sequence; and in most projects the conceptual model was **changed during later tasks, usually
+by adding complexity**. That last finding matters more than the proportions: it says elicitation
+does not terminate before building starts, and that the drift is one-directional. An elicitor
+designed around a clean "elicit-then-build" handoff is designed around something practitioners
+do not do.
+
+The literature does **not** give a breakdown of documents vs. data extracts vs. conversations
+vs. site visits. That proportion appears undocumented, and the honest answer to Yannis is that
+his guess is as good as any published one.
+
+What the literature _is_ prescriptive about is that the first activity is not content-gathering:
+Robinson's first framework activity is "understand the problem situation" **[V]**, and Law's
+process begins with problem formulation plus an information-collection phase whose output is an
+**assumptions document**, not a model **[V]**.
+
+The team's "prime from documents before questioning" idea aligns with contextual inquiry's
+insistence that understanding comes from the work setting **[R]** — though note the actual claim
+is stronger and less convenient: observation is held to be irreplaceable, not substitutable by
+documents. See also §9: a large fraction of what documents and logs _can_ answer is now
+mechanically extractable, which changes what the interview should spend its time on.
+
+**Key sources.**
+
+- Brooks, R. & Wang, W. (2015) "Conceptual modelling and the project process in real simulation projects: a survey of simulation modellers", _Journal of the Operational Research Society_ 66(10):1669–1685, doi:10.1057/jors.2014.128 **[V]**.
+- Robinson, S. (2008) "Conceptual modelling for simulation Part I: definition and requirements", _JORS_ 59(3):278–290 **[V]** (full text obtained via Loughborough figshare). Part II, "a framework for conceptual modelling", _JORS_ 59(3):291–304, doi:10.1057/palgrave.jors.2602369 **[C]** — genuinely closed access, no OA copy exists; its framework specifics below come from Robinson's own WSC tutorials, which reproduce it.
+- Law, A.M., "How to build valid and credible simulation models", WSC tutorial — 2022 version read in full **[V]**.
+- Beyer, H. & Holtzblatt, K. (1998) _Contextual Design: Defining Customer-Centered Systems_, Morgan Kaufmann **[R]**.
+
+**Pack-content candidates.**
+
+- **"Expect the model to grow" policy card**: the elicited description is a living artifact; support post-build additions rather than treating handoff as closure.
+- **Document-priming card**: ingest documents to _generate propositions to confirm_, not to skip questions. Document-derived facts enter at lower confidence than spoken confirmations.
+
+### 1.2 The first five questions, and what each feeds
+
+**Grounded answer.** Clear and defensible, and it is not "ask about structure". Robinson's
+framework orders the work as **[V]**:
+
+1. understand the problem situation;
+2. determine the **modelling objectives** (and general project objectives);
+3. identify the **model outputs / responses** — what the model must report;
+4. identify the **model inputs / experimental factors** — what the user will vary;
+5. determine the **model content**: scope and level of detail, recording **assumptions** and **simplifications**.
+
+A defensible first five, with the model element each feeds:
+
+| #   | Question                                                                                  | Feeds                                                                |
+| --- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
+| 1   | "What decision is waiting on this? What will you do differently depending on the answer?" | Objectives; and whether a model is warranted at all                  |
+| 2   | "What would you have to see reported to believe it?"                                      | Responses/outputs — and hence which quantities must be **emergent**  |
+| 3   | "What are you allowed to change in the real system?"                                      | Experimental factors — hence what must be explicit and parameterised |
+| 4   | "How close is close enough, and against what would you check it?"                         | Accuracy bar and validation data                                     |
+| 5   | "What's deliberately out of scope — what would you refuse to be held responsible for?"    | Scope boundary; assumptions and simplifications register             |
+
+Only then does structure become answerable, because scope and level of detail are _consequences_
+of 1–4. Sargent states the accuracy point verbatim **[V]**: "The amount of accuracy required
+should be specified prior to starting the development of the model or very early in the model
+development process."
+
+Two independent supports for broad-to-narrow ordering: the **funnel sequence** from interviewing
+methodology **[R]**, and ACTA's bounded opener, which is worth stealing outright **[V]**: _"At
+the most basic and simple level, can you break down your process into between three and six
+steps?"_ The bounded count does real work — it fixes an initial level of abstraction instead of
+inviting whatever detail comes to mind.
+
+A caution from the mistake literature (§5.1): **"incorrect opening of interview" was observed in
+15 of 28 interviews** and "incorrect ending" in 19 **[V]**. Openings and closings are the two
+most error-prone moments, not the middle.
+
+**Pack-content candidates.**
+
+- **Opening-five card** (the table above), with the explicit rule: _do not ask about structure in the first exchange_.
+- **Bounded task-diagram opener**: three-to-six steps, before any detail.
+- **Responses-before-structure guard**: refuse a structural claim until at least one response variable is on record.
+
+### 1.3 Dependency order of questions
+
+**Grounded answer.** Robinson's ordering _is_ the dependency order, and the dependencies are
+real: objectives determine responses; responses determine which quantities must be endogenous
+(and therefore cannot be supplied as inputs); those two together determine scope and level of
+detail **[V]**.
+
+Three concrete switch points where an early answer changes what to ask next:
+
+- **Is the quantity of interest a mean, or a tail/percentile/service level?** A tail answer forces distributional elicitation and a stochastic model; a mean answer may not. Highest-value branch, and grounded quantitatively (§6).
+- **Is a named quantity a response or an experimental factor?** Throughput offered as an input is a mis-scoping; throughput is a response. Robinson's factor/response distinction detects this mechanically **[V]**.
+- **Does the decision involve changing a resource count, or a policy?** If yes, resources and the contention rule must be explicit; if no, they can often be folded into a service-time distribution.
+
+**Pack-content candidates.**
+
+- **Mean-or-tail router card**: one early cheap question that switches the whole downstream quantitative strategy.
+- **Factor/response classifier**: every elicited quantity is tagged input-or-output; an output offered as an input raises an issue.
+
+### 1.4 Numbers vs. distributions vs. stories
+
+**Grounded answer.** The literature partitions these by what kind of thing is being asked for.
+
+- **Numbers** for quantities checkable in principle — capacities, counts, shift calendars, batch sizes. The discipline is Howard's **clairvoyant test** **[V]**: a quantity is well enough defined only if a clairvoyant — someone with perfect knowledge of all events and measurable quantities past, present and future, _but exercising no judgment_ — could answer it. That "no judgment" clause is the load-bearing part, because it is what separates definitional disagreement from factual disagreement (§5.3).
+- **Distributions** for durations, inter-arrival times, failure and repair behaviour. Elicit by **quantiles**. See below — this is where the strongest single quantitative finding in the review sits.
+- **Stories** for anything rare, and for anything whose absence from the event log is the point (§9). This is where CDM lives and where the "bad day" question belongs (§2.2).
+
+**The three-point habit is measurably wrong.** DES practice commonly elicits minimum / most
+likely / maximum and fits a triangular distribution. In a published comparison against measured
+emergency-department length-of-stay, a triangular built from SME triples **overstated the real
+mean by about 69%** (339.6 vs. 201 minutes actual), while a skewed beta that read the elicited
+middle value as a _mean_ rather than a mode landed within 1% **[V]**. The paper also documents
+the mode/mean confusion as the mechanism, and notes the hard structural constraint that a
+triangular's mean must lie in the middle third of its range — so the shape cannot represent the
+skew that real service times have. This is the most directly actionable number in the review.
+
+**What to do instead**, from structured expert judgment:
+
+- The classical model elicits **quantiles — typically 5%, 50% and 95%** — and this is confirmed verbatim as the format used across the entire TU Delft study series **[V]**.
+- SHELF's **quartile (bisection) method** asks for a median first, then conditional quartiles, and the protocol is reproduced verbatim in EFSA's guidance **[V]**. A written/remote adaptation exists with a nice two-step median: ask first for a "typical value", then have the expert adjust it until they are comfortable that the quantity is equally likely to fall above or below **[V]**.
+- The **IDEA protocol's four-step question** is the most transplantable script found, verbatim **[V]**: (1) "Realistically, what do you think the lowest plausible value for [X] will be?" (2) "…highest plausible value…" (3) "Realistically, what is your best guess for [X]?" (4) "How confident are you that your interval, from lowest to highest, could capture the true value of [X]? Please enter a number between 50% and 100%." Note the order — interval before best guess — and note that step 4 is what makes the interval usable: responses are standardised to a common credible interval afterwards.
+- The **roulette / chips-and-bins** method is the alternative for experts who prefer drawing to numbers; EFSA recommends ten bins over the plausible range, twenty chips, end bins left empty **[V]**.
+- Do **not** ask directly for means, variances or "the distribution", and do not anchor on extremes without the confidence question **[V]**.
+
+**When to ask for a specific bad day rather than an average.** Two grounded triggers: (i) the
+model's question concerns a tail, a resilience property or a threshold breach, so an
+average-based answer is answering a different question; and (ii) the phenomenon is rare enough
+to be absent or unrecognisable in the logs, so no data channel can supply it (§9). The team
+already reached (ii); (i) is the addition.
+
+**Key sources.**
+
+- Howard, R.A. (1988) "Decision analysis: practice and promise", _Management Science_ 34(6):679–695, doi:10.1287/mnsc.34.6.679 **[V]**; Morgan, M.G. & Henrion, M. (1990) _Uncertainty_, Cambridge University Press, p.50 **[V]**.
+- Holm & Barra, "Input modelling with expert opinion" comparison, _Proceedings of the 2011 Winter Simulation Conference_ (informs-sim.org/wsc11papers/324.pdf) **[V]** — the 69% / 1% result.
+- Colson, A.R. & Cooke, R.M. (2017) "Cross validation for the classical model of structured expert judgment", _Reliability Engineering & System Safety_ 163:109–120, doi:10.1016/j.ress.2017.02.003 **[V]**; Cooke, R.M. & Goossens, L.H.J. (2008) "TU Delft expert judgment data base", _RESS_ 93(5):657–674, doi:10.1016/j.ress.2007.03.005 **[V]**.
+- EFSA (2014) "Guidance on expert knowledge elicitation in food and feed safety risk assessment", _EFSA Journal_ 12(6):3734, doi:10.2903/j.efsa.2014.3734 **[V]** — the single most usable protocol document found; contains the SHELF quartile script and filled-in elicitation forms.
+- Speirs-Bridge, A. et al. (2010) "Reducing overconfidence in the interval judgments of experts", _Risk Analysis_ 30(3):512–523 **[V]** (origin of the four-step format); Hemming, V. et al. (2018) IDEA protocol, _Methods in Ecology and Evolution_ 9(1):169–180 **[V]**; Hemming, Walshe et al. (2018) _PLoS ONE_ 13(6):e0198468 **[V]** (standardisation formula).
+- O'Hagan, A. et al. (2006) _Uncertain Judgements: Eliciting Experts' Probabilities_, Wiley **[R]**; Tversky & Kahneman (1974) _Science_ 185:1124–1131 **[R]**; Alpert & Raiffa (1982) **[R]**.
+
+**Pack-content candidates.**
+
+- **Quantity-type router card**: classify each needed quantity as number / distribution / story _before_ asking, then use the matching script.
+- **Four-step interval card** (IDEA wording verbatim) as the default distribution script, with the quartile/bisection method as the deeper alternative when the quantity is load-bearing.
+- **Anti-triangular guard**: if a min/mode/max triple arrives unprompted, do not fit a triangular to it — ask the confidence question and record whether the middle value is a mode or a mean.
+
+---
+
+## Section 2 — How do you reach what nobody wrote down?
+
+### 2.1 Phrasings that elicit taxonomies, penalty weights, unwritten constraints
+
+**Grounded answer.** These are three different problems with three different mature techniques.
+
+**Taxonomies (e.g. product families) — laddering, verbatim.** A correction to a common
+misconception first: laddering-up phrased as _"why is that important?"_ belongs to the
+means-end-chain tradition in consumer research, **not** to knowledge-engineering laddering, and
+the two should not be conflated **[V]**. The knowledge-engineering laddered-grid prompts are
+**[V]**:
+
+| Move                      | Prompt                                                                                         |
+| ------------------------- | ---------------------------------------------------------------------------------------------- |
+| DOWN the domain knowledge | "Can you give examples of \<ITEM\>?"                                                           |
+| ACROSS                    | "What alternative examples of \<CLASS\> are there to \<ITEM\>?"                                |
+| UP                        | "What have \<SAME LEVEL ITEMS\> got in common?" · "What are \<SAME LEVEL ITEMS\> examples of?" |
+| Essential properties      | "How can you tell it is \<ITEM\>?"                                                             |
+| Discrimination            | "What is the key difference between \<ITEM 1\> and \<ITEM 2\>?"                                |
+
+Two of those are quietly the most valuable. _"How can you tell it is X?"_ elicits the
+recognition criteria — which for a product family is the actual operational definition nobody
+wrote down. And _"What is the key difference between X and Y?"_ is the discrimination probe that
+turns a flat list into a typed taxonomy with guards attached. The elicitor moves around the
+domain map in whatever order is convenient, building the network as it goes — it is explicitly
+**not** a fixed question sequence.
+
+**Card sorting** and **repertory grid / triadic elicitation** ("in what way are two of these
+alike and different from the third?") complement laddering by surfacing attributes the expert
+uses without having named **[V]**. The repertory grid has a second use worth noting: comparing
+one expert's grid with another's highlights areas of consensus and difference **[V]** — a
+mechanical route into §5.3.
+
+**Penalty weights and objectives** belong to decision analysis, which the team's corpus does not
+currently reflect. Keeney's devices **[V]**: ask for a **wish list** (how would you rank options
+if constraints were removed?); name a particularly good and a particularly bad outcome and say
+what makes each so; enumerate **shortcomings of the status quo**; ask what consequences would
+**change** an option's desirability; ask what objectives **other stakeholders** would name. For
+the weights themselves, **swing weighting** has the expert compare the swing from worst to best
+level on each attribute rather than state a weight directly **[V]** — the same methodological
+move as eliciting quantiles instead of variances.
+
+**Unwritten constraints** ("that product always runs on line 2"). The best framing is
+work-as-imagined vs. work-as-done **[V]**: what procedures say happens is systematically
+different from what happens, and the gap is normal rather than deviant (the ETTO principle —
+people trade thoroughness for efficiency as a matter of course). This reframes the question from
+"what are the undocumented rules?", which invites denial, to "where does the written procedure
+not survive contact with the day?", which invites description. Yannis's manuals-vs-event-logs
+observation is the same distinction; process mining's de facto/de jure framing is its third
+instance (§9).
+
+One directly usable phrasing for this from the question typology is the **negative balance
+question** **[V]**, which is built to counteract the tendency to describe the idealised version:
+"You seem to be very efficient. Do you remember any occasions in which you had problems that
+slowed you down?"
+
+**Key sources.**
+
+- Shadbolt, N.R. & Smart, P.R. (2015) "Knowledge elicitation: methods, tools and techniques", in Wilson & Sharples (eds) _Evaluation of Human Work_, 4th ed., CRC Press **[V]** — full text read; source of the laddering, card-sort and repertory-grid procedures above. **Citation correction**: the earlier chapter is Shadbolt, N. & Burton, M. (1990) "Knowledge elicitation", in Wilson & Corlett (eds) _Evaluation of Human Work: A Practical Ergonomics Methodology_, 2nd ed., pp.406–440, Taylor & Francis — _not_ "Knowledge elicitation: a systematic approach"; the 3rd-edition chapter is Shadbolt (2005) "Eliciting expertise" **[V]**.
+- Corbridge, C. et al. (1994) — laddering in knowledge engineering **[C]**; Reynolds, T.J. & Gutman, J. (1988) "Laddering theory, method, analysis and interpretation", _Journal of Advertising Research_ 28(1):11–31 **[V]** — the _other_ laddering, cited here only to keep them separate.
+- Kelly, G.A. (1955) _The Psychology of Personal Constructs_ **[R]** (repertory grid).
+- Keeney, R.L. (1992) _Value-Focused Thinking_, Harvard University Press **[V]**.
+- Hollnagel, E. (2014) _Safety-I and Safety-II_, Ashgate; Hollnagel (2015) "From Safety-I to Safety-II: A White Paper" **[V]**; Hollnagel (2009) _The ETTO Principle_ **[R]**.
+- Zaremba, S. & Liaskos, S. (2021) "Towards a typology of questions for requirements elicitation interviews", _RE'21_, pp.384–389, doi:10.1109/RE51729.2021.00042 **[V]**.
+
+**Pack-content candidates.**
+
+- **Taxonomy card**: card sort → "what do these share, and what is the grouping for?" → the five laddering prompts verbatim → triadic probe on any group the expert hesitates over. Emphasise "how can you tell it is X?" and the key-difference probe.
+- **Objectives-and-weights card**: Keeney's five devices, then swing weighting. Never ask "what weight would you give it?"
+- **Work-as-done card**: negative-balance phrasing, then "who decides that?" and "who would notice if you didn't?"
+
+### 2.2 Other questions of the "bad day" type
+
+**Grounded answer.** The richest importable seam in the review. The team's single question is the
+tip of three catalogues, all now in hand verbatim.
+
+**Prospective hindsight / the premortem** is the strongest single result **[V]**: imagining an
+event _has already happened_ increases correctly-identified reasons for it by about **30%**
+(Mitchell, Russo & Pennington 1989), operationalised by Klein as the premortem. Applied here:
+_"It's a year from now and this line missed its worst month on record. Tell me what happened."_
+Strictly stronger than "what keeps you up at night?", because it licenses concrete causal
+narration rather than anxiety report.
+
+**The CDM deepening sweep, verbatim.** The probe table below is reproduced from the IHMC
+_Protocols for Cognitive Task Analysis_ manual **[V]**, which documents the CDM procedure in
+practitioner form. It is applied to a single specific incident that has already been narrated
+and timelined, one pass per event on the timeline:
+
+| Probe topic          | Probes                                                                                                                  |
+| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
+| Cues & knowledge     | "What were you seeing?"                                                                                                 |
+| Analogues            | "Were you reminded of any previous experience?"                                                                         |
+| Standard scenarios   | "Does this case fit a standard or typical scenario?" · "Does it fit a scenario you were trained to deal with?"          |
+| Goals                | "What were your specific goals and objectives at the time?"                                                             |
+| Options              | "What other courses of action were considered or were available?"                                                       |
+| Basis of choice      | "How was this option selected / other options rejected?" · "What rule was being followed?"                              |
+| Mental modelling     | "Did you imagine the possible consequences of this action?" · "Did you imagine the events that would unfold?"           |
+| Experience           | "What specific training or experience was necessary or helpful in making this decision?"                                |
+| Decision-making      | "How much time pressure was involved?" · "How long did it take to actually make this decision?"                         |
+| Situation assessment | "If you were asked to describe the situation to a relief officer at this point, how would you summarize the situation?" |
+| Errors               | "What mistakes are likely at this point?" · "How might a novice have behaved differently?"                              |
+| Hypotheticals        | "If a key feature of the situation had been different, what difference would it have made in your decision?"            |
+
+Three of these are worth singling out for our purposes. **Basis of choice** — "what rule was
+being followed?" — is a direct elicitation of the conflict-resolution policy that a net needs at
+every contention point (§5.1). **Situation assessment** via the handover framing is a
+remarkably efficient device: asking the expert to brief an incoming colleague extracts the state
+variables they consider decision-relevant, which is close to asking what the marking must
+record. And **options / errors** yield the guards and the exception paths.
+
+The separate **what-if sweep** is a distinct later pass **[V]**: "What might have happened
+differently at this point?" · "What were the alternative decisions that could have been made
+here?" · "What choices were not made or what alternatives were rejected?" · "At this point,
+what if it had been a novice present rather than someone with your level of proficiency — would
+they have noticed Y? Would they have known to do X?" · "What sorts of error might have been made
+at this point? Why might errors have occurred here?"
+
+**The ACTA knowledge audit** is the third catalogue and the most general-purpose, because it is
+explicitly a set of probes for knowledge experts have but do not volunteer. ACTA runs as **task
+diagram → knowledge audit → simulation interview**, feeding a **cognitive demands table**
+**[V]**. The eight probes, verbatim from a published application that adapted them from Militello
+& Hutton (1998) — shown in their domain-adapted form precisely because that demonstrates the
+adaptation move we will need **[V]**:
+
+| #   | Probe                       | Wording as used                                                                                                                       |
+| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | Past and future             | "Can you remember entering a coaching situation when you knew how things got there and where they were headed?"                       |
+| 2   | Big picture                 | "What are the big picture targets you are aiming for?" · "What are the main elements you need to track as things progress?"           |
+| 3   | Noticing                    | "Can you remember any element of a situation popping out at you that others did not notice?"                                          |
+| 4   | Tricks of the trade         | "Are there any ways of working that you have found to be more effective or efficient?" · "Who else is involved?"                      |
+| 5   | Improvising / opportunities | "Can you think of a time when you have improvised, or noticed an opportunity to do it better?"                                        |
+| 6   | Self-monitoring             | "Can you remember a time that you needed to change the way you were working to get a good outcome?" · "How did you make adjustments?" |
+| 7   | Anomalies                   | "Can you remember a time that you knew something was amiss?"                                                                          |
+| 8   | Information difficulties    | "Have you ever had a time that data or specialist input pointed in one direction, but your judgment suggested something else?"        |
+
+Two details matter as much as the probes **[V]**:
+
+- **A universal follow-up after every probe**: _"How would you know this? What cues and strategies are you relying on?"_ and _"How would this be difficult for a less-experienced person?"_ The expert–novice contrast used as a routine cue-extractor rather than a special technique — one rule that upgrades every other card.
+- **Probe 8 is the elicitation counterpart of trusting the data estate.** "The data pointed one way but your judgment said otherwise" is the question that surfaces where an ERP/MES/historian figure is systematically wrong — for this project a data-binding requirement, not a psychological nicety.
+
+ACTA guidance recommends **3–5 subject-matter experts** **[V]**, the closest thing found to a
+sampling rule for this kind of elicitation.
+
+**Key sources.**
+
+- Mitchell, D.J., Russo, J.E. & Pennington, N. (1989) "Back to the future: temporal perspective in the explanation of events", _Journal of Behavioral Decision Making_ 2(1):25–38 **[V]**; Klein, G. (2007) "Performing a project premortem", _Harvard Business Review_ 85(9):18–19 **[V]**.
+- Hoffman, R.R., Crandall, B., Klein, G., Jones, D.G. & Endsley, M.R. (2008) _Protocols for Cognitive Task Analysis_, Institute for Human and Machine Cognition **[V]** — full text read; source of the CDM probe tables above. The primary CDM paper is Klein, G.A., Calderwood, R. & MacGregor, D. (1989) "Critical decision method for eliciting knowledge", _IEEE Transactions on Systems, Man and Cybernetics_ 19(3):462–472, doi:10.1109/21.31053 **[C]** (closed access).
+- Militello, L.G. & Hutton, R.J.B. (1998) "Applied cognitive task analysis (ACTA)", _Ergonomics_ 41(11):1618–1641, doi:10.1080/001401398186108 **[C]**; Taylor, J., Ashford, M. & Jefferson, M. (2023) _Frontiers in Psychology_ 14:1154168, doi:10.3389/fpsyg.2023.1154168 **[V]** — open access, source of the verbatim knowledge-audit table; Brown, Power & Gore (2025) "Cognitive task analysis: eliciting expert cognition in context", _Organizational Research Methods_, doi:10.1177/10944281241271216 **[V]**, open access, also reproduces the four CDM sweeps and the ACTA tables.
+- Crandall, B., Klein, G. & Hoffman, R.R. (2006) _Working Minds_, MIT Press **[R]**.
+
+**Pack-content candidates.**
+
+- **Premortem card**: the "worst month on record, a year from now" prompt; demand mechanism and sequence, not sentiment.
+- **Incident-probe card (CDM, verbatim above)**: narrate one real incident, timeline it, then sweep per event. Prioritise _basis of choice_ (→ conflict policy), _situation assessment via handover_ (→ marking content), _options_ and _errors_ (→ guards and exception paths).
+- **Knowledge-audit sweep card (eight probes, verbatim above)**, translated to operational wording — probe 3 becomes "can you remember something in the line's behaviour that jumped out at you and that others walked past?"; probe 8 becomes "when did the system's numbers point one way and your judgment the other?"
+- **Universal cue follow-up rule**: after any substantive answer — "how would you know that? what are you actually looking at?" and "how would this be hard for someone less experienced?"
+
+### 2.3 Do constructed hypotheticals work? Failure modes?
+
+**Grounded answer.** The literature splits, and the split is the useful part.
+
+**In favour, conditionally.** CDM has an entire dedicated what-if sweep **[V]**, so hypotheticals
+are endorsed by the strongest tradition here — but they are always **anchored to a real
+remembered incident** already narrated and timelined. The hypothetical _varies a case_; it does
+not invent one.
+
+**Against, when free-floating.** The stated-preference literature is the best available evidence
+on what happens when people answer about imagined situations, and it finds systematic
+distortion: a meta-analysis of studies eliciting both hypothetical and actual values with the
+same mechanism found a **median hypothetical-to-actual ratio of 1.35** with severe positive
+skew, with the broader literature reporting median bias from 25% to 300% **[V]**. The mechanism
+transfers: an expert asked "what would you do if…" reports the behaviour of an idealised self —
+which is **work-as-imagined**, the thing we were trying to get behind.
+
+**The named failure mode**: an unanchored hypothetical returns the expert's _policy_ (what they
+believe they should do) rather than their _practice_, fluently and confidently, which makes it
+hard to detect downstream. Mitigations, both grounded: anchor to a specific narrated incident
+before varying it; and ask for **cues and mechanism** rather than the decision outcome — "what
+would you be looking at?" is far more reliable than "what would you decide?"
+
+**Key sources.** Murphy, J.J., Allen, P.G., Stevens, T.H. & Weatherhead, D. (2005) "A
+meta-analysis of hypothetical bias in stated preference valuation", _Environmental and Resource
+Economics_ 30(3):313–325 **[V]**; List, J.A. & Gallet, C.A. (2001), _ERE_ 20:241–254 **[V]**;
+Hoffman et al. (2008) **[V]**; Hollnagel (2014/2015) **[V]**.
+
+**Pack-content candidates.**
+
+- **Hypothetical-escalation card with a precondition**: escalate only _after_ a real incident is on record, and phrase the variation against it.
+- **Policy-vs-practice detector**: when an answer arrives in normative language ("we would…", "the rule is…"), follow with "when did that last actually happen, and what did you do?" A hypothetical that cannot be grounded in an instance is recorded at low confidence.
+
+### 2.4 (added) Which technique, and how many — the efficiency evidence
+
+This subsection did not correspond to an inventory question but answers one the inventory
+implies: how should the elicitor _choose_ among these techniques, and does the choice matter
+quantitatively? It does, by roughly an order of magnitude.
+
+**Yield differs enormously by technique** **[V]**. Hoffman's comparison reports: unstructured
+interview ≈ 0.8 propositions per question and ≈ 0.13 propositions per task-minute; structured
+interview ≈ 1 new proposition per task-minute (with ~30% of first-pass propositions subsequently
+modified); and contrived methods — limited-information tasks, constrained-processing tasks,
+tough-case analysis — yielding 1–2 observation plus 1–2 inference propositions per task-minute.
+The summary rule of thumb: ~3 per minute is excellent, ~2 is on track, ~1 signals inefficiency.
+Most striking, unstructured-interview yield **collapses over time**: ~1.6 per minute in the first
+five hours against 0.13 averaged across 100 hours. The later methodological analysis gives the
+same ordering: unstructured under 1 informative proposition per total task-minute, structured
+≈1, contrived and tough-case 2–3 **[V]**.
+
+**But contrived tasks cannot stand alone** **[V]**. A four-method comparison (structured
+interview, think-aloud protocol analysis, laddered grid, card sort) across three domains found
+protocol analysis the most time-consuming and least productive, and found contrived tasks as
+informative as interviews in less time — _but_ that they "needed to be used in conjunction with
+an interview since they elicited specific knowledge and did not yield an overview of the domain
+knowledge."
+
+**Together these prescribe a two-phase architecture**: a short overview interview to get the
+domain map and the objectives, then a rapid switch into structured and contrived modes for the
+bulk of the work. The elicitor should not stay in open-ended conversational mode — that is the
+lowest-yield mode available, and its yield decays.
+
+**The differential access hypothesis, corrected** **[V]**. The strong version — that certain
+knowledge can _only_ be elicited by particular techniques — is contentious and not established.
+The field has shifted to **differential utility**: techniques are "scaffolds" establishing
+conditions under which articulation is more or less likely, and each has strengths and
+weaknesses, some procedural and some about the content elicited. The practical consequence is
+unchanged and important for pack design: **mix techniques deliberately**, because no single mode
+reaches everything, but do not believe that a specific probe is the only key to a specific kind
+of knowledge.
+
+**A caution on tacit knowledge and "why" questions.** Two classic results bound what direct
+questioning can achieve. People have "little or no direct introspective access to higher order
+cognitive processes", and reports about their own reasoning are often based on implicit causal
+theories rather than observation **[V]**. And verbal reports are valid _data under conditions_:
+concurrent verbalisation of currently-heeded content is reliable, whereas retrospective
+questions about motives and reasons address content that "may not be available directly or even
+at all" **[V]**. The pack-content rule that follows is concrete: **prefer "walk me through a
+specific occasion — what were you attending to?" over "why do you do it this way?"** The CDM and
+knowledge-audit probes above are all built this way, which is not a coincidence.
+
+**On the "knowledge acquisition bottleneck".** Widely invoked, but **not attributable to a
+single coiner** **[V]**. Hoffman (1987) calls knowledge extraction "widely regarded as the major
+bottleneck", citing a cluster of early-1980s expert-systems sources; the 1995 methodological
+analysis says elicitation "can be the most time-consuming and difficult stage in constructing a
+working program" and credits the phrase's currency to late-1980s books and reviews. Cite it as
+"widely regarded", with that trail — not as Feigenbaum's phrase.
+
+**Key sources.**
+
+- Hoffman, R.R. (1987) "The problem of extracting the knowledge of experts from the perspective of experimental psychology", _AI Magazine_ 8(2):53–67, doi:10.1609/aimag.v8i2.583 **[V]** (Tables 1 and 7 read from rendered page images).
+- Hoffman, R.R., Shadbolt, N.R., Burton, A.M. & Klein, G. (1995) "Eliciting knowledge from experts: a methodological analysis", _Organizational Behavior and Human Decision Processes_ 62(2):129–158 **[V]**. Also contains the guild proficiency scale — naivette / novice / initiate / apprentice / journeyman / expert / master — with "expert" defined as one "whose judgments are uncommonly accurate… who can deal effectively with rare or 'tough' cases" **[V]**. That definition is a usable screening criterion for choosing an interviewee.
+- Burton, A.M., Shadbolt, N.R., Rugg, G. & Hedgecock, A.P. — four-method comparison, reported in Hoffman et al. (1995) p.144 **[V]** (primary unavailable).
+- Hoffman, R.R. & Lintern, G. (2006) "Eliciting and representing the knowledge of experts", in Ericsson et al. (eds) _The Cambridge Handbook of Expertise and Expert Performance_, pp.216–217 **[V]**.
+- Nisbett, R.E. & Wilson, T.D. (1977) "Telling more than we can know: verbal reports on mental processes", _Psychological Review_ 84(3):231–259 **[V]**.
+- Ericsson, K.A. & Simon, H.A. (1980) "Verbal reports as data", _Psychological Review_ 87(3):215–251 **[V]**.
+
+**Pack-content candidates.**
+
+- **Two-phase interview architecture**: bounded overview first (objectives, task diagram, domain map), then switch to structured and contrived probes. Time-box the open-ended phase explicitly.
+- **Yield monitor**: track new propositions per minute; a sustained drop toward ~1 is the signal to change technique, not to ask more open questions. This is also a candidate PRO-104 metric (see shortlist).
+- **No-bare-why rule**: never ask "why do you do it this way?" as a primary probe; ask for an occasion and for what was attended to.
+
+---
+
+## Section 3 — Structure: invented or assembled?
+
+### 3.1 How much is motif instantiation? Can the catalogue be enumerated?
+
+**Grounded answer: qualified yes — but the shape of the catalogue matters more than its
+existence, and the literature is sharply divided on that shape.**
+
+**Evidence for a finite idiom set.**
+
+- **Workflow control-flow patterns**, derived empirically by surveying workflow products and languages **[V]**. The original twenty, with the 2003 category headings: _Basic Control Flow_ — 1 Sequence, 2 Parallel Split, 3 Synchronization, 4 Exclusive Choice, 5 Simple Merge; _Advanced Branching and Synchronization_ — 6 Multi-choice, 7 Synchronizing Merge, 8 Multi-merge, 9 Discriminator; _Structural_ — 10 Arbitrary Cycles, 11 Implicit Termination; _Multiple Instances_ — 12 MI Without Synchronization, 13 MI With a Priori Design Time Knowledge, 14 MI With a Priori Runtime Knowledge, 15 MI Without a Priori Runtime Knowledge; _State-based_ — 16 Deferred Choice, 17 Interleaved Parallel Routing, 18 Milestone; _Cancellation_ — 19 Cancel Activity, 20 Cancel Case.
+- The revised catalogue reaches **43 in eight categories** **[V]**: Basic Control Flow (5), Advanced Branching and Synchronization (14), Multiple Instance (7), State-based (5), Cancellation and Force Completion (5), Iteration (3), Termination (2), Trigger (2). Crucially, **the revision is disambiguation by parameter extraction, not additive noise**: the original Synchronizing Merge became three patterns differing in evaluation locality, and the original Discriminator became six on the cross-product {discriminator, partial-join-with-threshold-_n_} × {structured, blocking, cancelling}. That is exactly the "which pattern, with what parameters" shape an interviewer wants.
+- **Workflow resource patterns** — 43 in seven categories (Creation 11, Push 9, Pull 6, Detour 9, Auto-Start 4, Visibility 2, Multiple Resource 2) **[V]**, and methodologically the strongest of the catalogues because the patterns are _generated_ as labelled transitions on a work-item lifecycle state machine (created → offered → allocated → started → completed, plus withdrawn/failed) rather than collected anecdotally. For operational systems this is the most relevant catalogue, and it is the one the team's motif list (queue, resource pool, failure/repair, changeover, inspection) most resembles. Names worth having: Retain Familiar, History-Based Distribution, Shortest Queue, Round Robin Allocation, Delegation, Escalation, Deallocation, Suspension-Resumption, Piled Execution, Chained Execution, Simultaneous Execution, Additional Resources.
+- **Exception handling patterns** are the best interview artifact in the whole corpus, because they are not a list but a **tuple space** **[V]**: ⟨work-item strategy, case-level strategy, recovery action⟩ raised in the context of an exception type. Exception types (5): Work Item Failure, Deadline Expiry, Resource Unavailability, External Trigger, Constraint Violation. Work-item strategies (15), case-level (3: continue workflow case / remove current case / remove all cases), recovery (3: no action / rollback / compensate) — the paper notes 15×3×3 = 135 conceivable patterns, of which only those applicable to each exception type are tabulated. Empirically, across eight systems only deadline expiry was widely supported and **zero offerings supported resource-unavailability exceptions** — which is a strong hint about where real elicitation effort should go.
+- **Petri-net-specific**: the one real CPN pattern catalogue lists **34 patterns** **[V]** — including ID Matching, ID Manager, Aggregate Objects, Queue, FIFO/LIFO/Random/Priority Queue, Capacity-Bounding, Inhibitor Arc, Shared Database, Lock Manager, Log Manager, four Filter variants, Translator, Asynchronous/Synchronous Transfer, Rendezvous, Asynchronous Router/Aggregator, Broadcasting, Redundancy Manager, Data Distributor, Data Merge, Deterministic and Non-deterministic XOR-split, OR — classified as ⟨common component, diagnostic element, supplementary component⟩. Its opening premise is our hypothesis nearly verbatim: experienced Petri-net modellers model in terms of patterns, as object-oriented programmers use design patterns, and no structured collection existed. It also disclaims completeness, being "the result of an explorative work… not derived in a systematic manner", and **no successor exists** — so it is simultaneously the state of the art and evidence that the field never institutionalised this.
+- **Reliability and maintenance is the strongest case in the survey** **[V]**. Dynamic fault tree gates are a finite, standardised, parameterised motif set _with published Petri-net translations_: on top of static AND/OR/VOTE-_k_, the set is PAND (priority-AND), POR (priority-OR), FDEP (functional dependency), PDEP (probabilistic dependency), SEQ (sequence enforcing), and SPARE parameterised by spare type cold/warm/hot. Thirty years of literature treat this as fixed vocabulary, and a 2018 paper gives gate-by-gate GSPN templates. Adjacent settled taxonomy: cold/warm/hot standby, _k_-out-of-_n_, imperfect coverage (switch succeeds with probability _c_ < 1) as a sub-motif nesting inside the others, and a reusable **repair box** module parameterised by number of repairmen and priority rules.
+- **The strongest practical evidence is commercial** **[V]**: simulation tools ship closed block vocabularies — GPSS's 53 blocks; Arena's Basic Process (Create, Dispose, Process, Decide, Batch, Separate, Assign, Record), Advanced Process (Delay, Hold, Seize, Release, Search, Store, Match, Pickup, Dropoff, Gather, Signal…) and Advanced Transfer (Enter, Leave, Station, Route, Access, Convey, Request, Transport…); Simio's Server, Source, Sink, Rework, Combiner, Separator, Workstation, Worker, Resource, Vehicle, Conveyor. With the honest caveat that vendors _chose_ these vocabularies — closure is a design decision, not a discovered completeness result.
+
+**Evidence against the strong version — and this is where it gets interesting.**
+
+- **A correction to our own brief**: the standard GSPN textbook has **no "modelling paradigms / building blocks" chapter** **[V]**. Its own self-description is a set of illustrative examples from different application fields. **Do not cite it as evidence for a finite idiom set.** Where the GSPN tradition _is_ genuinely parameterised is transition semantics, and that is tool-enforced and exhaustively interviewable **[V]**: the **random switch** (immediate transitions in conflict resolved by normalised weights), race policy for timed conflicts, priority levels, inhibitor arcs, memory policy (enabling- vs age-memory), and a closed four-option **server-semantics** parameter — Infinite / _K_-Server (K=1 single, 2–127 multiple) / Marking-Dependent / Load-Dependent. That quiver is small, closed, and the right size to interview against.
+- **The reduction argument is the most consequential finding in this section** **[V]**. Börger's critique holds that the pattern catalogues come "without pragmatic or rational foundation", that there is "no statistical underpinning showing how frequently which patterns appear in real-life business processes", and that the growth from 20 to 43 to 126 patterns has no shown _fundamentum in re_ or limit. His positive claim: most patterns "resemble very much molecules rather than fundamental elements", and all 43 control-flow patterns can be defined as instantiations of **eight generic schemes — four sequential and four parallel** — whose parameters are the instantiation points. He also quotes the pattern authors' own concession that "the selection of these patterns was done in an ad-hoc manner", and notes an independent reduction of 43 to 25 (claimed reducible below 18). The rebuttal defends patterns as deliberately informal and says users "should first analyze which patterns they need" — but **does not answer the reduction argument at all** **[V]**.
+- **Frequency data is contaminated.** The catalogues were derived from _tools_ (15 products in 2003, 14 in the revision), and an independent study of five industrial projects found a **positive correlation between patterns used and patterns the chosen tool supports well** **[V]** — so pattern frequency partly measures tooling, not plants. Relatedly, van der Aalst's process-mining experience across 100+ organisations: typically **~80% of process instances fit a rather simple model, and the remaining 20% need the advanced patterns** **[V]**. That 80/20 is the honest prior for a motif catalogue: a small core will cover most behaviour, and the tail is where the modelling difficulty lives.
+- **Names are stable; semantics are not** **[V]**. Inclusive vs. exclusive PAND, early vs. late spare claiming, and a naming drift within the workflow catalogue itself are all live. An interview keyed on pattern _names_ alone yields ambiguous nets: you need **name plus variant selector**.
+- **The middle altitude is missing, and this is a real gap rather than a search failure** **[V]**. Between formal primitives (net algebra, transition semantics, hybrid constructs) and whole-application templates (a specific kanban system, a specific bridge model) there is **no institutionalised catalogue of operational motifs**. Setup/changeover, inspection/rework loop, batching/unbatching, AGV transport exist as named blocks in _simulation languages_ and as bespoke subnets in individual papers, but were never lifted into a named, cross-cited net-idiom set. Breakdown-and-repair has one name only in the deadlock-control literature ("recovery subnets"); kanban fragments into control-policy variants rather than one module. **This is precisely the altitude the team's motif catalogue would occupy** — which means the catalogue is a genuine contribution rather than a re-implementation, and also that there is no published list to copy.
+
+**Verdict.** A motif catalogue is **well supported as an interview scaffold and gap-detector, and
+poorly supported as a structure generator**. Its highest-value use is obligation-checking: "you
+have described a buffer but not what happens when it is full"; "you have two transitions
+competing for one resource and no rule". That use survives the absence of frequency data,
+because it only requires that each motif have known obligatory parameters.
+
+And the design consequence of Börger's argument is specific: build a **small quiver of
+parameterised schemes with explicit variant selectors**, not a long enumerated menu. The
+resource-pattern catalogue (generated from a lifecycle state machine), the exception tuple space,
+the GSPN server-semantics options, and the DFT gate set with its spare-type parameter are the
+four models to imitate — every one of them is a small closed set of _axes_, not a list.
+
+### 3.2 Cyber-physical-specific motifs
+
+**Grounded answer, including one finding that complicates our framing.**
+
+- **Degradation with inspection / condition-based maintenance** is the motif family most likely to genuinely require per-entity continuous state (§6). Well populated in the literature but **individually engineered** — no canonical named template, and no paper found encoding the standard delay-time inspection model as a named Petri-net motif **[V]**.
+- **Hybrid / fluid structures** where token counts make discrete tokens the wrong abstraction: David & Alla's primitives (continuous place, C-transition with maximal and instantaneous firing speeds, marking-dependent speeds, conflict resolution as an explicit formal problem) are a **closed primitive algebra but were never assembled into an application-level motif catalogue** **[V]**. Note the direction of travel: continuous approximation _reduces_ cost, so "continuous" is sometimes a simplification, not an escalation. The fluid-queue idiom — a discrete driving chain modulating a continuous level — is the one genuinely recurring composite **[V]**.
+- **Sensing–actuation loops**, including honest treatment of sensor error and latency. The ACTA "information difficulties" probe is the elicitation counterpart.
+- **Digital-twin synchronisation via Petri nets is genuinely thin** **[V]** — scattered papers, no catalogue, no shared naming. If the September demo leans on this, it will be inventing rather than instantiating.
+
+**The complication worth flagging.** The most thoroughly verified real-world asset-management
+Petri-net model found (railway track) decomposes as **nine sub-models, one per physical component
+type**, instantiated nine times and coupled by shared places — 98 places and 61 transitions in
+total — with **each sub-model bundling degradation, failure, inspection and maintenance
+together** **[V]**. That is _not_ "degradation subnet × inspection subnet × maintenance subnet,
+mix and match". If our interview design assumes functional-role modules that compose
+orthogonally, the strongest primary evidence available backs a different decomposition: per-object-type
+templates with internal lifecycles. Worth resolving deliberately before the catalogue is fixed,
+and it connects to the case-notion problem in §9.
+
+**Key sources.**
+
+- van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B. & Barros, A.P. (2003) "Workflow patterns", _Distributed and Parallel Databases_ 14(1):5–51 **[V]** (note: workflowpatterns.com miscites the issue as 14(3)); Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P. & Mulyar, N. (2006) "Workflow control-flow patterns: a revised view", BPM Center Report BPM-06-22 **[V]**.
+- Russell, N., ter Hofstede, A.H.M., Edmond, D. & van der Aalst, W.M.P. (2004/2005) "Workflow resource patterns", BETA Working Paper WP 127, TU/e; CAiSE'05, LNCS 3520:216–232 **[V]**. Workflow data patterns: 40 in four categories **[V]**.
+- Russell, N., van der Aalst, W.M.P. & ter Hofstede, A.H.M. (2006) "Workflow exception patterns", BPM-06-04; CAiSE'06, LNCS 4001:288–302 **[V]**.
+- Mulyar, N. & van der Aalst, W.M.P. (2005) "Patterns in coloured Petri nets", BETA Working Paper WP 139, TU/e **[V]**.
+- Börger, E. (2012) "Approaches to modeling business processes: a critical analysis of BPMN, workflow patterns and YAWL", _Software and Systems Modeling_ 11(3):305–318 **[V]**; Börger (2007) "Modeling workflow patterns from first principles", ER 2007, LNCS 4801:1–20 **[C]** (the eight schemes; the 4+4 split is verified from his later work, the scheme _names_ are not); van der Aalst, W.M.P. & ter Hofstede, A.H.M. (2012) "Workflow patterns put into context", _SoSyM_ 11(3):319–323 **[V]**.
+- GreatSPN 2.0.2 manual, Università di Torino **[V]** (server semantics, random switch, priorities, compositionality). Ajmone Marsan, M., Balbo, G., Conte, G., Donatelli, S. & Franceschinis, G. (1995) _Modelling with Generalized Stochastic Petri Nets_, Wiley **[V]** — cited here **only** to record that it does not contain a building-block catalogue.
+- Zhou, M. & DiCesare, F. (1993) _Petri Net Synthesis for Discrete Event Control of Manufacturing Systems_, Kluwer **[V]** — Parallel and Sequential Mutual Exclusion; three-step hybrid synthesis (top-down modular refinement, then stepwise addition of non-shared then shared resource places) with conditions preserving boundedness, liveness and reversibility. Ezpeleta, J., Colom, J.M. & Martínez, J. (1995) _IEEE T-RA_ 11(2):173–184 **[V]** — S³PR; deadlocks ⇔ unmarked siphons.
+- Dugan, J.B., Bavuso, S.J. & Boyd, M.A. (1992) _IEEE Transactions on Reliability_ 41(3):363–377, doi:10.1109/24.159800 **[V]** (DFT gates); Junges, S., Katoen, J.-P., Stoelinga, M. & Volk, M. (2018) "One net fits all: a unifying semantics of dynamic fault trees using GSPNs", Petri Nets 2018, LNCS 10877, arXiv:1803.05376 **[V]**; Bobbio, A. & Codetta-Raiteri, D. (2004) RAMS, doi:10.1109/RAMS.2004.1285491 **[V]** (repair box); Trivedi, K.S. & Bobbio, A. (2017) _Reliability and Availability Engineering_, Cambridge University Press **[V]**.
+- David, R. & Alla, H. (2010) _Discrete, Continuous, and Hybrid Petri Nets_, 2nd ed., Springer, doi:10.1007/978-3-642-10669-9 **[V]**; Trivedi, K.S. & Kulkarni, V.G. (1993) "FSPNs: fluid stochastic Petri nets", ICATPN'93 **[V]**.
+- Litherland, J. & Andrews, J. (2023) _Proc. IMechE Part F_, doi:10.1177/09544097221110970 **[V]** (nine per-component sub-models).
+
+**Five completeness disclaimers to quote against ourselves** **[V]** — worth keeping, because
+they are the honest frame for any catalogue we publish: pattern identification is "by definition
+an experiental activity and it is not possible to guarantee the completeness of any patterns
+collection"; the CPN patterns "do not claim… completeness"; the 2003 patterns "do not claim to be
+the only way of addressing the business requirements"; the composition-relationship list "is not
+exhaustive"; and the DFT GSPN gate set is framed as extensible, not canonical.
+
+**Pack-content candidates.**
+
+- **Motif-as-obligation card**: each motif ships with its obligatory questions — a buffer needs capacity plus full-behaviour (block / spill / divert); a resource pool needs size, claim discipline and contention rule; failure/repair needs a trigger (time- or usage-based), a repair-duration distribution, and a repair resource; changeover needs to say whether it depends on from-state, to-state or both.
+- **Variant-selector rule**: never record a motif by name alone; always record name plus the variant axis (e.g. spare = cold/warm/hot; merge = structured/local/general; server = infinite/K/marking-dependent/load-dependent).
+- **Exception sweep card**: for each of the five exception types, ask the three tuple questions — what happens to the work item, what happens to the case, and what recovery action. Prioritise resource unavailability, which tooling systematically ignores.
+- **Do not synthesise from the catalogue**: an explicit anti-card. The catalogue drives questions and gap-detection; structure comes from the expert's account.
+
+---
+
+## Section 4 — When are you done?
+
+### 4.1 Is there a minimal category set?
+
+**Grounded answer — and the team's list is missing three things.** Robinson's conceptual model
+content set **[V]**: modelling objectives; responses/outputs; experimental factors/inputs; scope;
+level of detail; **assumptions**; **simplifications**. Law adds the **assumptions document** as
+the physical artifact, with a seven-item contents list **[V]**. Sargent adds **data validity**
+and the **domain of intended applicability** **[V]**.
+
+Robinson's four requirements for a conceptual model are **validity, credibility, utility and
+feasibility** **[V]**, and his **assumptions/simplifications distinction is precise**:
+_assumptions_ arise from limited knowledge or uncertainty about the real system (a
+knowledge-acquisition problem); _simplifications_ are deliberate model abstractions adopted from
+a desire for simpler, faster models (a design decision) **[V]**. They therefore have different
+lifecycles — assumptions are elicitation backlog, simplifications are decisions to be defended —
+and collapsing them into one "limitations" section destroys the distinction that tells you what
+to go back and ask about.
+
+His **scope** and **level of detail** decisions are recorded in tables with explicit
+**Include / Exclude / Justification** columns **[V]**. That is the artifact shape our
+intermediate representation should adopt for boundaries: not prose, but a decision table where
+every exclusion carries a reason.
+
+Simplification catalogues exist and are worth having as prompts **[V]**: Robinson's own list
+comprises black-box modelling, grouping entities, replacing components with random variables,
+excluding infrequent events, reducing the rule set, and splitting models — with Zeigler's four
+and Morris's five as the older enumerations.
+
+Compared with the team's candidate set (structure/topology, types & colours, rates &
+distributions, initial marking, objective & penalties, constraints, data bindings, validation
+data), the literature adds:
+
+1. **Experimental factors** — what the user will _vary_. No slot for this currently, and without it there is no way to know what must be parameterised.
+2. **Domain of applicability and accuracy bar** — the conditions over which validity is claimed and how close is close enough, set _before_ building **[V]**.
+3. **Assumptions vs. simplifications, separated, each justified** **[V]**.
+
+### 4.2 Is completeness question-relative? Should the elicitor elicit the questions first?
+
+**Grounded answer: yes, and this is the most quotable result in the review.** Sargent, verbatim
+**[V]**:
+
+> "A model should be developed for a specific purpose (or application) and its validity
+> determined with respect to that purpose. If the purpose of a model is to answer a variety of
+> questions, the validity of the model needs to be determined with respect to each question."
+
+and
+
+> "This usually requires identifying the model variables of interest (i.e., the model variables
+> used in answering the questions that the model is being developed to answer) and specifying the
+> required acceptable range of accuracy for each variable."
+
+That is the "questions the model answers" table arriving from the V&V literature as a
+_precondition for validity_ rather than as documentation. It settles 4.2 affirmatively: elicit
+the questions first, because they are simultaneously the scope criterion, the completion
+criterion and the validation criterion.
+
+**Stopping rules: what the literature says about when interviewers actually stop.** Requirements
+research identifies four cognitive stopping rules **[V]** — two judgment-based: the **magnitude
+threshold** rule (belief in sufficiency must reach a preset level) and the **difference
+threshold** rule (stop when the marginal value of the latest information falls below a
+threshold); and two reasoning-based: the **mental list** rule (stop when a schema-derived list is
+complete) and **representational stability** (stop when the internal representation of the
+problem is no longer being developed). The reported problem is that analysts **stop too soon**,
+producing underspecification, and the proposed remedy is a **strategic prompting tool** built
+from argument types (causation, generalization, analogy) and argument strategies (building
+scenarios, elaborating with instances, generating counterarguments), which outperformed a
+syntactic who/what/why/where/when/how control.
+
+Two honest caveats. First, the conference paper that sets out this taxonomy contains **no results
+section** — it states that analysis "will be completed by May 1998 and presented at the
+conference" — so the taxonomy is citable from it but the empirical claims need the later journal
+treatment **[V]**. Second, do not import qualitative **saturation** thresholds (~80% of codes in
+the first six interviews; thematic saturation around twelve) as a completeness criterion **[V]**:
+they concern theme discovery across a population of informants, not sufficiency of a single
+system description.
+
+For our purposes the useful part is direct: **representational stability is the stopping rule an
+LLM elicitor will naturally implement** (it stops when its model stops changing), and it is one of
+the two rules associated with premature stopping. The counter-measure is to make stopping
+_criterion-based_ — the §4.1 category set plus the questions table — rather than
+stability-based, and to fire a clearinghouse probe (§5) before closing.
+
+### 4.3 Fact-list, or behavioural criterion?
+
+**Grounded answer: both, in sequence — and the literature names each.**
+
+The **fact-list** answer is Law's assumptions document, whose distinctive feature is not the
+document but its acceptance test: validation in a **structured walkthrough** with the
+subject-matter experts before any code is written **[V]**. Law's procedure is specific — the
+document is projected and walked bullet by bullet in a meeting, and pre-circulating it for
+private reading is explicitly _not_ a substitute, because the value is in the collective
+challenge. That is a _social_ completion test and a better fit for the elicitor than an internal
+checklist, because it produces a reviewable artifact the expert signs off.
+
+The **behavioural** answer is Sargent's, and he names the two criteria the team intuited **[V]**:
+
+- **Historical data validation**: "part of the data is used to build the model and the remaining data are used to determine (test) whether the model behaves as the system does" — reproduce a historical period.
+- **Turing tests**: "Individuals who are knowledgeable about the operations of the system being modeled are asked if they can discriminate between system and model outputs." This is exactly "yes, that's our Friday pile-up" — an established technique with published statistical treatment, not a soft heuristic.
+- **Face validity**: "Individuals knowledgeable about the system are asked whether the model and/or its behavior are reasonable" — the weaker, earlier-available cousin.
+
+Sargent is also explicit that conceptual-model validation's primary techniques are **face
+validation and traces**, and that face validation there "usually requires examining the flowchart
+or graphical model … or the set of model equations" **[V]** — direct support for the
+deterministic natural-language-summary requirement (FE-1335): the expert cannot face-validate
+what they cannot read.
+
+**So**: the fact-list is the right _intermediate_ completion artifact because it is what can be
+walked through before a model exists; the behavioural criteria are the right _final_ ones; they
+are ordered, not competing.
+
+### 4.4 When the simulation matches the spreadsheet too well
+
+**Grounded answer — assembled, because nothing addresses this directly.**
+
+First, **agreement with an analytic calculation is a recognised verification technique, not a
+warning sign** — Sargent, verbatim **[V]**: "Comparison to Other Models: … (1) simple cases of a
+simulation model are compared to known results of analytic models". The existing practice — net
+with failures off must reproduce the spreadsheet formula — is textbook, and should be kept.
+
+Second, agreement in the **full** case is different, and queueing theory supplies a quantitative
+discriminator. The Kingman/VUT relation gives queue time ≈ `((c_a² + c_e²)/2) · (u/(1−u)) · t_e`
+**[V]** — so a stochastic model _should_ diverge from a deterministic one when utilisation is
+high or coefficients of variation are large, and genuinely _should not_ when both are low. That
+turns "suspect a missing coupling" into a check.
+
+Ordered checklist when they agree too well:
+
+1. **Compute utilisation of the binding resource.** If it is low and CVs are small, the agreement is probably genuine — a simple system, and the simulation is not earning its keep.
+2. If utilisation is high, agreement is suspicious. Then:
+3. **Was any distribution replaced by its mean?** Law warns about this specifically **[V]**; the single most common way variability silently disappears.
+4. **Is there any coupling making stages non-independent** — blocking from a finite buffer, a shared resource or operator, a sequence-dependent setup? Independent stages with mean service times _is_ the spreadsheet, re-implemented.
+5. **Run the extreme condition test** — Sargent, verbatim: "The model structure and outputs should be plausible for any extreme and unlikely combination of levels of factors in the system", with his example: "if in-process inventories are zero, production output should usually be zero" **[V]**.
+6. **Degenerate test** — Sargent: "does the average number in the queue of a single server continue to increase over time when the arrival rate is larger than the service rate?" **[V]** A model that does not blow up when it should has no queueing wired in.
+
+The underlying principle — a deterministic calculation and a stochastic model answer different
+questions, and the average of a function is not the function of the average — is the "flaw of
+averages" / Jensen's inequality framing **[R]**.
+
+**Key sources.**
+
+- Sargent, R.G. (2011) "Verification and validation of simulation models", _Proceedings of the 2011 Winter Simulation Conference_, pp.183–198 **[V]** — full text read; all quotations above. **Version note**: "Fixed Values" appears in the 1999 and 2000 versions (16 techniques) and was dropped from 2005 onward (15). For the complete list cite **Sargent (1999)**, WSC, informs-sim.org/wsc99papers/005.PDF **[V]**.
+- Law, A.M. (2022) "How to build valid and credible simulation models", WSC, informs-sim.org/wsc22papers/128.pdf **[V]** — seven-step approach, seven-item assumptions-document contents, structured walkthrough procedure.
+- Robinson, S. (2008) Part I **[V]**; Part II **[C]**; Robinson's WSC tutorials 2013/2015/2017 **[V]**.
+- Kingman, J.F.C. (1961) _Proc. Cambridge Philosophical Society_ 57:902–904; Hopp, W.J. & Spearman, M.L. _Factory Physics_ **[V]**.
+- Pitts, M.G. & Browne, G.J. (1998) "Investigating evaluative stopping rules in information requirements determination", _AMCIS 1998 Proceedings_ 265 **[V]**; the stopping-rule constructs derive from Nickles, Curley & Benson (1995) **[V]**; the fuller empirical treatment is Browne & Pitts (2004), _Organizational Behavior and Human Decision Processes_ **[R]**.
+- Guest, G., Bunce, A. & Johnson, L. (2006) _Field Methods_ 18(1):59–82 **[V]**; Hennink, Kaiser & Marconi (2017) **[V]**.
+- Savage, S.L. (2009) _The Flaw of Averages_ **[R]**.
+
+**Pack-content candidates.**
+
+- **Definition-of-done card**: the literature's minimal set — objectives, responses, experimental factors, scope, level of detail, assumptions, simplifications, accuracy bar, domain of applicability, data validity — explicitly including experimental factors and the accuracy bar.
+- **Assumption/simplification splitter**: every limitation tagged as one or the other; assumptions become elicitation backlog, simplifications become defended decisions.
+- **Include/Exclude/Justification tables** for scope and level of detail, adopted verbatim as the boundary artifact.
+- **Criterion-based stopping**: never stop because the model stopped changing; stop on the category set plus the questions table, and fire a clearinghouse probe first.
+- **Walkthrough card**: the completion ritual is reading the fact-list back for sign-off — projected and walked item by item, not circulated for silent review.
+- **Too-good-agreement card**: the six-step checklist above, utilisation first.
+
+---
+
+## Section 5 — How do you cross-examine?
+
+### 5.1 Standard traps and tests
+
+**Grounded answer — the best finding is that the formalism generates its own cross-examination.**
+Three of the team's candidate traps have exact formal counterparts, so they can be run
+mechanically on the elicited structure and turned back into questions.
+
+- **Token conservation** ("where do these come from / go?") is the informal version of a **place invariant**: a weighted token count constant across firings. Asking what is conserved is asking for the invariants, and each elicited invariant becomes a checkable property.
+- **Structural completeness** has a canonical test: **workflow-net soundness** — (i) _option to complete_: from any reachable marking the final marking is still reachable; (ii) _proper completion_: when the end place is marked, all others are empty; (iii) _no dead transitions_ **[V]**. Each violation converts into a question. A dead transition means "you described this step but nothing can trigger it — when does it actually happen?" A lost option to complete means "there is a state your process can reach and never leave — is that a real deadlock you experience, or did I miss a recovery path?" The recovery path the expert then describes is exactly the unwritten knowledge §2 is chasing.
+- **Conflict policy** is _forced_ by the semantics rather than optional: two transitions sharing an input place require a priority, a weight, or a policy **[V]**. The elicitor needs no interviewing instinct to ask — the structure obliges it. And CDM's _basis of choice_ probe ("what rule was being followed?") is the matching human-side question.
+- **Assumed-vs-emergent** has a precise detector: Robinson's **experimental factor vs. response** distinction **[V]**. Throughput offered as an input is a response mis-filed as a factor.
+- **Data-vs-decision conflation** is a recognised failure with a recognised remedy: **separate decision logic from process logic**, the rationale for pairing decision tables with process models — decision logic encoded in control flow produces unmaintainable "spaghetti" **[V]**. The elicitation counterpart is to record the _decision rule_ as a distinct object with its own inputs rather than as a property of an arc.
+- **Boundary probing** is Robinson's simplifications register plus the Include/Exclude/Justification tables, and asking for it explicitly is recommended practice, not a trap **[V]**.
+
+**A ready-made probe set for cross-examination.** The interview-question typology supplies
+several verbatim moves that are exactly what an LLM elicitor is unusually well placed to
+execute, because it holds the whole transcript **[V]**:
+
+- **Consistency probe**: "You said earlier that **_ but then you told me _**. How do you explain that?"
+- **Clearinghouse probe**: "What have I not asked that is important in this process?" · "Is there anything else I should know?"
+- **Comparison/contrast**: "Can you tell me about the situation in department X…? How is it the same or different from what happens in your department?"
+- **Interpreting / check-reflect / restatement**: "You then mean that…?" · "So it takes a lot of effort to query the information — is that what you say?" · "So you're saying that \_\_\_" — the teachback family, for confirming a reading before building on it.
+- **Echo probe**: repeating what was just said, for confirmation and placement in the timeline.
+
+The same typology names the **anti-patterns**: leading probe ("Isn't it the case that…?"),
+forced choice (assumes at least one option is needed), and leading questions that presuppose a
+need. Those belong in the elicitor's do-not-do list.
+
+**Interviewer failure modes — now verified in full.** An empirical study of 28 elicitation
+interviews produced a **34-mistake taxonomy in seven categories**, with observed frequencies
+**[V]**:
+
+| Category                  | Mistakes (frequency out of 28 interviews)                                                                                                                                                                                                                                                    |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Question formulation**  | Asking vague questions (21) · asking technical questions (15) · asking irrelevant/incorrect questions (6) · **asking customer for solutions (4)** · asking very long questions (1) · incorrect formulation of questions (1)                                                                  |
+| **Question omission**     | Not identifying stakeholders (12) · **no probing questions (11)** · not asking about existing system / business process (11) · not asking about feature prioritisation (9) · not asking about the problem domain (7) · not identifying success criteria (1) · missing relevant questions (1) |
+| **Order of interview**    | Incorrect ending of interview (19) · incorrect opening of interview (15) · incorrect order of questions (15) · repeating the questions (6)                                                                                                                                                   |
+| **Communication skills**  | Unnatural dialogue style (14) · poor communication skills (5) · poor listening skills (2) · unclear voice (1) · looking at laptop during conversation (1)                                                                                                                                    |
+| **Analyst behaviour**     | Lack of confidence (5) · overconfidence/arrogance (1) · passive attitude (1) · unprofessional behaviour (1)                                                                                                                                                                                  |
+| **Customer interaction**  | No rapport with customer (16) · **influencing customer (1)** · interrupting customer (1)                                                                                                                                                                                                     |
+| **Teamwork and planning** | Lack of coordination among group (14) · lack of time management (3) · lack of preparation to understand problem domain (2) · lack of planning (1) · long pause (1)                                                                                                                           |
+
+Several of these land directly on our design. **"Asking vague questions" is the single most
+frequent mistake** (21 of 28), defined as questions yielding multiple interpretations — which is
+also the failure an LLM is most prone to, because fluent generic questions are cheap. **"No
+probing questions" (11)** is the failure mode the AI-interviewing evidence independently flags
+as the one that matters most (§8). **"Not identifying success criteria" and "not asking about the
+problem domain"** are the §1.2 objectives-first failures. And **"asking customer for solutions"**
+is precisely Lu's positioning critique of the incumbent Petrinaut assistant — asking the expert
+_for a net_ is a named, catalogued elicitation mistake, which is a considerably stronger way to
+make that argument than a preference claim.
+
+The four **order-of-interview** mistakes are worth separate attention because they are the ones a
+questionnaire-shaped agent will make by construction: incorrect ending (19) and incorrect opening
+(15) are the two most frequent single mistakes after vague questions.
+
+### 5.2 Contrastive cases
+
+**Grounded answer: yes, and there are three established forms.** **Triadic elicitation** — "in
+what way are two of these alike and different from the third?" — exists to surface the
+discriminating attribute an expert uses without naming **[V]**. Laddering's **key-difference**
+prompt is the two-item version **[V]**. CDM contributes the **expert–novice contrast** ("would
+someone less experienced have read that the same way?"), which isolates the cue actually being
+used **[V]**. And the question typology's **comparison/contrast** form gives the across-sites
+version **[V]**.
+
+For disambiguating two readings of one utterance, the minimal move is a **discriminating case**:
+construct a situation where the readings predict different behaviour and ask which happens. Note
+this is a hypothetical, so §2.3's precondition applies — anchor it to a real case where possible,
+and prefer asking what the expert would be _looking at_ over what they would decide.
+
+### 5.3 When experts disagree
+
+**Grounded answer, and the literature has a clear recommendation that cuts against consensus-seeking.**
+
+Two opposed approaches exist. **Behavioural aggregation** (SHELF) elicits individually, then
+convenes the experts and facilitates toward a single distribution representing what a **Rational
+Impartial Observer** would believe having heard the arguments — and note the exact framing
+**[V]**: experts are _not_ asked to agree; "they are asked to consider what an intelligent and
+impartial observer might now reasonably believe about X, having assimilated the experts'
+different opinions and arguments." **Mathematical aggregation** (Cooke's classical model) keeps
+experts separate, scores them on **seed variables** with known answers, and combines with weights
+from calibration ("statistical accuracy" — the p-value of the hypothesis that realisations fall
+in the inter-quantile intervals) and informativeness **[V]**.
+
+**The empirical verdict favours performance weighting** **[V]**: it beat equal weighting
+in-sample in 32 of 33 post-2006 studies, with a geometric-mean ratio of 3.86; out-of-sample there
+is a penalty on statistical accuracy but performance weighting still won on the combined index in
+26 of 33 (p = 0.001), and 54 of 73 pooled (p = 2.5 × 10⁻⁵). Sobering detail for anyone
+tempted by simple averaging: the **best single expert also beat equal weighting** (ratio 1.84).
+The database behind this is 45 panels, 521 experts, 67,001 elicitations.
+
+**And the literature's recommendation when experts strongly disagree is explicit and goes to
+mathematical aggregation** **[V]**: behavioural aggregation "sometimes… does not succeed because
+experts strongly disagree. When they do, any attempt to impose agreement will promote confusion
+between consensus and certainty. And since the goal should be to quantify uncertainty, not to
+remove it from the decision process, mathematical methods of aggregation should be sought." The
+same guidance warns that behavioural approaches "tend to encourage convergence of views… In risk
+analysis this may be extremely dangerous", and that good practice means "maintaining
+disagreements". It also gives a concrete false-consensus guard: compute an equal-weighted pool of
+the individual distributions as a width baseline, **do not show it to the experts**, and be
+suspicious if the negotiated consensus is appreciably narrower.
+
+**What an agent should do is neither, at first.** The prior move — most likely to resolve the
+disagreement outright — is to check that the experts are answering the **same question**, using
+the clairvoyant test **[V]**. Much apparent factual disagreement in elicitation is definitional:
+different assumed boundaries, units, or implicit conditioning ("cycle time" including or
+excluding setup). An agent is unusually well placed to catch this, holding both utterances in
+full — and the **consistency probe** (§5.1) is the move that surfaces it.
+
+Then, if disagreement survives definitional repair:
+
+- Do **not** silently average — it destroys the most valuable signal in the interview and, per the above, manufactures false certainty.
+- Record a **contested fact** with both values, both sources, and each expert's reasoning.
+- Cooke's performance weighting is not practically available to a live agent (seed variables need known answers prepared in advance), so the importable parts are the **format** (quantiles) and the **discipline** (preserve and propagate).
+- Where the disagreement concerns a model parameter, the honest projection is a range or a scenario pair, with the model's answer reported under both.
+- Distinguish disagreement about **facts** from **definitions** from **values/objectives** — the third is not resolvable by elicitation and belongs in the objectives record (§7), not the parameter record.
+
+One honest caveat: this literature reports **no methodological consensus**, "let alone a 'gold
+standard'", and notes that empirical comparisons are in contradiction **[V]**. We are choosing a
+defensible position, not implementing a settled one.
+
+**Key sources.**
+
+- van der Aalst, W.M.P. (1998) "The application of Petri nets to workflow management", _Journal of Circuits, Systems and Computers_ 8(1):21–66; van der Aalst et al. (2011) "Soundness of workflow nets", _Formal Aspects of Computing_ 23:333–363 **[V]**.
+- Batoulis, K., Meyer, A., Bazhenova, E., Decker, G. & Weske, M. (2015) "Extracting decision logic from process models", CAiSE 2015, LNCS 9097:349–366 **[V]**.
+- Bano, M., Zowghi, D., Ferrari, A., Spoletini, P. & Donati, B. (2019) "Teaching requirements elicitation interviews: an empirical study of learning from mistakes", _Requirements Engineering_ 24(3):259–289 **[V]** — Fig. 3 read directly; source of the 34-mistake taxonomy. The RE'18 conference version carries the same taxonomy **[V]**. Ferrari, A., Spoletini, P. & Bano, M. et al. (2020) "SaPeer and ReverseSaPeer", _Requirements Engineering_ 25(4):417–438 **[V]** documents which mistakes training does and does not fix. Ferrari, A., Spoletini, P. & Gnesi, S. (2016) _Requirements Engineering_ 21(3):333–355 **[V]** on ambiguity in elicitation interviews.
+- Zaremba & Liaskos (2021) **[V]** — the question typology and all verbatim probe examples in §5.1.
+- Colson & Cooke (2017) **[V]**; Cooke & Goossens (2008) **[V]**; Cooke, R.M. (1991) _Experts in Uncertainty_, Oxford University Press **[R]**.
+- EFSA (2014) _EFSA Journal_ 12(6):3734 **[V]** — RIO framing, the aggregation recommendation, the false-consensus guard.
+- Howard (1988) **[V]**. Rowe, G. & Wright, G. (1999) "The Delphi technique as a forecasting tool", _International Journal of Forecasting_ 15(4):353–375 **[V]** — four defining features (anonymity, iteration, controlled feedback, statistical group response); Delphi beat traditional groups 5:1 and statistical groups 12:2 in their tallies.
+
+**Pack-content candidates.**
+
+- **Soundness-to-question card**: run the three soundness checks; each violation has a scripted question. Highest-value implementable cross-examination in the review.
+- **Contention obligation card**: any shared input place without a resolution rule is an open issue, raised automatically; pair with CDM's "what rule was being followed?"
+- **Consistency-probe card**: verbatim wording above. Cheap for an agent, hard for a human — a genuine asymmetric advantage.
+- **Clearinghouse probe as a closing ritual**: "what have I not asked that is important?" before any completion claim.
+- **Clairvoyant-test card**: restate any quantity as a question a clairvoyant could answer; if you cannot, the definition is what to elicit next. Run first whenever two sources conflict.
+- **Contested-fact record**: disagreement is a first-class object with both positions, never an average; never negotiate toward a narrower range.
+- **Interviewer self-check rubric**: the 34-mistake taxonomy as a post-turn audit, weighted by observed frequency — vague questions, missing probes, and opening/ending errors first.
+
+---
+
+## Section 6 — Which systems earn which formalism?
+
+### 6.1 Evidence that earns each capability
+
+**Grounded answer, with one correction to the ladder's shape.** The ladder mixes three different
+kinds of thing, and separating them makes each answerable: **genuine expressiveness** (timed,
+stochastic, hybrid/continuous state), **engineering convenience** (colour, subnets), and
+**use-case properties** (live data feed, cyclic vs. terminating).
+
+| Capability                                  | What earns it                                                                                                                                                                                   | What says it isn't needed                                                                                                                                                                                                                                                     |
+| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Timed**                                   | Any response is a duration, rate, or due-date breach; or resources are contended (contention only bites in time).                                                                               | All responses concern feasibility or logical correctness, not timing.                                                                                                                                                                                                         |
+| **Stochastic**                              | The question concerns a tail, percentile or service level; **or** the binding resource's utilisation is high or CVs are large — VUT makes variability's effect quantifiable in advance **[V]**. | Low utilisation _and_ low variability _and_ a question about a mean. Then a deterministic calculation gives the same answer.                                                                                                                                                  |
+| **Coloured (static)**                       | Repeated structure differing only in parameter values, where the unfolded net would be unmanageable or hand-synchronised.                                                                       | Few entity types, or types that don't change behaviour. **Note:** with finite colour sets a CPN unfolds to an equivalent P/T net **[V]** — colour adds _no expressive power_, only compactness and maintainability. An engineering choice, not a capability a system "needs". |
+| **Dynamically coloured / continuous state** | A continuous per-entity quantity evolves _between_ events and feeds back into event timing or enabling, and thresholds cannot stand in for it.                                                  | The state can be discretised into a few threshold bands without changing the answer — usually the case, and the right default assumption.                                                                                                                                     |
+| **Guards / conflict resolution**            | Forced, not earned: two transitions sharing an input place require a priority, weight, or policy **[V]**.                                                                                       | Only if no contention exists anywhere — rare.                                                                                                                                                                                                                                 |
+| **Subnets / templating**                    | Repeated structural units that must stay in sync; same driver as colour, and hierarchical CPN exists for it **[R]**.                                                                            | One-off structures.                                                                                                                                                                                                                                                           |
+| **Live data feed**                          | The _use_ is reactive — re-run from observed current state. A property of the use case, not the system.                                                                                         | The use is design-time or comparative.                                                                                                                                                                                                                                        |
+| **Cyclic vs. acyclic**                      | Steady-state vs. terminating horizon. Determines **experiment design** (warm-up, run length, replications), not structure.                                                                      | —                                                                                                                                                                                                                                                                             |
+
+Two inversions cut against a prestige reading. **Continuous/fluid Petri nets are introduced to
+reduce computational cost** when token counts are large **[V]** — "continuous" is sometimes a
+simplification. And **colour is a folding**, so a system cannot "need" colour the way it can need
+stochasticity.
+
+### 6.2 Attacking the hypothesis
+
+**The working hypothesis survives.** "Most systems don't earn the full stack; a simpler variant is
+often the better model" is consistent with everything found, and with the field's central
+methodological norm — start simple, add complexity, keep the model as simple as will answer the
+question **[V]**. Brooks & Wang's finding that conceptual models drift toward _added_ complexity
+during projects **[V]** is the empirical warning that this norm is hard to hold, not evidence
+against it. Robinson's own framing of the four requirements puts **utility and feasibility**
+alongside validity and credibility **[V]**, which is the formal statement of the same point.
+
+**Where it is most likely wrong / what is underestimated:**
+
+- **Variability magnitude, not just presence.** Teams include stochasticity but with defaulted or wrong CVs. VUT makes the CV term a linear multiplier on queue time, so getting variability roughly right matters more than adding structural detail. Most under-served capability.
+- **Resource contention and blocking.** Finite buffers that block upstream, shared operators and tools — mundane, decisive, and the coupling whose absence produces the too-good spreadsheet agreement of §4.4.
+- **Calendars, shifts and changeovers.** Unglamorous, frequently decisive in scheduling, rarely on a feature ladder at all — and, per §9, exactly the parameters that process mining _cannot_ supply and interviews must.
+- **Exception and recovery behaviour.** The exception-pattern survey found tooling systematically ignores resource-unavailability exceptions **[V]**; there is no reason to think our elicitation would do better unless it asks explicitly.
+
+**What is prestige:** dynamic colouring. Hardest necessity to demonstrate, easiest to replace with
+threshold discretisation.
+
+**Confidence note:** no literature was found that empirically ranks Petri-net feature usage. The
+ranking above is inference from operations and queueing results, not a citable frequency
+distribution.
+
+### 6.3 Which use case earns the showcase?
+
+The literature cannot pick the demo. What it supplies is a **criterion**: a system genuinely
+strains dynamic colouring when a _per-entity continuous state gates events_, and the question is
+about **when a threshold is crossed** rather than about average flow. That points at
+condition-based maintenance on a fleet of degrading assets, or an energy/charge-constrained mobile
+fleet — each unit carrying its own continuously-evolving state, with the decision being whether to
+intervene before a crossing.
+
+Two cautions from §3.2. The best-verified real asset-management model of this kind decomposes
+**per component type**, each template bundling degradation, inspection and maintenance — so
+expect the showcase to need object-type templates rather than orthogonal functional modules. And
+Petri-net digital-twin synchronisation is thin in the literature, so a demo leaning on live
+state injection will be inventing rather than instantiating.
+
+The PRO-99 tension is real and this review sharpens rather than dissolves it: **most candidate use
+cases will not earn dynamic colouring**, so a showcase demo needs either a purpose-chosen use case
+of the kind above, or an honest pivot to showcasing what is genuinely load-bearing — variability
+and contention.
+
+**Pack-content candidates.**
+
+- **Formalism-earning card per capability** (the table above), each phrased as an evidence test.
+- **Utilisation-and-variability probe**: "how busy is the busiest resource, and how much do its times vary?" — one early question deciding stochastic-or-not on quantitative grounds.
+- **Threshold-substitution challenge**: before accepting continuous state, ask whether three or four bands would change the answer. If not, discretise.
+
+---
+
+## Section 7 — What lives outside the net?
+
+### 7.1 What else belongs on the list?
+
+The existing list (decision policies at conflict points, objective functions and penalty weights,
+goals and rationale, regulatory/business constraints, conservation laws, theoretical-vs-actual
+process, data-feed bindings, validation criteria) is well-founded. The literature adds:
+
+1. **Modelling objectives, responses, and experimental factors** **[V]** — purpose, what it must report, what the user will vary. Without the third you cannot tell what must be parameterised.
+2. **Accuracy bar and domain of applicability** **[V]**, set before building.
+3. **Assumptions and simplifications, separated, each justified** **[V]** — different lifecycles (§4.1).
+4. **Scope and level-of-detail tables with Include / Exclude / Justification columns** **[V]** — every exclusion carries a reason.
+5. **Decision logic as a first-class separate object** — decision tables, not control-flow encoding **[V]**. Where conflict-point policies belong, and the structural fix for data-vs-decision conflation.
+6. **Design rationale** — why this way, which alternatives were rejected, on what criterion. Established notations exist: QOC (questions / options / criteria), IBIS, DRL **[V]**.
+7. **The work-as-imagined vs. work-as-done divergence record** **[V]** — not just "manual says X, log says Y" but the _reason_ for the gap, where unwritten constraints live. §9 gives the log-side machinery for detecting it.
+8. **Per-fact provenance and confidence**, plus **contested facts** with both positions (§5.3). Yannis's confidence-directed questioning needs this substrate.
+9. **A definitions dictionary that passes the clairvoyant test** **[V]** — units, boundaries, what each named quantity includes. Cheapest defence against §5.3 disagreements and silent conflation.
+10. **A construct-deficit register** — what the notation cannot express, recorded deliberately. Representational analysis supplies the vocabulary: ontological incompleteness (construct deficit), construct overload, excess, redundancy **[V]**. Writing down what the net structurally cannot hold is what makes "the net is one projection" operational rather than rhetorical.
+11. **Declined and deferred items** — what the expert would not or could not answer. Absent from most schemas and load-bearing for an agent deciding where to probe next.
+12. **The case notion / object types and their granularity** **[V]** — see §9. For a physical system with several interacting object types this is a modelling decision with no data-internal ground truth, and it belongs in the record as a decision with a justification, not as an implicit choice.
+
+### 7.2 Minimum schema for the intermediate representation
+
+**Per fact / quantity:**
+
+- identity and a **clairvoyant-testable definition** (units; what is in and out of the quantity);
+- **kind**: structural element, quantity, distribution, rule/policy, constraint, objective, or narrative incident;
+- **role**: experimental factor, response, or fixed parameter (the §1.3 classifier);
+- **value**: point value, distribution _as elicited quantiles with the elicitation method recorded_, or narrative;
+- **provenance**: who said it, when, in answer to what — and whether spoken, document-derived, or log-derived;
+- **confidence**, and **contested-by** where sources differ;
+- **the objective(s)/question(s) it serves** — the link making question-relative completeness checkable;
+- **projection hint**: whether and how it lands in the net; for motifs, name **plus variant selector** (§3.1).
+
+**Per model:**
+
+- the **questions the model must answer**, each with its accuracy bar;
+- **scope** and **level-of-detail** tables with Include/Exclude/Justification;
+- **assumptions** and **simplifications** as separate justified lists;
+- the **case notion / object types** with rationale;
+- **validation plan**: the historical period to replay, and which pathologies the expert should be asked to recognise;
+- the **construct-deficit register** and the **declined/deferred** list.
+
+Note the shape: most of these fields exist to support _questions the elicitor will ask later_
+(confidence → where to probe; assumptions → backlog; declined → what not to re-ask). The IR is an
+interviewing work-list as much as a model description — a stronger claim than "the net is one
+projection of it".
+
+**Key sources.** Robinson (2008) Part I **[V]** and WSC tutorials **[V]**; Sargent (2011) **[V]**;
+Law (2022) **[V]**; Batoulis et al. (2015) **[V]**; MacLean, A., Young, R.M., Bellotti, V. &
+Moran, T.P. (1991) "Questions, options, and criteria: elements of design space analysis",
+_Human-Computer Interaction_ 6(3–4):201–250 **[V]**; Kunz & Rittel (1970) IBIS **[R]**; Lee & Lai
+(1991) DRL **[R]**; Wand & Weber BWW representation model, and Recker et al. on BPMN
+representational analysis **[V]**; Howard (1988) **[V]**.
+
+**Pack-content candidates.**
+
+- **Outside-the-net checklist** (the twelve items) as a late-interview sweep.
+- **Definitions-first rule**: no quantity recorded without a clairvoyant-testable definition.
+- **Rationale capture card**: for each significant modelling choice, record question, options considered, and criterion (QOC).
+
+---
+
+## Section 8 (added) — The elicitor as an agent
+
+The inventory has seven sections; the brief referred to eight. This section and §9 cover the
+cross-cutting questions the framing implies and the inventory leaves implicit.
+
+**The most directly useful finding.** In a study of 381 AI-conducted qualitative interviews there
+were **systematic differences between top-of-mind first responses and later responses, with
+interviewees' mental models emerging consistently later** **[V]**; the resulting data predicted
+real behaviour eight months on, weighing against a "cheap talk" reading. Three consequences:
+
+1. **Depth of probing is the differentiator**, not breadth. First answers are systematically unrepresentative of what the expert knows. This converges exactly with the mistake taxonomy's "no probing questions" (11 of 28) and with Hoffman's finding that structured and contrived modes outyield open conversation by an order of magnitude (§2.4).
+2. A direct argument against **question batching**: batching optimises throughput on first-pass answers, the least valuable ones. Lu's horizon-problem caveat has independent empirical backing — batch small, prefer depth.
+3. A **measurable evaluation proxy** for the otherwise-intractable evaluation problem: compare content extractable from first responses alone against content after probing. An elicitor adding little beyond first responses is failing, and this is measurable without a ground-truth model or a repeatable human.
+
+**On feasibility.** The 2025–26 literature reports respondents rating chatbot interviews
+**comparable in quality to human interviews**, and AI-led interviews **reaching saturation at
+comparable level and speed** **[V]**. But the same literature states plainly that **evaluation
+methodology remains unestablished** — no consensus on which constructs to measure **[V]**. Worth
+saying to the team directly: the evaluation problem aired in the meeting is an **open research
+problem**, not a local gap in diligence, and the existing plan (model-as-offline-respondent,
+frozen replay fixtures, mutation library) is a reasonable independent answer.
+
+**Two ready-made assets for the mutation library.** The 34-mistake taxonomy (§5.1) is a
+frequency-weighted defect list to inject deliberately, and a separate 28-criterion
+interviewer-assessment framework exists **[V]**. There is also a small but growing set of
+LLM-interviewer systems for requirements elicitation with published evaluations **[V]** — worth
+reading before building the control experiment Dora proposed, precisely because it defines what
+"vanilla LLM baseline" has already been measured to do.
+
+**Key sources.** Chopra, F. & Haaland, I. (2023) "Conducting qualitative interviews with AI",
+CESifo Working Paper 10666 / CEBI WP 06-23 **[V]**; AI conversational interviewing literature,
+arXiv:2504.13908, arXiv:2606.20064, arXiv:2606.20588 **[V]**; Bano et al. (2019) **[V]**;
+Shen, Singhal & Breaux, RE'25 interviewer-assessment criteria **[V]**; LLM-elicitation systems
+including LLMREI (arXiv:2507.02564), follow-up question generation (arXiv:2507.02858), Elicitron
+(arXiv:2404.16045), ReqElicitGym (arXiv:2602.18306), and Görer & Aydemir (arXiv:2406.11439)
+**[V]** (retrieved; not read in depth).
+
+**Pack-content candidates.**
+
+- **Probe-depth policy**: never accept a first answer on a load-bearing fact; the second and third passes carry the value.
+- **Anti-batching guard**: batch only questions that are mutually independent _and_ cheap; never batch a question whose framing depends on an unanswered one.
+- **Vagueness guard**: before emitting a question, check it admits only one reading — the most frequent human mistake and the one LLM fluency most invites.
+
+---
+
+## Section 9 (added) — Elicitation from logs: what data substitutes for, and what it cannot
+
+This is Yannis's theoretical-vs-actual framing with its literature attached, and it matters for
+scoping the interview: every parameter the data can supply is a question the elicitor should not
+spend expert time on.
+
+**The framing.** Process mining distinguishes **discovery** (derive a model from an event log),
+**conformance checking** (compare a model against a log), and **enhancement/extension** (enrich a
+model with log-derived information) **[V]**. Logs yield the **_de facto_** model — what actually
+happens; documents and interviews yield the **_de jure_** model — what is supposed to happen — and
+the refined framework has named activities for both directions of travel between them **[V]**.
+That is the same distinction as work-as-imagined vs. work-as-done (§2.1), arriving from the data
+side.
+
+**Where the log genuinely substitutes for the interview.** Simulation-model discovery from logs
+recovers control flow, branching probabilities, resource pools, and processing-time
+distributions **[V]**. One study provides a literal source-per-parameter table: mining supplies
+control flow, branching probabilities, resource pools and processing times; interviews supply
+calendars, shifts, availability fractions, costs, priorities and seasonality **[V]**. That table
+is close to a specification for what the elicitor should ask about — and note it lines up exactly
+with §6.2's "calendars and changeovers are underestimated".
+
+**The honest twist in that same study**: the largest residual error in the validated model, a
+~19% overshoot, traced to the **interview-supplied availability estimate** **[V]**. Elicited
+quantities need validation too; this is not a story about data being unreliable and experts being
+reliable.
+
+**What is structurally absent from any log, and must be elicited** **[V]**:
+
+1. **Behaviour that never touched the system** — phone calls, paper, offline workarounds. A healthcare study makes the point concretely: nurses phoning the pharmacy is invisible to _any_ data-only method; and of six identified workaround types, two are undetectable in principle from logs.
+2. **Rationale and context** — logs record the what, never the why. A recent taxonomy organises contextual factors across nine dimensions; seasonal variation is the canonical example where mining shows the pattern and only a person supplies the cause.
+3. **Resource reality** — part-time attention, workload-dependent speed, batching, calendars, priorities. The simulation-survival-guide risks are blunt about the consequence: models producing simulated flow times of minutes or hours where reality is weeks or months.
+4. **The case notion and abstraction level** — a modelling decision with a combinatorial search space (one reported instance: 90 tables yielding ~10,000 candidate case notions) and **no log-internal ground truth**. Consequences are quantified: flattening a multi-object log to a single case notion produced ~15% false directly-follows edges, ~47% of real ones missing, and some activity pairs 100% wrong **[V]**.
+
+**And one thing logs cannot settle even in principle**: the four discovery quality dimensions are
+fitness, precision, generalization and simplicity, and while a log settles fitness, **the
+precision-versus-generalization trade-off cannot be settled from the log alone** — generalization
+is defined against the unobserved real process, which in real settings is not knowable **[V]**.
+That is a judgement call, so it needs a human, and it is the formal version of "how much of what
+we didn't see should the model allow?" The same body of work names the **open-world assumption**
+problem and rates log quality on a five-star maturity scale on which manually-kept records are
+simply unusable **[V]**.
+
+**Human-in-the-loop discovery** is an established line — interactive and domain-knowledge-driven
+process discovery, with a 2022 review and recent LLM-guided variants **[V]** — which is the
+closest existing neighbour to what the elicitor does, and worth positioning against.
+
+**A gap worth naming**: no study was found quantifying the divergence between an
+interview-derived model and a mined model of the _same_ process **[V]**. That is a cheap,
+publishable experiment and it is nearly a by-product of the September demo if any use case has
+both a willing expert and a log.
+
+**Key sources.** van der Aalst, W.M.P. (2016) _Process Mining: Data Science in Action_, 2nd ed.,
+Springer **[V]** (§10.1 for de facto/de jure); IEEE Task Force on Process Mining (2011)
+_Process Mining Manifesto_ **[V]** (guiding principles GP1–GP6, challenges C1–C11, five-star
+maturity); van der Aalst, "Process mining in the large" tutorial **[V]**; Rozinat, A., Mans,
+R.S., Song, M. & van der Aalst, W.M.P. (2009) "Discovering simulation models", _Information
+Systems_ 34(3):305–327 **[C]**; Camargo, M., Dumas, M. & González-Rojas, O., SIMOD **[V]**;
+Gawin, B. & Marcinkowski, B. (2015) **[V]** (source-per-parameter table); Esser, S. & Fahland, D.
+(2021) on multi-dimensional/object-centric event data **[V]**; Outmazgin, N. & Soffer, P. on
+workaround detectability **[V]**; Dixit, P.M. et al. on interactive process discovery **[V]**;
+Schuster, D. et al. (2022) review **[V]**.
+
+**Pack-content candidates.**
+
+- **Source-router card**: before asking, decide whether a parameter is log-derivable (control flow, branching probabilities, service times, resource pools) or interview-only (calendars, shifts, availability, costs, priorities, seasonality, rationale, rare events). Spend expert time only on the second list — and validate the first list's assumptions with the expert rather than re-eliciting them.
+- **De facto / de jure confrontation card**: where both a document and a log exist, present the divergence to the expert and ask for the _reason_, not the correct version. The reason is the unwritten constraint.
+- **Off-system behaviour probe**: "what part of this happens by phone, on paper, or in someone's head, and would never show up in the system?"
+- **Case-notion card**: make the object types and granularity an explicit, justified decision in the record — never an implicit default.
+- **Generalization question**: "what could happen that has never happened?" — the human-supplied half of the precision/generalization trade-off.
+
+---
+
+## Where the literature is thin, or contradicts our framing
+
+1. **No literature gives "the first five questions" for eliciting a Petri net.** The nearest thing is Robinson's ordering, which _mildly contradicts_ the prep document's framing: C2 assumes questions map to model elements, whereas the literature says the first several questions map to _purpose_, and model elements are derived.
+
+2. **No empirical frequency data for modelling motifs, and the frequency data that exists is contaminated by tooling** (§3.1). The catalogue cannot be ordered by expected yield from the literature; order it from your own use-case pool, with van der Aalst's 80/20 as the prior.
+
+3. **The motif catalogue's altitude is genuinely unoccupied** (§3.1). Between formal primitives and whole-application templates there is no institutionalised operational-motif catalogue. Good news — it is a real contribution; bad news — there is no list to copy, and the one real Petri-net pattern catalogue had no successor.
+
+4. **Börger's reduction argument stands unanswered** and cuts against long catalogues: build a small quiver of parameterised schemes with variant selectors. The published rebuttal does not engage it.
+
+5. **Names are stable, semantics are not.** PAND inclusivity, spare-claiming timing, and workflow-pattern naming drift are all live. Never record a motif by name alone.
+
+6. **"SDCPN" is not a literature term, and the feature ladder does not map to any published hierarchy** — it conflates expressiveness with engineering convenience with use-case properties. Colour is the clearest case: a folding with no expressive gain.
+
+7. **The strongest real-world asset-management evidence backs per-object-type templates, not orthogonal functional modules** (§3.2). This may contradict our intended decomposition and should be resolved deliberately.
+
+8. **Penalty-weight elicitation exists, but in a different field.** MCDA has mature methods; nothing documents their use in a Petri-net or DES elicitation context. An integration opportunity, and a warning about importing preference-structure assumptions.
+
+9. **Saturation-style stopping rules do not transfer.** They concern theme discovery across informants. The transferable stopping-rule literature is the cognitive one (§4.2), and its message is that the natural rule for an LLM — stop when the representation stabilises — is one of the two associated with premature stopping.
+
+10. **Nothing addresses §4.4 directly.** The spreadsheet-agreement answer is assembled from a verification technique plus queueing theory: reasoned, not cited.
+
+11. **Structured expert judgment has no methodological consensus**, and its own literature says empirical comparisons are in contradiction. We are choosing a defensible position.
+
+12. **Petri-net digital-twin synchronisation is thin**, and no canonical named Petri-net template exists for the standard delay-time inspection model.
+
+13. **No study quantifies interview-derived vs. mined models of the same process** (§9) — a cheap experiment, nearly free from the September work.
+
+14. **The evaluation problem for AI interviewers is genuinely unsolved**, stated explicitly in that literature.
+
+15. **Residual verification gaps.** Still **[R]**: hierarchical-CPN specifics; the "flaw of averages" attribution; Cooke (1991) and O'Hagan et al. (2006) book content; Kelly (1955); contextual inquiry's principles; the Browne & Pitts (2004) journal treatment of stopping rules; Börger's eight scheme _names_ (the ER 2007 paper is paywalled and worth buying if the quiver design depends on them); IBIS and DRL specifics. Also unresolved: a minor discrepancy between two Cooke reviews' counts (31/33 vs 32/33) to reconcile before citing both, and Gause & Weinberg's context-free questions were **not** verified — the Zaremba & Liaskos typology is better sourced and is used instead throughout.
+
+---
+
+## Prioritized shortlist: the five highest-leverage findings for a September demo
+
+**1. Objectives-first ordering, and question-relative completeness — with a quotable warrant.**
+Reorder the interview so the model's questions, responses, experimental factors and accuracy bar
+precede structural elicitation, and treat the questions table as simultaneously the scope,
+completion and validation criterion. Sargent states it normatively and verbatim; Robinson supplies
+the ordering and the Include/Exclude/Justification tables to record it in. Cheapest change with
+the widest effect — it answers four inventory questions at once and needs no new machinery.
+_(§1.2, §4.1, §4.2)_
+
+**2. Import the probe catalogues wholesale — all the wordings are now in hand.**
+The CDM deepening and what-if sweeps, the eight ACTA knowledge-audit probes, and the
+35-type question typology are reproduced verbatim in §2.2 and §5.1 and can be translated to
+operational wording immediately. The premortem prompt adds the forward-looking case. Three
+individual items are worth calling out because they map straight onto net constructs: CDM's
+_basis of choice_ ("what rule was being followed?") elicits conflict policy; CDM's
+_situation assessment_ handover framing elicits what the marking must record; and the
+_clearinghouse_ and _consistency_ probes give the elicitor a closing ritual and a
+whole-transcript cross-check. Plus one universal follow-up rule — "how would you know that? how
+would this be hard for someone less experienced?" — that upgrades every other card. Highest
+content-per-unit-effort in the review and now the lowest-risk to ship. _(§2.2, §5.1, §5.2)_
+
+**3. Fix quantitative elicitation — and there is now a number to justify it.**
+Elicit distributions by the IDEA four-step (interval, then best guess, then a confidence
+percentage) or by median-then-quartiles bisection; never ask for a mean and standard deviation;
+never fit a triangular to a min/mode/max triple. The published comparison is stark: the
+three-point-triangular habit **overstated a measured mean by ~69%**, where a distribution reading
+the same elicited middle value as a mean landed within 1%. This is where a naive LLM interviewer
+fails worst and most invisibly — it will accept "about 40 minutes" and quietly make it a point
+estimate — and it is the input side of the §4.4 failure. _(§1.4)_
+
+**4. Ground the formalism-earning tests, and retire the prestige ladder.**
+Two results do the work: VUT gives a quantitative test for whether stochasticity is earned
+(utilisation and coefficients of variation), and the folding result establishes that colour buys
+compactness rather than expressiveness. Together they let the team defend "this system does not
+need the full stack" on technical grounds — addressing the PRO-99-versus-use-case-pool tension
+directly — and yield a principled showcase criterion: per-entity continuous state gating a
+threshold-crossing question. Carry the §3.2 caution that such a system will likely want
+per-object-type templates. _(§6)_
+
+**5. Make the formalism and the data generate the cross-examination.**
+Soundness checking (option to complete, proper completion, no dead transitions), the
+shared-input-place contention obligation, the response-versus-factor category check, and the
+motif-obligation sweep are all mechanical on an elicited structure, and each violation converts
+into a specific question. Pair this with the §9 source-router so expert time goes only to what
+logs cannot supply — calendars, priorities, rationale, rare events, and the
+precision/generalization judgement. Together these are what most differentiate the elicitor from
+the incumbent Petrinaut assistant, because they produce cross-examination pressure _without_
+requiring the interviewing expertise the team has established it does not have. And there is a
+sharper way to make that positioning argument now: **asking the expert for a net is a named,
+catalogued elicitation mistake** — "asking customer for solutions" — not merely a design
+preference. _(§5.1, §9)_
+
+**Bonus, for PRO-104.** Two literature-grounded metric candidates fell out of this review:
+**informative propositions per task-minute** (with published reference rates: ~1 for structured
+interviews, 2–3 for contrived tasks, and a "~1/minute means something is wrong" rule of thumb),
+and **first-response versus post-probe content delta** from the AI-interviewing work. Both are
+measurable without a ground-truth model or a repeatable human respondent, which is exactly the
+constraint that made the evaluation problem look intractable. _(§2.4, §8)_
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/petrinaut-survey.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/petrinaut-survey.md
new file mode 100644
index 00000000000..031203c742a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/petrinaut-survey.md
@@ -0,0 +1,1181 @@
+# Petrinaut Architecture Survey (FE-1358)
+
+Evidence-based audit of HASH's Petrinaut app/library and the three candidate
+couplings with the brunch elicitor. Read-only survey of
+`/Users/lunelson/Code/hashintel/hash` at branch state of 2026-08-11. All paths
+below are repo-relative, prefixed `../hash/`.
+
+## Executive summary
+
+1. **Petrinaut is not an app you'd live inside — it is already two published npm
+   libraries.** `@hashintel/petrinaut` (React 19 UI, v0.0.16) and
+   `@hashintel/petrinaut-core` (headless, v0.0.2, five deps, zero React).
+2. **`petrinaut-core` is the cheap coupling nobody has costed**: framework-free
+   ESM, exports SDCPN types, zod schemas, the AI prompt/tools, ELK auto-layout,
+   the simulation engine, and a pure file parser/serializer.
+3. **The artifact boundary already exists and is production code**: a versioned
+   file format (`version: 1`) with a `meta.generator` field, a pure
+   `parseSDCPNFile` that needs only `places` + `transitions`, and an **Import**
+   action that auto-lays-out position-less nets — but Import is **hidden in
+   HASH's embed** and present only on demo.petrinaut.org.
+4. **A brunch↔Petrinaut integration already ships**: "Actual mode", an SSE
+   protocol (`definition` / `initial_state` / `transition_firing` / `terminal`)
+   on the `/brunch` route, with a 941-line reference fixture server in-repo.
+5. **Petrinaut's AI assistant already does interview-first elicitation.** Its
+   system prompt literally says "Interview first, build second" and specifies
+   2–4 grouped questions per turn plus a "make it up" escape hatch.
+6. **That assistant is entirely browser-resident** and cannot be otherwise: tools
+   execute client-side against the live editor, and the iframe hosting it has
+   `connect-src 'self'` because it must run user code under `unsafe-eval`. There is
+   no headless net-_generation_ path (though the CLI is a headless _simulation_
+   path, used in production by the optimizer over a stdio subprocess).
+7. **There is no job queue, no background worker, no subagent structure** around
+   the assistant. One `useChat` loop, one edge function.
+8. **Persistence is thin and provenance is absent.** The net is one HASH entity
+   property holding the raw SDCPN blob; the AI conversation lives in
+   **localStorage**. Nothing records why the model made a modelling choice.
+9. **The net format holds no initial marking and no timing fields** — structure
+   only. A generated net that should start with tokens must emit a `scenario`, or
+   it opens fine and simulates to nothing: the likeliest way to ship a useless file.
+10. **npm is ~2 months stale relative to `main`** — last publish 2026-06-03 with
+    22 unreleased `@hashintel/petrinaut` changesets pending, including the HIR
+    compiler rewrite and Actual mode itself.
+11. **Evidence favours the artifact boundary**, but the real finding is the
+    overlap in §2/§6: the elicitation capability the demo needs partly exists
+    already, and the audit's hardest question is differentiation, not plumbing.
+
+---
+
+## 1. Architecture and dependencies
+
+### 1.1 Workspace layout
+
+Petrinaut is not one app. It is five workspaces:
+
+| Path                                     | What it is                                                       |
+| ---------------------------------------- | ---------------------------------------------------------------- |
+| `../hash/libs/@hashintel/petrinaut`      | React 19 editor UI. Published, v0.0.16.                          |
+| `../hash/libs/@hashintel/petrinaut-core` | Headless engine + types + AI contract. Published, v0.0.2.        |
+| `../hash/libs/@hashintel/petrinaut-cli`  | Internal JSON-lines CLI (`private: true`, `0.0.0-private`).      |
+| `../hash/apps/petrinaut-website`         | Standalone Vite SPA demo (demo.petrinaut.org), Vercel.           |
+| `../hash/apps/petrinaut-opt`             | Python optimizer service (Optuna), `pyproject.toml` + `uv.lock`. |
+
+Plus `../hash/libs/@local/petrinaut-optimizer-client` and
+`../hash/apps/hash-api/src/petrinaut-optimizer/` (the optimizer proxy), and
+`../hash/libs/@hashintel/petrinaut-old` (superseded).
+
+Monorepo tooling (`../hash/package.json`): Yarn 4.16 workspaces
+(`packageManager: yarn@4.16.0`), Node ≥ 22, Turborepo, oxlint + oxfmt, `mise`
+for toolchain, changesets for release. Workspace globs are `apps/**`, `libs/**`,
+`tests/**`.
+
+### 1.2 What a library would have to conform to, to live inside Petrinaut
+
+From `../hash/libs/@hashintel/petrinaut/package.json` and
+`../hash/libs/@hashintel/petrinaut/AGENTS.md`:
+
+- **React 19.2.6**, `react`/`react-dom` `^19.0.0` as peer deps.
+- **React Compiler enabled** with `panicThreshold: "critical_errors"` — the
+  build fails on critical errors unless opted out with `"use no memo"`. AGENTS.md
+  forbids `useMemo`/`useCallback`/`React.memo` absent a specific reason.
+- **ESM only** (`"type": "module"`), Vite 8 + Rolldown library build.
+- **Panda CSS** for all styling (`css()`, `cva()` from `@hashintel/ds-helpers/css`),
+  with a shipped panda preset and `panda.buildinfo.json`.
+- **`use()` for context, not `useContext()`**; function components only.
+- **Type-checked with `tsgo`** (`@typescript/native-preview`), tested with vitest,
+  linted with oxlint `--type-aware`.
+- **No `@local/*` imports** — AGENTS.md states this explicitly because the
+  package is published.
+
+Notable runtime deps that constrain a co-resident library:
+`@xyflow/react` 12.10.1 (canvas), `monaco-editor` 0.55.1 +
+`@monaco-editor/react` (code surfaces), `@ark-ui/react` 5.37.2, `uplot`,
+`@tanstack/react-form`, `@babel/standalone` (visualizer compilation), and
+crucially **`ai` 6.0.182 + `@ai-sdk/react` 3.0.184** — the assistant is built on
+the Vercel AI SDK v6.
+
+Peer deps include `@hashintel/ds-components` and `@hashintel/ds-helpers` as
+`workspace:^`, both published (0.2.2 / 0.2.1) — so an external consumer must
+install HASH's design system alongside Petrinaut. That is a real but bounded tax.
+
+### 1.3 `petrinaut-core` is the important one
+
+`../hash/libs/@hashintel/petrinaut-core/package.json`:
+
+```json
+"deps": { "elkjs": "0.11.0", "immer": "10.1.3", "uuid": "14.0.0",
+          "vscode-languageserver-types": "3.17.5", "zod": "4.4.3" },
+"peer": { "typescript": ">=5.5" }
+```
+
+Framework-free ESM with subpath exports: `.`, `./ai`, `./compiled-model`,
+`./examples`, `./hir`, `./hir-runtime`, `./optimization`, `./workers/lsp`,
+`./workers/monte-carlo`, `./workers/simulation`. No React, no DOM in the parts
+that matter (the file-format and AI modules are documented "Pure — no DOM, no
+I/O"). This is the single most consequential fact in the survey: **anything
+brunch needs from Petrinaut short of the canvas is available as a five-dependency
+Node-importable package.**
+
+### 1.4 Deployment / how it runs
+
+- Demo site: Vercel, `../hash/apps/petrinaut-website/vercel.json` — Vite SPA with
+  rewrites for `/brunch` and `/optimization`, plus one serverless function
+  `api/chat.ts` at `maxDuration: 300`.
+- In HASH: the editor runs in a **sandboxed null-origin iframe** at
+  `../hash/apps/hash-frontend/src/pages/processes/[uuid]/embed.page/`, hosted by
+  `[uuid].page/process-editor.tsx`, with the AI request relayed over a
+  postMessage bridge to a Next.js Pages-Router **Edge** route.
+
+  **Why the sandbox exists, and why it constrains everything** (§3.5, and decisive
+  for §6a): the editor compiles and runs _user-authored code_ — place visualizers
+  via Babel, metric and scenario expressions via `new Function()` — so it needs
+  `unsafe-eval`. It is therefore given `sandbox="allow-scripts allow-forms"`
+  **without** `allow-same-origin`, yielding an opaque origin that cannot read
+  HASH cookies, `localStorage`, or IndexedDB, cannot call HASH's API as the user,
+  and cannot touch the parent DOM (`process-editor.tsx:355-371`, `1125-1141`).
+  A dedicated stricter CSP is built by `buildEmbedCspHeader()` in
+  `../hash/apps/hash-frontend/src/lib/csp.ts:123-171` (applied via
+  `src/middleware.page.ts`): `default-src 'none'`, `form-action 'none'`, and
+  critically **`connect-src 'self'`** — so code inside the iframe has essentially
+  no network reach. That is precisely why persistence _and_ the AI stream must
+  round-trip through postMessage, and why the host hard-codes the AI and optimizer
+  URLs and forwards only the body, so the untrusted iframe can never make the host
+  fetch an arbitrary target. `allow-forms` is present only because the AI chat
+  form's submit event is otherwise blocked.
+
+- Release: `../hash/.github/workflows/release.yml` runs changesets on push to
+  `main`; `canary-release.yml` is `workflow_dispatch` only.
+
+### 1.5 Cadence and staleness (risk-relevant)
+
+- 42 commits touching the two Petrinaut libs + website in the last 8 weeks.
+- Contributors in that window: Chris Feijoo (19), claude[bot] (10), Alex Leon (6),
+  Yannis Zachos (2), plus Tim Diekmann, Kushida, Ciaran Morinan.
+- **Last npm publish: 2026-06-03** (`npm view @hashintel/petrinaut time.modified`).
+- **22 unreleased changesets** target `@hashintel/petrinaut` (1 minor, 21 patch)
+  and 20 target `petrinaut-core`, out of 45 pending repo-wide. Unreleased work
+  includes `.changeset/petrinaut-hir-compiler.md` (replaces Babel with a new HIR
+  compiler; explicitly breaking for code outside the supported TS subset),
+  `.changeset/petrinaut-actual-mode.md`, and
+  `.changeset/petrinaut-sdcpn-capabilities.md`.
+
+So: the published package is two months behind an actively-moving `main`, and the
+Brunch Actual-mode integration is _not in any published version_. Consuming
+Petrinaut from npm today means either accepting a June build or pulling from the
+monorepo.
+
+---
+
+## 2. The assistant
+
+### 2.1 Where it lives
+
+The AI contract is owned by **core**, not the UI:
+`../hash/libs/@hashintel/petrinaut-core/src/ai.ts` (292 lines) exports
+`petrinautAiPrompt`, `petrinautAiTools`, per-tool zod input schemas, and
+`createPetrinautAiWritableCallbacks`. Both server entry points import it:
+
+- `../hash/apps/hash-frontend/src/pages/api/petrinaut-ai-chat.api.ts` (HASH)
+- `../hash/apps/petrinaut-website/api/chat.ts` (demo site)
+
+The UI surface is `../hash/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel.tsx`
+(697 lines) plus a `ai-assistant-panel/` directory (transports, tool summaries,
+docs content, interactive tools registry).
+
+### 2.2 Prompting — the load-bearing excerpt
+
+The system prompt is a single template literal at
+`../hash/libs/@hashintel/petrinaut-core/src/ai.ts:235-292`. It opens:
+
+> You are an expert assistant for building Stochastic Dynamic Coloured Petri Nets
+> (SDCPNs) in Petrinaut.
+
+**It already specifies interview-first elicitation** (`ai.ts:245-253`):
+
+> Interview first, build second. Before creating a new net (or adding a
+> substantial new subsystem to an existing one), do NOT jump straight to tool
+> calls. Run a brief, focused interview to establish:
+>
+> 1. Process structure & timing — the key states/places, the events/transitions
+>    between them, capacity or routing constraints, and the typical rates/durations
+>    […] Flag where stochastic vs. predicate vs. continuous dynamics seem to fit.
+> 2. Observables & metrics — what the user wants to measure once the model runs […]
+> 3. Scenarios — the what-if conditions they want to compare […]
+>
+> Keep it tight: ask 2–4 grouped questions per turn, not a long form. Restate what
+> you already understand so the user only has to fill gaps. If the request is
+> already concrete and well-scoped […] skip the interview and act.
+>
+> Escape hatch. Every time you ask questions, explicitly tell the user they can
+> say "make it up", "use sensible defaults", or similar, and you will pick
+> plausible values (with a one-line justification for each major choice) and
+> proceed.
+
+The rest of the prompt is a ~20-line modelling policy (prefer small mutations,
+check `extensions` before using optional SDCPN features, use scenario parameters
+for tunable assumptions), a **"Validate every code-writing change"** rule
+requiring a diagnostics call after any code mutation, a warning that place names
+are part of the code surface so renames must update every dependent lambda/kernel/
+metric in the same batch, an eight-bullet **code-surface cheatsheet** giving exact
+runtime shapes for lambdas / kernels / dynamics / visualizers / metrics /
+scenario initial state, an auto-layout policy, and finally:
+
+> Here is a compact example Petrinaut document demonstrating coloured tokens,
+> stochastic and predicate transitions, transition kernels with distributions,
+> continuous dynamics, parameters, visualizer code, and scenarios:
+
+…followed by `JSON.stringify(probabilisticSatellitesSDCPN, null, 2)` inlined into
+the prompt (`ai.ts:290-292`). So the prompt carries a full worked example net as a
+few-shot, from `petrinaut-core/src/examples`.
+
+This is a mature, domain-specific prompt. It is one string with no templating,
+no per-session variation, and no strategy/policy layer — the "quiver of
+strategies" idea in the brunch spec has no counterpart here.
+
+### 2.3 Model / provider wiring
+
+Both endpoints are near-identical thin proxies. From
+`../hash/apps/hash-frontend/src/pages/api/petrinaut-ai-chat.api.ts`:
+
+- `const DEFAULT_MODEL = "gpt-5.5-2026-04-23"`, overridable by
+  `process.env.PETRINAUT_AI_MODEL` (line 47, 212).
+- `createOpenAI({ apiKey })` → `createProviderRegistry({ openai })` →
+  `registry.languageModel(\`openai:${modelId}\`)`. **OpenAI only**; the registry
+  indirection exists but no second provider is registered anywhere.
+- `streamText({ model, system: petrinautAiPrompt, messages, tools })` with
+  `providerOptions.openai = { reasoningEffort: "medium", reasoningSummary: "auto",
+textVerbosity: "medium" }`.
+- Returns `result.toUIMessageStreamResponse({ sendReasoning: true, … })`.
+- Pinned to `runtime: "edge"`. The comment at lines 18-42 explains this is
+  load-bearing: App Router is incompatible with the repo's custom `pageExtensions`,
+  and Vercel's Node serverless functions buffer the whole response, killing
+  streaming. Edge returns a Web `Response` over a `ReadableStream`.
+- Auth: Ory session cookie resolved by fetching `${apiOrigin}/auth/sessions/whoami`
+  (the Ory SDK is not edge-safe, line 138-141).
+- Rate limiting: in-memory token buckets, 10 requests / 30 s per Ory identity,
+  with a candid `@todo move to a durable store before relying on this` (line 82).
+
+### 2.4 Tool-use shape — the key architectural fact
+
+The tool _schemas_ are declared server-side but **every tool executes in the
+browser**. `petrinautAiTools` entries carry only `{ description, inputSchema }`
+(`ai.ts:39-42`) — no `execute`. The server further strips them to a
+validation-only `ToolSet` with `outputSchema: z.unknown()`
+(`petrinaut-ai-chat.api.ts:61-70`).
+
+Execution happens in `ai-assistant-panel.tsx` inside `useChat`'s `onToolCall`
+(from line ~340), dispatching to:
+
+- `applyPetrinautAiMutation` — looks up
+  `createPetrinautAiWritableCallbacks(instance)[toolName]` and calls it against
+  the live editor instance, returning a human-readable summary as tool output.
+- `applyPetrinautAiCommand` — an exhaustive switch, currently only
+  `applyAutoLayout`.
+- Read tools handled inline: `getLatestNetDefinition` returns
+  `{ title, definition: instance.definition.get(), extensions: instance.extensions }`;
+  `getNetCompilationErrors` returns formatted TS diagnostics; `readPetrinautDoc`
+  returns one of eleven bundled user-guide pages.
+
+The tool surface is the editor's mutation API verbatim — the prompt says so:
+"The tools use Petrinaut's raw mutation interfaces, so include stable IDs, full
+entity objects where required, and canvas positions." Mutation schemas live in
+`../hash/libs/@hashintel/petrinaut-core/src/action-schemas.ts` (561 lines);
+AI-exposed commands in `command-schemas.ts` (53 lines). Every schema must carry a
+`.describe()` — `getSchemaDescription` throws otherwise (`ai.ts:50-55`).
+
+Read tools: `getLatestNetDefinition`, `getNetCompilationErrors`,
+`readPetrinautDoc`. Write: all mutations + `setNetTitle` + `applyAutoLayout`.
+
+### 2.5 Conversation state and the agentic loop
+
+`useChat<PetrinautAiMessage>` in `ai-assistant-panel.tsx` with:
+
+- `sendAutomaticallyWhen: lastAssistantMessageIsCompleteWithToolCalls` — this is
+  the entire agent loop. Multi-step tool use is the AI SDK's client-driven
+  round-trip, not a server-side loop.
+- `experimental_throttle: 80` (ms) to stop reasoning deltas locking the main thread.
+- Two **transport decorators**, composed in `buildWrappedTransport`:
+  - `createDiagnosticsAwareAiTransport` — after a code-writing mutation, waits for
+    the LSP diagnostics version to bump (1 s timeout, 25 ms poll) and injects a
+    diagnostics context message into the next request. This is how "the assistant
+    sees TypeScript errors without the user relaying them."
+  - `createReasoningTimingAwareAiTransport` — stamps reasoning chunks with
+    `Date.now()` so elapsed-time survives panel close/reopen.
+- Host-pluggable transport via the `aiAssistant` prop
+  (`../hash/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx:39-44`):
+
+```ts
+export type PetrinautAiAssistant = {
+  messages?: PetrinautAiMessage[];
+  onClearMessages?: () => void;
+  onMessages?: (messages: PetrinautAiMessage[]) => void;
+  transport: PetrinautAiTransport; // = ChatTransport<PetrinautAiMessage>
+};
+```
+
+`aiAssistant` is **optional** on `PetrinautProps`; omitting it disables the panel.
+This is the cleanest extension point in the whole codebase for brunch purposes:
+a host supplies an arbitrary `ChatTransport` and owns message storage.
+
+Read-only rules are enforced client-side via `useReadOnlyReason` and
+`simulateModeAllowedMutationNames`; the panel renders only in Edit mode
+(`../hash/libs/@hashintel/petrinaut/docs/ai-assistant.md`).
+
+---
+
+## 3. IR and persistence of assistant output
+
+### 3.1 There is no intermediate representation
+
+The assistant does not emit a net document. It emits **a stream of mutation tool
+calls against the live editor**, each validated by a zod schema and applied
+immediately to the in-memory SDCPN. The SDCPN itself is the only representation.
+There is no plan object, no proposed-net staging area, no diff-then-apply step.
+Consequence: the assistant's output is not an artifact you can inspect, version,
+or hand to another system — it is a side effect on a document.
+
+### 3.2 Net persistence in HASH
+
+`../hash/apps/hash-frontend/src/pages/processes/[uuid].page/process-editor/use-process-save-and-load.tsx`:
+`persistDefinition(petriNet: SDCPN, title: string)` writes a HASH graph entity of
+type `systemEntityTypes.petriNet`, patching two properties:
+
+- `systemPropertyTypes.definitionObject` — the **entire SDCPN as one opaque JSON
+  blob**, `dataTypeId: blockProtocolDataTypes.object`.
+- `systemPropertyTypes.title` — text.
+
+So HASH's graph does not model places/transitions as entities; it stores the net
+as a single property value. Revision history comes free from HASH's entity
+versioning (`refetchRevisions`, and a `version-picker.tsx` in the embed).
+
+The editor consumes storage through a narrow interface it does not own —
+`PetrinautDocHandle` in
+`../hash/libs/@hashintel/petrinaut-core/src/handle/types.ts`:
+
+```ts
+export interface PetrinautDocHandle {
+  readonly id: DocumentId;
+  readonly capabilities?: PetrinautHandleCapabilities;
+  readonly state: ReadableStore<DocHandleState>;
+  whenReady(): Promise<void>;
+  doc(): SDCPN | undefined;
+  change(fn: (draft: SDCPN) => void): void;
+  subscribe(listener: (event: DocChangeEvent) => void): () => void;
+  readonly history?: PetrinautHistory;
+}
+```
+
+`createJsonDocHandle({ initial: SDCPN, capabilities?, historyLimit? })`
+(`handle/json-doc-handle/create-json-doc-handle.ts:51-88`) is the default
+in-memory Immer-backed implementation, with patch-based undo/redo (default 50
+checkpoints). The docstring states the contract's purpose plainly: "Petrinaut is
+built around the `PetrinautDocHandle` contract so hosts can provide different
+document backends, such as local JSON state, collaborative documents, or
+read-only mirrors."
+
+### 3.3 AI conversation persistence: localStorage
+
+`../hash/apps/hash-frontend/src/pages/processes/[uuid].page/process-editor/ai-messages-storage.ts`:
+
+> `localStorage`-backed persistence for Petrinaut AI-assistant conversations,
+> keyed by net. Lives on the host (`process-editor`) because the Petrinaut editor
+> runs inside a sandboxed null-origin iframe whose opaque origin has no usable
+> `localStorage`; the iframe relays conversation updates over the postMessage
+> bridge and the host reads/writes here.
+
+Root key `"petrinaut-ai-messages"`, shape `Record<netKey, PetrinautAiMessage[]>`,
+with corrupt JSON and quota failures swallowed to empty. The iframe sends
+`{ kind: "aiMessagesChanged", messages }` over the bridge
+(`embed.page/embed-content.tsx:286-287`) and the host writes it
+(`process-editor.tsx:792-796`).
+
+**The interview transcript is not in the database.** It is browser-local,
+per-device, and lost on cache clear.
+
+### 3.4 The demo site is a complete, minimal reference host
+
+`../hash/apps/petrinaut-website/src/main/app/local-storage-demo/local-storage-demo-app.tsx`
+is the smallest working integration in the repo and the best thing to read before
+costing §6b. It hosts the full editor from a plain Vite React SPA with:
+
+```ts
+import {
+  createJsonDocHandle,
+  type PetrinautDocHandle,
+  type SDCPN,
+} from "@hashintel/petrinaut-core";
+import {
+  DefaultChatTransport,
+  Petrinaut,
+  type PetrinautAiChatTransport,
+  type PetrinautAiMessage,
+  WalkthroughProvider,
+} from "@hashintel/petrinaut/ui";
+```
+
+…a `createJsonDocHandle` per net, nets in localStorage (`use-local-storage-sdcpns`),
+AI messages in localStorage (`use-local-storage-ai-messages`), and the AI wiring
+reduced to one expression: `new DefaultChatTransport({ api: "/api/chat" })` passed
+as `aiAssistant={{ transport, messages, onMessages, onClearMessages }}`. So both
+`Petrinaut` and a ready-made `DefaultChatTransport` are re-exported from
+`@hashintel/petrinaut/ui` — a host does not have to implement `ChatTransport`
+itself unless it wants to.
+
+Note this means **neither host persists nets server-side except HASH**: the demo
+site keeps nets and conversations in localStorage.
+
+### 3.5 The postMessage bridge — the full host contract
+
+Because the editor runs in a sandboxed null-origin iframe, everything it needs
+from HASH crosses a typed message bridge. The message union is in
+`../hash/apps/hash-frontend/src/pages/processes/shared/messages.ts` and is the
+most complete statement anywhere of what a host must provide:
+
+- **Host → iframe**: `init`, `load`, `setReadonly`, `setCapabilities`,
+  `revisionsList`, `saveResult`, `aiChatResponseStart`, `aiChatChunk`,
+  `aiChatEnd`, `aiChatError`, `optimizationCreateResult`,
+  `optimizationResponseStart`, `optimizationChunk`, `optimizationEnd`,
+  `optimizationError`.
+- **iframe → host**: `ready`, `dirtyChanged`, `titleChanged`, `requestSave`,
+  `requestNavigateBack`, `requestRevision`, `reportError`, `aiChatRequest`,
+  `aiChatAbort`, `optimizationCreate`, `optimizationAttach`,
+  `optimizationAbort`, `optimizationCancel`, `aiMessagesChanged`,
+  `aiMessagesCleared`.
+- Load state is `{ kind: "draft"; seedKey } | { kind: "saved"; entityId; userEditable }`.
+
+Two things worth noting. First, **the AI stream is chunk-relayed through the
+bridge** (`aiChatRequest` → `aiChatChunk`\* → `aiChatEnd`), because the null-origin
+iframe cannot reach the API route itself; the host page fetches it with the user's
+session cookie (documented at `petrinaut-ai-chat.api.ts:34-38`). Second, roughly
+half the surface is optimization plumbing — the AI half is small, and it is all
+transport and message storage, with no notion of a session, a capture store, or a
+resumable interview.
+
+### 3.6 Provenance and assumption capture: none
+
+I searched for provenance/rationale/assumption capture and found none. Concretely:
+
+- No field on `SDCPN` or any of its members records where a value came from,
+  who asserted it, or how confident anyone was. The type is
+  `{ places, transitions, types, differentialEquations, parameters, scenarios?,
+metrics?, subnets?, componentInstances? }` (§5).
+- The prompt asks the model to give "a one-line justification for each major
+  choice" when it invents values, and to use final text to "explain important
+  modelling choices, assumptions, how the pieces work together" — but that
+  justification lands in **chat prose**, which is stored in localStorage and never
+  linked to the net element it justifies.
+- The file format's only metadata is `meta: { generator, generatorVersion? }`.
+
+For an elicitation product whose value proposition includes defensible
+assumptions, this is a genuine greenfield gap rather than something to inherit.
+It is also the clearest place brunch adds something Petrinaut does not have.
+
+---
+
+## 4. Task / job / subagent architecture
+
+**There is none, around the assistant.** Specifically:
+
+- No queue, no background job, no durable workflow for AI work. The only
+  agentic loop is `sendAutomaticallyWhen` in the client `useChat`.
+- No multi-agent or subagent structure. `petrinautAiPrompt` is one system prompt;
+  a repo-wide grep for its consumers returns exactly the two proxy endpoints, the
+  panel, and `ai.test.ts` — nothing else imports it.
+- No server-side session state at all. Both endpoints are stateless: validate
+  messages, `streamText`, stream back.
+- Streaming: SSE-style UI message stream from the AI SDK
+  (`toUIMessageStreamResponse`), with `sendReasoning: true`.
+
+Background compute _does_ exist, but for simulation, not AI:
+
+- Web Workers for simulation, Monte Carlo, and the LSP
+  (`petrinaut-core/src/workers/{simulation,monte-carlo,lsp}`), with a documented
+  frame/backpressure protocol and ack policies per play mode
+  (`../hash/libs/@hashintel/petrinaut/ARCHITECTURE.md:13-49`).
+- A real detached-job system for **optimization**: `../hash/apps/petrinaut-opt`
+  (Python/Optuna, `pyproject.toml`, `uv.lock`, `openapi/`, `docker/`) proxied
+  through `../hash/apps/hash-api/src/petrinaut-optimizer/` with
+  `create-petrinaut-optimization-run-handler.ts`, an SSE events handler, and a
+  cancel handler. `.changeset` and git log show "detached, reconnectable
+  optimization runs […] proxied through NodeAPI" (FE-1224/1225, #9067).
+
+The optimization path is the one existing precedent in Petrinaut for
+"long-running server-side work with streamed progress" — worth reading if brunch
+ever needs to run inside HASH's backend, but it is a Python compute service, not
+an agent host. Its protocol (`../hash/apps/petrinaut-opt/README.md:11-40`) is
+`POST /optimize/runs` → `201 {run_id}`; `GET /optimize/runs/{run_id}/events` →
+replayable `text/event-stream` resumable by cursor / `Last-Event-ID`;
+`DELETE /optimize/runs/{run_id}` cancels. Run state is an **in-memory dict with a
+reaper — no database** (`src/optimization_runs.py:232-440`). The HASH side
+(`hash-api/src/petrinaut-optimizer/setup-petrinaut-optimizer-handler.ts`) is a
+stateless proxy; `/capabilities` is config-only rather than a healthcheck, and the
+frontend **fails open**, hiding the UI only on an explicit `{ optimization: false }`.
+The editor works fully without it: `PetrinautOptimizationContext` defaults to
+`null` = unavailable, UI hidden
+(`petrinaut/src/react/optimization-context.ts:5-11`).
+
+**Correction to "no headless path", worth knowing for §6a.** The optimizer service
+delegates _all_ Petrinaut semantics to `@hashintel/petrinaut-cli` over a **stdio
+subprocess** — `subprocess.Popen(("petrinaut", ...))` in
+`../hash/apps/petrinaut-opt/src/petrinaut_client.py:11,60-119`. So a headless,
+Node-based way to _load and simulate_ a net does exist and is in production use.
+What does not exist headlessly is net _generation_ by the assistant — that remains
+browser-only. The CLI is `private: true` and unpublished, so consuming it means
+vendoring or building from the monorepo.
+
+Note for §6a: the monorepo _does_ have serious agent infrastructure —
+`../hash/apps/hash-ai-worker-ts` (Temporal-based) and `../hash/apps/mcp` — but
+Petrinaut is wired to neither.
+
+---
+
+## 5. Net file format (the artifact boundary)
+
+### 5.1 The runtime type
+
+`../hash/libs/@hashintel/petrinaut-core/src/types/sdcpn.ts:210-220`:
+
+```ts
+export type SDCPN = {
+  places: Place[];
+  transitions: Transition[];
+  types: Color[];
+  differentialEquations: DifferentialEquation[];
+  parameters: Parameter[];
+  scenarios?: Scenario[];
+  metrics?: Metric[];
+  subnets?: Subnet[];
+  componentInstances?: ComponentInstance[];
+};
+```
+
+Five required arrays (may be empty), four optional. Zod schemas for each member
+live in `../hash/libs/@hashintel/petrinaut-core/src/action-schemas.ts` (exported
+via `ai.ts` as `placeSchema`, `transitionSchema`, `arcEndpointSchema`,
+`colorSchema`, `parameterSchema`, `differentialEquationSchema`, `metricSchema`,
+`scenarioSchema`, `subnetSchema`, `componentInstanceSchema`), plus
+`src/schemas/{entity,metric,scenario}-schema.ts`.
+
+### 5.2 The file format
+
+`../hash/libs/@hashintel/petrinaut-core/src/file-format/`:
+
+| File                    | Role                                                                        |
+| ----------------------- | --------------------------------------------------------------------------- |
+| `types.ts`              | `SDCPN_FILE_FORMAT_VERSION = 1`, `sdcpnFileSchema`, `legacySdcpnFileSchema` |
+| `parse-sdcpn-file.ts`   | `parseSDCPNFile(data: unknown): ImportResult`                               |
+| `serialize-sdcpn.ts`    | `serializeSDCPN({ petriNetDefinition, title, removeVisualInfo? })`          |
+| `remove-visual-info.ts` | strips `x`/`y`, `displayColor`, `iconSlug`                                  |
+| `sdcpn-to-tikz.ts`      | LaTeX export (structure only)                                               |
+
+The versioned root schema (`types.ts:160-173`):
+
+```ts
+const fileMetaSchema = z.object({
+  generator: z.string(),
+  generatorVersion: z.string().optional(),
+});
+
+export const sdcpnFileSchema = sdcpnSchema.extend({
+  version: z.number().int().min(1).max(SDCPN_FILE_FORMAT_VERSION),
+  meta: fileMetaSchema,
+  title: z.string(),
+});
+```
+
+**A `meta.generator` field already exists in the format.** Petrinaut writes
+`generator: "Petrinaut"` (`serialize-sdcpn.ts`); nothing stops brunch writing
+`generator: "brunch"`. This is the format anticipating external producers.
+
+`parseSDCPNFile` is pure ("Pure — no DOM, no I/O. Callers […] are responsible for
+sourcing the data") and handles three cases: versioned v1, legacy (no
+`version`/`meta`), and pre-2025-11-28 formats. It rejects future versions
+explicitly rather than silently stripping an unknown `version`
+(`parse-sdcpn-file.ts:130-150`) and returns typed Zod issue paths on failure —
+so an external generator gets actionable errors.
+
+Both `parseSDCPNFile` and `serializeSDCPN` are exported from the package index
+(`petrinaut-core/src/index.ts:429,432`).
+
+**There is no file-format migration system beyond v1 + the legacy fallback.**
+`../hash/libs/@hashintel/petrinaut-core/src/schema-migration.ts` looks like one by
+name but is unrelated: it migrates _positional scenario rows_ when a user edits a
+colour type's `elements` array in the editor (`TypeElementEdit` = add / remove /
+move / changeType), coercing stored cells to the new element types. Its docstring
+notes "Name-only renames are NOT represented here: scenario rows are positional,
+so renames require no row migration." Nothing to do with files.
+
+**Two schema tiers, and the difference matters a lot for a generator.**
+
+- **Strict tier** — `../hash/libs/@hashintel/petrinaut-core/src/schemas/entity-schemas.ts`,
+  `metric-schema.ts`, `scenario-schema.ts`. Every entity is `z.strictObject` with
+  no defaults, ids via `idSchema`, place/transition names via `entityNameSchema`
+  (PascalCase). **This is the tier the AI mutation tools and the runtime use** —
+  unknown keys are a hard failure.
+- **Permissive tier** — `file-format/types.ts:28-146`, used **only on import**. It
+  re-wraps each strict schema's `.shape` in a plain `z.object` and loosens fields:
+
+```ts
+const placeSchema = z.object({
+  ...currentPlaceSchema.shape,
+  id: z.string(), // overrides idSchema
+  name: z.string(), // overrides entityNameSchema — no PascalCase check
+  x: z.number().optional(),
+  y: z.number().optional(),
+});
+```
+
+Its own comment explains why: "File import intentionally stays more permissive
+than current runtime/action schemas: older files may omit visual fields and input
+arc type, and imported display names may predate current UI validation rules."
+
+Three consequences for brunch:
+
+1. **Unknown keys on an individual place/transition/colour in a _file_ are
+   stripped, not rejected** — the opposite of the AI-tool path. So a file can
+   carry per-element extra keys; Petrinaut just drops them on import.
+2. **Import bypasses name validation.** A file may contain a place named
+   `"Order queue"`. It will load — and then break every code surface, because
+   place names are used as identifiers (`input.PlaceName`,
+   `state.places.PlaceName.count`). A generator must enforce PascalCase itself;
+   the file schema will not.
+3. **Import loses an invariant check.** `currentInputArcSchema` requires exactly
+   one of `placeId` / `endpoint` via `.check(assertSingleArcEndpoint)`
+   (`entity-schemas.ts:78-98`), but re-wrapping `.shape` in `z.object` drops the
+   `.check`. An arc with neither or both passes validation and only throws later,
+   at `getArcEndpoint` (`../hash/libs/@hashintel/petrinaut-core/src/arc-endpoints.ts:33`).
+   This is a live footgun for an external generator — credit to the parallel
+   survey for spotting it.
+
+Note also that arcs have **two accepted endpoint forms**: the legacy shorthand
+`{ placeId, weight }` and the newer `{ endpoint: { kind: "place", placeId }, weight }`.
+Repo examples use both (§5.6).
+
+The strict-tier schemas carry long `.meta({ description })` strings on nearly
+every field — they are simultaneously the validation contract and the model's
+field documentation, and they are the right thing to read before generating nets.
+
+Required vs optional in the strict tier, for the record: **Place** requires `id`,
+`name`, `colorId` (nullable), `dynamicsEnabled`, `differentialEquationId`
+(nullable), `x`, `y`; optional `isPort`, `visualizerCode`, `showAsInitialState`.
+**Transition** requires all of `id`, `name`, `inputArcs`, `outputArcs`,
+`lambdaType`, `lambdaCode`, `transitionKernelCode`, `x`, `y` with nothing
+optional. **Color** requires `id`, `name`, `iconSlug`, `displayColor`, `elements`;
+each element requires `elementId`, `name` (must match
+`/^[A-Za-z_$][A-Za-z0-9_$]*$/`), `type`. **Parameter** requires `id`, `name`,
+`variableName` (lower*snake_case), `type`, `defaultValue` (a \_string*, refined by
+`getParameterValueError`). **Scenario** requires `id`, `name`,
+`scenarioParameters`, `initialState`, with `parameterOverrides` defaulting to
+`{}`; scenario parameter `type` admits a fourth value, **`ratio`**, that net
+parameters do not. **Metric** requires `id`, `name`, `code`. **Subnet** requires
+its own `places`, `transitions`, `types`, `differentialEquations`, `parameters`
+and notably has **no** `scenarios`/`metrics`/nested `subnets`.
+
+**Forgiveness on import.** `fillMissingVisualInfo` defaults every missing `x`/`y`
+to 0 and every `Color` to `iconSlug: "circle"`, `displayColor: "#808080"`, and
+recurses into subnets; `hasMissingPositions` reports whether ELK layout is needed
+(`parse-sdcpn-file.ts:19-111`). So **a generator may omit all layout and all
+palette information** and still produce a net that opens and looks reasonable.
+
+### 5.3 Minimum viable externally-generated net
+
+**At the file level the floor is lower than the runtime type suggests.** In
+`sdcpnSchema` only `places` and `transitions` lack a default; `types`,
+`differentialEquations`, `parameters`, `scenarios`, `metrics`, `subnets`, and
+`componentInstances` all carry `.default([])` (`types.ts:148-158`). So the
+smallest file Petrinaut will accept is:
+
+```json
+{
+  "version": 1,
+  "meta": { "generator": "brunch", "generatorVersion": "0.1.0" },
+  "title": "Elicited process model",
+  "places": [
+    /* … */
+  ],
+  "transitions": [
+    /* … */
+  ]
+}
+```
+
+Everything else — the other seven arrays, all `x`/`y`, all colour palette info —
+is filled by defaults and ELK.
+
+At the _runtime_ level (constructing an `SDCPN` in code rather than parsing a
+file, e.g. if brunch depends on `petrinaut-core`), the five required arrays must be
+present explicitly. The `toSDCPN` normalizer at
+`../hash/apps/petrinaut-website/src/main/app/brunch-demo/brunch-definition.ts:23-47`
+is a working demonstration of that floor. It fills:
+
+- per place: `{ id, name, colorId: null, dynamicsEnabled: false,
+differentialEquationId: null, x, y }`
+- per transition: `{ id, name, inputArcs, outputArcs, lambdaType: "predicate",
+lambdaCode: "", transitionKernelCode: "", x, y }`
+- `types: []`, `differentialEquations: []`, `parameters: []`
+
+That is the whole minimum: a graph with ids, names, and arcs, and three empty
+arrays. Arc shape is `{ placeId, weight, type?: "standard" | "read" |
+"inhibitor" }` on input and `{ placeId, weight }` on output.
+
+### 5.4 What the net file does NOT contain (important for generation)
+
+**There is no initial marking in the net.** Greps for `marking` / `tokens` /
+`initialMarking` in both `types/sdcpn.ts` and `file-format/types.ts` return zero
+hits. `SDCPN` describes _structure only_. Initial state is either:
+
+- **session state** — `SimulationProvider`'s `initialMarking`
+  (`Record<placeId, TokenRecord[] | number>`), which ARCHITECTURE.md explicitly
+  calls "configuration for the _next_ run" that "survives `reset()`" and is never
+  serialized into the net; or
+- **a scenario** — `scenario.initialState`, a discriminated union
+  (`schemas/scenario-schema.ts:42-80`):
+  - `{ type: "per_place", content }` — **keyed by place ID**; uncoloured values are
+    _string expressions_ with `parameters` and `scenario` in scope (e.g.
+    `"scenario.population * (1 - scenario.infected_ratio)"`, `Math.round`ed and
+    clamped ≥ 0); coloured values are row arrays in colour-element order.
+  - `{ type: "code", content }` — a function body returning an object **keyed by
+    place NAME**, an asymmetry the schema itself flags.
+
+So **a brunch-generated net that should start with tokens somewhere must emit a
+`scenario`.** A bare `places` + `transitions` file loads as an empty-marking net
+that will not do anything when simulated. This is the single most likely way for a
+naive generator to produce a file that "opens in Petrinaut" but is useless — worth
+building into brunch's output contract and its own validation.
+
+**There is also no timing field.** No `delay`, `duration`, or `firingTime` exists
+anywhere. Durations are modelled purely as `lambdaType: "stochastic"` plus a
+`lambdaCode` returning a rate in firings per simulation second (with the
+non-exponential patterns documented in `docs/useful-patterns.md`). Likewise
+`seed`, `dt`, and `maxTime` are session-only
+(`petrinaut-core/src/simulation/api.ts:62-88`), never in the file.
+
+### 5.5 SDCPN features in the format today — all present
+
+`../hash/libs/@hashintel/petrinaut-core/src/extensions.ts:11-49`:
+
+```ts
+export const PETRINAUT_EXTENSION_NAMES = [
+  "colors",
+  "stochasticity",
+  "dynamics",
+  "parameters",
+  "subnets",
+] as const;
+export const DEFAULT_PETRINAUT_EXTENSIONS = {
+  colors: true,
+  stochasticity: true,
+  dynamics: true,
+  parameters: true,
+  subnets: true,
+};
+```
+
+All five ship enabled by default. Mapping to the SDCPN acronym:
+
+- **Dynamic colouring** — `types: Color[]` (typed token attributes: real, integer,
+  boolean, uuid, string), `place.colorId`, transition kernels producing typed
+  output tokens.
+- **Stochastic transitions** — `transition.lambdaType: "stochastic" | "predicate"`
+  with `lambdaCode`; rate in firings per simulation second, `0` disables,
+  `Infinity` always fires. `Distribution.Gaussian/Uniform/Lognormal` available in
+  kernels.
+- **Guards** — the `predicate` lambda type is the guard mechanism; plus
+  **inhibitor arcs** and **read arcs** as first-class arc types.
+- **Continuous dynamics** — `differentialEquations: DifferentialEquation[]` with
+  `Dynamics((tokens, parameters) => …)` returning derivatives for real-valued
+  elements; requires both `colors` and `dynamics`.
+- **Hierarchical subnets** — `subnets: Subnet[]` + `componentInstances`, with
+  boundary places exposed as ports. UI is behind **Settings → Net Components**
+  (`docs/drawing-a-net.md:76-80`).
+- Also in-format: global `parameters`, named `scenarios` (parameter overrides +
+  per-place or code-mode initial marking), and `metrics` (compiled scalar
+  functions over simulation state).
+
+A host can _disable_ extensions per document via
+`PetrinautHandleCapabilities.disabledExtensions`, and
+`resolvePetrinautHandleCapabilities` enforces the dependency that disabling
+`colors` also disables `dynamics`. `sanitizeSDCPNForExtensions` strips disabled
+content on handle creation. The assistant is told to consult `extensions` before
+authoring extension-specific content.
+
+### 5.6 Import/export UX
+
+`../hash/libs/@hashintel/petrinaut/docs/drawing-a-net.md:161-173`:
+
+> **Export**: **JSON** — the full SDCPN […] **and** canvas positions / display
+> colours. The format other Petrinaut instances can re-import faithfully.
+> **JSON without visual info** — the same payload minus node positions and type
+> display colours. Useful when only the logical structure matters […] On import,
+> the receiving editor applies auto-layout to fill in positions.
+> **TikZ** — […] Token types, dynamics, read/inhibitor arcs, scenarios, and
+> metrics are **not** encoded.
+>
+> **Import**: loads a net from a `.json` file. If node positions are missing, an
+> automatic layout is applied on load.
+
+**Important caveat, now confirmed: HASH's embed has no Import button.** The menu
+items are host-controlled via `PetrinautProps.hideNetManagementControls`
+(`petrinaut.tsx:55-65`), and
+`../hash/libs/@hashintel/petrinaut/src/ui/views/Editor/editor-view.tsx:113` reads:
+
+```ts
+const showNetManagementMenuItems = hideNetManagementControls === undefined;
+```
+
+HASH's embed passes `hideNetManagementControls="except-title"`
+(`../hash/apps/hash-frontend/src/pages/processes/[uuid]/embed.page/embed-content.tsx:438`),
+so `showNetManagementMenuItems` is `false` and the gated items — **New, Open,
+Import, Load example** (`editor-view.tsx:259-330`) — are all absent. **Export,
+Layout, and Docs are ungated and remain available.** So the asymmetry is: HASH can
+export a net but cannot import one; demo.petrinaut.org (which passes nothing) has
+the full set. See §6c for what this does to the artifact-boundary option.
+
+**Example nets to copy**, in `../hash/libs/@hashintel/petrinaut-cli/examples/` —
+note most are in the _legacy_ (unversioned) shape, so pick the right model:
+
+- **`supply-chain-profit-model.json`** — the only **versioned** example:
+  `version: 1`, `meta: { generator: "Petrinaut" }`, plus empty `subnets` and
+  `componentInstances`, and arcs in the newer
+  `endpoint: { kind: "place", placeId }` form. **This is the file to model
+  brunch's output on.**
+- `sir-model.json` (7 KB, the smallest), `deployment-pipeline.json`,
+  `satellites-launcher.json`, `production-with-machine-failure.json`,
+  `supply-chain-with-disruption.json` — all **legacy**: no `version`/`meta`, arcs
+  in the `placeId` shorthand.
+- `supply-chain-profit-optimization.json` is a different format entirely
+  (`kind: "petrinaut-optimization"`, schema at
+  `petrinaut-core/src/optimization.ts:139-170`) — not a net.
+- Also `../hash/libs/@hashintel/petrinaut/gen/ex-supplychain.gen.json` and
+  `gen/ex-satellites.gen.json` — unversioned, and they carry an extra top-level
+  `id` with no `scenarios`/`metrics`.
+
+**No example net in the repo has non-empty `subnets`, `componentInstances`, or
+`isPort`.** Hierarchy coverage is TypeScript-only
+(`petrinaut-core/src/lsp/lib/helper/create-sdcpn.ts` plus tests). If the demo needs
+hierarchical subnets, there is no worked JSON example to copy and that path is
+comparatively unexercised — treat it as a spike, not a given.
+
+---
+
+## 6. Comparative audit
+
+### 6a. brunch-in-Petrinaut (elicitor as a library Petrinaut imports)
+
+**What would have to be true.** The elicitor would need to be an ESM package
+importable by React 19 + React Compiler + Panda CSS code, with no `@local/*`
+imports, type-checked under `tsgo`, linted by type-aware oxlint, versioned by
+changesets, and released on `main` pushes.
+
+Facts that cut against it:
+
+- **The elicitor's shape is wrong for the slot that exists.** Petrinaut's AI
+  extension point is `PetrinautAiAssistant`, i.e. a `ChatTransport` plus message
+  storage. A transport is a request/response pipe. An elicitor that owns a
+  conversation loop, an `ask` API, a capture envelope, an issue queue, and sweep
+  bookkeeping (per brunch-lite's `CONTEXT.md`) does not fit behind a transport
+  without either collapsing to a server the transport points at (which is §6c
+  with extra steps) or reimplementing the loop client-side.
+- **Petrinaut has no backend to host an LLM loop with persistence.** Both AI
+  endpoints are stateless proxies; HASH's is pinned to the **Edge** runtime for
+  streaming reasons documented at length, and Edge is a poor host for a
+  stateful agent (no durable storage, and the existing rate limiter is already
+  flagged as broken-by-design across isolates). The demo site has one Vercel
+  function capped at 300 s. The one place in HASH that runs durable agent work is
+  `hash-ai-worker-ts` (Temporal), which Petrinaut does not touch.
+- **Conversation persistence today is localStorage.** Any elicitor needing a
+  durable capture store must bring its own storage and a way to reach it from a
+  sandboxed null-origin iframe — the iframe cannot even use `localStorage`, which
+  is why the host relays messages over postMessage.
+- **Release cadence is against a 5-week window.** npm is 2 months stale with 22
+  pending changesets; landing brunch code in the published library means either
+  waiting on HASH's release train or vendoring from the monorepo. Merging into
+  `../hash` also means entering a repo with 42 Petrinaut commits in 8 weeks from
+  4+ contributors, plus CI (`lint.yml` 16.5K, `test.yml` 15.6K, `deploy.yml` 28.2K).
+- **Capability overlap is the real cost.** Petrinaut's assistant already
+  interviews (§2.2) and already has the full mutation tool surface. Landing a
+  second elicitor inside it means either replacing `petrinautAiPrompt` (a change
+  to a shared published contract used by two apps) or running two assistants.
+
+Facts that cut for it: the extension point is genuinely clean and optional;
+`petrinautAiTools`/`petrinautAiPrompt` are already factored into core, so the
+contract is designed to be swapped; and the demo would inherit the canvas,
+diagnostics loop, and simulator for free.
+
+**Risk against 5 weeks: high.** The blocking issue is not integration mechanics,
+it is that the server-side home for an agent loop does not exist in Petrinaut and
+would have to be built inside HASH's deployment.
+
+### 6b. Petrinaut-in-brunch (net rendering/editing consumed by an elicitation app)
+
+**Is the editor exported as a reusable package? Yes.**
+`@hashintel/petrinaut@0.0.16` is on npm, `private: false`, with subpath exports
+`.`, `./react`, `./ui`, `./styles.css`, `./panda-preset`.
+
+What it needs from a host — `PetrinautProps`
+(`../hash/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx:50-69+`):
+
+- `handle: PetrinautDocHandle` — **required**. The host owns storage; §3.2's
+  interface is eight members and `createJsonDocHandle` covers the trivial case.
+- Optional: `title`, `setTitle`, `readonly`, `hideNetManagementControls`,
+  `existingNets`, `createNewNet`, `loadPetriNet`, `aiAssistant`, plus a
+  `PetrinautSlots` mechanism (`src/ui/types/petrinaut-slots.ts`) for host-injected
+  UI, and `NetManagement` context.
+
+What it costs:
+
+- **React 19.2.6 + React Compiler + Panda CSS.** brunch's substrate is the
+  Pi/Flue agent family, and brunch-lite's own notes flag that Flue's rich path
+  (`useFlueAgent`) is React-specific while `@flue/sdk` is framework-neutral. If
+  brunch has no React UI shell yet, adopting Petrinaut means adopting one.
+- **Peer deps on HASH's design system** (`@hashintel/ds-components`,
+  `@hashintel/ds-helpers`) and a Panda preset + `panda.buildinfo.json` to wire
+  into the consuming app's Panda config. Non-trivial build integration.
+- **Heavy runtime**: xyflow, Monaco, uPlot, `@babel/standalone`, three Web
+  Workers. Fine for a web app; a large surface to stand up in 5 weeks.
+- **npm staleness bites hardest here**: the published 0.0.16 predates Actual mode
+  and the HIR compiler, so consuming from npm gets a June editor.
+
+**A much cheaper variant exists and should be scoped separately:** depend on
+`@hashintel/petrinaut-core` only (five deps, no React) for SDCPN types, zod
+validation, `parseSDCPNFile`/`serializeSDCPN`, ELK auto-layout, and — if wanted —
+`petrinautAiTools`/`petrinautAiPrompt` as a starting point. brunch gets
+type-safe, schema-validated net construction with no UI coupling at all. Nothing
+in the repo does this yet, so it is untested as an integration, but the package
+boundary supports it by construction.
+
+**Risk against 5 weeks: medium for the full editor** (mostly React/Panda shell
+work and stale-npm handling), **low for core-only**.
+
+### 6c. Artifact-boundary decoupling (elicitor produces a net file Petrinaut opens)
+
+**This is the only option where the mechanism already exists in shipped code, in
+two independent forms.**
+
+_Form 1 — the JSON file._ A generator must emit an object satisfying
+`sdcpnFileSchema`: `version: 1`, `meta: { generator: string,
+generatorVersion?: string }`, `title: string`, plus the five required SDCPN arrays
+(§5.1). Layout and palette may be omitted entirely — `fillMissingVisualInfo`
+defaults them and ELK lays the net out on load. Extension-heavy content is
+optional; §5.3 gives the working minimum. Round-tripping is symmetric:
+`serializeSDCPN` produces exactly what `parseSDCPNFile` accepts, and "JSON without
+visual info" is explicitly the share-structure-only mode.
+
+**Where the file can be opened matters, and it differs by host (§5.6).** The
+hamburger → **Import** action exists on demo.petrinaut.org but is _hidden in
+HASH_, which passes `hideNetManagementControls="except-title"`. So this option has
+three sub-variants with different costs:
+
+- **Demo site**: works today, zero code. `/` with the full menu, Import a
+  brunch-generated `.json`.
+- **HASH, via the graph**: skip the UI entirely — create a `petriNet` entity with
+  the SDCPN in the `definitionObject` property (§3.2) and open
+  `/processes/<uuid>`. No Petrinaut change needed, but brunch must talk to HASH's
+  graph API and hold a session.
+- **HASH, via the UI**: needs either a one-line prop change in
+  `embed-content.tsx:438` or a new host-supplied import affordance. Small, but it
+  is a change inside `../hash` with that repo's review and release cadence.
+
+_Form 2 — the live SSE stream (already built, for brunch specifically)._ See §7.1.
+A `/brunch?sse=<url>` route consumes `definition`, `initial_state`,
+`transition_firing`, `terminal` events, normalizes the definition into a read-only
+SDCPN with all extensions disabled, and renders it in Actual mode.
+
+Costs and limits:
+
+- The artifact carries **almost no sanctioned provenance** —
+  `meta.generator` / `meta.generatorVersion` is the whole of it, and Petrinaut
+  itself captures none anywhere (§3.6). But the import path is _permissive_
+  (§5.2), which is more forgiving than I first assumed: because every
+  file-format member schema is a plain `z.object`, brunch can attach extra keys
+  **both at the top level and on individual places/transitions**, and Petrinaut
+  will strip them silently rather than reject the file. So a brunch-authored file
+  can double as its own provenance record.
+
+  The limits are real, though: stripped means **not round-trippable** — the moment
+  a user edits and re-exports from Petrinaut, every brunch annotation is gone; the
+  editor UI will never surface it; and nothing stops a future Petrinaut version
+  from tightening the file schema to strict, which would turn a silently-ignored
+  annotation into a hard import failure. Treat inline annotation as convenient, not
+  as a contract, and keep the authoritative capture on brunch's side.
+
+- **A generator has to supply things the schema will not check.** From §5.2 and
+  §5.4: place names must be PascalCase or every code surface breaks (import does
+  not validate this); arcs must carry exactly one of `placeId` / `endpoint` or the
+  file passes validation and throws later at `getArcEndpoint`; and a net with no
+  `scenario` has no initial marking, so it opens but simulates to nothing. These
+  are brunch's problems to catch, and the good news is it can — `parseSDCPNFile` is
+  pure and exported, so brunch can validate in CI, but it will need its own checks
+  on top for the three items above.
+- Petrinaut's _editing_ affordances are unavailable to the elicitor: once the
+  file is handed over, brunch cannot revise the net in place, watch the user edit
+  it, or read back what changed. It is a one-way handoff per file.
+- Nothing in the format expresses "this is a draft" or "these fields are
+  uncertain".
+- The Actual-mode form is deliberately extension-free (no colours,
+  stochasticity, dynamics, parameters), so it cannot carry an SDCPN — only a plain
+  Petri net. The file form has no such restriction.
+
+**Risk against 5 weeks: low.** Both mechanisms are shipped, `parseSDCPNFile` is
+pure and exported so brunch can validate its own output in CI, and the reference
+fixture server (§7.1) is a working contract test. The open work is generation
+quality, not integration.
+
+### 6d. Where the evidence is thin
+
+- **Forward compatibility of a generated v1 file is genuinely unknown.** There is
+  no file migration system (§5.2), and `parseSDCPNFile` rejects any `version`
+  above `SDCPN_FILE_FORMAT_VERSION` outright. If Petrinaut bumps to v2 before
+  September, brunch-generated v1 files keep working only if the legacy/v1 path is
+  retained — which is likely but is a decision owned by the Petrinaut team, not a
+  guarantee in the code.
+- I read `placeSchema` in full and confirmed the strictness pattern, but I did not
+  read every member schema in `schemas/entity-schemas.ts` /
+  `action-schemas.ts` (561 lines) / `metric-schema.ts` / `scenario-schema.ts`.
+  Per-field required/optional detail for Transition, Color, Parameter,
+  DifferentialEquation, Scenario, Metric, Subnet, and ComponentInstance is
+  uncharacterized. Anyone generating nets should read those files directly — the
+  `.meta({ description })` strings on each field are the real spec.
+- No load/perf evidence for large nets, and no evidence about whether the
+  assistant's tool-call-per-element approach scales to a net of the size the demo
+  needs — worth a spike, since a 40-place net is ~100 sequential mutation calls.
+- The Brunch SSE protocol's owner is explicitly unsettled (see §7.1); I have no
+  evidence about who on the Petrinaut side would commit to stabilizing it by
+  September.
+
+---
+
+## 7. Incidental findings
+
+### 7.1 A brunch↔Petrinaut integration already exists ("Actual mode")
+
+This was not in the ticket's assumptions and materially changes the picture.
+
+`../hash/libs/@hashintel/petrinaut-core/src/actual-mode/README.md`:
+
+> Actual Mode lets Petrinaut render an execution that comes from an external
+> source instead of from Quick Simulation or Monte Carlo. The first integration is
+> the Brunch demo route in `apps/petrinaut-website`, which connects to a Brunch
+> SSE endpoint and feeds Petrinaut a Petri net definition, an initial marking, and
+> transition firing events.
+
+Flow (README, "Current Brunch Flow"): `/brunch?sse=<url>` → `EventSource` →
+website-local parsers validate → normalize to read-only SDCPN with extensions
+disabled → `ActualModeContext` into `@hashintel/petrinaut` → core reconstructs
+markings and timeline frames.
+
+Implementation: `../hash/apps/petrinaut-website/src/main/app/brunch-demo/`
+(10 files, ~850 lines) — `brunch-protocol.ts` (zod schemas),
+`brunch-definition.ts` (normalizer, §5.3), `brunch-frame-parsers.ts`,
+`brunch-actual-mode-provider.tsx` (the `EventSource` wiring),
+`brunch-endpoint.ts`, `brunch-petrinaut.tsx`, `brunch-status-page.tsx`.
+
+SSE event names (`brunch-actual-mode-provider.tsx:250-255`): `definition`,
+`initial_state`, `transition_firing`, `terminal`, `error`. Transition payload
+(`actual-mode/README.md:46-58`):
+
+```json
+{
+  "transitionId": "start_implementation",
+  "input": { "queued": 1 },
+  "output": { "implementing": 1 },
+  "ts": "2026-06-05T17:17:27.866Z"
+}
+```
+
+`input`/`output` are transition-local token count maps, not before/after markings.
+Reconnect semantics are already solved: the stream replays from the beginning and
+Petrinaut rebuilds the timeline, so an interruption neither duplicates nor drops
+firings (`docs/actual-mode.md:17`).
+
+**There is a reference producer in-repo**:
+`../hash/apps/petrinaut-website/scripts/brunch-sse-fixture.ts` (941 lines,
+`yarn brunch:fixture`) — a Brunch-compatible SSE server that serves a net, an
+initial marking, historical firings, then streams new ones, and can replay a
+Petrinaut Actual-mode export. This is effectively a written-down contract test for
+the brunch side.
+
+**Ownership is explicitly unsettled**, and this is the caveat to weigh:
+
+> This is not a stable Petrinaut protocol yet. The Brunch SSE event names,
+> endpoint layout, raw export shape, and temporary Brunch definition schema are
+> still owned by the demo website integration. They should not be treated as a
+> public Petrinaut Core protocol until the Brunch and Petrinaut teams standardize
+> that contract.
+
+And in `brunch-protocol.ts:41-57`: "This is intentionally not Petrinaut's full
+SDCPN document format […] The whole schema is temporary and should be replaced by
+the standardized Brunch/Petrinaut protocol once that protocol is owned in
+Petrinaut Core."
+
+Note the split: Actual mode is about _executions_ (a running net), whereas the
+September demo needs _elicitation of a model_ (a net definition). The existing
+integration solves the downstream half. But its `definition` event already
+carries a net, and `brunch-definition.ts` already normalizes an external
+graph-only definition into a Petrinaut SDCPN — which is exactly the artifact
+handoff §6c needs, minus the extensions.
+
+### 7.2 Rendering and simulation capability (SDCPN in the UI)
+
+- Canvas is `@xyflow/react`; layout via ELK (`elkjs`), exposed as
+  `calculateGraphLayout` from core and as the `applyAutoLayout` AI tool.
+- Simulation: worker-based, with `SimulationProvider` mirroring `status`/`frames`
+  stores, a `PlaybackProvider` driving a `requestAnimationFrame` loop, three
+  backpressure/ack policies (`viewOnly`, `computeBuffer`, `computeMax`), and an
+  `ExecutionFrameSource` abstraction so canvas and timeline work identically for
+  live playback and Actual-mode recordings
+  (`../hash/libs/@hashintel/petrinaut/ARCHITECTURE.md`).
+- Monte Carlo experiments with per-run metric frames, distribution histograms
+  (bins × frames heatmap), and run aggregations (mean/median/min/max/p10-p90),
+  rendered with uPlot.
+- Optimization via Optuna over a scenario's flat parameters, streamed trials,
+  cancellable (§4).
+- Users author real code in-editor (transition lambdas, kernels, dynamics,
+  metrics, place visualizers as JSX) with a Monaco-based TS LSP and a diagnostics
+  panel. `.changeset/petrinaut-hir-compiler.md` records that all user code now
+  compiles through a new HIR to programs reading packed frame buffers directly,
+  replacing Babel — with an explicit compatibility break for code outside the
+  supported TypeScript subset.
+- Place visualizers are compiled in the UI package
+  (`src/ui/lib/compile-visualizer.ts`, Babel + classic React runtime) — described
+  in ARCHITECTURE.md as "the one authoring surface that is inherently React".
+
+### 7.3 Other notes
+
+- `../hash/libs/@hashintel/petrinaut/docs/` is not developer documentation — it is
+  the end-user guide, **consumed at runtime by the AI assistant** via
+  `readPetrinautDoc` (eleven pages, each with a summary in `ai.ts:104-127`). If
+  brunch ever authors Petrinaut content, this doc set is the assistant's own
+  reference and is worth reading as spec.
+- `ARCHITECTURE.md` carries an explicit note that it deliberately does _not_ live
+  in `docs/` for that reason.
+- HASH removed Petrinaut branding from the AI panel in favour of HASH breadcrumbs
+  (git log, H-6720, #9084) — the panel is already treated as a white-labelled
+  host-configurable surface.
+- `../hash/libs/@hashintel/petrinaut-old` exists alongside the current library;
+  I did not investigate what remains of it.
+- **Two latent bugs found in passing**, both consequences of the opaque-origin
+  iframe, neither blocking but both worth knowing:
+  1. Petrinaut persists its own visual/user settings to `localStorage` key
+     `"petrinaut:user-settings"` _inside the library_
+     (`petrinaut/src/react/state/user-settings-provider.tsx:19-45`, try/catch
+     wrapped). In HASH's opaque-origin iframe that storage is unavailable, so user
+     settings **silently fail to persist across reloads** in HASH while working
+     fine on the demo site.
+  2. Draft AI conversations are written but **never restored**, and are migrated
+     onto the new entity UUID on first save
+     (`process-editor.tsx:259-262`, `804-828`).
+- Sentry cannot ship from inside the embed CSP, so the iframe's `reportError`
+  bridge message exists purely so the host can re-capture errors
+  (`process-editor.tsx:563-584`).
+- HASH passes `createNewNet`/`loadPetriNet` as a `noNetSwitchingError` that
+  **throws** (`embed-content.tsx:58-63`) — the host drives every net load over the
+  bridge rather than letting the editor initiate one. Import/export
+  implementations live in `petrinaut/src/ui/file-io/` (`import-sdcpn.ts` uses a
+  hidden `<input type="file" accept=".json">` → core `parseSDCPNFile` → ELK when
+  positions are missing).
+- brunch-lite itself currently contains **no application code** — only `docs/`,
+  `.scratch/`, `CONTEXT.md`, `AGENTS.md`. There is no package.json. Whatever the
+  coupling decision, the brunch side of it is greenfield, which means no
+  dependency conflicts to inherit but also no app shell, UI, or backend to build
+  on within the 5-week window.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/re-interviewing-literature-worker-report.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/re-interviewing-literature-worker-report.md
new file mode 100644
index 00000000000..c71f10fc2a5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/re-interviewing-literature-worker-report.md
@@ -0,0 +1,188 @@
+# Requirements-engineering interviewing: worker report (verbatim catalogs)
+
+Companion to [elicitation-strategy-literature](elicitation-strategy-literature.md), which
+synthesizes this material. Preserved in full because it carries verbatim, citation-verified
+instruments the synthesis only summarizes: the Bano/Ferrari/Donati/Zowghi **34-mistake taxonomy
+with per-group frequencies** and its operationalized Likert questionnaire (the de facto
+evaluation instrument for machine interviewers - LLMREI evaluated against it directly), the
+Zaremba & Liaskos question typology, Gause & Weinberg's context-free question lists (with
+misattribution warnings), the completeness/stopping-rule literature, and the 2023-2026
+LLM-interviewer findings. Worker completed 2026-08-11.
+
+---
+
+All research threads are complete. Here is the consolidated report.
+
+---
+
+# Requirements Elicitation by Interview: Literature Report
+
+## 1. Interview-based RE guidance and technique selection
+
+### Zowghi & Coulin 2005 (read in full, camera-ready copy)
+
+**Zowghi, D. & Coulin, C., "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools," ch. 2 in Aurum & Wohlin (eds.), _Engineering and Managing Software Requirements_, Springer, 2005, pp. 19–46. DOI 10.1007/3-540-28244-0_2.** (Full chapter read via https://web.eecs.umich.edu/~weimerw/2022-481W/readings/requirements.pdf)
+
+- **Five fundamental elicitation activities** (§2.2.1): (1) understanding the application domain, (2) identifying the sources of requirements, (3) analyzing the stakeholders, (4) selecting the techniques, approaches, and tools to use, (5) eliciting the requirements from stakeholders and other sources. Plus five analyst roles: facilitator, mediator, documenter, proxy, validator.
+- ⚠️ **Premise correction:** the familiar six-category taxonomy (traditional/group/prototyping/model-driven/cognitive/contextual) is **not** theirs — it is **Nuseibeh & Easterbrook, "Requirements Engineering: A Roadmap," ICSE 2000, pp. 35–46, DOI 10.1145/336512.336523**. Zowghi & Coulin list ~20 techniques (interviews, questionnaires, task analysis, domain analysis, introspection, repertory grids, card sorting, laddering, group work, brainstorming, JAD, workshops, ethnography, observation, protocol analysis, apprenticing, prototyping, goal-based approaches, scenarios, viewpoints) and reduce them to a **core eight** (interviews, domain analysis, groupwork, ethnography, prototyping, goals, scenarios, viewpoints) in two tables: Table 2.1 maps techniques × the five activities (interviews/domain/groupwork suit all five); Table 2.2 marks each pair Complementary vs Alternative (e.g., interviews complementary with goals/scenarios/viewpoints, alternative to groupwork/ethnography/prototyping).
+- On **interviews**: "probably the most traditional and commonly used technique"; three types — unstructured ("risk that some topics may be completely neglected"; best "for exploration when there is a limited understanding of the domain, or as a precursor to more focused and detailed structured interviews"), structured ("depends on knowing what are the right questions to ask, when should they be asked, and who should answer them"; "tend to limit the investigation of new ideas"), semi-structured. Open vs closed questions appear under **questionnaires**, not interviews.
+- On matching technique to situation: they cite Hickey & Davis's four reasons analysts actually choose ((a) only technique known, (b) favorite, (c) prescribed by methodology, (d) intuition), and close: "**requirements elicitation still remains more of an art than a science**." Ethnographic techniques are flagged as "very expensive… requir[ing] significant skill," with the observer effect noted.
+
+### Hickey & Davis — the unified model of elicitation
+
+- **Hickey, A.M. & Davis, A.M., "A Unified Model of Requirements Elicitation," _Journal of Management Information Systems_ 20(4), Spring 2004, pp. 65–84, DOI 10.1080/07421222.2004.11045786.** ⚠️ Paywalled, no OA copy anywhere; not read directly. The model's content was verified from their HICSS'03 paper.
+- **Hickey & Davis, "Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes," HICSS-36, 2003, DOI 10.1109/HICSS.2003.1174229** (read in full). The model: elicitation as iterated function application — **elicitᵢ(Rᵢ, Sᵢ, tᵢ) → Rᵢ₊₁, Sᵢ₊₁**, where Rᵢ = current knowledge of requirements, Sᵢ = situation (problem-domain + solution-domain + project characteristics), tᵢ ∈ T (all known techniques). Selection: **σ(Rᵢ, Sᵢ, χ(T)) → {applicable techniques}**, where χ(T) = static technique characteristics; then a personal selector **π({t}, P) → tᵢ** applying analyst preferences. Composed: elicitᵢ(Rᵢ, Sᵢ, π(σ(Rᵢ,Sᵢ,χ(T)),P)). A methodology is then just a fixed sequence of elicit steps — and their critique of methodologies is that fixing tᵢ a priori assumes Sᵢ and Rᵢ in advance: "one size [methodology] fits all."
+- **Hickey & Davis, "Elicitation Technique Selection: How Do Experts Do It?", RE'03, pp. 169–178, DOI 10.1109/ICRE.2003.1232748** (read in full). In-depth interviews with nine named experts (Booch, Constantine, DeMarco, Gause, Lister, Lockwood, Robertson, Wiegers, Yourdon; the companion AMCIS'03 paper adds Reifer as tenth). Key finding: "although some experts think of themselves as practitioners of just one means of performing elicitation, they really have **a default means of doing elicitation, and anomalous conditions result in alternative approaches**." Four emergent constructs per technique: **Major Drivers, Anomalies, Prerequisite Skills, Success Enhancers**. They also self-apply Goguen & Linde: "A difference may exist between what these experts say they do, and what they actually do."
+- The situational-characteristics ontology is in **Hickey & Davis, "A Tale of Two Ontologies: The Basis for Systems Analysis Technique Selection," AMCIS 2003, paper 386** (read in full): 24 printed coded situational characteristics in five categories (problem domain: FUZZ, CPLX, CNFL, MATU, SECU, RESP, SAFE, RELI; solution domain: TYPE, COTS, OUTS; stakeholders: #STK, STEX, STCM, STCP, STTV, STAC, STDV; solution builders: SOEX, SOCO, SOSW, SOTO; bridge-builders: BBEX, BBTE, BBCO) out of "over fifty" isolated; plus a **ten-dimension technique attribute vector** (physical co-location, temporal co-location, record-keeping, analyst role, convergence/divergence, anonymity, stakeholder count, tool-based, product/human focus, direct/indirect). Notable empirical observation: "a moderately good technique for a specific situation in the hands of an experienced 'master' can become an ideal technique for that situation." ⚠️ No numbered "propositions" exist in any of the three 2003 papers; if JMIS 2004 adds them, that is unverified.
+
+### Goguen & Linde 1993 (read in full, author preprint)
+
+**Goguen, J.A. & Linde, C., "Techniques for Requirements Elicitation," Proc. IEEE Int. Symposium on Requirements Engineering (RE'93), San Diego, 1993, pp. 152–164, DOI 10.1109/ISRE.1993.324822.** (Preprint: https://cseweb.ucsd.edu/~goguen/ps/rqelit.pdf. Affiliations: Goguen — Oxford PRG; Linde — Institute for Research on Learning.)
+
+- Their categorization: traditional techniques (**introspection, questionnaires, interviews** [questionnaire interviews / open-ended interviews / focus & JAD groups], **protocol analysis**) vs discourse-analytic techniques (**conversation analysis, discourse analysis, interaction analysis**), grounded in ethnomethodology. Organizing principle: "The methods surveyed so far all impose an analyst's order on the social world, with no guarantee that this is the same as the order that members perceive."
+- The **say–do problem**, verbatim: "People know how to do many things that they cannot describe… This problem is so familiar that it has a nickname in social science: the _say-do problem_; also, philosophers speak of _tacit knowledge_." Moral: "**Don't ask people to describe activities that they do not normally describe, or if you do, then don't believe the answers.**" Summary verdict: "**None of these methods can elicit tacit knowledge, and all are subject to the say-do problem.**"
+- On introspection: "the introspection of an expert in a different field… is unlikely to reflect the experience of actual users"; "So called naive users are often experts in their own speciality, about which the requirements engineers are naive."
+- On interviews: questionnaire interviews suppress "interactional resources that routinely mediate uncertainties of relevance and interpretation" (via Suchman & Jordan, JASA 1990); "Interview methods can fail if the interviewer and respondent do not share a category system"; elicited narratives formally differ from spontaneous ones (Wolfson).
+- On matching to situation: they recommend a "**zooming**" method — cheap methods broadly, "the more expensive but detailed methods… only employed selectively for problems that have been determined by other techniques to be especially important"; recommended sequence: ethnography first, then interviews, then conversation/interaction analysis on selected hot spots. ⚠️ RE'93 contains **no table or figure**; the requirements-are-emergent claim ("requirements… gradually emerge from interactions") is verbatim only in Goguen's 1994 chapter "Requirements Engineering as the Reconciliation of Technical and Social Issues" (in Jirotka & Goguen, _Requirements Engineering: Social and Technical Issues_, Academic Press, 1994).
+
+## 2. INTERVIEW MISTAKES — the Ferrari/Spoletini/Bano/Zowghi/Donati taxonomy (fully verified from author manuscripts)
+
+### Chain of papers (all citations verified)
+
+1. **Donati, B., Ferrari, A., Spoletini, P., Gnesi, S., "Common Mistakes of Student Analysts in Requirements Elicitation Interviews," REFSQ 2017, LNCS, pp. 148–164, DOI 10.1007/978-3-319-54045-0_11.** 36 students, 18 sessions; first set of **9 mistake categories** (full list paywalled; not verified verbatim).
+2. **Bano, M., Zowghi, D., Ferrari, A., Spoletini, P., Donati, B., "Learning from Mistakes: An Empirical Study of Elicitation Interviews Performed by Novices," RE'18 (26th IEEE Int. RE Conf.), 2018, pp. 182–193, DOI 10.1109/RE.2018.00027.** (full text read via NSF PAR)
+3. **Bano, M., Zowghi, D., Ferrari, A., Spoletini, P., Donati, B., "Teaching requirements elicitation interviews: an empirical study of learning from mistakes," _Requirements Engineering_ 24(3), 2019, pp. 259–289, DOI 10.1007/s00766-019-00313-0.** (full author manuscript read; 110 students, 28 groups, role-played customer, two independent reviewers + customer think-aloud + observer)
+4. **Ferrari, A., Spoletini, P., Bano, M., Zowghi, D., "SaPeer and ReverseSaPeer: teaching requirements elicitation interviews with role-playing and role reversal," _Requirements Engineering_ 25(4), 2020, pp. 417–438, DOI 10.1007/s00766-020-00334-0** (full OA text read; note Ferrari-first author order). Conference precursor: Ferrari et al., "Learning Requirements Elicitation Interviews with Role-Playing, Self-Assessment and Peer-Review," RE'19, pp. 28–39, DOI 10.1109/RE.2019.00015.
+
+### The complete taxonomy — 34 mistakes in 7 categories (Fig. 3 of the REJ 2019 paper, transcribed from the rendered figure, with frequency of occurrence in 28 groups)
+
+**1. Question Formulation** — asking vague questions [21]; asking technical questions [15]; asking irrelevant/incorrect questions [6]; asking customer for solutions [4]; asking very long questions [1]; incorrect formulation of questions [1].
+**2. Question Omission** — not identifying stakeholders [12]; no probing questions [11]; not asking about existing system/business process [11]; not asking about feature prioritisation [9]; not asking about the problem domain [7]; not identifying success criteria [1]; missing relevant questions [1].
+**3. Order of Interview** — incorrect ending of interview [19]; incorrect opening of interview [15]; incorrect order of questions [15]; repeating the questions [6].
+**4. Communication Skills** — unnatural dialogue style [14]; poor communication skills (language issues) [5]; poor listening skills [2]; voice of analyst (not clear) [1]; looking at their laptop during conversation [1].
+**5. Analyst Behaviour** — lack of confidence [5]; overconfidence, arrogance [1]; passive attitude of analyst [1]; unprofessional behaviour [1].
+**6. Customer Interaction** — no rapport with customer [16]; influencing customer [1]; interrupting customer [1].
+**7. Teamwork and Planning** — lack of coordination and choreography among group [14]; lack of time management [3]; lack of preparation and planning to understand problem domain [2]; lack of planning (for interview) [1]; long pause during interview [1].
+
+Most frequent overall: (1) asking vague questions, (2) incorrectly ending the interview (no final summary — 19/28 groups), (3) not building rapport (16/28). 12/28 groups failed to identify stakeholders.
+
+Definitions worth quoting: vague questions = "the type of questions that may yield multiple interpretations, or cases where no reasonable meaning can be inferred from the questions asked." Recommended interview strategy in the study: build rapport → understand existing business process → understand problems in current process → summarize findings at the end to confirm understanding.
+
+### The operationalized questionnaire (Appendix A, REJ 2019 — verbatim statements, 5-point Likert)
+
+Question Formulation: "The analyst asked vague questions / asked technical questions / asked questions that appeared irrelevant to me / asked the customer for solutions / asked long and overly complex questions / formulated their questions in a way that appeared incorrect to me."
+Question Omission: "The analyst DID NOT ask for additional stakeholders / DID NOT ask probing questions to confirm their understanding / DID NOT ask about the existing system or business process / DID NOT ask questions about feature prioritisation / DID NOT ask information about the problem domain / DID NOT identify goals and success criteria / DID NOT ask all the questions that I consider relevant."
+Order of Interview: "DID NOT perform a summary at the end / started the interview by asking direct questions about the system / asked questions in an order that appeared incorrect to me / repeated the same questions multiple times."
+Communication Skills: "dialogue style… appears unnatural / poor communication skills / poor listening skills / spoke with a low and unclear tone."
+Analyst Behaviour: "showed lack of confidence / appeared overconfident or arrogant / showed a passive attitude / behaviour that appeared unprofessional."
+Customer Interaction: "DID NOT create rapport with the customer / tried to influence the customer / interrupted the customer."
+Teamwork & Planning: "lack of coordination and choreography among team members / did NOT manage their time / lack of preparation on the domain / did not plan the interview / long pauses during the interview."
+
+### Longitudinal findings (Study 2, REJ 2019) and training effects (SaPeer, REJ 2020)
+
+- Across three successive interviews, students **did not improve** in Question Formulation, Question Omission, or Interview Order; they got _worse_ at omission in later interviews (failed to re-ask goals/success criteria of new stakeholders). No correlation found between interview performance and final SRS marks.
+- SaPeer (role-play + mistake-based training + self-assessment + peer review): significant mistake reduction interview 1→2 (paired t = −4.77, p = 0.00012, Cohen's d = −1.037, large). Largest improvements: "no final summary," "no probing questions" — mistakes fixable by simple recommendations. Small/insignificant improvement: "not identifying success criteria," "not asking about feature prioritisation," and behavioural/systemic mistakes (Communication Skills, Analyst Behaviour, Customer Interaction) — "harder to correct with recommendations, and may require more exposure to practice." Improvement vs a practice-only control was **not** significant except for "asking customer for solutions" and "no final summary" — practice itself is the main active ingredient.
+
+### Ambiguity as a cue in interviews (Ferrari/Spoletini line — read in full)
+
+- **Ferrari, A., Spoletini, P., Gnesi, S., "Ambiguity and tacit knowledge in requirements elicitation interviews," _Requirements Engineering_ 21(3), 2016, pp. 333–355, DOI 10.1007/s00766-016-0249-3** (postprint read). Based on 34 customer–analyst interviews. Central inversion: ambiguity is not just a defect but "**a resource for discovering tacit knowledge**" — each detected ambiguity is a trigger for a follow-up question; "every unidentified ambiguity is a missed opportunity." Formal framework built on Gervasi et al.'s tacit-knowledge predicates (articulated, interpretable, acceptable, accessible): **ambiguity ⇔ the customer articulated k, and the analyst either can't access k or interprets a different k′**. Four categories: **(1) Unclarity** (interpretation unclarity — jargon/inarticulate speech; acceptance unclarity — interpretation conflicts with the analyst's mental framework of goals/requirements/domain/specification), **(2) Multiple Understanding** (several acceptable readings), **(3) Incorrect Disambiguation** (single wrong interpretation; _detected_ vs _undetected_), **(4) Correct Disambiguation** (a.k.a. innocuous ambiguity — resolved subconsciously, never surfaces). Quantitative sketch: with domain experts, interpretation unclarity 30% and domain-acceptance unclarity 21%; with CS-background customers, interpretation unclarity 24%, multiple understanding 24%, detected incorrect disambiguation 15%. Ambiguity disclosed tacit knowledge about requirements, goals, domain — and in some cases **unknown unknowns**.
+- **Ferrari, Spoletini, Gnesi, "Ambiguity Cues in Requirements Elicitation Interviews," RE'16, pp. 56–65, DOI 10.1109/RE.2016.25.** Five categories of ambiguity **cues** (linguistic triggers a listening analyst should react to): **under-specified terms, vague terms, quantifiers, pronouns, domain-specific terms** (category list verified via secondary sources/abstract; full text paywalled).
+- **Ferrari, Spoletini, Donati, Zowghi, Gnesi, "Interview Review: Detecting Latent Ambiguities to Improve the Requirements Elicitation Process," RE'17, pp. 400–405, DOI 10.1109/RE.2017.15**; and **Spoletini, Ferrari, Bano, Zowghi, Gnesi, "Interview Review: An Empirical Study on Detecting Ambiguities in Requirements Elicitation Interviews," REFSQ 2018, LNCS 10753, pp. 101–118, DOI 10.1007/978-3-319-77243-1_7** — a protocol in which a _reviewer_ listens to the interview recording to flag ambiguities the interviewer missed, generating additional questions for the next interview.
+
+### An independent synthesis: 28 interviewer-mistake criteria (Shen/Singhal/Breaux RE'25)
+
+**Shen, Y., Singhal, A., Breaux, T.D., "Requirements Elicitation Follow-Up Question Generation," RE'25 (33rd IEEE Int. RE Conf.), 2025, pp. 117–129 (arXiv:2507.02858).** From 14 papers they synthesized **28 mistake criteria** in 7 concern areas; the 14 in-paper criteria (verbatim, each with source citations):
+
+- _Follow-up questions:_ fail to elicit tacit assumptions; fail to consider alternatives; no clarification when unclear; no clarification when contradictory; fail to elicit tacit knowledge.
+- _Question framing:_ ask a generic, domain-independent question; ask a question that is too long or articulated; use jargon; ask a technical question; ask a question inappropriate to user's profile; ask for solutions; ask a question that involves multiple kinds of requirements; ask a vague question that leads to multiple interpretations; ask a vague question which could infer no reasonable meaning.
+  The other 14 (from their artifact's references.pdf, verbatim): _Opening:_ no guidelines; fail to build rapport; fail to understand the problem domain. _Ambience:_ fail to be empathetic; fail to be ethical; no protection of privacy. _Elicitation goals:_ fail to elicit explicit goals; fail to elicit feature priority; fail to elicit non-functional requirements. _Flow:_ go back and forth among topics; interrogate the interviewee with too many direct questions; fail to analyze and react to the interviewee's response; interrupt in the middle of a response. _Closing:_ fail to provide a summary.
+
+## 3. Question taxonomies
+
+### Zaremba & Liaskos 2021 — the RE-specific question typology (read in full)
+
+**Zaremba, O. & Liaskos, S., "Towards a typology of questions for requirements elicitation interviews," RE'21 (29th IEEE Int. RE Conf.), 2021, pp. 384–389, DOI 10.1109/RE51729.2021.00042** (author PDF: yorku.ca/liaskos/Papers/RE2021/RE2021.pdf). Cross-disciplinary literature review yielding a typology on dimensions **Time / Content / Form / Style / Probing Style / Objective**, plus **sequencing patterns**. Selected verbatim rows (Fig. 1):
+
+- **Time:** past / present / future.
+- **Content:** users/stakeholders ("Who are the main users?"); needs/evaluations ("What are some issues with the current system?"); processes; objects/data; required functions ("Should the system allow you to…?"); technology; pragmatics ("What is your budget on…?").
+- **Form:** open; bipolar; multiple choice; catchall ("Is there anything else that you think I should know about and we haven't yet discussed?"); comparison/contrast; declarative; introducing; specifying; structuring.
+- **Style:** ready reference; instructional ready reference; directional; tour ("Could you explain to me the process step-by-step?"); targeted mini-tour.
+- **Probing style** (>10 types): elaboration/informational ("Could you tell me more about that?"); reason-seeking ("Why do you think…?" — flagged as "an important tool for goal-oriented elicitation," citing Yu RE'97); clearinghouse ("What have I not asked that is important in this process?"); consistency ("You said earlier that **_ but then you told me _**. How do you explain that?"); interpreting; check-reflect; echo; question-reformulation; restatement; leading probe; silent probing; reflecting probe (counterfactual "what if the opposite were true").
+- **Objective / content maneuvering** (bias-injecting forms): forced choice; leading; direct vs indirect; negative balance ("You seem to be very efficient. Do you remember of any occasions in which you had problems that slowed you down?").
+- **Sequencing** (from Keats, _Interviewing_, 2000): simple structure; chain; branching with channeling; sequential with feedback loops; branching with complex loops; constellated. Consensus best practice: open/general questions first, specific later.
+  Related: Burnay, Jureta & Faulkner, "What stakeholders will or will not say…," _Information Systems_ 46, 2014, pp. 61–81, DOI 10.1016/j.is.2014.05.006 (Elicitation Topic Map: six topic sets — items, rules, localization for scope; activities, connections, granularity for depth); Scheinholtz & Wilmont, "Interview Patterns for Requirements Elicitation," REFSQ 2011, pp. 72–77.
+
+### Gause & Weinberg's context-free questions (verified against two independent scans of the book, Ch. 6, pp. 59–67)
+
+**Gause, D.C. & Weinberg, G.M., _Exploring Requirements: Quality Before Design_, Dorset House, 1989, ISBN 0-932633-13-7.** Definition (p. 59): "high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions… context-free questions help you decide which limb to climb, rather than which branch or twig."
+
+**Context-free process questions** (§6.6, p. 65, verbatim): "Who is the client? / What is a highly successful solution really worth to this client? / What is the real reason for wanting to solve this problem? / Should we use a single design team, or more than one? / Who should be on the team(s)? / How much time do we have for this project? / What is your trade-off between time and value? / Where else can the solution to this design problem be obtained? / Can we copy something that already exists?"
+
+**Context-free product questions** (p. 65, verbatim — the complete list is only four): "What problems does this product solve? / What problems could this product create? / What environment is this product likely to encounter? / What kind of precision is required or desired in the product?" (§6.3 wording says "this system" for the first three.)
+
+**Metaquestions** (§6.4, pp. 62–64, verbatim): "Am I asking you too many questions? / Do my questions seem relevant? / Are you the right person to answer these questions? / Are your answers official? / …May I write down your answers and give you a written copy to study and approve? / Is there anyone else who can give me useful answers? / Is there someplace I can go to see the environment in which this product will be used?" End of every interaction: "Is there anything else I should be asking you? / Is there anything you would like to ask me? / May I return or call you with more questions later…?" Plus paired-interviewer nonverbal probes ("I notice that you hesitated a long time before answering… Is there something else we should know?").
+
+**Verified heuristics elsewhere in the book:** the four ambiguity heuristics (§9.7, pp. 102–103): ambiguity poll; memorization heuristic; "Mary had a little lamb" (re-read emphasizing a different word each time); "Mary conned the trader" (mix-and-match dictionary definitions of key words). Ch. 25 "Ending" (pp. 277–284) is the book's answer to elicitation completeness: "Nobody can tell you just when to step off the cliff. It's simply a matter of courage" — with automatic design, hacking, freezing requirements, renegotiation, and fear of explicit assumptions named as the courage-avoiding pathologies. Rule of Three (~p. 211): "If you can't think of three things that might cause your great idea to fail, all that means is that you haven't thought enough about it yet."
+⚠️ **Misattribution warnings:** "Reverse the process," "dropping the context," "Undiscovered Ruins," "Yes, but," and "Missing user" are **not** in this book — the last three are **Leffingwell & Widrig, _Managing Software Requirements_, Addison-Wesley, 1999, ch. 7** ("The search for requirements is like a search for undiscovered ruins — the more you find, the more you know remain…" — secondhand snippet, unverified against page). The "Rule of Three Interpretations" circulating in the testing community is not in this book either.
+
+## 4. Contextual inquiry (Beyer & Holtzblatt)
+
+**Citations:** Beyer, H. & Holtzblatt, K., _Contextual Design: Defining Customer-Centered Systems_, Morgan Kaufmann, 1998, ISBN 1-55860-411-1 (print date Sept 1997). 2nd ed.: Holtzblatt, K. & Beyer, H., _Contextual Design: Design for Life_, Morgan Kaufmann/Elsevier, 2017, ISBN 978-0-12-800894-2 (author order reverses). Also Holtzblatt, Wendell & Wood, _Rapid Contextual Design_, 2005. Primary verbatim sources actually verified: **Beyer & Holtzblatt, "Apprenticing with the Customer," _CACM_ 38(5), 1995, pp. 45–52**, and **Holtzblatt & Beyer, _Contextual Design: Evolved_, Morgan & Claypool, 2014, §3.1**. Origin: **Whiteside, Bennett & Holtzblatt, "Usability Engineering: Our Experience and Evolution," in Helander (ed.), _Handbook of Human-Computer Interaction_, North-Holland, 1988, pp. 791–817** (confirmed as the authors' own cited origin); first named in Wixon, Holtzblatt & Knox, CHI'90, pp. 329–336.
+
+**Four principles** (verbatim, 2014 formulation): **Context** ("While people do their life and work activities, observe and discuss what they are doing and why. Use artifacts… Use retrospective accounts—detailed re-telling of specific events in the recent past…"); **Partnership** ("let them lead the interview by doing their own activities and commenting on them… Do not come with planned questions"); **Interpretation** ("Determine the meaning of the user's words, emotions, and actions together with the user by sharing your interpretations… They will not let you mis-construe their motivations"); **Focus** ("Steer the conversation to meaningful topics… Let users know the focus so they can steer, too"). 1998 1st-edition wording is only partially verified (Context at p. 47 as "_ongoing experience_ rather than _summary experience_, concrete data rather than abstract data"; Interpretation p. 58; Focus p. 62 — via a quotation site, treat as needing confirmation).
+
+**Master/apprentice model** (CACM 1995, verbatim): "the relationship between master craftsman and apprentice stands out as a useful model… A master teaches by doing the work and talking about it while working." Five reasons it beats interviews: teaching ability not needed; **"People are not aware of everything they do… they become aware in the doing"** (footnoted to Polanyi); seeing work reveals details ("Talking about work while doing it protects the master craftsman from the human propensity to talk in generalizations… A design built on such generalizations may not meet anyone's needs… nothing is more detailed than an organization's software development policy manual, and there are few less reliable guides to how that organization actually develops software"); seeing work reveals structure; the apprentice learns from re-told recent events.
+
+**What CI claims interviews away from the workplace cannot get** (2014, verbatim): "most people are not aware of what they really do. The everyday things people do become habitual and unconscious, so they are usually unable to articulate their practices… They are likely to forget about the workarounds they had to invent… If designers watch people while they engage in their activities, then people do not have to articulate their practices." Anti-abstraction technique: "If the customer says 'we usually get reports by email' ask, 'When was the last time that happened?'… Any statement in the present tense is usually an abstraction." Canonical example: the secretary who "just comes in and gets started" but enacts a fully structured routine when asked to do it. On bias: "customers are not easily led astray in the midst of their work… Open-ended questions give the customer less guidance in thinking about their work than an interpretation, and result in less insight."
+
+**Critique/evaluation:** CI has essentially **no controlled empirical evaluation**. Davis, Dieste, Hickey, Juristo & Moreno, RE'06, pp. 179–188, DOI 10.1109/RE.2006.17 (systematic review): "**interviews, preferentially structured, appear to be one of the most effective elicitation techniques**; many techniques often cited in the literature… tend to be less effective than interviews." Dieste & Juristo, IEEE TSE 37(2), 2011, pp. 283–304: contextual techniques absent from aggregable evidence. Cost critiques: Zowghi & Coulin ("ethnographic techniques… very expensive"); Millen's "Rapid Ethnography" (DIS'00); the _Rapid Contextual Design_ book itself. Epistemological critiques of field methods as requirements source: Anderson (HCI 9(2), 1994); Dourish, "Implications for Design" (CHI'06); Crabtree et al., "Ethnography Considered Harmful" (CHI'09).
+
+## 5. Completeness — when is elicitation done?
+
+**Standards (verbatim from the standards):**
+
+- **IEEE Std 830-1998** §4.3.3: "An SRS is complete if, and only if, it includes… a) All significant requirements… b) Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations… c) Full labels and references to all figures, tables… and definition of all terms and units of measure." §4.3.3.1: "Any SRS that uses the phrase 'to be determined' (TBD) is not a complete SRS." (Status: superseded by 29148:2011.)
+- **ISO/IEC/IEEE 29148:2011** — individual requirement Complete: "needs no further amplification because it is measurable and sufficiently describes the capability…"; set-level Complete: "contains everything pertinent… In addition, the set contains no TBD/TBS/TBR clauses," with the NOTE: "include all requirements types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity." Set characteristics 2011: Complete, Consistent, Affordable, Bounded.
+- **29148:2018** — individual: Necessary, Appropriate, Unambiguous, Complete, Singular, Feasible, Verifiable, Correct, Conforming; set: Complete, Consistent, Feasible, Comprehensible, Able to be validated. Set Complete: "stands alone such that it sufficiently describes the necessary capabilities… without needing further information," plus the TBx rule.
+- Observation: all definitions are circular or negative; the standards contain **no stopping rule**.
+
+**Theory — completeness is undecidable/relative:**
+
+- **Zave, P. & Jackson, M., "Four Dark Corners of Requirements Engineering," ACM TOSEM 6(1), 1997, pp. 1–30, DOI 10.1145/237432.237434** (read in full). All RE statements are about the environment; indicative (domain knowledge K) vs optative (requirements R); specifications S must satisfy **S, K ⊨ R**. Their §6.3 five completion criteria: R validated _informally_ as "expressing all the customer's desires"; K validated _informally_ as true of the environment; S properly restricted; proof S,K ⊨ R; proof S,K consistent. The completeness of R itself is irreducibly informal even in the strongest formal account. Also: "Because there is uncertainty about what [domain knowledge] is for, there is also uncertainty about how much of it to gather."
+- **Leveson, N., "Completeness in Formal Specification Language Design for Process-Control Systems," FMSP 2000, pp. 75–87, DOI 10.1145/349360.351140** (read in full): "**Absolute completeness… is a theoretical but probably unattainable goal… the only truly complete specification of something would be the thing itself.** The trick is to determine whether a specification is _sufficiently_ complete," relative to system requirements/hazard analysis. Her group's 26 → ~60 formal criteria trace to **Jaffe, Leveson, Heimdahl & Melhart, IEEE TSE 17(3), 1991, pp. 241–258, DOI 10.1109/32.75414** (read in full), whose robustness criteria are the formal counterpart of "asking about exceptions": every state must handle every possible input; the OR of transition guards must be a tautology; every state needs a timeout transition; all sensor inputs used; every legal output value producible. Decidable-side tooling: Heimdahl & Leveson, IEEE TSE 22(6), 1996, pp. 363–377. Empirical anchor: Lutz, RE'93 (DOI 10.1109/ISRE.1993.324825): safety-related errors arise mostly from requirements/interface incompleteness, not coding.
+- **Zowghi, D. & Gervasi, V., "On the interplay between consistency, completeness, and correctness in requirements evolution," IST 45(14), 2003, pp. 993–1009, DOI 10.1016/S0950-5849(03)00100-9** (read in full): **internal** vs **external** completeness (after Cordes & Carver 1989; Boehm 1984 secondary); "it is impossible to define and measure absolute completeness… The notion of completeness is essentially related and tied to the purpose and goal of a system." Formally, S ∪ D ⊨ R assesses S's completeness w.r.t. R "but not the completeness… of R in isolation."
+- **Firesmith, D., "Are Your Requirements Complete?", _Journal of Object Technology_ 4(1), 2005, pp. 27–43** (verified): completeness disaggregated over seven objects; missing-element checklists per requirement type, including missing **exceptional "rainy day" paths** for functional requirements.
+
+**Stopping rules / saturation:**
+
+- The direct empirical answer to "when do interviewers stop": **Pitts, M.G. & Browne, G.J., "Stopping Behavior of Systems Analysts During Information Requirements Elicitation," _JMIS_ 21(1), 2004, pp. 203–226, DOI 10.1080/07421222.2004.11045795**; precursors AMCIS 1998 (paper 265, read in full) and **Browne & Pitts, _OBHDP_ 95(2), 2004, pp. 208–224**. Four cognitive stopping rules (after Nickles, Curley & Benson 1995): **magnitude threshold, difference threshold** ("stop… when he judges that he is no longer learning anything new" — saturation by another name), **mental list, representational stability**. Finding: "cognitive limitations of analysts result in flawed application… producing **premature termination**"; 54 professional analysts elicited only **57% of available requirement categories and 27% of available quality points** before stopping; procedural prompts help (**Pitts & Browne, ISJ 17(1), 2007, pp. 89–110, DOI 10.1111/j.1365-2575.2006.00240.x**).
+- **Saturation is not used as an elicitation stopping rule in RE.** Origin: Glaser & Strauss 1967 (via Saunders et al., _Quality & Quantity_ 52(4), 2018 — secondary); **Guest, Bunce & Johnson, "How Many Interviews Are Enough? An Experiment with Data Saturation and Variability," _Field Methods_ 18(1), 2006, pp. 59–82, DOI 10.1177/1525822X05279903** — 70% of 114 themes in the first 6 interviews, 92% within 12 (numbers verified via Guest, Namey & Chen, PLOS ONE 2020, which also gives the only parameterised rule: base 4 + run 2, ≤5% new-information threshold). Full-text searches find **zero** RE papers proposing saturation as a project-level elicitation stopping criterion; capture-recapture (Petersson et al., JSS 72(2), 2004, pp. 249–264) is only ever applied to defects in an existing artifact — no one estimates never-elicited requirements. Sutcliffe & Sawyer, "Requirements elicitation: Towards the unknown unknowns," RE'13, pp. 92–104, DOI 10.1109/RE.2013.6636709 names the problem and leaves it open. Nielsen & Landauer's Found(i)=N(1−(1−λ)^i) model (INTERCHI'93, pp. 206–213; λ≈0.31; benefit/cost peak at 3.2 test users) has **no RE analogue**. Interestingly, ReqElicitGym (below) found effective elicitation questions are **back-loaded** in dialogues — the opposite of a decay curve.
+
+**Goal-oriented RE as completeness driver:**
+
+- **Yue 1987** (IWSSD-4) originated the criterion; **van Lamsweerde, "Goal-Oriented Requirements Engineering: A Guided Tour," RE'01, pp. 249–263, DOI 10.1109/ISRE.2001.948567** (read in full): "Goals provide a precise criterion for **sufficient completeness** of a requirements specification; the specification is complete with respect to a set of goals if all the goals can be proved to be achieved from the specification and the properties known about the domain." **R, As, D ⊨ g** for each goal g. Elicitation heuristics: "keep asking **HOW** questions" to refine, "**WHY** questions" to abstract — with the mechanism that a newly surfaced parent goal makes _missing sibling_ subgoals discoverable. Formal AND-refinement completeness (entailment + minimality + consistency + non-triviality) is from **Darimont & van Lamsweerde, FSE-4, 1996, pp. 179–190, DOI 10.1145/239098.239131**: "intuitive refinements made 'by hand' tend to be incomplete. Incomplete goal refinements result in incomplete requirements."
+- **van Lamsweerde & Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering," IEEE TSE 26(10), 2000, pp. 978–1005, DOI 10.1109/32.879820** (read in full) — the formal counterpart of "asking about exceptions": obstacle O obstructs G iff {O, Dom} ⊨ ¬G and {O, Dom} ⊭ false; a set of obstacles is **domain-complete** iff **{¬O1,…,¬On, Dom} ⊨ G** — "completeness is a notion relative to what is known about the domain" (the aquaplaning example: whether the obstacle set is complete depends on whether the domain theory knows wheels can aquaplane). The **completion construction** O\* = ◊(¬GC ∧ ¬OC1 ∧ … ∧ ¬OCk) literally manufactures the exception you haven't thought of. Identification: regression, proved obstruction patterns, and HAZOP-like heuristic checklists (InfoUnavailable, WrongBelief → InfoOutdated/InstanceConfusion/UnitConfusion…). Resolution taxonomy: elimination (goal substitution, agent substitution, obstacle prevention, goal deidealization, domain transformation), reduction, tolerance (goal restoration, mitigation, do-nothing). "Obstacle identification should be exhaustive for Safety or Security goals… cost-benefit analysis needs to be carried out to decide when the obstacle identification process should terminate." Later: **Alrajeh, Kramer, van Lamsweerde, Russo & Uchitel, "Generating Obstacle Conditions for Requirements Completeness," ICSE 2012, pp. 705–715** — automated generation found all the manually derived LAS obstacles **plus obstacles the authors' own manual formal analysis had missed**.
+- **Yu, E., "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering," RE'97, pp. 226–235, DOI 10.1109/ISRE.1997.566873** (read in full) — i*explicitly **declines** the completeness framing for early RE: "the model of internal intentionality is not assumed to be complete… There is no definitive 'top'… nor 'bottom'… It is the stakeholders' decision as to when the issues have been adequately explored." What i* contributes to questioning is the **why-question battery** ("Why is it necessary to schedule meetings ahead of time?… And whose interests does it serve?") and vulnerability analysis over dependencies.
+- Evidence that goal models improve completeness is thin: Horkoff et al., REJ 24(2), 2019, pp. 133–160 (mapping of 246 top-cited GORE papers: only ~7% controlled experiments); Mavin et al., "Does Goal-Oriented Requirements Engineering Achieve Its Goal?", RE'17, pp. 174–183, DOI 10.1109/RE.2017.40 (industrial use "inconsistent, informal, rarely… formal").
+- **Convergent answer:** no source claims you can _know_ elicitation is complete. Every serious treatment substitutes a relative criterion plus a **procedure that names its own gaps** — the failed refinement proof, the domain-consistent O\*, the WHY question, the state with no timeout transition, Gause & Weinberg's "courage to end it all."
+
+## 6. Elicitation by AI/LLM agents (2023–2026)
+
+- **Korn, A., Gorsch, S., Vogelsang, A., "LLMREI: Automating Requirements Elicitation Interviews with LLMs," RE'25, pp. 19–30, DOI 10.1109/RE63999.2025.00013 (arXiv:2507.02564)** (read in full). GPT-4o chatbot, 33 simulated stakeholder interviews, evaluated **directly against the Bano et al. mistake questionnaire** (Question Formulation / Question Omission / Order of Interview / Communication Skills / Customer Interaction; 2 of the human categories dropped as inapplicable). Results: LLMREI made a similar number of mistakes to human interviewers; raters even scored its communication skills _better_; long "least-to-most" prompt embedding Ferrari et al. guidelines beat a 3-sentence zero-shot prompt on mistake avoidance (64.2% vs 59.1% disagree-mistake-present); elicited up to 60.9% of ground-truth requirements fully + 12.8% partially (73.7% total; ground truth = 12- and 8-requirement scenarios); ~50% of questions context-dependent. **What failed:** fine-tuning GPT-3.5 on 50 transcripts of Ferrari et al.'s student interviews failed entirely ("incoherent responses," lost focus — attributed to poor quality of novice-interviewer training data); hallucination (bot invented a project price estimate); boundary-crossing (asked for the user's email); and the bot **ended interviews too readily** when users signaled impatience, "missed opportunities to gather crucial information" — i.e., no stopping discipline.
+- **Shen, Singhal & Breaux, RE'25 (arXiv:2507.02858)** (read in full; details in §2 above). Minimally guided GPT-4o follow-up questions were statistically indistinguishable from human interviewers'; **mistake-guided** generation (prompting with the 14 criteria) significantly _beat_ human questions (68% preference; p < 1e-5 on relevancy). GPT-4o agreed with a human analyst on mistake classification 81% (340/420). Also derived a seven-type follow-up question typology from open coding of 146 real follow-ups: **topic change (71), answer probing (27), confirmation (13), question probing (13), alternative-seeking (11), preference-seeking (6), clarification (5)** — with topic-change questions needing no prior context and probing questions needing ≥2 turns.
+- **Jin, D., Jin, Z., et al., "ReqElicitGym: An Evaluation Environment for Interview Competence in Conversational Requirements Elicitation," arXiv:2602.18306 (2026; under submission to TOSEM)** (read in full). 101 website scenarios, LLM oracle user + evaluator (κ = 0.72 vs experts); metrics **IRE** (implicit-requirements elicitation ratio), ESR, **TKQR** (nDCG-style, rewards early key questions). Findings: best LLM reaches **IRE 0.32**; models "overwhelmingly favor probing over clarification and **often lack effective stopping criteria**" (GPT-5.2 exhausts the 20-turn budget); effective questions emerge late; style-related requirements consistently missed.
+- **Jin, D., et al., "From Chat to Interview: Agentic Requirements Elicitation with an Experience Ontology," arXiv:2605.05828 (RE 2026)** (read in full). OntoAgent: a three-level domain ontology (aspects → dimensions → clarification slots) induced from requirements corpora steers slot selection each turn (ParseUser/ScoreOnto/ReRankOnto/GatePrune); +33% IRE, +21% TKQR over free-form LLM chat, whose failure mode is "omission of implicit requirements and redundant questions."
+- **Görer, B. & Aydemir, F.B., "Generating Requirements Elicitation Interview Scripts with Large Language Models," REW 2023, pp. 44–51, DOI 10.1109/REW57809.2023.00015**, and **"GPT-Powered Elicitation Interview Script Generator for Requirements Engineering Training," arXiv:2406.11439 (2024)** (read in full). Prompt-chained GPT script generation for training; expert evaluation found scripts coherent but **lacking depth** ("briefly touch on all these topics but lack depth," NFRs especially), and — assessed against the Donati/Bano mistake list — the generated scripts themselves exhibited **influencing the stakeholder, unnatural dialogue style, and ignoring other stakeholders** ("the interviewer does not ask for additional stakeholders in any of the scripts").
+- **Ataei, M., et al., "Elicitron: A Large Language Model Agent-Based Simulation Framework for Design Requirements Elicitation," _J. Computing and Information Science in Engineering_ 25(2), 2025, 021012 (arXiv:2404.16045)**: LLM agents _simulate users_ (serial generation gave best persona coverage) and are interviewed by an LLM to surface latent needs — automation of the stakeholder side rather than the interviewer side.
+- **Singhal, A., Carvalho, P., Breaux, T., "AI-assisted Script Management for Requirements Elicitation Interviews," arXiv:2608.01640 (2026)** (read in full). Full workflow: script generation from business goals under **9 literature-derived design rules** (goal alignment; introduction + rapport; **context-free opener** — Gause & Weinberg's term operationalized as a rubric rule; topic ordering; length; open-ended; one question per turn; clarity ≤ 30 words; concluding summary) + live topic-coverage tracking + on-demand follow-up generation. Untrained AI-assisted interviewers vs trained unassisted: AI scripts scored 92.8 vs 74.8/100; AI-assisted interviews covered **fewer topics** (9.6 vs 14.5) but more scripted questions (86% vs 69%) and 3× more follow-ups per topic — depth traded against breadth.
+- Adjacent verified: Zowghi/Bano co-edited context; **Palomares et al., "The state-of-practice in requirements elicitation: an extended interview study at 12 companies," REJ 26(2), 2021, pp. 273–299**; Debnath & Spoletini's AnnoteREI (RE'22, pp. 255–256); **Ferrari, Spoletini, Debnath, "How do requirements evolve during elicitation?…" REJ 27(4), 2022, pp. 489–519, DOI 10.1007/s00766-022-00383-7** — only 30–38% of post-interview requirements trace fully to customer's initial ideas; requirements are "**co-created** through interviews," which reframes both the mistake and completeness literatures.
+
+**Summary of what has been tried and failed in LLM interviewing:** fine-tuning on novice transcripts (failed outright); free-form chat (redundant, misses implicit requirements — IRE < 0.5 for all models); no model has a stopping criterion (either quits too eagerly on user impatience or exhausts the turn budget); style/NFR requirements systematically missed; hallucination and scope-creep remain live risks. What works: mistake-taxonomy-guided prompting (the Bano/Ferrari taxonomy has become the de facto evaluation instrument for machine interviewers), and structure injection (ontologies, scripts, topic trackers).
+
+---
+
+**Unverified items (flagged):** Donati 2017's original 9-mistake list verbatim; Ferrari 2016 RE'16 cue-category definitions verbatim (paywalled — category names verified); Boehm 1984 wording (secondary via Zowghi & Gervasi); Hickey & Davis JMIS 2004 text (paywalled; model verified from HICSS'03); Beyer & Holtzblatt 1998 1st-edition principle wording (2014/1995 wording fully verified instead); Leffingwell & Widrig "Undiscovered Ruins" quote (search-snippet only); Jackson ICSE'95 body text; Guest et al. 2006 full text (numbers verified via the authors' 2020 OA paper).
+
+Downloaded full texts are in `/private/tmp/claude-501/-Users-lunelson-Code-hashintel-brunch-lite/cee4cf43-9867-4a93-8b99-53e180e4a409/scratchpad/` (bano2019.pdf/.txt, fig3-12.png, nsf10610.txt, sapeer.txt, amb2016.txt, zaremba.txt, refs28.txt, pb1998.txt, 2507.02564/2507.02858/2605.05828/2608.01640/2602.18306/2406.11439/2404.16045 .txt, ieee830.txt, 29148-2011.txt, 29148-2018.txt, zave.txt, jaffe1991.txt, zowghi.txt, report_contextual.txt).
+
+Sources: [Bano et al. REJ 2019](https://link.springer.com/article/10.1007/s00766-019-00313-0) ([OA manuscript](https://par.nsf.gov/servlets/purl/10105611)) · [Bano et al. RE'18](https://par.nsf.gov/servlets/purl/10105610) · [Donati et al. REFSQ'17](https://link.springer.com/chapter/10.1007/978-3-319-54045-0_11) · [SaPeer REJ 2020](https://link.springer.com/article/10.1007/s00766-020-00334-0) ([OA](http://openportal.isti.cnr.it/data/2020/437163/2020_%20437163.published.pdf)) · [Ferrari et al. REJ 2016](https://link.springer.com/article/10.1007/s00766-016-0249-3) ([OA postprint](https://openportal.isti.cnr.it/data/2016/353983/2016_353983.postprint.pdf)) · [Ambiguity Cues RE'16](https://ieeexplore.ieee.org/document/7765511/) · [Interview Review REFSQ'18](https://link.springer.com/chapter/10.1007/978-3-319-77243-1_7) · [Zaremba & Liaskos RE'21](http://www.yorku.ca/liaskos/Papers/RE2021/RE2021.pdf) · [Zowghi & Coulin 2005](https://web.eecs.umich.edu/~weimerw/2022-481W/readings/requirements.pdf) · [Hickey & Davis RE'03](https://doi.org/10.1109/ICRE.2003.1232748) · [Goguen & Linde RE'93](https://cseweb.ucsd.edu/~goguen/ps/rqelit.pdf) · [Gause & Weinberg Ch. 6 scan](https://assets.ctfassets.net/bncv3c2gt878/4mvcQWNWhWQ0sgiKWCakEU/cce06a8bdc4d3e274ca47eb72d60fbe0/Gause_-_Context-Free_Questions.pdf) · [Apprenticing with the Customer](https://dl.acm.org/doi/10.1145/203356.203365) · [Zave & Jackson 1997](https://www.fceia.unr.edu.ar/asist/zave00.pdf) · [Leveson 2000](http://sunnyday.mit.edu/papers/completeness.pdf) · [Jaffe et al. 1991](https://escholarship.org/uc/item/30n0q0zm) · [van Lamsweerde RE'01](https://webperso.info.ucl.ac.be/~avl/files/RE01.pdf) · [van Lamsweerde & Letier TSE 2000](https://doi.org/10.1109/32.879820) · [Yu RE'97](https://www.cs.toronto.edu/pub/eric/RE97.pdf) · [Pitts & Browne AMCIS'98](https://aisel.aisnet.org/amcis1998/265/) · [Pitts & Browne JMIS 2004](https://doi.org/10.1080/07421222.2004.11045795) · [LLMREI](https://arxiv.org/abs/2507.02564) · [Follow-up Question Generation](https://arxiv.org/abs/2507.02858) ([artifact](https://github.com/anmolsinghal98/Requirements-Elicitation-Follow-Up-Question-Generation)) · [ReqElicitGym](https://arxiv.org/abs/2602.18306) · [OntoAgent](https://arxiv.org/abs/2605.05828) · [Görer & Aydemir](https://arxiv.org/abs/2406.11439) · [Elicitron](https://arxiv.org/abs/2404.16045) · [AI-assisted Script Management](https://arxiv.org/abs/2608.01640)
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/voice-feasibility.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/voice-feasibility.md
new file mode 100644
index 00000000000..ddf3f7cfd9a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/research/voice-feasibility.md
@@ -0,0 +1,706 @@
+# Voice-first elicitation: feasibility against the elicitation kernel
+
+Resolves FE-1359. Written 2026-08-11 against
+[`spec.md`](../../../spec.md) (draft assembled 2026-08-10, reviewed twice since),
+the inbox note [voice-implementation-recommendation-pplx](../../../reference/voice-implementation-recommendation-pplx.md),
+the three prototype branches (`prototype/10-flue-roundtrip`, `prototype/11-capture-sweep`,
+`prototype/13-sweep-seam`), and web verification of the provider landscape (sources at the end).
+
+The spec mentions voice, audio, speech, and modality **zero times**. This is a genuinely new axis,
+not an under-specified one.
+
+## Executive summary
+
+1. Verdict: **bolt-on with constraints** — but the bolt-on attaches at the **ui shell**, not as a
+   provider-owned adapter in front of the harness, which is where the inbox note points it.
+2. The inbox note's shape is disqualified on its own documented terms: Speech Engine returns **text
+   only** (so no affordances reach the client), hands your server a flat `{role, content}` history
+   (so §9.4 provenance cannot survive), exposes **no partial transcripts** (so the live-extraction
+   beat is unbuildable), and has **no push-to-talk** (so the safe fallback is unavailable). OpenAI and
+   Google don't admit an external LLM at all; buy standalone streaming ASR and TTS instead.
+3. Voice-in over our existing Flue transport is additive: string-only inbound (§7.7) and the
+   markdown floor (§7.2) already make the kernel modality-agnostic on the input side.
+4. Three kernel mechanisms turn out to fit voice by accident: §5.1 already licenses tap-less uis to
+   yield inferred-only absences, §8.3's content-keyed sweep idempotence already survives a
+   mid-flight abort, and §7.3's one-live-affordance rule is _strengthened_ by a serial audio channel.
+5. The deepest collision is not barge-in — it is that voice makes **endpointing** a ui-shell
+   responsibility, and the ui is chartered to own no elicitation semantics (§4). Push-to-talk
+   returns that judgment to the user and dissolves the collision; open-mic does not.
+6. "The agent interrupts to clarify" has **no seam at all**: capability 7 is an end-of-agent-turn
+   hook (§8.1, §10), and nothing in the ten capabilities evaluates anything _during_ the user's turn.
+7. Live entity extraction is a second cheap-model pass that fits §11.4's "noticed, not yet asked"
+   scratchpad, but **not** capability 6 during the user's turn — no dispatch is in flight to host it.
+8. Biggest under-rated risk is evidential, not technical: ASR mangles exactly the proper nouns that
+   get captured. This project's own meeting transcript renders "Petri net"/"Petrinaut" as
+   **"PetriKnot" 35 times and correctly zero times**.
+
+---
+
+## (a) Collision analysis
+
+Severity is scored for the September demo, not for the product's long run.
+
+| #   | Collision                                                                           | Severity                               | Short resolution                                                    |
+| --- | ----------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------- |
+| C1  | Turn-loop latency vs. the suspend/fresh-dispatch cycle                              | **High**                               | Stream first sentence to TTS; keep continuation turns silent        |
+| C2  | Barge-in vs. dispatch atomicity                                                     | Medium                                 | §8.3 idempotence already covers it; verify Flue client-abort        |
+| C3  | Endpointing becomes a ui responsibility the charter withholds                       | **High** (conceptual)                  | Name a _turn shell_ with a one-way valve; push-to-talk collapses it |
+| C4  | Agent-initiated interruption has no seam                                            | **High** (for the aspiration)          | Implement as forced endpointing in the turn shell, labeled honestly |
+| C5  | Structured affordances have no audio form; the markdown floor is not a speech floor | Medium                                 | Add a speech rendition; keep a screen so taps survive               |
+| C6  | One-live-affordance rule under audio                                                | **None** — it survives and strengthens | No action                                                           |
+| C7  | ASR-mediated evidence vs. "only the true user's side is evidence" (§9.4)            | **High**                               | Audio pointer on spans, lexicon biasing, visible transcript         |
+| C8  | TTS must inherit the `purpose`/`display` filter                                     | Low                                    | New explicit clause in the ui contract                              |
+| C9  | Provider-owned conversation vs. single-authority durability (§9.1, §9.6)            | **High**                               | Buy audio primitives, not the conversation                          |
+
+### C1 — Turn-loop latency vs. the suspend/fresh-dispatch cycle (High)
+
+The kernel spends more than one model turn per user-visible question. §7.4 fixes the ask cycle as
+`terminate: true` + pending-affordance slot + **the answer arriving as a fresh dispatch**. §8.1 then
+adds a would-stop settlement check that "steers a settlement-check signal into a **same-response
+continuation turn**." Ticket 10 measured a third turn — the wake wart, one wasted model call per ask
+— which §7.4 removes by keeping the pending affordance out of the instructions, but the structural
+point stands: a single spoken question can sit behind two or three sequential model invocations plus
+a durable-submission round trip.
+
+In text, a three-second gap between "Send" and the next question is invisible. In voice it is more
+than the entire budget. LiveKit's published thresholds: **"under 500ms feels like talking to a
+person," "under 1 second feels natural," "over 2 seconds feels broken."** Their component breakdown
+for a well-tuned streaming cascade totals roughly 300–600ms — VAD 10–50ms, streaming STT partial
+under 100ms, **LLM time-to-first-token 300–800ms (the slowest stage by far)**, TTS first chunk
+100–200ms — against 1000–2000ms+ for a naive non-streaming cascade.
+
+Read our turn structure against that breakdown and the problem states itself: **the budget allows
+approximately one LLM time-to-first-token, and the kernel spends one to three sequential model
+invocations plus a durable-submission round trip.** The audio stack is not the risk — ElevenLabs
+quotes Scribe v2 Realtime at ~150ms, which is noise at this scale. The risk is the kernel's own turn
+economy, and it is a design cost we chose for good reasons (harness-owned suspension, agent-judged
+settlement) that voice now prices.
+
+Worth noting too that cascaded-vs-native is not the axis that decides this. Native speech-to-speech
+is cited at ~200–300ms in principle, but measured end-to-end time-to-first-audio across 2026 vendors
+"clusters between 0.78s (xAI Grok Voice Agent) and 2.98s (Gemini 3.1 Flash Live)" — a slow native
+model loses to a good cascade. Vendor and tuning dominate architecture; one production example
+(Vapi + AssemblyAI) reports ~465ms end-to-end after tuning.
+
+Resolutions, in order of leverage:
+
+- **Speak the first sentence, not the finished turn.** Flue streams text deltas; the TTS sink should
+  begin on the first sentence boundary. This is the single largest win and it is cheap.
+- **Never let the settlement check precede the speech.** §8.1's continuation turn is silent work; if
+  the ui speaks only text parts and the continuation emits diagnostics (§7.7), the ordering is
+  already harmless — but it must be verified rather than assumed, because the seam "fires on
+  suspensions too" (§8.1).
+- **Keep asks short.** A pack-level style constraint, not a mechanism change.
+- **Consider a filler.** This is the one place the managed path has something we would have to build:
+  ElevenAgents exposes `soft_timeout_config` (0.5–8.0s, disabled by default) which "fills dead air via
+  a filler message while your LLM is slow" rather than failing the turn. A hand-rolled equivalent —
+  speaking an acknowledgement token while the sweep-and-settle turns run — is a few hours' work and
+  buys back most of the perceptual gap. Worth doing at T1.
+
+### C2 — Barge-in vs. dispatch atomicity (Medium)
+
+Barge-in has three distinct cases and only one is interesting.
+
+1. **User speaks over TTS playback of an already-suspended turn.** Harmless and the common case: the
+   ask already terminated the turn, so playback is a ui artifact lagging behind a finished dispatch.
+   The reply is a fresh dispatch exactly as §7.4 specifies. Nothing in the kernel notices.
+2. **User speaks while a dispatch is mid-generation.** The harness has a partially emitted turn.
+   Ticket 01 records Flue's durable-submission contract as "every accepted submission reaches
+   exactly one durable terminal outcome — completed, failed, or **aborted**," with a retry budget and
+   a wall-clock timeout "enforced preemptively via the attempt's abort signal." So `aborted` is a
+   first-class terminal state; what is **unverified** is whether a client can initiate that abort,
+   and what a second `dispatch` arriving during one in flight does. Both are cheap prototype
+   questions and both are on the critical path.
+3. **User speaks while a tool call is in flight** — the genuinely scary one, because that tool may be
+   `sweep_range`. Here the kernel is already safe for an unrelated reason: §8.3 makes mechanical
+   sweep idempotence "**load-bearing, not optional**, under at-least-once tool re-execution (Flue
+   fact, ticket 13)," with content-keyed capture identity so "re-sweeping a range never
+   double-captures **and can repair omissions**." An aborted-and-retried sweep is precisely the
+   at-least-once case the spec already hardened against. Whole-sweep-atomic application (§9.2, §9.6)
+   closes the other half.
+
+The residual risk is therefore not corruption but _conversational_ incoherence: an aborted turn
+leaves a truncated assistant entry in the durable log that the model will later re-read and that a
+capture could, in principle, be anchored near. §9.4 keeps it out of evidence (only true-user entries
+are citable), so this is cosmetic.
+
+### C3 — Endpointing becomes a ui responsibility the charter withholds (High, conceptual)
+
+This is the deepest collision and it is easy to miss because it looks like plumbing.
+
+`CONTEXT.md` defines the ui as "the interface shell: whatever affords user interaction — rendering,
+input, reply transport. **Not bound to GUI or TUI; a chat channel qualifies.**" §4 sharpens it: "the
+ui renders parts and transports replies; **it owns no elicitation semantics**." Three jobs, no
+judgment.
+
+In a text ui the Send button is the endpointer, and the _user_ owns it — deciding that an utterance
+is finished is a human act the interface merely records. In voice that judgment moves into software.
+Whoever decides "this pause means the answer is over" is making a conversationally consequential
+call: cut too early and you truncate a domain expert mid-thought and capture half a fact; cut too
+late and the agent feels dead. That is elicitation semantics living in the ui.
+
+2026 practitioner consensus is emphatic that this, not raw latency, is the hard part — and it is also
+where the latency actually goes. Two quantifications worth carrying into the design conversation: "a
+silence timeout set to 800ms adds nearly a full second to every single response before the pipeline
+even starts," and Vapi's stock endpointing defaults "can add 1.5+ seconds to your response time —
+completely negating all your other optimizations." Set against C1's 500ms/1s/2s thresholds, the
+endpointing policy is a larger lever than any model choice. The tradeoff is irreducible and stated
+plainly in the literature: "a lower threshold or a shorter horizon makes the agent commit to
+end-of-turn sooner, which is faster but produces more false interruptions." The industry's answer is
+learned turn-detection rather than energy thresholds — Pipecat's SmartTurnAnalyzer, LiveKit's
+TurnDetector, semantic VAD that re-listens and issues a resume when the interrupting audio contains no
+decipherable words.
+
+Two consequences for us. Our interview domain is the _worst case_ for acoustic endpointing: a domain
+expert describing a plant thinks in long sentences with mid-thought pauses, exactly the signal a
+silence threshold misreads. And ElevenLabs' own answer here — `turn_eagerness: patient` alongside
+`turn_timeout` (1–30s) — is real prior art worth copying conceptually even if we do not buy the
+platform.
+
+Resolution: **name the responsibility instead of smuggling it.** Add a fifth shell to the
+architecture picture — a **turn shell** sitting between ui and substrate — whose whole job is
+converting a continuous audio stream into discrete dispatches, and whose contract is a one-way
+valve:
+
+> The turn shell may synthesize user entries and abort dispatches. It may never write to the capture
+> store, never interpret an answer, and never be citable as evidence.
+
+Note what this buys: **push-to-talk is not a fallback, it is the conceptually clean mode.** It
+returns endpointing to the user, shrinks the turn shell to a transcription pipe, and leaves §4's
+three-job ui charter intact. The inbox note recommends push-to-talk defensively ("it protects the
+demo from VAD ambiguity"); the stronger argument is architectural.
+
+### C4 — Agent-initiated interruption has no seam (High for the aspiration)
+
+The demo aspires to "the agent interrupts to clarify" during an audio description. Check the
+capability list (§10) for a seam that could host that decision: capability 7 is "subscribe to the
+**would-stop** lifecycle seam, with same-response signal steering" — an end-of-agent-turn hook.
+Capabilities 5 and 9 are suspend-for-reply and signal injection. **Nothing in the ten capabilities
+evaluates anything during the user's turn**, and by §7.4's design the turn is _suspended_ while the
+user talks — there is no agent running to notice anything.
+
+So agent-initiated interruption is either an eleventh capability (a during-user-turn evaluation
+seam, which would be the first genuinely new mechanism voice demands) or it lives outside the kernel.
+
+Resolution, and it is a good one: implement interruption as **forced endpointing in the turn shell**.
+The same monitor loop that drives live extraction (see (b)) watches the partial transcript and, on
+its own heuristic or a cheap-model judgment, decides to close the user's turn early and dispatch the
+transcript-so-far. The kernel then sees a perfectly ordinary — merely shorter — user entry, and every
+downstream invariant is untouched. What the audience experiences as the agent interrupting is
+mechanically the edge deciding the user's turn is over.
+
+Two honesty obligations. First, this is not agent judgment in the kernel's sense, and the demo
+narrative should not imply the interviewing agent is exercising interviewing skill mid-monologue
+unless the monitor is actually running a model call with the pack's guidance in it. Second, false
+interruption is the named primary failure mode of this feature class in the 2026 literature — acoustic
+VAD misfiring on mid-sentence pauses and throat-clears, with semantic VAD and learned turn-detectors
+as the current mitigation — and unlike latency it reads as _rudeness_: one badly-timed interrupt in
+front of an audience costs more than five seconds of silence would. Building agent-initiated
+interruption means deliberately adding a false-positive channel to the one interaction where the
+system's credibility is the product.
+
+Note also what the managed voice platforms do _not_ give you here. Their interruption support is
+uniformly user-interrupts-agent — Speech Engine's `AbortSignal`, ElevenAgents' `agent_response_correction`
+event for a "truncated response after interruption," Gemini Live's "users can interrupt the model at
+any time." Agent-interrupts-user is a different feature and none of the fetched docs offer it. This is
+the one demo aspiration where no vendor is carrying any of the weight.
+
+### C5 — No audio rendering for structured affordances; the markdown floor is not a speech floor (Medium)
+
+Two separable problems.
+
+**The epistemic one is already resolved in the spec, and the resolution is a real capability loss.**
+§5.1 makes tap-ness a transport fact: the harness defines "a **reserved reply encoding** — a
+sentinel-format string the ui emits for structured affordance taps," and only a reply parsing as that
+encoding while its affordance is pending counts as transport-explicit; "every other reply is
+conversational, and absences read from it carry `epistemic_status: inferred`." It then says the quiet
+part out loud: "Structured taps are an **optional ui capability, not a requirement** … A ui that only
+affords the markdown floor never produces the encoding and honestly yields inferred-only absences."
+
+Voice is exactly that ui. **A voice-only elicitation can never produce an `explicit` absence.**
+Every "not applicable" spoken aloud is `inferred`, forever, by design. That is honest and
+pre-authorized — and it lands squarely on the absence strip, which is one of the demo's showpieces.
+The fix is not a spec change but a product decision: **keep a screen.** In a voice+screen hybrid the
+affordance still renders, the taps still work, the encoding still fires, and `explicit` survives.
+The prototype's `send(choice)` path in
+`prototypes/sweep-seam/src/ui/chat.tsx` is already the whole mechanism.
+
+**The rendering one is a small genuine gap.** §7.2's floor is a _markdown_ floor, and markdown reads
+aloud badly — bullets, backticks, tables, and code spans all become noise. Worse, questionnaire
+chaining is defined as "**one affordance with multiple steps**, the payload carries all N questions,
+**the ui walks them locally** … zero intermediate model turns." Walking N steps serially in audio
+means the turn shell must speak Q1, endpoint, speak Q2 — a mini-interviewer in the ui, which is the
+§4 breach again.
+
+Resolutions: add a **speech floor** to the affordance envelope — a plain-prose or SSML rendition
+alongside the markdown floor. It is a small, cheap amendment (a concept-schema-axis change, §12.6,
+"cheap while the ecosystem is workspace-internal"). And in voice mode, collapse questionnaires to
+their floor — speak the set, take prose back, let the model interpret at sweep time — or disable the
+form. Do not let the turn shell walk steps.
+
+### C6 — One live affordance under audio: survives, and strengthens (None)
+
+Worth stating as a positive finding. §7.3 derives the one-live-affordance rule from transport truth
+(the data channel is a last-write-wins "current-affordance surface, not a log") and enforces it as
+mechanism: "the ask tool **rejects a second interactive affordance in the same batch**." Audio is
+strictly serial — only one question can be in the air — so the audio channel wants exactly the same
+rule for independent reasons.
+
+Reply binding also survives. §7.4 makes binding harness-mechanical precisely because at most one
+affordance is pending, "no echo token, and no reliance on the model remembering an id." A spoken
+reply that wanders — answering an earlier question, or volunteering three facts and ignoring the one
+asked — gets bound to the pending affordance anyway, and that is fine: binding is a hint, not an
+interpretation. §7.4 puts interpretation at sweep time "citing the quoted reply text," and §7.5
+already has `redirected` for "cancellation-by-topic-change." Voice produces more wandering replies
+than text; the machinery for that was built already.
+
+### C7 — ASR-mediated evidence (High)
+
+The kernel's evidentiary claim is unusually strong. §5 makes each evidence span "a **quoted excerpt
+plus a pointer**," with the excerpt "primary at proposal time and … the **model-facing citation
+currency**." §8.2 has the harness resolve quotes to entries because "the model's quotes were
+flawless and its sequence guesses never converged." §9.4 is titled "Provenance: only the true user's
+side is evidence."
+
+Under voice, the durable user entry is not the user's words — it is a machine transcription of them.
+Every mechanism keeps working (both model and harness see the same transcript text, so quote
+resolution gets _easier_, not harder), while the invariant's plain-English meaning quietly becomes
+false. And the failure is not uniform noise: ASR breaks proper nouns and technical vocabulary, which
+is precisely the population of things worth capturing.
+
+The local evidence is stark. This project's own expert-meeting transcript
+(`docs/reference/yannis-dora-lu-transcript-2026-08-11.md`), an ASR product's output on exactly the
+conversation type the demo is imitating, renders the central domain noun as **"PetriKnot" 35 times
+and "Petri net"/"Petrinaut" zero times**, and "STCPN" 14 times where the project's term is SDCPN —
+a misreading that propagated into the human-written findings note. A demo that captured from that
+transcript would produce evidence-anchored, correctly-swept, perfectly-idempotent captures about a
+formalism that does not exist.
+
+Resolutions, all cheap, and the first two are worth doing even for a demo:
+
+- **Show the transcript and let the user correct it.** Already the demo's own aspiration ("live
+  transcription runs"), so it costs nothing extra and it converts the risk into a feature.
+- **Bias the ASR with the plugin's vocabulary.** This is a solved, cheap, well-supported feature and
+  it is the highest-value single mitigation. §13.1 already gives `plugin-gherkin` "a pack-declared
+  **step-lexicon**"; a target's lexicon _is_ the biasing list. This introduces a new read-only
+  plugin → turn-shell flow, admissible on the same footing as form tags (the ui already keys rendering
+  on plugin form tags, §7.2) — it carries no elicitation semantics. Options, with the caveat that all
+  vendors describe biasing as hints: **Deepgram Nova-3** keyterm prompting (100 terms, no retraining,
+  ~150ms first partial, mature browser SDKs); **AssemblyAI Universal-Streaming** keyterms (100 terms,
+  $0.15/hr, the cheapest verified rate, self-reported — so treat sceptically — as 21% more accurate
+  than Nova-3 on domain terms); **ElevenLabs Scribe v2 Realtime**, which notably biases toward terms
+  only when actually spoken rather than force-inserting them, unlike Whisper-style prompting that
+  "often insert[s] prompted terms where they don't belong… especially on ambiguous audio" — a real
+  distinction, since a forced insertion is _worse_ than a misrecognition when the output becomes
+  evidence; and **OpenAI**'s `keywords` on a transcription session, documented for "product names,
+  acronyms, and other literal terms," with "keywords are hints, not required output."
+  **Unresolved:** two passes over the ElevenLabs docs returned conflicting realtime keyterm caps —
+  50 terms × 20 chars on the speech-to-text capability page versus 100 terms × 50 chars elsewhere.
+  The cap matters for how aggressively a pack lexicon must be pruned, so confirm it before designing
+  that pruning. Either way a cap exists and a full domain lexicon will exceed it.
+- **Mark voice-derived captures**, and require on-screen confirmation before a voice-derived proper
+  noun reaches `explicit`.
+- **Longer-term: add an audio pointer to the evidence span.** Keep the audio, point at it by
+  timestamp, and the excerpt becomes navigable back to the actual utterance. This is the honest fix
+  and it is a §12.6 concept-schema-axis change — cheap now, expensive later.
+
+### C8 — TTS must inherit the display filter (Low)
+
+§7.7: messages carry `purpose` and `display`, "**the ui must filter on them** (injected signals
+arrive `display: 'diagnostic'`)." The speech layer needs the same clause, stated separately, because
+the failure mode is loud: §8.1's settlement nudge "is itself a session entry," §9.3's re-entry
+briefing is an injected state message, and the prototype ui renders tool parts and sweep JSON
+inline. A naive "speak all text" implementation reads the agent's own bookkeeping aloud.
+
+Also: §9.3 requires "a **minimal user-visible insertion notice**" with every injected state message.
+Voice needs an audible equivalent — an earcon, or a screen-only notice in the hybrid shape. Trivial,
+but it is a contract clause that currently has no audio answer.
+
+### C9 — Provider-owned conversation vs. single-authority durability (High)
+
+This collides with the _recommended architecture_ rather than with voice itself, and it is the one
+place I dissent from the inbox note.
+
+First, a naming correction the note gets wrong and that matters for anyone reading its links.
+ElevenLabs currently ships **two** relevant products, and Speech Engine is not a rename of the
+older one:
+
+- **ElevenAgents** (`/docs/eleven-agents/`) is the hosted agent platform, descendant of
+  "Conversational AI"/"Agents Platform" — confirmed by redirect, `/docs/conversational-ai/overview`
+  → `/docs/eleven-agents`. Its **Custom LLM** feature is the classic HTTP contract: "it must align
+  with one of the following OpenAI-compatible request/response structures: Chat Completions API
+  (`/v1/chat/completions`) [or] Responses API (`/v1/responses`)", replying SSE with
+  `ChatCompletionChunk` frames terminated by `data: [DONE]`.
+- **Speech Engine** (`/docs/overview/capabilities/speech-engine`) is a separate, newer, additive
+  product and is what the note actually recommends. It is **not** a POST-to-your-endpoint contract:
+  you attach a server via `elevenlabs.speechEngine.attach()` over a persistent SDK/WebSocket
+  connection, and your `onTranscript` handler receives the history and session each turn. No required
+  path or schema; not OpenAI-compatible by requirement.
+
+Either way the division of labour is the note's: the provider owns audio, turn-taking, and
+interruption detection, while "your server provides the LLM logic." Speech Engine "adds voice
+capabilities to any chat agent," the SDK "manages conversation turns, so your server only needs to
+respond to transcripts," and it cancels an in-flight LLM call "automatically via an `AbortSignal`" —
+a positive interruption signal rather than silence inference, which is genuinely nicer than what we
+would build.
+
+It is a clean pattern for a stateless chat agent. Against this kernel, its documented surface is
+disqualifying on four counts — and then, decisively, on the demo's own live-transcription aspiration.
+
+1. **The return channel is text, full stop.** The JS SDK's only outbound path is
+   `session.sendResponse()`, accepting `string | AsyncIterable<unknown>`; the docs list no mechanism
+   for structured data back to the client. But capability 4 is "emit an affordance payload" via "data
+   channel + tool output parts" (§10), and §7.3 makes durable affordance identity ride the ask tool's
+   output part. So every choice strip, absence strip, questionnaire and interpretation render needs a
+   parallel channel to the browser _anyway_ — at which point the provider transports half the
+   conversation and we transport the other half, with two orderings to reconcile.
+2. **The provider's history model cannot represent ours.** `onTranscript(transcript:
+TranscriptMessage[], signal, session)` receives the history as `{ role: "user" | "agent"; content:
+string }` on every turn. There is no room in that shape for tool parts, affordance output parts,
+   or — critically — §9.4's distinction between true-user entries and injected on-behalf-of-user
+   signals, which the kernel needs _mechanically_ ("a capture citing an injected entry is refused at
+   validation"). Meanwhile §9.1 makes the capture store plus session logs authoritative and §9.6
+   binds evidence pointers to the target-document's own archive "so evidence pointers resolve against
+   the target-document's own store, **never against whatever the substrate happens to retain**." A
+   provider-held history is a third copy, lossy in exactly the dimension the kernel's provenance
+   invariant lives in.
+3. **Our turn is not one text response.** `terminate: true` mixed batches (§7.7: "mixed batches
+   suspend correctly when the terminating result is present") and §8.1's same-response continuation
+   turn mean model work continues _after_ the user-facing answer. Both integrations are
+   turn-shaped — one `onTranscript` in, one `sendResponse` out; one `/v1/chat/completions` request,
+   one SSE stream — and neither documents a slot for further model work once the turn's text is
+   delivered.
+4. **The provider becomes the turn shell** — C3's judgment handed to a vendor, behind an extra async
+   hop. ElevenAgents does expose real controls over that judgment (`turn_timeout` 1–30s,
+   `turn_eagerness` patient/normal/eager, a `vad_score` event, `user_activity` to suppress
+   interruption during silence), which is more than nothing. But **push-to-talk / manual turn-end is
+   not documented in either product** — checked directly against the conversation-flow page — so the
+   demo-safe fallback is unavailable on this path, and their direction of travel is away from it
+   (a first-party blog describes "speculative turn-taking" reading conversational flow rather than any
+   hard threshold).
+
+And the finding that should settle it: **the agent products expose no partial transcripts.** For
+Speech Engine, "the full transcript is passed to `onTranscript` on every turn," with no
+intermediate/partial mechanism documented and `"user_transcript"` as the only transcript event; on
+ElevenAgents `user_transcript` is explicitly "finalized speech-to-text results." The demo's headline
+beat — live transcription with entities appearing as the conversation goes — is not implementable on
+the integration the note recommends. Partials exist at ElevenLabs, just one layer down, in the raw
+ASR product.
+
+The same holds for the other vendors, and it is worth stating flatly: **neither OpenAI nor Google
+supports putting your own model in a realtime voice session.** OpenAI's docs "provide no information
+about using third-party LLMs — all references assume OpenAI's models are in the loop," and
+practitioners confirm you cannot reliably load assistant audio or a multi-message history into a
+Realtime session. Gemini Live is explicit: "the Live API documentation makes no provision for
+substituting an alternative LLM within a session. All reasoning and response generation occurs within
+the Gemini model selected at session initialization" — and its half-cascade models, which allowed
+swapping _TTS only_, are narrowing rather than expanding. Gemini Live also remains "in Preview."
+
+Resolution: **buy the provider's audio primitives, not its conversation.** The pieces all exist
+standalone; the honest caveat is that **"ASR + your own LLM + TTS" is not a named, documented pattern
+at any of these vendors** — you assemble it from parts, which is a modest integration risk rather than
+a blocker.
+
+Input (streaming ASR with partials, push-to-talk, and vocabulary biasing — see C7 for the biasing
+comparison):
+
+- **OpenAI transcription-only Realtime sessions** — `gpt-live-transcribe`, "text from a microphone…
+  without a spoken assistant response," partials as
+  `conversation.item.input_audio_transcription.delta` and finals as `…transcription.completed`.
+  Push-to-talk is first-class and documented in as many words: `turn_detection: null` is "useful for
+  interfaces where you would like to take granular control over audio input, like push to talk
+  interfaces," then `input_audio_buffer.commit`. Server VAD defaults to 500ms silence, with
+  `semantic_vad` available as a middle ground; practitioners raise it to 800ms–1s for interview-shaped
+  conversations, which is exactly our case.
+- **ElevenLabs Scribe v2 Realtime** — client-side or server-side WebSocket streaming, ~150ms, word-level
+  timestamps, "delivers partial transcripts as you speak and committed transcripts when a speech
+  segment completes," with manual commit or VAD auto-commit.
+- **Deepgram Nova-3 / AssemblyAI Universal-Streaming** — the two best-documented choices for biasing
+  specifically, and the ones to default to if C7's accuracy spike goes badly (C7).
+
+Output (streaming TTS from our own text):
+
+- **ElevenLabs TTS WebSocket** — `/v1/text-to-speech/{voice_id}/stream-input`, built for partial-text
+  chunk input from an LLM token stream, which is exactly C1's first-sentence-streaming requirement.
+  Note it does not support the `eleven_v3` model.
+- **OpenAI Realtime as a speaker** — a sanctioned trick rather than a product: `response.create` with
+  `input: []` and `instructions: "Say exactly the following: <text>"`, with OpenAI noting
+  `gpt-realtime` is good at "reading disclaimer scripts word-for-word." Useful if we are already
+  holding a Realtime session for transcription. Its documented **out-of-band responses**
+  (`response.conversation: "none"`) are also the closest vendor analogue to (b)'s side-channel
+  extraction pass — worth knowing exists, not worth adopting.
+
+Either sits beneath our existing Flue transport, which the prototype already has working
+(`useFlueAgent({ url })` and `agent.sendMessage(text)` in `prototypes/sweep-seam/src/ui/chat.tsx`;
+ticket 01 confirms `@flue/sdk`'s `createFlueClient` for non-React hosts). One conversation authority,
+one transport, voice strictly additive.
+
+The honest cost of dissenting from the note: we then own microphone handling, echo cancellation,
+endpointing, and interruption plumbing — real engineering the managed path gives away. Push-to-talk
+removes nearly all of it, which is the third independent argument for push-to-talk.
+
+---
+
+## (b) The live-extraction beat
+
+"Entities extracted as the conversation goes, shown in a running list" needs four things beyond an
+ASR/TTS adapter:
+
+1. **Streaming ASR with partial results**, not per-turn finalized transcripts. This is the
+   requirement that eliminates the managed-agent path outright (C9): Speech Engine hands you "the full
+   transcript … on every turn" and documents no partials, and ElevenAgents' `user_transcript` is
+   "finalized speech-to-text results." The standalone STT products do supply them — Scribe v2 Realtime
+   "delivers partial transcripts as you speak," or
+   `conversation.item.input_audio_transcription.delta` on an OpenAI transcription session.
+2. **A debounced second model pass** over the growing transcript — cheap model, rolling window,
+   triggered on ~1–2s of silence or ~N new words rather than per partial. Per-partial is both
+   expensive and visually unstable.
+3. **A stable-keyed display list**, so entities do not flicker and reorder as the transcript
+   revises. This is more of the work than it sounds.
+4. **A promotion rule** — what, if anything, carries from this list into the real capture path.
+   Answer below: nothing automatic.
+
+### Does it fit capability 6?
+
+**Not during the user's turn, no.** Capability 6 is "private model call — native (`harness.prompt`
+scratch conversation)" (§10), and a `harness.prompt` call is only reachable from inside an agent
+render or tool execution. By §7.4's design the turn is _suspended_ while the user speaks: there is no
+dispatch in flight to host the call. Ticket 01 adds the matching constraint on the output side —
+`useDataWriter` streams data parts "strictly one-way out of the agent," and "a write never
+re-renders the agent" — so a data part can carry the running list _while an agent turn is running_
+and cannot otherwise.
+
+Two placements, and they trade liveness against containment:
+
+**(1) Per-turn, inside the kernel.** Run extraction as a private model call at the top of the agent's
+turn — Flue's `useAgentStart` is the documented async load-data seam (ticket 01) — and stream the
+list out as a data part. This fits capability 6 exactly, needs no new capability, and touches the
+main loop not at all: it is a side call whose output is display-only. Cost: the list updates at turn
+boundaries. For a 5–20s conversational exchange that reads as live; for the demo's _long audio
+description of a system_, the panel sits empty for minutes and then fills at once. Which is exactly
+the beat the demo wants to avoid.
+
+**(2) Continuous, outside the kernel.** The turn shell runs the pass over partial transcripts and
+renders the list itself. True "as the conversation goes" behaviour, no kernel contact, and it is the
+same monitor loop C4's interrupt heuristic needs — one watcher, two outputs (entities noticed,
+interrupt-now?). This is the demo answer.
+
+### The rule that keeps (2) safe
+
+The spec already has the concept, and it is the right one. §11.4 names "a **private,
+non-authoritative scratchpad** for 'noticed, not yet asked' — **not** harness session state." The
+running entity list _is_ that scratchpad made visible. Therefore:
+
+> The extraction pass produces noticing, never capture. Its output never becomes a capture, never
+> reaches the model, and is never citable as evidence. Captures still arrive only through
+> agent-judged settlement and sweep (§8.1, §8.3).
+
+And a presentation requirement that follows from it: **the running list must be visually distinct
+from the target-document panel.** The prototype already renders those separately (`StorePanel`
+polling `/store/:targetId` beside the chat), and that separation is now load-bearing. If a demo
+audience reads the live list as "the system captured these," then the product's actual
+differentiator — evidence-anchored, agent-judged, idempotent capture — is invisible, and the demo has
+accidentally sold a much weaker product that any streaming NER pipeline could deliver.
+
+There is a real upside available here too. The list is the natural place to show what the kernel can
+do that a NER pipeline cannot: an entity moving from _noticed_ to _captured with an epistemic status
+and a quoted span_, on screen, when the sweep lands. That transition is the demo's best single beat
+and it costs only wiring, since both panels already exist.
+
+---
+
+## (c) Verdict
+
+**Bolt-on with constraints.** Not an architectural rewrite, and not an unconstrained bolt-on either.
+
+The case for "not a rewrite" is concrete: every load-bearing kernel mechanism survives voice
+unchanged — string-only inbound replies and the ui's `purpose`/`display` filter (§7.7), the markdown
+floor and its optional-tap licence (§7.2, §5.1), one live affordance and mechanical reply binding
+(§7.3, §7.4), `terminate: true` + fresh dispatch (§7.4), content-keyed sweep idempotence under
+at-least-once execution (§8.3), harness-resolved quote anchoring (§8.2), and the private model call
+(§10, capability 6). Two of them — §5.1's inferred-only degradation and §8.3's abort tolerance — fit
+voice by accident, because both were designed for other reasons that happen to generalize.
+
+What voice genuinely adds is one new shell responsibility (endpointing, and with it interruption) and
+two small envelope additions (a speech rendition beside the markdown floor; an audio pointer on
+evidence spans). One capability gap exists and should be left open on purpose: a during-user-turn
+evaluation seam. Do not add it for September.
+
+### Constraints, enumerated
+
+1. **Voice attaches at the ui/turn shell.** Flue remains the only conversation authority; a provider
+   supplies ASR and TTS, not the session. Default picks: an OpenAI transcription-only session or
+   Deepgram/AssemblyAI for input (all three document push-to-talk and keyterm biasing), ElevenLabs' TTS
+   WebSocket for output. (C9, C7)
+2. **Turn-shell one-way valve.** It may synthesize user entries and abort dispatches; it may never
+   write captures, interpret answers, or be citable as evidence. (C3)
+3. **TTS inherits the display filter.** Diagnostics, injected signals, and tool narration are never
+   spoken; injected briefings get an audible or on-screen insertion notice. (C8, §7.7, §9.3)
+4. **Keep a screen.** Voice+screen preserves structured taps and therefore `explicit` absences;
+   voice-only is honestly inferred-only and must be described that way. (C5, §5.1)
+5. **The live entity list is scratchpad**, visually separated from the target-document panel, never
+   fed to the model, never promoted automatically. (b, §11.4)
+6. **Voice-derived captures are marked**; proper nouns get lexicon biasing and on-screen
+   confirmation before `explicit`. (C7)
+7. **Questionnaires collapse to their speech floor in voice mode**, or are disabled there. The turn
+   shell never walks multi-step forms. (C5, §7.2)
+8. **Add a speech rendition** alongside the markdown floor — small §12.6 concept-schema change. (C5)
+
+### Minimal demo-safe shape
+
+Ship the lowest tier that tells the story; rehearse the next one behind a toggle.
+
+- **T0 — push-to-talk voice-in, text-out.** Live partial transcript on screen, affordances rendered
+  and tappable as today, no TTS, no VAD, no barge-in. The user owns endpointing, so C3 and C4 do not
+  arise and C1 barely bites. Both candidate STT products support this directly — OpenAI documents
+  manual turn detection with `input_audio_buffer.commit` as a first-class mode. This already
+  demonstrates "describe your system out loud and watch it become structure," which is the actual
+  claim.
+- **T1 — add TTS out**, first-sentence streaming, with press-to-talk cancelling playback as the only
+  barge-in. Still no VAD.
+- **T2 — add the continuous extraction pass** and the running entity list, with the noticed →
+  captured transition wired as the showpiece beat.
+- **T3 — open mic + agent-initiated interruption.** Provider VAD or turn-detection model, forced
+  endpointing for interrupts. Stretch only; demo behind a toggle and rehearse T1 as the fallback in
+  the same session.
+
+The honest read is that **T0–T2 delivers the demo's narrative and T3 delivers its adjectives.**
+"Interrupts to clarify" is the most fragile item on the aspiration list and the least load-bearing
+for the argument the demo is making.
+
+### What to prototype first
+
+One spike, three numbers, on the existing `prototype/13-sweep-seam` branch rather than anything new.
+
+1. **Measure the loop.** Instrument end-to-end wall clock for one ask cycle: user dispatch → model →
+   ask tool `terminate` → part on the client, including §8.1's settlement continuation turn. Then add
+   a streaming-ASR mic and a TTS sink at the two edges of `chat.tsx`'s `send()` and text-part render.
+   The number that decides the demo is time-to-first-audio after the user stops speaking, read against
+   LiveKit's thresholds: under 1s is natural, over 2s "feels broken." Given that a single LLM
+   time-to-first-token is 300–800ms and our cycle contains one to three of them plus a
+   durable-submission hop, the honest prior is that we land past 2s on the first attempt. If tuning
+   cannot get it under that, T0 (silent, text-out) becomes the _right_ answer rather than the safe one.
+   This retires the biggest risk because it is the only one that can invalidate the whole aspiration.
+2. **Measure domain-term accuracy**, with and without lexicon biasing, on real audio — the
+   Yannis/Dora recording if it exists, where the current transcript scores 0/35 on the project's own
+   central noun. This retires the risk that the demo captures confident nonsense.
+3. **Answer two Flue questions** (cheap, half a day): can a client abort an in-flight submission, and
+   what happens when a second `dispatch` arrives while one is in flight? Both are needed for any
+   barge-in beyond press-to-talk-cancels-playback.
+
+### Effort estimate
+
+Labeled explicitly as an estimate: one engineer, **on top of a working kernel loop**, and excluding
+the Petri-net projection and residual-questions render (those are plugin work, not voice work).
+
+| Tier                                        | Estimate                                  |
+| ------------------------------------------- | ----------------------------------------- |
+| T0 (push-to-talk voice-in, live transcript) | 2–4 days                                  |
+| T0 + T1 (TTS out, playback cancel)          | ~1 week                                   |
+| T0–T2 (+ live extraction panel)             | 1.5–2 weeks                               |
+| T3 (open mic, agent interruption)           | +3–4 weeks, with an unbounded tuning tail |
+
+The dominant caveat is not about voice at all. **This repository currently contains no product
+code** — `main` holds a spec, a map, thirteen resolved tickets and `CONTEXT.md`; the only executable
+artifacts are the three prototype branches. In a five-week window the kernel's milestone one is the
+critical path, and T3's tuning tail would consume it. Recommended commitment: **T0 and T1 in scope,
+T2 as the stretch that most improves the demo per day spent, T3 explicitly out** — revisited only if
+the kernel loop is demonstrably done with two weeks to spare.
+
+---
+
+## Sources
+
+Spec and repo (primary):
+
+- [`spec.md`](../../../spec.md) §4, §5, §5.1, §7.2–§7.7, §8.1–§8.3, §9.1–§9.6, §10,
+  §11.4, §12.6, §13.1
+- [`CONTEXT.md`](../../../../CONTEXT.md) — ui-shell definition
+- [`issues/01-flue-architecture-deep-read.md`](../../../history/planning/elicitation-kernel/issues/01-flue-architecture-deep-read.md)
+  — durable-submission terminal outcomes and abort signal; `useDataWriter` one-way; `useAgentStart`
+  load-data seam; `@flue/sdk` for non-React hosts
+- [`issues/10-walking-skeleton-flue-roundtrip.md`](../../../history/planning/elicitation-kernel/issues/10-walking-skeleton-flue-roundtrip.md)
+  — turn suspension proven, wake wart, update-in-place data channel
+- `prototypes/sweep-seam/src/ui/chat.tsx` on `prototype/13-sweep-seam` — the existing reply
+  transport (`useFlueAgent`, `agent.sendMessage(text)`), tap-as-string, `StorePanel`
+- [`docs/reference/yannis-dora-lu-transcript-2026-08-11.md`](../../../reference/yannis-dora-lu-transcript-2026-08-11.md)
+  — the ASR-fidelity evidence
+
+Provider and practice (web, fetched 2026-08-11):
+
+- [`docs/reference/voice-implementation-recommendation-pplx.md`](../../../reference/voice-implementation-recommendation-pplx.md)
+  — the prior recommendation this document refines and partly dissents from
+- [ElevenLabs Speech Engine overview](https://elevenlabs.io/docs/overview/capabilities/speech-engine)
+  — "adds voice capabilities to any chat agent"; "your server provides the LLM logic"; SDK "manages
+  conversation turns"; interruption cancels the in-flight LLM request "via an `AbortSignal`"
+- [Speech Engine JavaScript SDK reference](https://elevenlabs.io/docs/eleven-api/resources/libraries/speech-engine/javascript-sdk-reference)
+  — `onTranscript(transcript: TranscriptMessage[], signal, session)` with
+  `{ role: "user" | "agent"; content: string }`; `session.sendResponse(string | AsyncIterable)`;
+  "the full transcript is passed to `onTranscript` on every turn"; no partial transcripts; "no
+  explicit push-to-talk or turn-initiation API exists"; no structured data channel to the client
+- [ElevenLabs speech-to-text](https://elevenlabs.io/docs/capabilities/speech-to-text) — Scribe v2
+  Realtime, "Low latency (~150ms)", "precise word-level timestamps", keyterm prompting (realtime: 50
+  terms × 20 chars; batch: 1000 × 50); links to a client-side-streaming WebSocket guide
+- [ElevenAgents custom LLM](https://elevenlabs.io/docs/eleven-agents/customization/llm/custom-llm) —
+  the OpenAI-compatible contract: "must align with one of the following OpenAI-compatible
+  request/response structures: Chat Completions API (`/v1/chat/completions`) [or] Responses API
+  (`/v1/responses`)", SSE with `ChatCompletionChunk` frames and `data: [DONE]`; request fields
+  `messages`, `model`, `temperature`, `max_tokens`, `stream`, `tools`, `elevenlabs_extra_body`; no
+  `conversation_id` documented. Turn controls (`turn_timeout` 1–30s, `turn_eagerness`,
+  `soft_timeout_config`, `user_activity`, `vad_score`, `agent_response_correction`) from the same
+  product's conversation-flow docs; **push-to-talk / manual turn-end not documented** (checked
+  directly). Naming confirmed by redirect: `/docs/conversational-ai/overview` → `/docs/eleven-agents`
+- ElevenLabs realtime STT — [client-side streaming](https://elevenlabs.io/docs/eleven-api/guides/how-to/speech-to-text/realtime/client-side-streaming),
+  [server-side streaming](https://elevenlabs.io/docs/eleven-api/guides/how-to/speech-to-text/realtime/server-side-streaming),
+  [capability overview](https://elevenlabs.io/docs/capabilities/speech-to-text) — Scribe v2 Realtime,
+  "~150ms", word-level timestamps, "delivers partial transcripts as you speak and committed
+  transcripts when a speech segment completes", manual or VAD-based commit. **Keyterm cap unresolved:
+  50 × 20 chars on one page, 100 × 50 chars on another**
+- [ElevenLabs TTS WebSocket](https://elevenlabs.io/docs/api-reference/text-to-speech/v-1-text-to-speech-voice-id-stream-input)
+  — `/v1/text-to-speech/{voice_id}/stream-input`, built for partial-text chunks from a token stream;
+  no `eleven_v3` support
+- [OpenAI Realtime guide](https://developers.openai.com/api/docs/guides/realtime) — models
+  `gpt-realtime-2.1`, `gpt-realtime-translate`, `gpt-live-transcribe`; GA-vs-preview per model **not
+  confirmed**; no documented pattern for an external LLM in-session
+- [OpenAI realtime transcription guide](https://developers.openai.com/api/docs/guides/realtime-transcription)
+  — transcription-only sessions on `gpt-live-transcribe`;
+  `conversation.item.input_audio_transcription.delta` / `.completed`; manual turn detection
+  (`turn_detection: null` "useful for… push to talk interfaces", then `input_audio_buffer.commit`);
+  `keywords` biasing "for product names, acronyms, and other literal terms", "hints, not required
+  output". (A second research pass did not find the `keywords` field; the quote above is from a direct
+  fetch of this guide.)
+- [OpenAI out-of-band responses cookbook](https://developers.openai.com/cookbook/examples/realtime_out_of_band_transcription)
+  — `response.conversation: "none"` for side processing; and the "say exactly the following"
+  text-in/audio-out pattern from the Realtime conversations docs
+- [Latent Space, OpenAI Realtime deep-dive](https://latent.space/p/realtime-api) — "it is currently
+  not possible… to retrieve the conversation context via the OpenAI Realtime API, to load 'assistant'
+  audio messages into the context, or to load a multiple-message history reliably"; endpointing
+  practice (500ms default, 800ms–1s for interview bots)
+- [Gemini Live API](https://ai.google.dev/gemini-api/docs/live-api) — "The Live API is in Preview";
+  "users can interrupt the model at any time"; transcripts of both input and output; function calling;
+  **no provision for substituting an alternative LLM** — "all reasoning and response generation occurs
+  within the Gemini model selected at session initialization"; native-audio models are audio-output
+  only; half-cascade (TTS-swap) availability narrowing. Manual-VAD/push-to-talk equivalent **not found**
+- [LiveKit, sequential pipeline architecture](https://livekit.com/blog/sequential-pipeline-architecture-voice-agents)
+  — "under 500ms feels like talking to a person", "under 1 second feels natural", "over 2 seconds feels
+  broken"; cascade breakdown (VAD 10–50ms, STT partial <100ms, LLM TTFT 300–800ms, TTS 100–200ms;
+  ~300–600ms streaming total vs 1000–2000ms+ naive); native S2S ~200–300ms
+- Turn-taking and semantic VAD (2026 practitioner sources):
+  [inworld.ai on semantic VAD](https://inworld.ai/resources/what-is-semantic-vad),
+  [gradium.ai](https://gradium.ai/content/semantic-vad-voice-agents-turn-detection-2026),
+  [futureagi.com](https://futureagi.com/blog/voice-ai-barge-in-turn-taking-2026) — the 800ms-timeout
+  and Vapi 1.5s+ figures, the faster-endpointing/more-false-interruptions tradeoff, Pipecat
+  SmartTurnAnalyzer / LiveKit TurnDetector
+- Vendor latency comparisons (secondary, treat as indicative): QubitTool's April 2026 round-up
+  (end-to-end TTFA clustering 0.78s–2.98s; per-component figures),
+  [AssemblyAI on Vapi tuning](https://assemblyai.com/blog/how-to-build-lowest-latency-voice-agent-vapi)
+  (~465ms end-to-end)
+- Biasing options: [Deepgram keyterm prompting](https://developers.deepgram.com/docs/keywords)
+  (Nova-3, 100 terms), [AssemblyAI streaming keyterms](https://assemblyai.com/blog/streaming-keyterms-prompting)
+  (100 terms, $0.15/hr, self-reported 21% over Nova-3 — vendor claim, not independently verified)
+
+Still unverified after this pass: per-model GA-vs-preview status on OpenAI Realtime; Gemini Live's
+push-to-talk equivalent and session limits; the ElevenLabs realtime keyterm cap (two conflicting
+numbers); and ElevenLabs Scribe base pricing. None of these change the recommendation. One claim in
+C4 — that a badly-timed interrupt costs more in front of an audience than silence does — is
+presentational judgment, not a sourced finding.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-evidence-2026-08-19.json b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-evidence-2026-08-19.json
new file mode 100644
index 00000000000..b641ea4a247
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-evidence-2026-08-19.json
@@ -0,0 +1,168 @@
+{
+  "probe": "FE-1434 Flue client-tool suspension",
+  "probeSourceCommit": "4df6f86b6881653c3400eca101df01d21211dba1",
+  "probeSourcePathAtCommit": "apps/dev/test/flue-client-tool-suspension.probe.ts",
+  "commandAtCommit": "node --experimental-strip-types apps/dev/test/flue-client-tool-suspension.probe.ts",
+  "probeSourceDisposition": "Removed from the branch head after evidence capture; spike code is disposable and only this normalized evidence plus the verdict persist.",
+  "flueVersion": "2.0.3",
+  "carrier": "signal delivery containing a toolCallId-keyed result batch",
+  "nativeToolResultDelivery": {
+    "rejected": true,
+    "status": 400,
+    "errorType": "invalid_request"
+  },
+  "scenarios": [
+    {
+      "batchSize": 3,
+      "dispatches": { "request": 1, "resultReturn": 1, "total": 2 },
+      "modelTurns": 2,
+      "terminatingToolOutcomes": 3,
+      "suspensionBoundary": {
+        "firstSubmissionOutcome": "completed",
+        "modelTurnsBeforeResume": 1,
+        "resultSignalPresentBeforeResume": false
+      },
+      "toolCallIdCoverage": {
+        "pendingCount": 3,
+        "resultCount": 3,
+        "first": "batch-003-call-001",
+        "last": "batch-003-call-003",
+        "exactMatch": true
+      },
+      "resultDeliveryProjection": {
+        "role": "system",
+        "purpose": "dispatch",
+        "display": "diagnostic",
+        "tagName": "client-tool-results",
+        "sweepKind": "non-user"
+      },
+      "stateSurvivedResume": true,
+      "allResultsReachedModel": true,
+      "evidenceAttempt": {
+        "excerpt": "batch-003-result-001",
+        "outcome": "refused",
+        "refusalCode": "non-user-evidence",
+        "refusalMessage": "The quote \"batch-003-result-001\" occurs only in injected non-user entries and cannot be cited as user evidence."
+      },
+      "normalizedTranscript": [
+        {
+          "role": "user",
+          "purpose": "user",
+          "display": "visible",
+          "text": "Queue 3 client mutations.",
+          "tools": []
+        },
+        {
+          "role": "assistant",
+          "purpose": "assistant",
+          "display": "visible",
+          "text": "",
+          "tools": [
+            {
+              "toolName": "probe_client_mutation",
+              "toolCallId": "batch-003-call-001",
+              "state": "output-available",
+              "input": { "batchId": "batch-003", "operation": "mutation-001" },
+              "output": {
+                "status": "pending-client",
+                "batchId": "batch-003",
+                "toolCallId": "batch-003-call-001",
+                "operation": "mutation-001"
+              }
+            },
+            {
+              "toolName": "probe_client_mutation",
+              "toolCallId": "batch-003-call-002",
+              "state": "output-available",
+              "input": { "batchId": "batch-003", "operation": "mutation-002" },
+              "output": {
+                "status": "pending-client",
+                "batchId": "batch-003",
+                "toolCallId": "batch-003-call-002",
+                "operation": "mutation-002"
+              }
+            },
+            {
+              "toolName": "probe_client_mutation",
+              "toolCallId": "batch-003-call-003",
+              "state": "output-available",
+              "input": { "batchId": "batch-003", "operation": "mutation-003" },
+              "output": {
+                "status": "pending-client",
+                "batchId": "batch-003",
+                "toolCallId": "batch-003-call-003",
+                "operation": "mutation-003"
+              }
+            }
+          ]
+        },
+        {
+          "role": "system",
+          "purpose": "dispatch",
+          "display": "diagnostic",
+          "signal": {
+            "tagName": "client-tool-results",
+            "attributes": { "batchId": "batch-003", "resultCount": "3" }
+          },
+          "text": "{\"batchId\":\"batch-003\",\"results\":[{\"toolCallId\":\"batch-003-call-001\",\"output\":\"batch-003-result-001\"},{\"toolCallId\":\"batch-003-call-002\",\"output\":\"batch-003-result-002\"},{\"toolCallId\":\"batch-003-call-003\",\"output\":\"batch-003-result-003\"}]}",
+          "tools": []
+        },
+        {
+          "role": "system",
+          "purpose": "dispatch",
+          "display": "diagnostic",
+          "signal": {
+            "tagName": "client-tool-results-bound",
+            "attributes": {
+              "batchId": "batch-003",
+              "pendingCount": "3",
+              "returnedCount": "3"
+            }
+          },
+          "text": "{\"batchId\":\"batch-003\",\"pendingToolCallIds\":[\"batch-003-call-001\",\"batch-003-call-002\",\"batch-003-call-003\"],\"returnedToolCallIds\":[\"batch-003-call-001\",\"batch-003-call-002\",\"batch-003-call-003\"]}",
+          "tools": []
+        },
+        {
+          "role": "assistant",
+          "purpose": "assistant",
+          "display": "visible",
+          "text": "Three client results were bound.",
+          "tools": []
+        }
+      ]
+    },
+    {
+      "batchSize": 100,
+      "dispatches": { "request": 1, "resultReturn": 1, "total": 2 },
+      "modelTurns": 2,
+      "terminatingToolOutcomes": 100,
+      "suspensionBoundary": {
+        "firstSubmissionOutcome": "completed",
+        "modelTurnsBeforeResume": 1,
+        "resultSignalPresentBeforeResume": false
+      },
+      "toolCallIdCoverage": {
+        "pendingCount": 100,
+        "resultCount": 100,
+        "first": "batch-100-call-001",
+        "last": "batch-100-call-100",
+        "exactMatch": true
+      },
+      "resultDeliveryProjection": {
+        "role": "system",
+        "purpose": "dispatch",
+        "display": "diagnostic",
+        "tagName": "client-tool-results",
+        "sweepKind": "non-user"
+      },
+      "stateSurvivedResume": true,
+      "allResultsReachedModel": true,
+      "evidenceAttempt": {
+        "excerpt": "batch-100-result-001",
+        "outcome": "refused",
+        "refusalCode": "non-user-evidence",
+        "refusalMessage": "The quote \"batch-100-result-001\" occurs only in injected non-user entries and cannot be cited as user evidence."
+      }
+    }
+  ]
+}
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-verdict-2026-08-19.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-verdict-2026-08-19.md
new file mode 100644
index 00000000000..fbd6cf5eb46
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/spikes/fe-1434-suspension-verdict-2026-08-19.md
@@ -0,0 +1,112 @@
+# FE-1434 suspension spike verdict
+
+## Question
+
+Can Flue end a turn with several client-tool calls pending, preserve their binding state, and
+resume on a later dispatch that returns all outputs as data inside one machine-authored batch
+entry? If it can, should the external-tool batch use the same pending-interaction pattern as the
+existing singular user-question (`ask`) affordance, or does it require another inbound channel?
+
+## Approach
+
+The bounded probe uses Flue 2.0.3 in process, its public HTTP router and history projection, and
+a deterministic faux provider. It adds no production protocol. The disposable evidence
+instrument is preserved in commit `4df6f86b6881653c3400eca101df01d21211dba1` at
+`apps/dev/test/flue-client-tool-suspension.probe.ts`; at that commit it ran as
+`node --experimental-strip-types apps/dev/test/flue-client-tool-suspension.probe.ts`. The branch
+head intentionally removes the probe source. Its normalized captured output persists as
+[`fe-1434-suspension-evidence-2026-08-19.json`](fe-1434-suspension-evidence-2026-08-19.json).
+
+The faux provider emits a multi-tool batch in which every tool outcome returns
+`terminate: true`. Each callback records its Flue `toolCallId` through updater-form
+`usePersistentState`, so calls in the same batch compose rather than overwrite each other. A
+later `signal` dispatch carries all browser results as one JSON batch keyed by those ids. The
+success-path resume hook checks that the returned ids exactly cover the durable pending ids,
+clears the slot after that check, and emits a machine binding signal before the next model turn.
+The probe did not run negative mismatch or retry cases; fail-before-clear remains a requirement
+for the protocol ticket rather than a behavioral claim from this spike.
+
+Two cases ran: three returned tool outputs, retained as a normalized before/after transcript,
+and 100 returned tool outputs, pressure-testing the count raised by the
+[Petrinaut survey §6d](../research/petrinaut-survey.md#6d-where-the-evidence-is-thin) for a
+roughly 40-place net. These are faux outputs, not 100 real dependent Petrinaut mutations. The
+probe then read public Flue history through the binding's
+[`projectFlueHistoryForSweep`](../../../../packages/binding-flue/src/history-reader.ts) function
+and tried to cite a recorded result sentinel in an actual capture-store sweep. It also attempted
+an undeclared native `kind: 'tool-result'` dispatch to distinguish a native Flue carrier from a
+harness-defined envelope.
+
+## Verdict
+
+**The suspension floor holds, with a signal carrier.** A terminating multi-tool batch settled
+after one model turn and before any result signal existed. One later dispatch to the same
+conversation produced a binding signal whose pending and returned ids match exactly, then exposed
+every returned output to the following model turn. The 3-output evidence retains the five-entry
+normalized transcript; the 100-output evidence records the same transition with count and
+first/last-id checks.
+
+Flue does not accept a native inbound tool-result delivery. The attempted
+`kind: 'tool-result'` message was rejected before admission with HTTP 400 `invalid_request`.
+The public Flue SDK type available to the probe admits `user | signal`, and the runtime rejection
+confirms the closed union, so the external-tool protocol must carry its tool-call-id-keyed result
+batch inside a `signal`. That is not user-message laundering: the materialized return was
+`role: system`, `purpose: dispatch`, `display: diagnostic`; the binding projected it as
+`non-user`; and the capture store refused the transcript sentinel `batch-003-result-001` with
+`non-user-evidence` and the explicit message that injected non-user entries cannot be cited.
+
+**Adjudication: batch-as-pending-slot variant, not a parallel channel.** The observed behavior
+requires only one live pending-interaction slot, represented as either the existing singular
+user-question variant or an external-tool-batch variant containing every call from one assistant
+turn. The return signal names the batch and provides one result per pending `toolCallId`. Because
+that shape succeeded, a second inbound transport or separately persisted result log is not
+required by the evidence; selecting the slot variant is the smaller design, not proof that every
+parallel design lacks value. As a recommended guardrail, initially reject a model turn that tries
+to suspend both a user question and a client-tool batch. Mixed-pending semantics remain untested.
+
+FE-1435 (the panel-to-AI-SDK adapter spike named by the
+[integration spec](../petrinaut-integration-spec.md#testing-decisions)) still has to prove that
+the real panel's batched tool-result POST can become this one Flue signal without losing ids.
+That is the exact remaining wire uncertainty; it does not reopen the Flue runtime behavior tested
+here.
+
+## Confidence shift
+
+Confidence is high for the tested Flue behavior: the proof crosses real admission, runtime,
+persistent state, public history, binding projection, and capture-store boundaries without a
+live model. Confidence in the panel adapter is unchanged until FE-1435 runs the recorded panel
+round-trip.
+
+Observed dispatch and model-turn counts were the same at both sizes:
+
+| Returned results | Request dispatches | Result-return dispatches | Total dispatches | Model turns |
+| ---------------: | -----------------: | -----------------------: | ---------------: | ----------: |
+|                3 |                  1 |                        1 |                2 |           2 |
+|              100 |                  1 |                        1 |                2 |           2 |
+
+The protocol therefore permits one result-return dispatch to carry 100 outputs; it does not
+require one Flue dispatch per output. Because the probe ran in process, it did not measure real
+network round-trips or latency. A real 100-mutation turn would still mean 100 tool calls, 100
+client executions, and 100 correlated outputs, with their payload, context, local execution
+ordering, and any provider tool-count limits.
+
+## Recommendation
+
+FE-1438 (the external-tool round-trip protocol) should put portable batch state and validation
+around one durable pending interaction, while the Flue binding maps the portable result batch to
+one non-user signal. Exact id coverage, duplicate/retry handling, and fail-before-clear semantics
+are protocol requirements still to test. The wire adapter should translate the panel's returned
+tool outputs into that signal rather than asking Flue to admit tool-result messages it does not
+support.
+
+The app-level `PetrinautDocHandle` fallback is **not selected**, because the required suspension
+shape succeeded. If the adapter spike later shows that the panel's real POST cannot be translated
+while preserving the batch's ids, one-return-dispatch shape, and non-user provenance, that is the
+failure condition: select the doc-handle path in writing and retain this probe as evidence that a
+future Pi-substrate binding (`binding-pi`) needs a first-class machine delivery or the same
+explicit signal envelope.
+
+> **Reflection:** Re-rendered as a transport budget, the result is narrower than “100 mutations
+> are cheap.” Flue proves one suspension and one return dispatch can carry the batch; it says
+> nothing about whether Petrinaut can apply 100 dependent mutations concurrently or whether the
+> model/provider will emit that many calls in one turn. Those pressures remain visible instead
+> of being smuggled into the substrate verdict.
diff --git a/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/transport-aisdk-implementation-2026-08-19.md b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/transport-aisdk-implementation-2026-08-19.md
new file mode 100644
index 00000000000..5d7b522acc3
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/planning/process-model-elicitation/transport-aisdk-implementation-2026-08-19.md
@@ -0,0 +1,87 @@
+# FE-1436 transport-aisdk implementation record
+
+**Date:** 2026-08-19
+**Source:** `ln/fe-1436-transport-aisdk`, stacked on the FE-1435 panel-spike branch
+**Contract input:** `test/fixtures/transport-aisdk/` from the real-panel FE-1435 run
+
+## Outcome
+
+The production-intent transport path now crosses the real boundary that the spike identified:
+
+```text
+Petrinaut ChatTransport POST
+  -> apps/dev /api/chat application route
+  -> Flue-backed GherkinElicitor
+  -> substrate-neutral HarnessReplyEvent stream
+  -> transport-aisdk AI SDK v6 encoder
+  -> Petrinaut UI-message SSE renderer
+```
+
+`transport-aisdk` depends only on `@brunch/core`, `ai`, and `valibot`. Valibot establishes trust
+at the external POST boundary; the Flue chunk projection stays in `binding-flue`, and the
+application composes the two. Dependency and physical-resolution gates make that split
+executable. No fetch shim, alternate conversation renderer, or disposable server loop is part
+of the path.
+
+The frozen initial POST drives the committed application route, actual Gherkin elicitor, Flue
+reply projector, and AI SDK transport; the complete normalized SSE sequence is compared with a
+committed golden fixture. A separate wire test encodes a fixed harness event sequence and
+reproduces the spike's initial SSE byte-for-byte. The frozen automatic tool-result POST is also
+a contract input: this slice refuses it with `422 tool_result_follow_up_not_supported` before
+dispatch, rather than misclassifying Petrinaut's synthetic diagnostics message as user evidence.
+FE-1438 (the client-tool round-trip) owns admitting that machine-input protocol.
+
+## Inspection surface
+
+Set `BRUNCH_TRANSPORT_AISDK_INSPECT=1` on the application server to emit one JSON object per line, prefixed
+with `TRANSPORT_AISDK`. The committed stream reports request, response, and turn boundaries;
+part kinds; stable message, part, turn, and tool-call ids; and the terminal state. The sink is
+endpoint-side only and is never dispatched into the elicitor, stored as conversation content, or
+offered to evidence capture.
+
+## Repeatable local panel run
+
+Build the clean external hash checkout, then start the committed application server and real-panel launcher:
+
+```shell
+cd /path/to/hash
+turbo run build --filter '@apps/petrinaut-website'
+
+BRUNCH_TRANSPORT_AISDK_INSPECT=1 \
+BRUNCH_PETRINAUT_ORIGINS=http://127.0.0.1:4915 \
+turbo run dev --filter '@apps/brunch-agent' -- --host 127.0.0.1 --port 4321
+
+PETRINAUT_WEBSITE_ROOT=/path/to/hash/apps/petrinaut-website \
+BRUNCH_CHAT_ORIGIN=http://127.0.0.1:4321 \
+turbo run petrinaut:dev --filter '@apps/brunch-agent' -- --host 127.0.0.1 --port 4915
+```
+
+The launcher loads hash's own Vite configuration, removes only its incumbent development
+`/api/chat` handler, and proxies that route to the brunch application server. It does not edit hash.
+
+## Observed evidence
+
+The 2026-08-19 run used hash commit `1046b5c881cd00cf205b4895348b022934d66b4a`.
+The real Petrinaut panel issued a same-origin `/api/chat` POST and received a `200` AI SDK v6
+event stream. It rendered expandable reasoning and this elicitor text after an actual panel
+follow-up:
+
+> What I heard: A shopper completes an online shopping cart and receives an order
+> confirmation. This is a basic e-commerce scenario covering the checkout and confirmation
+> flow.
+
+The corresponding inspection stream preserved message id
+`entry_01M0CXCAZ8S9S326SM91V6BZX5`, turn id
+`turn_01M0CXCACJET69FNEGTVTJP29W`, reasoning part id ending `:reasoning:1`, text part id
+ending `:text:2`, and tool-call id `toolu_01RkHpPgUKwFJUzbYCJnbRuz`; it terminated as
+`completed` with finish reason `stop`. The hash checkout was still on the same commit with no
+tracked changes after the run.
+
+The elicitor's structured `brunch_ask` currently appears as a server-executed tool part; the
+plain-text and reasoning conversation path is live. FE-1449 (structured ask in the panel)
+owns rendering that ask as an interactive client affordance.
+
+> **Reflection:** Re-rendering the implementation as a boundary crossing exposed the useful
+> negative contract: refusing tool-result follow-ups is not an absent feature hidden by the
+> happy path. It is the guard that keeps synthetic diagnostics out of user evidence until the
+> machine-entry protocol exists.
diff --git a/libs/@hashintel/brunch-agent/docs/reference/2026-08 SDCPNs for cyber-physical systems.md b/libs/@hashintel/brunch-agent/docs/reference/2026-08 SDCPNs for cyber-physical systems.md
new file mode 100644
index 00000000000..fc1c8212aed
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/2026-08 SDCPNs for cyber-physical systems.md	
@@ -0,0 +1,201 @@
+# SDCPNs for cyber-physical systems
+
+_One formalism for continuous dynamics, stochastic events and typed state, demonstrated across industrial gas supply, truck fleet maintenance, and semiconductor fabrication._
+
+# SDCPN as a Common Language for Physical and Digital Systems
+
+Most industrial systems have a physical part (machines, stock levels) and a digital part (control rules, schedulers). A Stochastic Dynamic Coloured Petri Net (SDCPN) can represent both cyber and physical in the same net, sharing the same state. A change on one side immediately affects the other: a physical event enables or blocks decisions, and decisions change the physical trajectory. There is no handoff between separate tools and no assumption that the other side behaves as expected.
+
+This matters because most real world failures happen at the boundary between the physical and digital sides. They emerge from the interaction, a decision made on incomplete physical information, or a physical process that evolves faster than the control logic can respond. Finding these failures requires a model where both sides participate in the same feedback loop.
+
+This blog post builds one such model through five levels of the formalism, then applies the full SDCPN to two further industries to explore how it can be used to model various domains and its limitations.
+
+# What is an SDCPN?
+
+A [Petri net](https://petrinaut.org/) is a directed graph of places, transitions, and arcs. Tokens sit in places, transitions fire and move tokens between places, and the arrangement of all tokens at a given moment represents the state of the system. A plain Petri net records what can happen and in what order, but without modelling durations, likelihoods, or what distinguishes one token from another, it cannot answer "how often" or "how likely" in a scenario.
+
+An SDCPN extends a plain Petri net with 4 features:
+
+- **Colour**. Tokens carry data so they become distinguishable. A transition can inspect that data before firing.
+
+- **Stochastic firing.** Transitions can fire at random, drawn from explicit distributions. The distribution's parameters can read a token's own data to model correlations, e.g. a component's failure rate rising with its degradation.
+
+- **Continuous dynamics.** Token data changes while a token sits in a place, governed by differential equations. This can be used to represent continuous processes such as products being consumed, condition deteriorating etc.
+
+- **Stochastic dynamics.** The differential equations can include random noise, so continuous quantities fluctuate between firings. An example being demand rates drifting randomly, or ambient temperature variations.
+
+The four features together allow SDCPNs to represent all aspects of a cyber-physical system in the same state and clock: its physical process (a tank emptying, a machine wearing), control logic (when to dispatch, when to service), and the randomness that affects both (a breakdown, a demand spike).
+
+## Where SDCPNs come from
+
+[Mariken Everdij and Henk Blom](https://link.springer.com/chapter/10.1007/11587392_10) developed the formalism at the National Aerospace Laboratory (NLR) in the Netherlands in the early 2000s. The problem they were trying to solve was quantifying the probability of a mid-air collision, an event too rare to observe in testing, and requires modelling many aircraft moving continuously, controlled by different humans and automated systems. Everdij and Blom extended the Dynamically Coloured Petri Net (DCPN) by adding Brownian motion to the equations governing how token data evolves between firings, and defined the result as a formal 12-component specification ([P, T, A, N, S, C, V, W, G, D, F, I](https://old.sf.bg.ac.rs/downloads/katedre/apatc/ICRAT2010.pdf)).
+
+The formalism was designed to support a safety case: a defensible and quantitative statement about how often something bad happens in a system too complex to test exhaustively. The ARIA Safeguarded AI programme chose the same formalism for the same reason. Its goal is a world model expressive enough to hold both the physical system and the AI that controls it, with a safety specification over both. The air traffic problem, with continuous dynamics, multiple agents, human and automated controllers, rare catastrophic events is exactly the class of system Safeguarded AI is building for. The only difference is the controller: the original use case modelled human operators and procedural automation; Safeguarded AI focuses on neural networks.
+
+# Modelling real world with SDCPNs
+
+The following sections model an industrial supply chain process progressively, adding one feature of the formalism at each level until the model is a full SDCPN. To illustrate the expressivity of SDCPNs, we model two further domains as full SDCPNs: truck fleet maintenance and semiconductor fabrication.
+
+## Industrial gas supply chain
+
+Taking an industrial gases supply chain as an example use case: a gas supplier delivers liquid gases (e.g. nitrogen, oxygen) to customer sites by road tankers. The supply chain operates in a standard practice where the supplier owns the liquid in each customer's tank, reads the level by telemetry, and decides when to send a refill. The customer draws product as needed and only pays for what they consumes, but does not place orders.
+
+Each tank empties from two sources: the customer's consumption and heat leaking through the walls, which boils liquid gas off continuously. A delivery that arrives before enough space exists risks overfilling. The supplier must keep every tank within a safe range:
+
+- Too low: the customer's production line stops (stockout).
+
+- Too full: boil-off gas has nowhere to go, pressure rises, and the relief valve vents the gases into the atmosphere, creating wastage and potential safety concerns.
+
+The reorder point, load size, consumption rate, boil-off rate, and delivery lead time are all coupled. A tanker dispatched to one site is unavailable to other customer sites until it returns.
+
+### Plain Petri net
+
+First we model the system using a plain Petri net with only places, transitions, tokens (without colours) and different arcs and arc weights.
+
+The net consists of just 1 customer site to illustrate the core concepts. To start, there is a tank of nitrogen on site holding 42 out of 54 units of liquid gas; one tanker at the depot and up to 2 loads may be on order at once. The customer’s production line is running.
+
+As the customer consumes the nitrogen and some boils off, the level drops. When the level drops to 15 (representing the telemetry-based sensor in the tank), an order is placed. A tanker dispatches, arrives and delivers 12 units (only if 12 units of space exist in the tank). The permit and tanker return on delivery and cycle repeats.
+
+Stockout happens if the tank hits zero and the production line stops. It restarts when at least 1 unit arrives.
+
+If the tank is completely full, a relief valve opens and reduces the level of gas (by 1 unit). Under this level trigger order policy, venting is unreachable since the maths of the reorder point and load size prevent it (gas only refills by 12 units when below 15 units). In later timed-extensions of the model, we introduce pressure-driven venting since in practice, venting is required when pressure gradually builds as the liquid warms.
+
+\[BELOW\] shows the net for a variant of the order policy based on consumption-trigger. Instead of reordering when the level drops below a threshold, the system reorders after every 8 units are drawn by the customer without accounting for any evaporation. This results in a failure mode whereby, If enough nitrogen boils off, the tank empties without the consumption counter ever reaching 8\. The system reaches a deadlock: the tank is at zero, fewer than 8 units have been drawn since the last order, and nothing in the model can change the state in the system so the production line stops and never restarts.
+
+Without time accounted for in the model, the net picks any enabled transition to fire without any rules on ordering. There can be a scenario where the transition for consuming nitrogen is fired repeatedly and empties the contents without dispatching the tanker for refill. Adding durations fixes this so events happen according to rates rather than random choice, which we explore in the next progression to SPN.
+
+This basic Petri net is useful for checking the logic of the system, such as finding deadlocks (consumption-trigger variant), checking conservation laws (liquid \+ ullage \= 54 always) etc. Without the additional features, it falls short on answering the more interesting timing questions like whether the tank runs dry before the tanker arrives, or what load size and reorder point minimise stockouts.
+
+### SPN
+
+The following shows a Stochastic Petri net (SPN), based on the same structure as the basic Petri net with the addition of rates on each transition and a second site (SlowNitrogen) to represent a low-consumption customer.
+
+Each enabled transition now independently draws a random wait time from its exponential distribution:
+
+e^(-λt) \= random number (0 to 1), λ as the average number of events per hour (lambda rate) and t as the random wait time until the next firing.
+
+So whichever transition draws the shortest time fires first. For example, when the customer’s (SteadyNitrogen) tank is half full, three transitions are enabled at once: the customer drawing product (rate 0.80/h), boil-off (0.16/h), and the tanker arriving (rate 1/6 ≈ 0.17/h). The runtime engine rolls a random wait time for each: 0.45 hours for product draw, 3.1 hours for boil-off, and 2.8 hours for the arrival. The nitrogen draw transition fires first so one unit leaves the tank, the clock advances 0.45 hours, and all three roll again from scratch.
+
+A limitation of modelling journey time as a stochastic rate on the arrival transition (1/6, 1/9, or 1/12 per hour, giving mean journeys of 6, 9, and 12 hours) is that the exponential distribution allows a delivery to arrive almost immediately or take far longer than its mean. Realistic journey times need a minimum and a bounded spread, which requires clocks counted down by dynamics.
+
+With the addition of a second customer, the one supplier tanker serves both sites with a new "returning" state to represent the time the tanker spends driving home after each delivery, introducing a risk of stockout if one customer is left waiting whilst the tanker delivers for another. For example, if the SteadyNitrogen tank crosses its reorder threshold (16 units) while the tanker is mid-journey to the SlowNitrogen site, it must wait for the delivery to complete (up to 9 hours remaining), the return trip (\~4 hours) plus its own journey (\~6 hours) before receiving the product. At a combined drain of \~0.96 units/hour, 16 units of buffer lasts roughly 17 hours, so on some runs can result in a stockout for the high consumption customer (SteadyNitrogen).
+
+This stochastic net introduces time and contention with transitions competing to fire next and additional customers that can lock out delivery for each other. It answers questions on stockout frequency, the cost of sharing a tanker and the effect of slower routes. It falls short on the realism of timing (a 6-hour journey is exponentially distributed, so it sometimes arrives in minutes and sometimes takes a day), distinguishing between different products, and continuous processes like boil-off are still modelled as discrete random events rather than a steady flow.
+
+### SCPN
+
+To distinguish which product a tanker is holding, we can add colours to the SPN so each tanker token now has a data field identifying its gas type. In this example, the timing mechanism stays stochastic but the network grows to three customers and three tankers.
+
+The third customer requires a different type of gas, oxygen with a draw rate of 0.60/h and average delivery journey time of 12 hours. The depot now holds 3 tankers (2 nitrogen, 1 oxygen) and a transition guard checks the correct product is dispatched. If a nitrogen order is placed and only the oxygen tanker is idle, the order waits.The cycle for drawing, boiling-off and ordering works as before.
+
+With product identity added to the fleet, the SCPN can answer questions on whether fleet composition matters more than fleet count and by how much. For example, the same three tankers re-specified from one to two oxygen tankers can eliminate the oxygen stockout completely if they are the most critical customer from a business perspective. The colour features also allows for modelling of tanker spot hires. For example if 3 or more orders are waiting and no tanker is idle, a hire transition fires: its kernel writes a new tanker token into the depot with a rental flag, and a release transition destroys it when the demand clears. (This is included in the next progression of DCPN.)
+
+The SCPN still has the same timing limitations as the SPN: exponential journey times and discrete boil-off events.
+
+### DCPN
+
+The Dynamic Coloured Petri Net (DCPN) replaces the stack of unit tokens with a single token governed by differential equations, to model the level of gas and pressure as real numbers that can fall or grow continuously. With the inclusion of dynamics, the net can now model scenarios that simpler nets couldn’t:
+
+- **Pressure building in a tank with relief valve cycling.** Boil-off gas fills the empty space above the liquid, the reduced space raises the pressure more so a fuller tank pressurises faster. When pressure reaches the relief setpoint (8 units), the valve opens, 0.4 units of liquid escape as gas and the pressure drops just below 8\. If the tank is still nearly full, pressure climbs back to 8 and the valve opens again. This reveals a trade-off where a fuller tank means fewer stockouts but more wastage through vented product, resulting in higher supplier costs.
+
+- **Realistic durations from lognormal distributions.** The dispatch kernel samples a journey time from a lognormal distribution and writes it onto the tanker token. Place dynamics counts the remaining time down by 1 per hour, and the arrival transition fires when it reaches 0\. This gives each journey a reasonable minimum, a mode near the nominal hours, and a long tail for delays.
+
+The DCPN captures the physical behaviour that the simpler nets cannot: tanks drain smoothly, pressure builds and vents in cycles, and journey times have realistic distributions rather than memoryless exponentials. What it does not capture is variability that changes between runs, such as ambient temperature, weather and demand fluctuations are all fixed. Every simulation with the same parameters produces the same pressure curve and the same boil-off rate.
+
+### SDCPN
+
+The final progression to the full definition of SDCPN adds stochasticity, “noise” to the dynamics. Ambient temperature and customer draw rate, which the DCPN held as fixed constants, now evolve as stochastic processes (Ornstein-Uhlenbeck, mean-reverting with random fluctuations).
+
+At every 0.5 simulated hours, a clock on the tank token reaches zero and a transition fires one diffusion step (Euler-Maruyama): it draws a new ambient temperature and a new draw rate from Gaussian distributions centred on a mean-reverting update of the current value, and writes both values back onto the tank token. Boil-off now scales with ambient temperature, so weather drives evaporation (faster when warmer) and deliveries. Similarly, the draw rate fluctuates around its contracted value rather than a constant value, so a customer with the same average consumption can produce demand spikes that empty a tank faster than the reorder system can respond.
+
+Introducing noise and randomness to the dynamics in SDCPNs enables us to answer questions on the system’s varying environment. One limitation of this model is specific to the current Petrinaut engine: its integrator handles only deterministic ODEs, so diffusion is injected discretely via a kernel every 0.5 simulated hours rather than continuously. The approximation works, but its quality depends on the step size the model builder chooses rather than improving automatically as the engine's time step shrinks.
+
+## Truck fleet maintenance
+
+SDCPNs can be used for truck fleet operators to solve their maintenance problem, in deciding when and where they should service each vehicle. The service must occur early enough to prevent a breakdown on the road, and late enough not to waste maintenance capacity. The maintenance schedule must ensure deliveries are still completed within the agreed window.
+
+In this example, the fleet operator has 8 trucks over three route classes: motorway (420 km, flat), urban (180 km, stop-start), and mountain (260 km, steep gradients). Loads are posted to a freight board at stochastic rates; if no truck collects one within 10 hours, it goes to a competitor. Each delivery has a time window (2.2× driving time): missing the window incurs a 30% revenue penalty, missing it entirely (breakdown mid-route) means losing the load and paying for recovery.
+
+The depot has 2 service bays, 2 technicians, and a stock of spare parts. A truck that reaches a wear threshold is serviced (5 hours, resets to new). A truck that breaks down at the roadside needs a recovery vehicle, a tow, and a longer repair (12 hours, only partially restores condition). Both compete for the same bays, technicians, and parts.
+
+Each truck is modelled as a coloured token carrying 19 fields of continuous and discrete state. The key mechanisms are:
+
+- **Three wear components per truck.** Brakes, engine, and tyres each degrade at different rates depending on the route. Brake wear accumulates 2.5× faster on mountain descents (heavy braking on gradients); engine wear increases when carrying load; tyre wear rises with road roughness and weather severity.
+
+- **Breakdown driven by the weakest component.** The roadside failure rate is set by whichever component is the most degraded. For example, a truck with fresh brakes and fresh tyres but a worn engine fails at the engine's rate.
+
+- **Road conditions as stochastic dynamics.** The same diffusion mechanism that models ambient temperature in the industrial gas supply chain is also used here to model the variations in driving conditions that a truck encounters on any given trip. Two state variables on each truck token represent this road conditions: road severity which multiplies all wear rates and fuel consumption and speed factor which impacts travel speed and therefore journey time.
+
+- **Driver hours enforced.** EU Regulation (561/2006) limits drivers to 9 hours of continuous driving, so the model includes a compulsory rest stop at the depot for 11 hours before it can be dispatched again.
+
+The model helps the operator understand the interactions between servicing policy, workshop capacity and dispatch rules in relation to fleet profitability whilst accounting for variability in weather and roads. The main simplification is that it models one depot with identical trucks and generic parts. A real operator has multiple depots, mixed-age vehicles, component-specific spares, and demand that varies with season.
+
+## Semiconductor wafer fabrication
+
+A semiconductor foundry processes batches of wafers (wafer lots) through 28 steps using shared machines. The same machine group handles multiple steps in the sequence, for example the same lithography group is visited at layers 0, 4, 9, 12, 16, 20, and 24, so wafer lots at different stages compete for the same machines.
+
+The main trade-off is between throughput and yield. Machines degrade as they work, but taking one offline for maintenance backs up the production. Deferring maintenance increases the risk for breakdown or slow accumulation of defects that only becomes visible at final inspection.
+
+For this use case we modelled 16 chambers across 4 machine groups (4 lithography, 6 etch, 4 deposition, 2 inspection), 3 product types (logic, memory, analog) arriving stochastically, a capacity limit of 50 lots in progress, and 3 technicians shared between planned and unplanned work.
+
+Each lot token carries its product type, current layer, cumulative defects, age, and a customer due date. Each machine token holds data on its condition, particle count, hours since maintenance, machine group, qualification level, and batch counter. The degradation mechanisms use the following SDCPN features:
+
+- **Machine degradation is modelled as continuous dynamics**, rising at a fixed rate while processing. When the machine crosses a threshold (default 0.85) it triggers preventive maintenance. The breakdown rate grows exponentially with condition, so a machine at 0.9 fails 8 times faster than a fresh one.
+
+- **Microscopic particle contamination as stochastic dynamics.** Contamination fluctuates randomly but trends upward the longer a machine runs without maintenance.
+
+- **Per-chamber process drift as stochastic dynamics.** Each chamber's process accuracy varies independently via a second diffusion process. Drift in either direction from zero increases defect rates. Maintenance recalibrates the chamber, but calibration is imperfect and each reset samples a small residual error. This means two chambers on the same tool can produce different defect rates even at identical condition and particle levels.
+
+- **Defects at each step are sampled from a distribution** whose mean depends on the machine’s current condition, its particle count and process drift. A clean, well-calibrated chamber deposits few defects; a degraded, contaminated or drifted chamber deposits many. Defects accumulate across all 28 layers but the number of defects is only checked at final inspection.
+
+To model the dispatch mechanism as close to the real world fabrications as possible, the net enforces all four of the below constraints simultaneously:
+
+- **Machine-specific qualification.** Not every machine can run every product. Each machine carries a bitmask encoding which product types it is certified for.
+
+- **Chamber-level recipes.** Processing time depends on the product being made. For example, a furnace step takes 5 hours at baseline; analog lots take 15% longer, memory lots 15% shorter. The same applies to lithography and etch steps.
+
+- **Batch processing for furnaces.** Furnace steps require loading multiple lots before the machine fires. Lots destined for a furnace layer enter a batch queue. In the model the furnace only starts when the batch reaches 4 lots, or after 3 hours if fewer are available.
+
+- **Dynamic priority from customer due dates.** Each lot arrives with a due date. Priority is recalculated every 2 hours based on remaining time to deadline. A lot close to its due date is dispatched ahead of a lot with time in hand. Lots that exceed their due date by 30 hours trigger a deadline renegotiation, and the due date extends by one full cycle time and priority resets, representing the real-world practice of agreeing a new delivery window with the customer.
+
+The model can help fabrication managers understand the interaction between maintenance policy,chamber calibration, batch sizing and in progress capacity in relation to yield and on-time delivery. The main simplifications are that each chamber processes one lot at a time and lots cannot be split for partial rework (lot-splitting). This means the model's absolute throughput figures are lower than a real foundry's , but relative comparisons between scenarios remain valid because all scenarios share the same simplification. Modelling lot-splitting would reduce the cost of contamination events by allowing partial recovery as a secondary effect, but does not change the fundamental question of when to maintain.
+
+## Why SDCPNs?
+
+Running a simulation shows what happened under specific conditions. It does not show what happens under the conditions you did not test. A Petri net offers two kinds of claims beyond that.
+
+### Structural guarantees
+
+These come from the net's topology, arc weights and connections:
+
+- **Reachability**. Can the system ever reach a specific state? For example: "is there any sequence of events that results in the tank being empty with no order on its way?" The check works by building the full graph of every state the net can reach from its starting state by firing every enabled transition and recording each new state. If the target state appears in that graph, it is reachable. If it does not appear , it is proven unreachable from the given starting state regardless of timing or ordering.
+
+- **Boundedness**. For any place in the net, you can determine the highest number of tokens it can ever hold by scanning every state in the full state graph and recording the maximum token count seen at each place. If the graph is finite, that maximum is the proven bound and can never be exceeded in any execution. If the graph cannot be completed (because some place grows without limit), the net is unbounded at that place, which usually signals a modelling error or a missing constraint. Conservation is a special case, where if a set of places always sums to the same total (e.g. items in storage \+ items in transit \= total inventory), then each place in that set is bounded
+
+- **Liveness**. Can every transition fire at least once? A transition that never appears in the state graph is dead, either from a modelling error or a mechanism that is unreachable by design. Deadlock is the extreme case: no transition can fire and the system freezes.
+
+These checks require a finite state space. Once tokens carry real-valued data (continuous levels, pressures, temperatures), the state graph cannot be exhaustively checked and these proofs do not apply directly. Extending formal guarantees to models with continuous state and stochastic dynamics is an open research problem, and one of the reasons the ARIA Safeguarded AI programme is investing in this formalism.
+
+### Probabilistic claims
+
+Once the model includes randomness, it produces distributions rather than single answers. An SDCPN produces probabilistic results differently from a conventional simulator in two ways:
+
+- **The randomness is formal and inspectable.** Firing rates, lognormal durations, diffusion terms etc. are explicit components of the model specification. They can be inspected so a reviewer can read exactly what distribution governs each event. In a conventional simulator, stochastic behaviour typically lives in code scattered across event handlers.
+
+- **Rare-event probabilities can be quantified.** Some failures are too rare to observe in ordinary Monte Carlo, estimating a probability of 10⁻⁹ would need billions of runs. SDCPNs support acceleration methods ([importance sampling](https://doi.org/10.1109/acc.2011.5991305), [interacting particle systems](https://doi.org/10.1201/9781420008548.ch10)) that exploit the net's structure (strong Markov property) to estimate these probabilities efficiently.
+
+# Conclusion
+
+This post applied SDCPNs to model three domains: industrial gas supply, truck fleet maintenance and semiconductor fabrication. We explored what each feature from the formalism adds, where by:
+
+- A plain Petri net finds logical and structural failures like deadlocks
+
+- Stochastic firing adds timing, so the model can quantify how often events like stockouts occur.
+
+- Colour makes identity visible so fleet composition or product routing can be modelled.
+
+- Continuous dynamics replace discrete approximations with differential equations for flows like gas levels, machine degradation and contamination.
+
+- Stochastic dynamics helps to add the necessary real world noise, like environmental variability to the model.
+
+What makes the formalism worth the added complexity is not that it can represent these interactions, but that it can quantify the frequency, costs and conditions that trigger them. When the controller is an AI making real-time decisions over a physical system, that quantification is what separates a deployment backed by evidence, and eventually verification, from one backed by assumption.
diff --git a/libs/@hashintel/brunch-agent/docs/reference/SDCPN Library - Ideas.md b/libs/@hashintel/brunch-agent/docs/reference/SDCPN Library - Ideas.md
new file mode 100644
index 00000000000..0d0de03d8ed
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/SDCPN Library - Ideas.md	
@@ -0,0 +1,456 @@
+|     | Domain                                   | Physical system           | Cyber component     | Pros                                              | Cons |
+| --- | :--------------------------------------- | :------------------------ | :------------------ | :------------------------------------------------ | :--- |
+| 1   | **Data Center Operation**                | Electricity flow, cooling |                     | Commercial                                        |      |
+| 2   | **Outpatient Care**                      |                           |                     | NHS opportunity/Dora’s partner; Human-centric CPS |      |
+| 3   | **Warehouse Automation**                 | Robots, shelves, packages | Task allocation     | Easy to visualize, 3D                             |      |
+| 4   | **Air Defence System**                   | Aircraft trajectories     | Air traffic control | Safety-critical concurrency                       |      |
+| 5   | **Intelligent Cellular Network**         |                           |                     |                                                   |      |
+| 6   | **Truck Fleet Predictive Maintenance**   |                           |                     |                                                   |      |
+| 7   | **Production Scheduling _Optimization_** |                           |                     |                                                   |      |
+| 8   | **Stock Replenishment _Optimization_**   |                           |                     |                                                   |      |
+
+Notes on each pasted from ChatGPT:
+
+# Car/Truck Fleet Predictive Maintenance
+
+Imagine a logistics company operating hundreds or thousands of delivery vans and trucks. Each vehicle continuously reports its condition, enabling maintenance to be scheduled before failures occur while minimizing disruption to deliveries.
+
+### Physical layer
+
+- Fleet vehicles (cars, vans, trucks)
+- Engines and drivetrains
+- Braking systems
+- Tyres
+- Batteries (electric or conventional)
+- Maintenance depots and repair facilities
+- Road network and operating environments
+
+### Cyber layer
+
+- Vehicle telematics
+- On-board diagnostics (OBD)
+- Predictive maintenance algorithms
+- Fleet management system
+- Maintenance scheduling
+- Route optimization
+- Parts inventory management
+- Driver reporting system
+
+### Events
+
+- Vehicle begins journey
+- Engine fault code detected
+- Brake wear threshold exceeded
+- Tyre pressure warning issued
+- Vehicle returns to depot
+- Maintenance scheduled
+- Replacement part unavailable
+- Unexpected component failure
+- Vehicle removed from service
+- Maintenance completed
+
+### Continuous state
+
+- Engine temperature
+- Oil condition
+- Battery state of health
+- Brake pad wear
+- Tyre tread depth and pressure
+- Fuel or battery consumption
+- Vehicle mileage
+- Component vibration
+- Predicted remaining useful life (RUL)
+
+### Interesting emergent behaviour
+
+- Vehicles operating on rough roads experience accelerated suspension and tyre wear compared with identical vehicles on urban routes.
+- A delivery vehicle develops abnormal vibration patterns, allowing bearing failure to be predicted weeks before a breakdown occurs.
+- Multiple vehicles require servicing simultaneously, forcing maintenance schedules to balance workshop capacity against delivery commitments.
+- Delaying maintenance on low-priority vehicles increases the probability of roadside failures, while performing maintenance too early wastes component life.
+- A shortage of replacement parts requires the fleet manager to dynamically reprioritize maintenance across the fleet.
+- Seasonal demand peaks reduce opportunities for maintenance, increasing operational risk until workloads decrease.
+- Real-time vehicle health data enables routes to be reassigned, preventing vehicles with emerging faults from being stranded far from maintenance facilities.
+
+This demonstrates:
+
+- continuous degradation of physical assets
+- condition-based and predictive maintenance
+- data-driven decision making
+- optimization under resource constraints
+- interaction between operational planning and maintenance scheduling
+- uncertainty in component failures
+- concurrent management of large vehicle fleets
+
+---
+
+This example is particularly effective because it combines physics (component wear and degradation), real-time sensing, predictive analytics, and operational decision-making. The cyber system must continuously estimate each vehicle's health, predict future failures, and coordinate maintenance without unnecessarily disrupting fleet operations. It showcases SDCPNs' ability to model systems where continuous degradation, stochastic failures, resource allocation, and logistics interact over long time horizons.
+
+# Intelligent Cellular Network
+
+Imagine a mobile network operator dynamically adapting its cellular infrastructure to meet changing demand as people move throughout a city. Cell towers are powered up, placed into low-power modes, or reconfigured in anticipation of demand, balancing quality of service against energy consumption.
+
+### Physical layer
+
+- Cellular base stations (macro cells and small cells)
+- User devices (phones, tablets, IoT devices)
+- Radio coverage areas
+- Data traffic over wireless channels
+- Electrical power supplied to base stations
+- Geographic distribution of users (homes, offices, transport hubs, stadiums)
+
+### Cyber layer
+
+- Network management and orchestration
+- Traffic demand forecasting
+- Mobility prediction
+- Load balancing
+- Cell activation/deactivation controller
+- Handover management
+- Energy optimization algorithms
+- Network performance monitoring
+
+### Events
+
+- Morning commute begins
+- Large public event starts
+- Train arrives at a station
+- Cell becomes overloaded
+- Additional cell activated
+- Cell enters sleep mode
+- Network fault detected
+- Backhaul link failure
+- Emergency demand surge
+- Major event concludes
+
+### Continuous state
+
+- Number and distribution of connected users
+- Data throughput
+- Cell utilization
+- Signal strength and interference
+- Base station power consumption
+- Network latency
+- User mobility patterns
+- Predicted traffic demand
+
+### Interesting emergent behaviour
+
+- Morning commuters create a moving corridor of high network demand, with capacity progressively shifting from residential areas to business districts.
+- A football match or concert causes thousands of users to concentrate within a single coverage area, requiring dormant small cells to be activated before congestion occurs.
+- As office workers leave for the evening, traffic shifts back toward residential suburbs, allowing underutilized city-centre base stations to enter low-power sleep modes.
+- An unexpected incident (such as severe weather or public transport disruption) causes large deviations from predicted movement patterns, forcing rapid network reconfiguration.
+- A base station failure causes neighbouring cells to expand their coverage, increasing load and triggering further adaptive resource allocation.
+- Temporary communication failures between controllers lead to localized optimization decisions that must later be reconciled across the wider network.
+
+This demonstrates:
+
+- human mobility driving physical system dynamics
+- predictive decision making under uncertainty
+- distributed resource allocation
+- continuous demand estimation
+- adaptive infrastructure management
+- energy-performance trade-offs
+- large-scale concurrent operation
+- resilience to failures and unexpected events
+
+---
+
+This is a particularly compelling SDCPN example because it couples human behaviour, communication infrastructure, continuous traffic dynamics, and discrete control decisions. Unlike many CPS examples where the physical dynamics arise from machines or vehicles, here the driving force is the stochastic movement and behaviour of large populations, making it an excellent demonstration that SDCPNs can model systems where cyber decisions adapt continuously to changing human activity. It also illustrates an important optimisation objective that is easy for a non-technical audience to grasp: _providing enough network capacity where and when people need it, while minimizing the energy consumed by thousands of cell towers._
+
+# Autonomous Warehouse
+
+Imagine a fully automated fulfilment centre where robots retrieve products, conveyors transport packages, and software coordinates thousands of simultaneous tasks.
+
+### Physical layer
+
+- Mobile robots
+- Conveyor belts
+- Storage shelves
+- Packing stations
+- Charging docks
+- Inventory
+- Human maintenance staff
+
+### Cyber layer
+
+- Warehouse management system
+- Inventory database
+- Robot fleet scheduler
+- Route planner
+- Task allocation
+- Collision avoidance
+- Predictive maintenance
+
+### Events
+
+- Customer order received
+- Robot assigned task
+- Package picked
+- Conveyor jam detected
+- Robot battery low
+- Charging dock becomes available
+- Inventory replenished
+- Equipment failure
+
+### Continuous state
+
+- Robot position and velocity
+- Battery charge
+- Queue lengths
+- Conveyor speed
+- Inventory levels
+- Order completion times
+
+### Interesting emergent behaviour
+
+- Several robots converge on the same aisle, creating congestion.
+- Charging stations become a bottleneck during peak demand.
+- A conveyor failure causes robots to dynamically redistribute work.
+- High-priority orders interrupt normal scheduling.
+- Inventory shortages require alternative fulfilment strategies.
+- Robot failures trigger automatic task reassignment to maintain throughput.
+
+This demonstrates:
+
+- multi-agent coordination
+- continuous robot motion
+- concurrent task execution
+- dynamic scheduling
+- resource contention
+- fault-tolerant operation
+
+# Smart Hospital (ChatGPT-original, superseded by Outpatient Care)
+
+Imagine a large hospital where patients, staff, medical equipment, and digital systems continuously coordinate to deliver care.
+
+### Physical layer
+
+- Patients
+- Doctors and nurses
+- Ambulances
+- ICU beds
+- Operating theatres
+- Medical equipment
+- Pharmacy inventory
+
+### Cyber layer
+
+- Electronic health records
+- Patient monitoring systems
+- Triage decision support
+- Operating theatre scheduling
+- Bed management
+- Medication dispensing
+- Hospital communications
+
+### Events
+
+- Patient admitted
+- Emergency ambulance arrives
+- Surgery completed
+- ICU bed becomes available
+- Laboratory result received
+- Medical device failure
+- Patient deterioration detected
+- Staff shift changes
+
+### Continuous state
+
+- Heart rate
+- Blood pressure
+- Oxygen saturation
+- Medication concentration
+- Bed occupancy
+- Waiting times
+- Staff workload
+
+### Interesting emergent behaviour
+
+- Multiple emergency patients arrive simultaneously.
+- ICU capacity becomes exhausted.
+- A ventilator failure requires rapid patient transfer.
+- Delayed laboratory results postpone treatment.
+- Staff shortages increase waiting times across multiple departments.
+- Hospital systems reprioritize surgeries following a major incident.
+
+This demonstrates:
+
+- human-in-the-loop decision making
+- stochastic arrivals
+- resource allocation
+- interacting workflows
+- safety-critical monitoring
+- adaptive scheduling
+
+# Smart Power Grid
+
+Imagine a modern electrical grid integrating renewable generation, battery storage, conventional power plants, and millions of intelligent consumers.
+
+### Physical layer
+
+- Transmission and distribution lines
+- Solar farms
+- Wind turbines
+- Conventional generators
+- Battery energy storage systems
+- Consumer and industrial loads
+
+### Cyber layer
+
+- Grid monitoring (SCADA)
+- State estimation
+- Demand forecasting
+- Generation scheduling
+- Automatic protection systems
+- Distributed energy management
+- Market and pricing systems
+
+### Events
+
+- Sudden increase in electricity demand
+- Renewable generation drops unexpectedly
+- Transmission line fault
+- Generator trips offline
+- Battery storage activated
+- Protective relay disconnects equipment
+- Demand-response programme initiated
+- Cyber communication failure
+
+### Continuous state
+
+- Power flow
+- Voltage
+- Frequency
+- Generator output
+- Battery state of charge
+- Consumer demand
+
+### Interesting emergent behaviour
+
+- Cloud cover causes a rapid reduction in solar generation.
+- Batteries coordinate to stabilize frequency.
+- Multiple faults isolate part of the network.
+- Demand-response reduces peak loading without interrupting service.
+- Communication delays cause distributed controllers to make conflicting decisions.
+- Equipment failures propagate into cascading outages unless protective systems intervene.
+
+This demonstrates:
+
+- hybrid physical dynamics
+- distributed optimization
+- fault detection and recovery
+- concurrent infrastructure operation
+- stochastic renewable generation
+- resilience under failures
+
+# Autonomous Vehicle Fleet
+
+Imagine a city-wide fleet of autonomous taxis transporting passengers while coordinating with one another and the surrounding transport infrastructure.
+
+### Physical layer
+
+- Vehicle motion (position, speed, acceleration)
+- Road network and intersections
+- Traffic flow
+- Pedestrians and cyclists
+- Battery charge and charging stations
+- Weather and road conditions
+
+### Cyber layer
+
+- Vehicle perception (camera, lidar, radar)
+- Localization and mapping
+- Route planning
+- Collision avoidance
+- Fleet management system
+- Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication
+
+### Events
+
+- Passenger requests ride
+- Obstacle detected
+- Traffic accident reported
+- Charging station becomes available
+- Vehicle enters autonomous/manual mode
+- Sensor fault detected
+- Communication link lost
+- Emergency vehicle approaches
+
+### Continuous state
+
+- Vehicle position and velocity
+- Battery state of charge
+- Sensor confidence
+- Traffic density
+- Estimated arrival times
+
+### Interesting emergent behaviour
+
+- Several vehicles compete for the same charging station.
+- Traffic congestion causes fleet-wide rerouting.
+- Sensor degradation forces reduced-speed operation.
+- Temporary communication loss causes vehicles to operate independently.
+- Road closures trigger dynamic replanning across the fleet.
+- Emergency vehicles receive priority through coordinated routing.
+
+This demonstrates:
+
+- continuous vehicle dynamics
+- distributed decision making
+- probabilistic perception
+- adaptive planning
+- networked coordination
+- resource allocation
+
+# Air Defence Network
+
+Imagine defending a city or military base from multiple incoming aircraft or drones.
+
+### Physical layer
+
+- Aircraft and drone trajectories
+- Radar line-of-sight
+- Missile or interceptor flight
+- Weather affecting sensors
+
+### Cyber layer
+
+- Radar processing
+- Target tracking
+- Threat classification
+- Interceptor assignment
+- Communication between radar sites
+- Human authorization
+
+### Events
+
+- Radar detects object
+- Target disappears
+- Sensor failure
+- Communication outage
+- Interceptor launched
+- Target intercepted
+
+### Continuous state
+
+- Position
+- Velocity
+- Fuel
+- Radar confidence
+
+### Interesting emergent behaviour
+
+- Two radars disagree.
+- Communications fail.
+- Several drones appear simultaneously.
+- Resources become exhausted.
+- A false alarm wastes an interceptor.
+- Human approval delays engagement.
+
+This demonstrates:
+
+- distributed sensing
+- decision fusion
+- probabilistic uncertainty
+- real-time control
+- human-in-the-loop decisions
diff --git a/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md b/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md
new file mode 100644
index 00000000000..4fb02053eb5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md
@@ -0,0 +1,553 @@
+# Agentic Elicitation Challenges
+
+- Source: chatgpt
+- URL: https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678
+- Exported: 2026-08-06T10:02:41.982Z
+- Format: XML-style turn markers with raw markdown bodies
+
+<turn index="001" role="user" url="https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678">
+
+Some thoughts on agentic elicitation and capture of unstructured content from a user, in to some kind of structured representation:
+
+- common thread: **parsing and mapping** of content
+- parsing: seeing and identifying — possibly through different lenses?
+- mapping: projecting and matching — against a schema, or rubric, criteria?
+- requires:
+  - knowing what to look for / how to look
+  - knowing what you are trying to fulfill / satisfy
+
+Help me reflect on how to approach this implementation challenge effectively. The levers I have are those such as provided by any contemporary agent harness. The actual target, in terms of (A) what kind of thing(s) are we eliciting, and (B) in what structure(s) to we intend to record them, needs to be swappable
+
+</turn>
+
+<turn index="001" role="assistant" url="https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678">
+
+Your parsing/mapping distinction is useful, but it becomes substantially more tractable if neither step writes directly into the final target structure.
+
+The core abstraction should be:
+
+> **Unstructured content → evidence-linked interpretations → target-specific projections**
+
+That middle layer lets you vary both:
+
+- **A: the semantic target** — requirements, preferences, risks, events, decisions, entities, arguments, and so on.
+- **B: the representation target** — a form, JSON schema, graph, CRM record, issue tracker object, document section, or several of these simultaneously.
+
+## 1. Treat the system as an interactive compiler
+
+A useful analogy is a compiler with interactive error recovery:
+
+```text
+User conversation
+      │
+      ▼
+Segmentation and observation
+      │
+      ▼
+Semantic intermediate representation
+      │
+      ├──────────────► Target-schema projector
+      │                         │
+      │                         ▼
+      │                  Structured record
+      │
+      ▼
+Gap and conflict analysis
+      │
+      ▼
+Clarification question
+      │
+      └──────────────► back into the semantic state
+```
+
+In this analogy:
+
+- **Parsing** detects potentially meaningful content and anchors it to evidence.
+- **Semantic analysis** decides what that content means, including modality, scope, and relationships.
+- **Mapping** projects that meaning into a particular destination structure.
+- **Validation** acts like type checking.
+- **Elicitation** is error recovery: asking the user for information needed to resolve an ambiguity, contradiction, or missing requirement.
+
+This avoids the brittle pattern:
+
+```text
+conversation → one large prompt → final JSON
+```
+
+That pattern couples recognition, interpretation, completeness, and serialization into a single operation.
+
+## 2. Separate four contracts
+
+A schema alone is not enough to tell the agent what to do. I would represent the task through four independently versioned contracts.
+
+### Concept contract: what counts as the thing
+
+This defines the semantic target:
+
+- What kinds of objects or propositions are relevant?
+- What distinguishes an instance from a near miss?
+- What attributes and relations matter?
+- What are examples and counterexamples?
+- What kinds of inference are permitted?
+
+For a “risk,” for example, the concept contract might distinguish:
+
+- a present problem,
+- a possible future adverse event,
+- a constraint,
+- a dependency,
+- and a vague expression of concern.
+
+These may all resemble one another linguistically but have different semantics.
+
+### Observation contract: how to notice it
+
+This defines the lenses through which content is examined:
+
+- actor/action/object,
+- temporal information,
+- obligations and permissions,
+- preference versus hard constraint,
+- causality,
+- risk and uncertainty,
+- corrections and negations,
+- entity identity and coreference.
+
+A lens should generate **candidate observations**, not directly populate fields. Multiple lenses may notice different aspects of the same passage.
+
+For example:
+
+> “Friday would be ideal, but Monday is okay. Don’t schedule anything before ten.”
+
+Different lenses might produce:
+
+- a preferred date,
+- an acceptable fallback date,
+- a hard time constraint,
+- a distinction between preference and obligation.
+
+A direct mapping into a single `date` field would discard important meaning.
+
+### Completion contract: what “enough” means
+
+This is separate from both recognition and storage.
+
+It determines:
+
+- which concepts are required,
+- acceptable cardinality,
+- acceptable uncertainty,
+- which conflicts must be resolved,
+- which missing values may be defaulted,
+- when the agent should stop asking questions.
+
+There are actually two kinds of completeness:
+
+1. **Semantic completeness**: enough information to understand the thing correctly.
+2. **Representation completeness**: enough information to satisfy a particular downstream schema.
+
+Those should remain distinguishable. A CRM may require a category code that the user never expressed. That is a property of the sink, not necessarily a property of the user’s underlying intent.
+
+### Projection contract: how meaning is represented
+
+This defines:
+
+- output schema,
+- field semantics,
+- mapping functions,
+- normalization rules,
+- required fields,
+- merge behavior,
+- target-specific validators,
+- treatment of unsupported or lossy content.
+
+A projection operation should preferably declare what kind of operation it performs:
+
+- literal copy,
+- normalization,
+- classification,
+- aggregation,
+- decomposition,
+- inference,
+- composition,
+- defaulting.
+
+Inference and defaulting should be explicitly distinguishable from user-stated information.
+
+## 3. Use an evidence-preserving intermediate representation
+
+The key to swappability is a semantic intermediate representation, or IR.
+
+It should be richer than any one destination schema but much smaller than a universal ontology. A good pattern is a **thin common core with domain-specific payloads**.
+
+For example:
+
+```json
+{
+  "id": "claim-17",
+  "kind": "constraint",
+  "payload": {
+    "relation": "start_time_not_before",
+    "value": "10:00",
+    "scope": "scheduling"
+  },
+  "epistemic_status": "explicit",
+  "modality": "must",
+  "evidence": [
+    {
+      "turn_id": "turn-8",
+      "text": "Don't schedule anything before ten."
+    }
+  ],
+  "confidence": "high",
+  "alternatives": [],
+  "status": "active"
+}
+```
+
+The important parts are not the exact field names. They are the distinctions the model preserves:
+
+- what was said,
+- where it was said,
+- what interpretation was assigned,
+- whether it was explicit or inferred,
+- how certain the interpretation is,
+- whether alternatives remain,
+- whether later content corrected or contradicted it.
+
+For more relational targets, represent the IR as a claim graph:
+
+```text
+Actor ──owns──► Work item
+Work item ──blocked_by──► Legal approval
+Work item ──has_deadline──► Ambiguous quarter end
+Legal approval ──concerns──► Data-retention policy
+```
+
+The IR should be an interface between stages, not an attempt to create one ontology for every possible application.
+
+## 4. Make parsing hypothesis-generating rather than decisive
+
+“Parsing” is doing several different jobs:
+
+1. **Segmentation**
+   Identify spans, clauses, discourse boundaries, quotations, lists, and references.
+
+2. **Candidate detection**
+   Notice that a span might express a relevant concept.
+
+3. **Interpretation**
+   Assign semantic type, scope, modality, polarity, temporality, and participants.
+
+4. **Evidence anchoring**
+   Preserve the exact source that supports the interpretation.
+
+The output should initially be hypotheses such as:
+
+```text
+Possible deadline:
+  value: quarter-end
+  ambiguity: quarter and year unspecified
+  evidence: "before quarter-end"
+
+Possible owner:
+  value: Priya
+  modality: proposed rather than confirmed
+  evidence: "Priya can own it"
+```
+
+A reconciliation stage can then merge overlapping observations, resolve coreference, recognize corrections, and maintain competing interpretations where necessary.
+
+This matters because repeated model calls do not necessarily resolve semantic ambiguity. A formatting failure should trigger a retry. A genuine ambiguity should become an explicit issue or user question.
+
+## 5. Let projection create backpressure without controlling semantics
+
+A swappable output target may discover that it cannot produce a valid record from the current semantic state.
+
+For example, a projector might report:
+
+```json
+{
+  "issue": "missing_required_value",
+  "origin": "projection",
+  "target": "jira_issue",
+  "required_concept": "project_key",
+  "can_default": false,
+  "needs_user_input": true
+}
+```
+
+The projector should not directly ask the user. It should return a typed issue to the elicitation controller.
+
+That controller can then decide whether to:
+
+- ask the user,
+- derive the value from context,
+- call a lookup tool,
+- use a declared default,
+- leave it unresolved,
+- or reject the projection.
+
+This gives the representation layer controlled influence over elicitation without tightly coupling the two.
+
+A useful issue vocabulary is:
+
+```text
+missing
+ambiguous
+conflicting
+invalid
+unsupported
+unmapped
+low-confidence
+```
+
+Each issue should record whether it originated in the semantic target or a particular representation target.
+
+## 6. Put the “agentic” behavior in selection and control
+
+Most extraction and mapping steps can be structured pipeline operations. The agentic part is primarily deciding:
+
+- which lenses are relevant,
+- which observations deserve deeper analysis,
+- which ambiguity is worth resolving,
+- which tool to invoke,
+- what to ask next,
+- and when to stop.
+
+The next-question policy can be thought of as maximizing expected information value:
+
+```text
+priority =
+    requiredness
+  × downstream impact
+  × current uncertainty
+  × likelihood the user can answer
+  ÷ interaction cost
+```
+
+This prevents the system from mechanically asking for every empty field.
+
+Good clarification behavior generally means:
+
+- ask about ambiguities that materially affect the result;
+- prefer one high-value question over several low-value questions;
+- ask in the user’s language, not in schema terminology;
+- make the current interpretation visible when correction is useful;
+- distinguish “not mentioned” from “no,” “unknown,” and “not applicable”;
+- stop when additional precision has low downstream value.
+
+A question such as:
+
+> “You mentioned quarter-end. Which quarter and year should I record?”
+
+is better than:
+
+> “Please provide `deadline_date`.”
+
+## 7. Package the variable parts
+
+A practical modularization might look like this:
+
+```text
+ElicitationPack
+  concept definitions
+  examples and counterexamples
+  eligible lenses
+  permitted inference rules
+  semantic completeness rules
+  clarification hints
+
+ProjectionPack
+  target schema
+  mapping functions
+  normalizers
+  target validators
+  merge and default policies
+
+DialoguePolicy
+  issue prioritization
+  question budget
+  confirmation thresholds
+  stop conditions
+
+RuntimeState
+  raw turns
+  observations
+  claim graph
+  unresolved issues
+  active projections
+  revision history
+```
+
+The stable interfaces could be:
+
+```text
+observe(content, elicitation_pack) -> Observation[]
+
+reconcile(
+    prior_claims,
+    observations
+) -> ClaimGraph
+
+project(
+    claim_graph,
+    projection_pack
+) -> DraftRecord + ProjectionIssues
+
+validate(
+    claim_graph,
+    draft_record,
+    elicitation_pack,
+    projection_pack
+) -> Issue[]
+
+choose_next_action(
+    issues,
+    dialogue_policy
+) -> Question | ToolCall | Complete
+```
+
+With this arrangement:
+
+- Changing **A** swaps the elicitation pack and potentially reruns observation over the retained source.
+- Changing **B** swaps the projection pack and reprojects the existing claim graph.
+- Multiple **B** targets can operate simultaneously.
+- A new target structure does not require rewriting all extraction behavior.
+- A new semantic target does not require redesigning the orchestration runtime.
+
+## 8. Use the agent harness as a typed state machine
+
+The useful harness capabilities map naturally to this design.
+
+| Harness capability      | Appropriate use                                                        |
+| ----------------------- | ---------------------------------------------------------------------- |
+| Structured model output | Observation, claim, issue, and question contracts                      |
+| State graph             | Explicit observe → reconcile → project → validate → ask transitions    |
+| Tool calling            | Lookups, normalization, deterministic validation, identity resolution  |
+| Model routing           | Cheap model for detection; stronger model for difficult reconciliation |
+| Parallel execution      | Independent lenses over the same content                               |
+| Checkpointing           | Durable claim state and resumable conversations                        |
+| Human-in-the-loop       | Clarification, confirmation, and correction                            |
+| Tracing                 | Evidence, transformations, model decisions, and validator output       |
+| Retries                 | Malformed output and transient failures, not genuine uncertainty       |
+| Evals                   | Regression testing at each pipeline boundary                           |
+
+A graph of narrowly typed stages is usually easier to reason about than a set of autonomous agents exchanging prose. Multiple agents are most justified when they need genuinely independent perspectives, different permissions, separate context, or adversarial review.
+
+## 9. Preserve distinctions that are commonly lost
+
+Several distinctions should be first-class because they strongly affect mapping:
+
+- explicit statement versus inference,
+- preference versus requirement,
+- current fact versus future intention,
+- entity versus role,
+- proposed assignment versus confirmed assignment,
+- absence of evidence versus negative evidence,
+- correction versus contradiction,
+- recurring condition versus one-time event,
+- exact value versus approximate value,
+- source content versus system-generated default.
+
+The system should also retain information that is relevant but currently unmapped. Otherwise, changing the destination schema later will require re-eliciting it.
+
+A projection can be intentionally lossy, but it should produce a warning such as:
+
+```text
+The target schema supports one date only.
+The semantic state contains:
+- preferred date: Friday
+- acceptable fallback: Monday
+Projection policy selected Friday and omitted the fallback.
+```
+
+## 10. Evaluate the stages separately
+
+End-to-end accuracy alone will not tell you where the system is failing.
+
+Useful evaluation categories include:
+
+### Observation quality
+
+- concept-level recall,
+- false-positive rate,
+- evidence-span accuracy,
+- handling of negation and correction,
+- modality classification.
+
+### Reconciliation quality
+
+- duplicate merging,
+- entity resolution,
+- conflict preservation,
+- temporal ordering,
+- revision handling.
+
+### Projection quality
+
+- schema validity,
+- semantic correctness,
+- unsupported-content detection,
+- correct default and inference labeling,
+- consistency across multiple projections.
+
+### Elicitation quality
+
+- required information obtained,
+- number of questions,
+- information gained per question,
+- unnecessary-question rate,
+- user correction rate,
+- premature stopping rate.
+
+A particularly valuable test is **reprojection consistency**: capture once into the IR, project into two different target schemas, and verify that both preserve the same underlying semantics.
+
+## 11. Avoid several common implementation traps
+
+The main traps are:
+
+1. **Using the output schema as the semantic specification**
+   Field names rarely define what counts as valid evidence.
+
+2. **Premature normalization**
+   Converting “the end of next quarter” into a date before resolving context can silently invent information.
+
+3. **Silent inference**
+   A plausible value should not become indistinguishable from a user assertion.
+
+4. **Over-generalizing the IR**
+   A universal ontology often becomes less useful than a small claim/evidence core with domain extensions.
+
+5. **Treating all missing fields equally**
+   Some are essential to meaning; others are merely required by a sink.
+
+6. **Using another model call as the only validator**
+   Structural constraints, date validity, enum membership, and many consistency checks should be deterministic.
+
+7. **Discarding source evidence after capture**
+   Without provenance, correction, audit, and future reprojection become difficult.
+
+## 12. A sensible initial implementation
+
+A good first system would be deliberately small:
+
+- one claim/evidence IR;
+- four or five issue types;
+- three lenses, such as entity/action, temporal, and modality/constraint;
+- one reconciliation stage;
+- two materially different elicitation packs;
+- two materially different projection packs;
+- one question-selection policy;
+- deterministic schema and consistency validation;
+- complete tracing of every transformation.
+
+Using two targets on each axis from the beginning is important. It forces the abstractions to demonstrate actual swappability rather than merely appearing configurable.
+
+The governing design principle is:
+
+> **Capture meaning and evidence before committing to representation. Let semantic requirements and destination requirements both generate issues, but keep their origins explicit.**
+
+That makes parsing a process of forming grounded hypotheses, mapping a controlled projection, and elicitation an information-seeking policy over unresolved semantic and representational obligations.
+
+</turn>
diff --git a/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md b/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md
new file mode 100644
index 00000000000..e716c9848f7
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md
@@ -0,0 +1,1134 @@
+# 2. Structural criteria
+
+- Source: chatgpt
+- URL: https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678
+- Exported: 2026-08-06T14:11:18.579Z
+- Format: XML-style turn markers with raw markdown bodies
+
+<turn index="002" role="user" url="https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678">
+
+In order to test how well this has been abstracted and generalized, and how well the plugin API has been designed to enable ease-of-implementation of elicitation flows against arbitrary goals/targets, what structural and/or semantic criteria would you apply? What kinds of smells would you look for?
+
+</turn>
+
+<turn index="002" role="assistant" url="https://chatgpt.com/c/6a7430db-490c-83eb-8491-ea376fd3f678">
+
+The strongest test is not whether the framework can technically load many plugins. A framework with a `run(context: any) -> any` hook is infinitely extensible in a trivial sense. The real test is whether different elicitation goals and representation targets can be introduced **without bypassing the semantic guarantees of the system**.
+
+A useful model is an hourglass:
+
+```text
+Many elicitation goals and lenses
+                │
+                ▼
+     Claims · Evidence · Issues
+       Revisions · State deltas
+                │
+                ▼
+Many schemas and representation targets
+```
+
+The waist should be narrow enough to remain stable, but semantically rich enough that the runtime can reason about provenance, uncertainty, conflicts, completeness, and projection loss. Two opposite failures are common:
+
+- The waist becomes a union of every domain concept ever introduced.
+- The waist becomes `type: string, payload: any`, leaving the runtime unable to enforce meaningful behavior.
+
+## 1. The main proof obligations
+
+I would judge the abstraction against five proof obligations.
+
+### Independent variability
+
+You should be able to change:
+
+- what is being elicited,
+- how completeness is judged,
+- how questions are selected,
+- how the result is represented,
+
+without unnecessarily changing the others.
+
+A particularly strong test is:
+
+> Can I add a new elicitation goal and project it into an existing target without changing the target plugin, and add a new target for an existing goal without changing the elicitation plugin?
+
+Some target-specific backpressure is legitimate. For example, a destination may require a project identifier. But that requirement should appear as a **target-originated issue**, not become part of the universal definition of the semantic object.
+
+### Semantic conservation
+
+Relevant distinctions in the source should survive until an explicit component decides to discard or normalize them.
+
+For example:
+
+```text
+“Friday is ideal, but Monday is acceptable.”
+```
+
+should not immediately become:
+
+```json
+{ "date": "Friday" }
+```
+
+The semantic state should preserve at least:
+
+```text
+preferred date: Friday
+acceptable fallback: Monday
+```
+
+A target that supports only one date can select Friday, but it should recognize that the projection is lossy.
+
+### Explicit transformation
+
+Every material transformation should be attributable:
+
+- user-stated,
+- inferred,
+- normalized,
+- classified,
+- aggregated,
+- defaulted,
+- omitted,
+- overridden.
+
+This is more important than preserving the exact original wording. The system should be able to explain why a target field has a value and what evidence supports it.
+
+### Controlled elicitation
+
+Plugins should contribute domain knowledge without independently taking over the conversation.
+
+A plugin may identify:
+
+```text
+Deadline is ambiguous because the quarter and year are unknown.
+```
+
+The runtime should decide:
+
+- whether this matters,
+- whether another source can resolve it,
+- whether to ask the user,
+- how to phrase the question,
+- and whether some higher-priority issue should be addressed first.
+
+Otherwise, composing plugins produces competing agents rather than one coherent elicitation flow.
+
+### Local implementation
+
+A plugin author should need to understand the domain contract and public SDK, not the internal orchestration graph, prompt assembly system, persistence layer, or retry logic.
+
+The implementation should be locally testable. A developer should be able to test:
+
+```text
+input semantic state
+→ plugin output
+```
+
+without running a full conversational agent.
+
+---
+
+# 2. Structural criteria
+
+## Core independence
+
+The runtime should contain no branches such as:
+
+```python
+if plugin.name == "requirements_capture":
+    ...
+elif plugin.name == "sales_qualification":
+    ...
+```
+
+Nor should its common enums continually grow with domain-specific concepts:
+
+```text
+REQUIREMENT
+SALES_LEAD
+MEDICAL_SYMPTOM
+DESIGN_GOAL
+...
+```
+
+The core should know about generic constructs such as claims, evidence, issues, revisions, actions, and projections. Domain-specific types should be registered or namespaced by plugins.
+
+A useful mechanical test is to inspect the core diff after adding a plugin. Within an existing extension category, the expected core diff should normally be zero.
+
+Zero core changes are not sufficient, however. A plugin that receives the entire runtime object and implements everything itself has merely escaped the abstraction.
+
+## Dependency direction
+
+Plugins should depend on public runtime contracts. The runtime should not depend on plugin implementation classes.
+
+Prefer:
+
+```text
+plugin receives immutable state snapshot
+plugin returns observations, issues, or state deltas
+runtime validates and applies them
+```
+
+over:
+
+```text
+plugin receives session/database/runtime
+plugin mutates arbitrary state directly
+```
+
+Declarative returns make validation, tracing, rollback, replay, and access control possible.
+
+## Orthogonal interfaces
+
+The API should not force a plugin to implement unrelated responsibilities.
+
+For example, these are distinct concerns:
+
+```text
+ObservationPlugin
+SemanticAssessmentPlugin
+ProjectionPlugin
+ValidationPlugin
+QuestionPolicyPlugin
+NormalizationPlugin
+```
+
+They do not necessarily need to be separate deployment packages, but they should be separate interfaces or capabilities. A plugin manifest can declare which capabilities it provides.
+
+A single required interface such as:
+
+```python
+run_conversation(...)
+```
+
+is too broad. Conversely, forty lifecycle hooks are likely to produce callback soup. The ideal surface consists of a small number of semantically meaningful operations.
+
+## Typed semantic contracts
+
+Inputs and outputs should have machine-checkable structure.
+
+For example:
+
+```text
+observe(turn, state) -> Observation[]
+
+assess(state) -> SemanticIssue[]
+
+project(state) -> ProjectionResult
+
+validate(record, state) -> ProjectionIssue[]
+
+propose_questions(issues, state) -> QuestionCandidate[]
+```
+
+Free-form explanatory text can accompany these objects, but should not be the sole integration mechanism.
+
+Particularly important types include:
+
+- issue origin,
+- issue severity,
+- evidence reference,
+- epistemic status,
+- revision operation,
+- mapping operation,
+- loss classification,
+- supported capability.
+
+## Stable identity and namespacing
+
+Claims, entities, evidence spans, issues, and plugin-defined concepts need durable identifiers.
+
+The API should define:
+
+- who creates identifiers,
+- how plugin namespaces work,
+- whether two plugins can refer to the same claim,
+- how duplicate observations are reconciled,
+- what happens when a plugin is removed,
+- how plugin-generated IDs survive replay.
+
+Without this, composition tends to rely on field names and execution order.
+
+## State ownership
+
+The runtime should own canonical conversational and semantic state. Plugins may maintain caches or indexes, but the authoritative meaning should not be hidden inside opaque plugin state.
+
+Opaque private state is dangerous when:
+
+- another plugin needs to consume the information,
+- the conversation is replayed,
+- a plugin version changes,
+- the system needs to explain a decision,
+- the plugin crashes or is removed.
+
+Plugin-specific state may be appropriate for implementation details, but not as the only representation of captured user meaning.
+
+## Idempotence and replay
+
+Calling a plugin twice on the same state should not create duplicate semantic facts or produce uncontrolled side effects.
+
+The system should support:
+
+```text
+raw event log
+→ replay observations
+→ rebuild semantic state
+→ regenerate projections
+```
+
+Purely deterministic replay may not be possible for every model call, but the runtime should at least preserve the original plugin outputs, model versions, prompts or prompt identifiers, and state transitions.
+
+A retry caused by malformed output should not accidentally count as a second user assertion.
+
+## Composition semantics
+
+The API should define what happens when two plugins:
+
+- identify the same concept,
+- assign different types to the same evidence,
+- make conflicting inferences,
+- require incompatible normalizations,
+- propose competing questions,
+- produce issues with different priorities.
+
+“Run all plugins and concatenate their output” is not a composition model.
+
+The runtime needs explicit merge and conflict behavior. Plugins should be able to express:
+
+```text
+supports
+refines
+contradicts
+supersedes
+possibly-equivalent-to
+```
+
+without being forced to resolve every disagreement themselves.
+
+## Capability negotiation
+
+Plugins should declare constraints such as:
+
+```text
+supported input kinds
+concepts produced or consumed
+incremental-processing support
+required tools
+external side effects
+supported languages
+supported core contract versions
+lossless versus lossy mapping
+required semantic features
+```
+
+This permits the runtime to reject invalid compositions before a conversation begins.
+
+For example, a projector that requires stable entity identity should not silently consume a state containing only anonymous text spans.
+
+## Versioning and migration
+
+A plugin API is not mature if its state cannot survive plugin evolution.
+
+You need to distinguish:
+
+- API contract version,
+- plugin implementation version,
+- plugin concept-schema version,
+- target-schema version,
+- persisted state version.
+
+A change to the meaning of a field is not merely a serializer change. The system should be able to determine whether existing state can be:
+
+- reused,
+- migrated mechanically,
+- reinterpreted from retained evidence,
+- or must be elicited again.
+
+---
+
+# 3. Semantic criteria
+
+## Evidence fidelity
+
+Every material claim should be linked to the content that supports it.
+
+The link should be precise enough to distinguish:
+
+- the sentence stating a fact,
+- the phrase supplying a value,
+- surrounding context that changes interpretation,
+- the later correction that supersedes it.
+
+A claim with only a conversation-level provenance marker is often insufficient.
+
+Test whether the system can answer:
+
+> What exact user content supports this value?
+
+and:
+
+> Which parts of this record are unsupported by direct user evidence?
+
+## Epistemic distinctions
+
+The representation should not collapse:
+
+```text
+explicit user statement
+reasonable inference
+tentative hypothesis
+system default
+external lookup
+plugin classification
+```
+
+A single floating-point `confidence` value does not solve this. Confidence is not the same as provenance or epistemic status.
+
+These statements must remain distinguishable:
+
+```text
+“Priya owns this.”
+“Priya could own this.”
+“I assume Priya owns this.”
+“The directory lists Priya as owner.”
+```
+
+They may all refer to the same relation, but they do not have the same evidential or modal force.
+
+## Polarity, modality, and preference
+
+Minimal semantic differences should not collapse into the same representation:
+
+```text
+Use Friday.
+Prefer Friday.
+Friday is acceptable.
+Friday is required.
+Do not use Friday.
+No later than Friday.
+Friday might work.
+```
+
+This is one of the best areas for minimal-pair tests because field-oriented extraction frequently loses these distinctions.
+
+## Absence states
+
+The system should distinguish:
+
+```text
+not mentioned
+unknown to the user
+not yet decided
+not applicable
+explicitly absent
+declined to answer
+intentionally deferred
+```
+
+Treating all of these as `null` makes both elicitation and downstream behavior unreliable.
+
+For example, “I don’t know the budget” should not be interpreted as “there is no budget.”
+
+## Ambiguity and alternatives
+
+The semantic model should be able to preserve more than one live interpretation.
+
+For example:
+
+```text
+“We need it after the review with Alex.”
+```
+
+may be ambiguous because:
+
+- there are several Alexes,
+- there are several reviews,
+- “it” has multiple possible referents,
+- “after” may describe scheduling or dependency.
+
+The parser should not be forced to pick one answer solely because the destination schema accepts only one.
+
+## Revision and correction
+
+A correction should modify the active semantic state while preserving history:
+
+```text
+“Make that Monday, not Friday.”
+```
+
+should not yield two unrelated dates.
+
+The model should represent that:
+
+- Friday was previously asserted or inferred,
+- Monday supersedes Friday,
+- the correction is supported by a later turn,
+- projections using the prior value are now stale.
+
+Test both direct corrections and less explicit revisions:
+
+```text
+“Actually, the later option is better.”
+```
+
+## Conflict handling
+
+Contradictory content should not be silently merged or resolved based on recency in every case.
+
+Recency may be appropriate for a correction, but not necessarily for two claims from different actors or sources.
+
+The state should distinguish:
+
+```text
+revision
+disagreement
+inconsistent evidence
+context-dependent truth
+multiple valid values
+```
+
+A target may require a single value, but that is a projection constraint rather than evidence that the conflict has disappeared.
+
+## Scope and qualification
+
+Claims need enough scope to avoid false generalization.
+
+Compare:
+
+```text
+“No meetings before ten.”
+“No meetings before ten next week.”
+“No customer meetings before ten.”
+“I generally avoid meetings before ten.”
+```
+
+A weak representation may normalize all four into the same global scheduling constraint.
+
+Useful scope dimensions include:
+
+- actor,
+- entity,
+- time interval,
+- location,
+- scenario,
+- source,
+- conditional context,
+- degree of generality.
+
+## Relationship and cardinality support
+
+The abstraction should not assume that all elicitation is field filling.
+
+It should support:
+
+- one-to-many relations,
+- many-to-many relations,
+- ordered sequences,
+- conditional constraints,
+- alternatives,
+- dependencies,
+- hierarchies,
+- claims about claims,
+- rationales and evidence.
+
+A new target such as a graph should not require reconstructing relationships that were flattened during capture.
+
+## Semantic completeness versus target completeness
+
+The API should treat these as separate assessments.
+
+A semantic object may be adequately understood while a particular target remains invalid:
+
+```text
+Semantic state:
+  “The project should begin after legal approval.”
+
+Target requirement:
+  exact ISO start date
+```
+
+Conversely, a record may be structurally complete because defaults were inserted, while the user’s actual intent remains poorly understood.
+
+Each issue should identify its origin:
+
+```json
+{
+  "origin": "semantic",
+  "kind": "ambiguous_dependency"
+}
+```
+
+or:
+
+```json
+{
+  "origin": "projection",
+  "target": "calendar_event",
+  "kind": "missing_exact_start_time"
+}
+```
+
+## Loss-aware projection
+
+Every projector should classify unmapped content.
+
+Typical outcomes include:
+
+```text
+mapped exactly
+normalized without semantic loss
+mapped approximately
+collapsed with other concepts
+omitted because unsupported
+omitted by target policy
+defaulted
+unrepresentable
+```
+
+A projection that silently discards a fallback preference, qualification, uncertainty, or conflict is semantically unsafe even when its output passes JSON Schema validation.
+
+## Path independence
+
+Equivalent evidence should normally lead to equivalent semantic state regardless of the order in which it was elicited.
+
+For example:
+
+```text
+Path 1:
+  user gives deadline, then owner
+
+Path 2:
+  user gives owner, then deadline
+```
+
+should converge to equivalent active claims.
+
+There will be legitimate path-dependent conversational behavior, but the final semantic state should not depend on arbitrary plugin execution order or the order of schema fields.
+
+---
+
+# 4. Plugin authoring criteria
+
+The API should be evaluated not only by what it can express but by what plugin authors must implement repeatedly.
+
+A well-designed plugin SDK should provide standard machinery for:
+
+- evidence anchoring,
+- claim identity,
+- issue construction,
+- schema validation,
+- retries,
+- idempotency,
+- state-delta application,
+- tracing,
+- test fixtures,
+- model invocation,
+- question candidate formatting,
+- version declaration.
+
+The plugin author should mainly provide:
+
+```text
+domain concept definitions
+examples and counterexamples
+observation or classification logic
+semantic completeness rules
+target mappings
+domain validators
+optional question guidance
+```
+
+## Authoring locality
+
+Adding one concept should generally involve changing one concept definition and its tests, rather than editing:
+
+- a global prompt,
+- a central enum,
+- the orchestration graph,
+- the persistence schema,
+- several target mappings,
+- the conversation controller.
+
+Count the number of files and public concepts a plugin author must understand. This “change surface” is a useful practical metric.
+
+## Defaults without confinement
+
+The SDK should provide sensible defaults for ordinary plugins while allowing specialized behavior through explicit extension points.
+
+Two smells sit at the extremes:
+
+- Every plugin reimplements the entire lifecycle.
+- The default lifecycle is impossible to escape without forking the runtime.
+
+## Local simulation
+
+A plugin developer should have a harness that can run fixtures such as:
+
+```yaml
+conversation:
+  - user: "Friday is ideal, but Monday works."
+expected_claims:
+  - kind: date_preference
+    preferred: Friday
+    acceptable:
+      - Monday
+expected_issues: []
+```
+
+The simulator should expose:
+
+- observations,
+- claim merges,
+- unresolved issues,
+- proposed questions,
+- projection outputs,
+- loss reports,
+- trace events.
+
+Debugging should not require reading an entire agent transcript.
+
+## Actionable failures
+
+A contract error should say:
+
+```text
+Projection plugin emitted a claim reference that does not exist.
+```
+
+rather than:
+
+```text
+Invalid plugin output.
+```
+
+The runtime should distinguish plugin defects from legitimate semantic uncertainty.
+
+## Escape-hatch accounting
+
+Some domains will require custom processing. Escape hatches are reasonable, but they should be visible.
+
+For example:
+
+```text
+custom reconciliation hook used
+custom direct model invocation used
+opaque state storage used
+non-idempotent side effect used
+```
+
+The more frequently plugins require these, the less successful the abstraction probably is.
+
+---
+
+# 5. High-value test matrix
+
+Testing one goal against one JSON schema will mostly confirm that the happy path works. A better test matrix crosses three axes.
+
+## Axis A: semantic goals
+
+Use goals with materially different semantic shapes:
+
+1. **Finite fact capture**
+   Contact or account details.
+
+2. **Constraint elicitation**
+   Requirements, prohibitions, dependencies, and acceptance criteria.
+
+3. **Preference elicitation**
+   Rankings, tradeoffs, acceptable alternatives, and hard versus soft constraints.
+
+4. **Temporal reconstruction**
+   Events, durations, recurring patterns, and corrections.
+
+5. **Decision rationale**
+   Options, arguments, evidence, assumptions, and confidence.
+
+6. **Open-ended design intent**
+   Desired effects, references, exclusions, and aesthetic criteria.
+
+## Axis B: representation targets
+
+Use targets with different representational properties:
+
+1. Flat form or JSON object.
+2. Nested document schema.
+3. Normalized relational records.
+4. Property graph.
+5. Constraint or rules representation.
+6. Human-readable report.
+7. Several simultaneous targets with different required fields.
+
+## Axis C: dialogue perturbations
+
+Run each combination against:
+
+- information given in narrative order,
+- fields given out of order,
+- indirect statements,
+- corrections,
+- contradictions,
+- multiple entities,
+- ambiguous pronouns,
+- uncertainty,
+- refusal to answer,
+- “not applicable,”
+- off-topic content,
+- target change mid-conversation,
+- plugin failure and retry.
+
+The most revealing cases are usually not random long conversations but carefully constructed minimal pairs.
+
+Examples:
+
+```text
+“The budget is €20,000.”
+“The budget might be €20,000.”
+
+“Alex approved it.”
+“Alex should approve it.”
+
+“We have no deadline.”
+“I don’t know the deadline.”
+
+“Friday is preferred.”
+“Friday is required.”
+```
+
+The IR and elicitation behavior should differ appropriately in each pair.
+
+---
+
+# 6. Specific swap tests
+
+## Projector substitution test
+
+Capture one conversation once, then project the same semantic state into:
+
+- a flat record,
+- a graph,
+- a narrative summary.
+
+The projections should agree about the underlying facts. Differences should be traceable to target capabilities or declared mapping policy.
+
+## Elicitation-goal substitution test
+
+Run the same source through two semantic packs, such as:
+
+- project requirement capture,
+- risk identification.
+
+The packs should be able to identify different relevant content from the same evidence without corrupting or overwriting one another.
+
+## Mid-session target swap
+
+Begin eliciting for one target, then add or replace a target during the conversation.
+
+The system should:
+
+- retain previously gathered evidence,
+- reproject where possible,
+- identify only genuinely new gaps,
+- avoid asking the user to repeat information.
+
+## Multi-target backpressure test
+
+Attach two targets, one of which requires extra fields.
+
+The extra requirement should be namespaced to that target. It should not make the entire semantic state globally incomplete unless satisfying both targets is explicitly the active goal.
+
+## Loss challenge
+
+Use a rich semantic state and deliberately project it into an impoverished schema.
+
+The projector should report exactly what it cannot represent. A successful JSON serialization is not a passing result.
+
+## Unsupported-concept test
+
+Supply content that a plugin cannot interpret safely.
+
+A good plugin should return something like:
+
+```text
+unsupported
+unmapped
+ambiguous
+requires specialist interpretation
+```
+
+It should not fabricate a nearest matching concept merely to produce complete output.
+
+## Replay test
+
+Replay a completed conversation with:
+
+- the same plugin versions,
+- an upgraded projector,
+- an upgraded elicitation plugin.
+
+Verify which stages can be reused and which claims need reinterpretation.
+
+## Composition collision test
+
+Install two plugins that define overlapping concepts or observe the same evidence. Confirm that namespacing, equivalence, and conflict policies work without execution-order dependence.
+
+## Plugin removal test
+
+Remove a plugin after state has been captured.
+
+The runtime should still be able to:
+
+- inspect the evidence,
+- preserve claims in a generic serialized form,
+- identify which interpretations came from the removed plugin,
+- continue operating with unaffected plugins.
+
+## Black-box implementation test
+
+Give the public API documentation and SDK to a developer who has not read the core implementation. Ask them to implement a new goal plugin and target plugin.
+
+Measure:
+
+- time spent understanding the framework,
+- number of core concepts they must learn,
+- boilerplate written,
+- core changes requested,
+- undocumented assumptions discovered,
+- ability to test locally,
+- number of escape hatches needed.
+
+This is one of the best tests of actual ease of implementation.
+
+---
+
+# 7. Structural smells
+
+## The universal callback
+
+```python
+plugin.run(context) -> dict
+```
+
+The callback has access to everything and may return anything. This provides extension without abstraction.
+
+## The giant context bag
+
+Plugins receive an object containing the model client, database, user session, prompt builder, tool registry, HTTP client, and internal state.
+
+This causes implicit coupling and makes permissions, testing, and replay difficult.
+
+## The monolithic domain plugin
+
+One plugin performs extraction, question selection, conversation management, state mutation, validation, projection, and persistence.
+
+Such a plugin may work, but A and B are no longer independently swappable.
+
+## Core branching by plugin identity
+
+Plugin-specific behavior appears in the runtime, often as conditionals, special registries, or domain-specific exception handling.
+
+## The ever-growing common schema
+
+Every new plugin adds fields to the supposedly universal claim model. This produces a central ontology bottleneck.
+
+## The opaque payload waist
+
+The common API contains little more than:
+
+```json
+{
+  "plugin": "x",
+  "payload": {}
+}
+```
+
+The runtime cannot reason about evidence, conflicts, completeness, or revisions.
+
+## Callback soup
+
+The plugin API exposes many weakly defined hooks:
+
+```text
+before_parse
+after_parse
+before_map
+after_map
+before_question
+after_question
+before_save
+...
+```
+
+Behavior becomes order-sensitive and difficult to compose.
+
+## Direct mutation
+
+Plugins alter canonical state, mark issues resolved, or write projections directly. The runtime cannot validate the transition or reconstruct why it happened.
+
+## Order-sensitive execution
+
+Changing plugin registration order changes active claims or projected results without an explicit priority or merge rule.
+
+## Copy-paste plugin development
+
+New plugins are created by cloning an existing one and replacing prompts, field names, and validators. This usually indicates that common mechanics have not been captured by the SDK.
+
+## Full-stack testing requirement
+
+A plugin cannot be unit tested without launching the whole agent, model, database, and UI.
+
+## Hidden target leakage
+
+Target-specific terms appear in the semantic layer:
+
+```text
+jira_project_key
+salesforce_lead_status
+database_column_name
+```
+
+even though the same underlying meaning should support other targets.
+
+---
+
+# 8. Semantic smells
+
+## Schema-shaped questioning
+
+The conversation follows the order of destination fields:
+
+```text
+What is field one?
+What is field two?
+What is field three?
+```
+
+This often indicates that the schema is being treated as the semantic model.
+
+## Syntactic completeness treated as semantic completeness
+
+The system stops because every required field has a value, even though some values were guessed, defaulted, or remain contradictory.
+
+## One confidence score for everything
+
+A scalar `confidence: 0.82` is used instead of distinguishing user uncertainty, model uncertainty, weak evidence, ambiguity, inference, and source disagreement.
+
+## Null collapse
+
+Unknown, absent, declined, not applicable, and not yet decided all become `null`.
+
+## Silent coercion
+
+A vague phrase is converted into a precise value without recording the normalization assumption:
+
+```text
+“toward the end of the month”
+→ 2026-08-28
+```
+
+## Silent loss
+
+The output schema cannot represent alternatives or qualifiers, and the projector simply discards them.
+
+## Correction as duplication
+
+The semantic state contains both the old and corrected values as equally active claims.
+
+## Recency as universal truth
+
+The most recent statement always wins, even when the later statement comes from a different actor, concerns a different scope, or expresses uncertainty rather than correction.
+
+## Inference presented as user fact
+
+A plausible interpretation becomes indistinguishable from something the user explicitly stated.
+
+## Field-level provenance only
+
+The system can say that a field came from “turn 8” but cannot identify which phrase supported which aspect of the interpretation.
+
+## Validation limited to schema syntax
+
+The output is celebrated as valid because it conforms to JSON Schema, despite being semantically contradictory or unsupported.
+
+## Extraction that cannot abstain
+
+Every input span must be classified into one of the plugin’s concepts. There is no unsupported, irrelevant, or ambiguous outcome.
+
+## Questions generated directly from missing fields
+
+The runtime sees a missing key and asks for it without first determining:
+
+- whether the user already implied it,
+- whether it can be derived,
+- whether it matters,
+- whether the user can answer,
+- whether another ambiguity should be resolved first.
+
+## Premature normalization
+
+Relative dates, vague quantities, organizational roles, and entity references are resolved before sufficient context exists.
+
+## Projection-specific gaps contaminating global state
+
+Adding a target with extra required fields suddenly causes an otherwise complete semantic object to become globally incomplete.
+
+---
+
+# 9. Useful invariants to encode as tests
+
+A strong runtime can enforce several properties independent of domain plugins:
+
+1. **No unsupported value without provenance.**
+   Every projected value must point to a claim, a declared default, or a documented transformation.
+
+2. **No silent conflict resolution.**
+   Resolving contradictory active claims must produce an explicit revision or resolution event.
+
+3. **No silent projection loss.**
+   Relevant active claims that cannot be represented must appear in a loss report.
+
+4. **Corrections do not erase history.**
+   Superseded claims remain inspectable but are not treated as active.
+
+5. **Retries are semantically idempotent.**
+   Retrying a failed plugin call cannot create additional user assertions.
+
+6. **Target issues are namespaced.**
+   A target-specific requirement does not automatically become a semantic requirement.
+
+7. **Plugin failures are atomic.**
+   A failed invocation cannot leave partially applied state.
+
+8. **Equivalent state produces equivalent projection.**
+   Projection results should not depend on the order in which claims were discovered.
+
+9. **Unknown remains distinct from false.**
+
+10. **Explicit remains distinct from inferred and defaulted.**
+
+These invariants give the core genuine semantic responsibility without requiring it to understand every domain.
+
+---
+
+# 10. A compact scorecard
+
+A plugin system can be scored from 0–2 on each dimension:
+
+| Dimension            | 0                         | 1                    | 2                                               |
+| -------------------- | ------------------------- | -------------------- | ----------------------------------------------- |
+| Goal swappability    | Core rewrite              | Adapter work         | Plugin-only change                              |
+| Target swappability  | Coupled to extraction     | Partial separation   | Independent projection                          |
+| Semantic fidelity    | Field values only         | Some provenance      | Evidence, modality, ambiguity, revision         |
+| Loss handling        | Silent                    | Informal warning     | Typed, attributable loss report                 |
+| Composition          | Order-dependent           | Manual coordination  | Defined merge and conflict semantics            |
+| State model          | Mutable opaque state      | Partial events       | Replayable validated deltas                     |
+| Authoring ergonomics | Requires core knowledge   | Usable with examples | SDK, fixtures, diagnostics, local testing       |
+| Versioning           | Replace in place          | Manual migration     | Explicit compatibility and migration            |
+| Observability        | Transcript only           | Stage logs           | Claim-level provenance and transformation trace |
+| Failure isolation    | State corruption possible | Recoverable manually | Atomic, idempotent, replayable                  |
+
+The overall result should not be averaged blindly. Some dimensions are gating requirements. In particular, semantic fidelity, explicit loss handling, and state integrity should be treated as non-negotiable for high-stakes use.
+
+The central smell to watch for is **accidental coupling hidden by configurability**. A framework may appear general because schemas and prompts are configurable, while its actual semantics remain field-oriented and target-dependent. The better abstraction demonstrates that meaning can be captured once, revised coherently, interrogated by the runtime, and projected into materially different structures without either turning the core into a universal ontology or reducing the plugin boundary to an untyped escape hatch.
+
+</turn>
diff --git a/libs/@hashintel/brunch-agent/docs/reference/amp-analysis-flue-vs-tilde.md b/libs/@hashintel/brunch-agent/docs/reference/amp-analysis-flue-vs-tilde.md
new file mode 100644
index 00000000000..a6c682bc225
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/amp-analysis-flue-vs-tilde.md
@@ -0,0 +1,4231 @@
+---
+title: Compare two agent frameworks
+author: Lu Nelson
+threadId: T-019fffb3-00c1-7275-a991-40af8a6f5824
+created: 2026-08-14T09:55:49.057Z
+agentMode: high
+---
+
+# Compare two agent frameworks
+
+## User
+
+I'd like you to make a comparative assessment of the following two agent frameworks, focusing on their respetive development and deployment stories, and consider the import of that anlysis for the present project
+
+## Assistant
+
+Which two frameworks should I compare? Please send their names or links; I’ll assess both against this project’s current architecture and deployment constraints.
+
+Which two agent frameworks should I compare? Please provide their names or links.
+
+## User
+
+[Getting Started | Flue](https://flueframework.com/docs/guide/getting-started/)
+
+[Start building with Tilde - Tilde documentation](https://trytilde.ai/docs)
+
+## Assistant
+
+**Tool Use:** `skill`
+
+```json
+{
+  "name": "context-mode"
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wWTIKtjEH3KCehifXF`
+
+````
+{
+  "content": [
+    {
+      "text": "<loaded_skill name=\"context-mode\">\n# context-mode Skill\n\n\n# Context Mode: Default for All Large Output\n\n## MANDATORY RULE\n\n<context_mode_logic>\n  <mandatory_rule>\n    Default to context-mode for ALL commands. Only use Bash for guaranteed-small-output operations.\n  </mandatory_rule>\n</context_mode_logic>\n\nBash whitelist (safe to run directly):\n- **File mutations**: `mkdir`, `mv`, `cp`, `rm`, `touch`, `chmod`\n- **Git writes**: `git add`, `git commit`, `git push`, `git checkout`, `git branch`, `git merge`\n- **Navigation**: `cd`, `pwd`, `which`\n- **Process control**: `kill`, `pkill`\n- **Package management**: `npm install`, `npm publish`, `pip install`\n- **Simple output**: `echo`, `printf`\n\n**Everything else → `ctx_execute` or `ctx_execute_file`.** Any command that reads, queries, fetches, lists, logs, tests, builds, diffs, inspects, or calls an external service. This includes ALL CLIs (gh, aws, kubectl, docker, terraform, wrangler, fly, heroku, gcloud, etc.) — there are thousands and we cannot list them all.\n\n**When uncertain, use context-mode.** Every KB of unnecessary context reduces the quality and speed of the entire session.\n\n## Decision Tree\n\n```\nAbout to run a command / read a file / call an API?\n│\n├── Command is on the Bash whitelist (file mutations, git writes, navigation, echo)?\n│   └── Use Bash\n│\n├── Output MIGHT be large or you're UNSURE?\n│   └── Use context-mode ctx_execute or ctx_execute_file\n│\n├── Fetching web documentation or HTML page?\n│   └── Use ctx_fetch_and_index → ctx_search\n│\n├── Using Playwright (navigate, snapshot, console, network)?\n│   └── ALWAYS use filename parameter to save to file, then:\n│       browser_snapshot(filename) → ctx_index(path) or ctx_execute_file(path)\n│       browser_console_messages(filename) → ctx_execute_file(path)\n│       browser_network_requests(filename) → ctx_execute_file(path)\n│       ⚠ browser_navigate returns a snapshot automatically — ignore it,\n│         use browser_snapshot(filename) for any inspection.\n│       ⚠ Playwright MCP uses a SINGLE browser instance — NOT parallel-safe.\n│         For parallel browser ops, use agent-browser via execute instead.\n│\n├── Using agent-browser (parallel-safe browser automation)?\n│   └── Run via execute (shell) — each call gets its own subprocess:\n│       execute(\"agent-browser open example.com && agent-browser snapshot -i -c\")\n│       ✓ Supports sessions for isolated browser instances\n│       ✓ Safe for parallel subagent execution\n│       ✓ Lightweight accessibility tree with ref-based interaction\n│\n├── Processing output from another MCP tool (Context7, GitHub API, etc.)?\n│   ├── Output already in context from a previous tool call?\n│   │   └── Use it directly. Do NOT re-index with ctx_index(content: ...).\n│   ├── Need to search the output multiple times?\n│   │   └── Save to file via ctx_execute, then ctx_index(path) → ctx_search\n│   └── One-shot extraction?\n│       └── Save to file via ctx_execute, then ctx_execute_file(path)\n│\n└── Reading a file to analyze/summarize (not edit)?\n    └── Use ctx_execute_file (file loads into FILE_CONTENT, not context)\n```\n\n## When to Use Each Tool\n\n| Situation | Tool | Example |\n|-----------|------|---------|\n| Hit an API endpoint | `ctx_execute` | `fetch('http://localhost:3000/api/orders')` |\n| Run CLI that returns data | `ctx_execute` | `gh pr list`, `aws s3 ls`, `kubectl get pods` |\n| Run tests | `ctx_execute` | `npm test`, `pytest`, `go test ./...` |\n| Git operations | `ctx_execute` | `git log --oneline -50`, `git diff HEAD~5` |\n| Docker/K8s inspection | `ctx_execute` | `docker stats --no-stream`, `kubectl describe pod` |\n| Read a log file | `ctx_execute_file` | Parse access.log, error.log, build output |\n| Read a data file | `ctx_execute_file` | Analyze CSV, JSON, YAML, XML |\n| Read source code to analyze | `ctx_execute_file` | Count functions, find patterns, extract metrics |\n| Fetch web docs | `ctx_fetch_and_index` | Index React/Next.js/Zod docs, then search |\n| Playwright snapshot | `browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search` | Save to file, index server-side, query |\n| Playwright snapshot (one-shot) | `browser_snapshot(filename)` → `ctx_execute_file(path)` | Save to file, extract in sandbox |\n| Playwright console/network | `browser_*(filename)` → `ctx_execute_file(path)` | Save to file, analyze in sandbox |\n| MCP output (already in context) | Use directly | Don't re-index — it's already loaded |\n| MCP output (need multi-query) | `ctx_execute` to save → `ctx_index(path)` → `ctx_search` | Save to file first, index server-side |\n| Wipe indexed KB content | `ctx_purge(confirm: true)` | Permanently deletes all indexed content |\n\n## Automatic Triggers\n\nUse context-mode for ANY of these, without being asked:\n\n- **API debugging**: \"hit this endpoint\", \"call the API\", \"check the response\", \"find the bug in the response\"\n- **Log analysis**: \"check the logs\", \"what errors\", \"read access.log\", \"debug the 500s\"\n- **Test runs**: \"run the tests\", \"check if tests pass\", \"test suite output\"\n- **Git history**: \"show recent commits\", \"git log\", \"what changed\", \"diff between branches\"\n- **Data inspection**: \"look at the CSV\", \"parse the JSON\", \"analyze the config\"\n- **Infrastructure**: \"list containers\", \"check pods\", \"S3 buckets\", \"show running services\"\n- **Dependency audit**: \"check dependencies\", \"outdated packages\", \"security audit\"\n- **Build output**: \"build the project\", \"check for warnings\", \"compile errors\"\n- **Code metrics**: \"count lines\", \"find TODOs\", \"function count\", \"analyze codebase\"\n- **Web docs lookup**: \"look up the docs\", \"check the API reference\", \"find examples\"\n\n## Language Selection\n\n| Situation | Language | Why |\n|-----------|----------|-----|\n| HTTP/API calls, JSON | `javascript` | Native fetch, JSON.parse, async/await |\n| Data analysis, CSV, stats | `python` | csv, statistics, collections, re |\n| Shell commands with pipes | `shell` | grep, awk, jq, native tools |\n| File pattern matching | `shell` | find, wc, sort, uniq |\n\n## Search Query Strategy\n\n- BM25 uses **OR semantics** — results matching more terms rank higher automatically\n- Use 2-4 specific technical terms per query\n- **Always use `source` parameter** when multiple docs are indexed to avoid cross-source contamination\n  - Partial match works: `source: \"Node\"` matches `\"Node.js v22 CHANGELOG\"`\n- **Always use `queries` array** — batch ALL search questions in ONE call:\n  - `ctx_search(queries: [\"transform pipe\", \"refine superRefine\", \"coerce codec\"], source: \"Zod\")`\n  - NEVER make multiple separate ctx_search() calls — put all queries in one array\n\n## External Documentation\n\n- **Always use `ctx_fetch_and_index`** for external docs — NEVER `cat` or `ctx_execute` with local paths for packages you don't own\n- For GitHub-hosted projects, use the raw URL: `https://raw.githubusercontent.com/org/repo/main/CHANGELOG.md`\n- After indexing, use the `source` parameter in search to scope results to that specific document\n\n## Critical Rules\n\n1. **Always console.log/print your findings.** stdout is all that enters context. No output = wasted call.\n2. **Write analysis code, not just data dumps.** Don't `console.log(JSON.stringify(data))` — analyze first, print findings.\n3. **Be specific in output.** Print bug details with IDs, line numbers, exact values — not just counts.\n4. **For files you need to EDIT**: Use the normal Read tool. context-mode is for analysis, not editing.\n5. **For Bash whitelist commands only**: Use Bash for file mutations, git writes, navigation, process control, package install, and echo. Everything else goes through context-mode.\n6. **Never use `ctx_index(content: large_data)`.** Use `ctx_index(path: ...)` to read files server-side. The `content` parameter sends data through context as a tool parameter — use it only for small inline text.\n7. **Always use `filename` parameter** on Playwright tools (`browser_snapshot`, `browser_console_messages`, `browser_network_requests`). Without it, the full output enters context.\n8. **Don't re-index data already in context.** If an MCP tool returned data in a previous response, it's already loaded — use it directly or save to file first.\n\n## Sandboxed Data Workflow\n\n<sandboxed_data_workflow>\n  <critical_rule>\n    When using tools that support saving to a file: ALWAYS use the 'filename' parameter.\n    NEVER return large raw datasets directly to context.\n  </critical_rule>\n  <workflow>\n    LargeDataTool(filename: \"path\") → mcp__context-mode__ctx_index(path: \"path\") → ctx_search()\n  </workflow>\n</sandboxed_data_workflow>\n\nThis is the universal pattern for context preservation regardless of\nthe source tool (Playwright, GitHub API, AWS CLI, etc.).\n\n## Examples\n\n### Debug an API endpoint\n```javascript\nconst resp = await fetch('http://localhost:3000/api/orders');\nconst { orders } = await resp.json();\n\nconst bugs = [];\nconst negQty = orders.filter(o => o.quantity < 0);\nif (negQty.length) bugs.push(`Negative qty: ${negQty.map(o => o.id).join(', ')}`);\n\nconst nullFields = orders.filter(o => !o.product || !o.customer);\nif (nullFields.length) bugs.push(`Null fields: ${nullFields.map(o => o.id).join(', ')}`);\n\nconsole.log(`${orders.length} orders, ${bugs.length} bugs found:`);\nbugs.forEach(b => console.log(`- ${b}`));\n```\n\n### Analyze test output\n```shell\nnpm test 2>&1\necho \"EXIT=$?\"\n```\n\n### Check GitHub PRs\n```shell\ngh pr list --json number,title,state,reviewDecision --jq '.[] | \"\\(.number) [\\(.state)] \\(.title) — \\(.reviewDecision // \"no review\")\"'\n```\n\n### Read and analyze a large file\n```python\n# FILE_CONTENT is pre-loaded by ctx_execute_file\nimport json\ndata = json.loads(FILE_CONTENT)\nprint(f\"Records: {len(data)}\")\n# ... analyze and print findings\n```\n\n## Browser & Playwright Integration\n\n**When a task involves Playwright snapshots, screenshots, or page inspection, ALWAYS route through file → sandbox.**\n\nPlaywright `browser_snapshot` returns 10K–135K tokens of accessibility tree data. Calling it without `filename` dumps all of that into context. Passing the output to `ctx_index(content: ...)` sends it into context a SECOND time as a parameter. Both are wrong.\n\n**The key insight**: `browser_snapshot` has a `filename` parameter that saves to file instead of returning to context. `ctx_index` has a `path` parameter that reads files server-side. `ctx_execute_file` processes files in a sandbox. **None of these touch context.**\n\n### Workflow A: Snapshot → File → Index → Search (multiple queries)\n\n```\nStep 1: browser_snapshot(filename: \"/tmp/playwright-snapshot.md\")\n        → saves to file, returns ~50B confirmation (NOT 135K tokens)\n\nStep 2: ctx_index(path: \"/tmp/playwright-snapshot.md\", source: \"Playwright snapshot\")\n        → reads file SERVER-SIDE, indexes into FTS5, returns ~80B confirmation\n\nStep 3: ctx_search(queries: [\"login form email password\"], source: \"Playwright\")\n        → returns only matching chunks (~300B)\n```\n\n**Total context: ~430B** instead of 270K tokens. Real 99% savings.\n\n### Workflow B: Snapshot → File → Execute File (one-shot extraction)\n\n```\nStep 1: browser_snapshot(filename: \"/tmp/playwright-snapshot.md\")\n        → saves to file, returns ~50B confirmation\n\nStep 2: ctx_execute_file(path: \"/tmp/playwright-snapshot.md\", language: \"javascript\", code: \"\n          const links = [...FILE_CONTENT.matchAll(/- link \\\"([^\\\"]+)\\\"/g)].map(m => m[1]);\n          const buttons = [...FILE_CONTENT.matchAll(/- button \\\"([^\\\"]+)\\\"/g)].map(m => m[1]);\n          const inputs = [...FILE_CONTENT.matchAll(/- textbox|- checkbox|- radio/g)];\n          console.log('Links:', links.length, '| Buttons:', buttons.length, '| Inputs:', inputs.length);\n          console.log('Navigation:', links.slice(0, 10).join(', '));\n        \")\n        → processes in sandbox, returns ~200B summary\n```\n\n**Total context: ~250B** instead of 135K tokens.\n\n### Workflow C: Console & Network (save to file if large)\n\n```\nbrowser_console_messages(level: \"error\", filename: \"/tmp/console.md\")\n→ ctx_execute_file(path: \"/tmp/console.md\", ...) or ctx_index(path: \"/tmp/console.md\", ...)\n\nbrowser_network_requests(includeStatic: false, filename: \"/tmp/network.md\")\n→ ctx_execute_file(path: \"/tmp/network.md\", ...) or ctx_index(path: \"/tmp/network.md\", ...)\n```\n\n### CRITICAL: Why `filename` + `path` is mandatory\n\n| Approach | Context cost | Correct? |\n|----------|-------------|----------|\n| `browser_snapshot()` → raw into context | **135K tokens** | NO |\n| `browser_snapshot()` → `ctx_index(content: raw)` | **270K tokens** (doubled!) | NO |\n| `browser_snapshot(filename)` → `ctx_index(path)` → `ctx_search` | **~430B** | YES |\n| `browser_snapshot(filename)` → `ctx_execute_file(path)` | **~250B** | YES |\n\n### Key Rule\n\n> **ALWAYS use `filename` parameter when calling `browser_snapshot`, `browser_console_messages`, or `browser_network_requests`.**\n> Then process via `ctx_index(path: ...)` or `ctx_execute_file(path: ...)` — never `ctx_index(content: ...)`.\n>\n> Data flow: **Playwright → file → server-side read → context**. Never: **Playwright → context → ctx_index(content) → context again**.\n\n## Subagent Usage\n\nSubagents automatically receive context-mode tool routing via a PreToolUse hook. You do NOT need to manually add tool names to subagent prompts — the hook injects them. Just write natural task descriptions.\n\n## Anti-Patterns\n\n- Using `curl http://api/endpoint` via Bash → 50KB floods context. Use `ctx_execute` with fetch instead.\n- Using `cat large-file.json` via Bash → entire file in context. Use `ctx_execute_file` instead.\n- Using `gh pr list` via Bash → raw JSON in context. Use `ctx_execute` with `--jq` filter instead.\n- Piping Bash output through `| head -20` → you lose the rest. Use `ctx_execute` to analyze ALL data and print summary.\n- Narrowing `ctx_execute` output upstream of capture → `ctx_execute` captures, `ctx_search` filters; merging the layers drops data that the index never sees. See `references/anti-patterns.md` §8.\n- Running `npm test` via Bash → full test output in context. Use `ctx_execute` to capture and summarize.\n- Calling `browser_snapshot()` WITHOUT `filename` parameter → 135K tokens flood context. **Always** use `browser_snapshot(filename: \"/tmp/snap.md\")`.\n- Calling `browser_console_messages()` or `browser_network_requests()` WITHOUT `filename` → entire output floods context. **Always** use the `filename` parameter.\n- Passing ANY large data to `ctx_index(content: ...)` → data enters context as a parameter. **Always** use `ctx_index(path: ...)` to read server-side. The `content` parameter should only be used for small inline text you're composing yourself.\n- Calling an MCP tool (Context7 `query-docs`, GitHub API, etc.) then passing the response to `ctx_index(content: response)` → **doubles** context usage. The response is already in context — use it directly or save to file first.\n- Ignoring `browser_navigate` auto-snapshot → navigation response includes a full page snapshot. Don't rely on it for inspection — call `browser_snapshot(filename)` separately.\n- Expecting `ctx_stats` to reset or wipe anything → `ctx_stats` is read-only (shows stats only). Use `ctx_purge(confirm: true)` to permanently delete all indexed content.\n\n## Reference Files\n\n- [JavaScript/TypeScript Patterns](./references/patterns-javascript.md)\n- [Python Patterns](./references/patterns-python.md)\n- [Shell Patterns](./references/patterns-shell.md)\n- [Anti-Patterns & Common Mistakes](./references/anti-patterns.md)\n\n\nBase directory for this skill: file:///Users/lunelson/.claude/plugins/cache/context-mode/context-mode/1.0.169/skills/context-mode\nRelative paths in this skill (e.g., scripts/, reference/) are relative to this base directory.\n\n<skill_files>\n<file>/Users/lunelson/.claude/plugins/cache/context-mode/context-mode/1.0.169/skills/context-mode/references/anti-patterns.md</file>\n<file>/Users/lunelson/.claude/plugins/cache/context-mode/context-mode/1.0.169/skills/context-mode/references/patterns-javascript.md</file>\n<file>/Users/lunelson/.claude/plugins/cache/context-mode/context-mode/1.0.169/skills/context-mode/references/patterns-python.md</file>\n<file>/Users/lunelson/.claude/plugins/cache/context-mode/context-mode/1.0.169/skills/context-mode/references/patterns-shell.md</file>\n</skill_files>\n</loaded_skill>",
+      "type": "text"
+    }
+  ]
+}
+````
+
+## Assistant
+
+I’ll compare the frameworks from their current documentation, then map the differences onto this repository’s actual agent workflow, runtime boundaries, and deployment assumptions rather than treating it as a generic feature comparison.
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/getting-started/",
+  "objective": "Establish Flue's current development model, core abstractions, local setup, runtime requirements, state/tool/model integration, observability/testing story, and deployment model. Capture links to authoritative follow-on documentation needed for a rigorous framework assessment.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs",
+  "objective": "Establish Tilde's current development model, core abstractions, local setup, runtime requirements, state/tool/model integration, observability/testing story, and deployment model. Capture links to authoritative follow-on documentation needed for a rigorous framework assessment.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `finder`
+
+```json
+{
+  "query": "Assess the present brunch-lite project's agent framework architecture and deployment story. Identify the production entry points and end-to-end flow, agent/workflow abstractions and dependencies, persistence/state model, integrations, local development commands, tests/evaluation/observability mechanisms, and deployment configuration or assumptions. Return concise findings with exact file paths and line numbers, and flag planned-vs-implemented distinctions from CONTEXT.md and ADRs."
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wWoPgf9Ql9EvAhklZY`
+
+````
+# description: Set up a Flue project automatically or create your first agent manually.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg
+**Flue** is the open agent framework, from the creators of [Astro](https://astro.build/). Use a React-like hooks API to build agents in TypeScript using your favorite LLMs.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg
+Run them locally or deploy them anywhere: Node.js, Cloudflare, GitHub Actions, GitHub CI/CD, etc.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Prerequisites
+* **Node.js** — `>=22.19.0` minimum required version.
+* **LLM** — API key(s) to connect to your favorite model provider. Flue is built on Pi, and supports [all Pi providers](https://pi.dev/docs/latest/providers) out of the box.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Prerequisites
+Flue’s [Cloudflare runtime](https://flueframework.com/docs/guide/getting-started/docs/guide/targets/cloudflare/) provides a built-in `cloudflare/*` AI gateway, no API keys required.
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Manual Installation
+> _The AI-guided prompt above is strongly recommended for most users. Follow the steps below if you prefer to set things up yourself._
+In a new directory, install the runtime and the CLI:
+```bash
+npm install @flue/runtime @flue/cli
+````
+
+Then, create a basic `flue.config.ts` file:
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Manual Installation
+
+```ts
+import { defineConfig } from "@flue/runtime/config";
+
+export default defineConfig({
+  target: "node", // or 'cloudflare'
+});
+```
+
+And finally, create your first `src/agents/assistant.ts`:
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Manual Installation
+
+```ts
+// The `'use agent'` directive marks the Assistant() function below as a Flue agent.
+"use agent";
+import { useModel } from "@flue/runtime";
+
+// This is your first agent: `Assistant`.
+// It's return value is your agent's instructions, which become the agent's "system" instructions.
+```
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Manual Installation
+You can use any [Model/Provider](https://flueframework.com/docs/guide/models/) that Pi supports. In the example above, we use Claude Haiku. Whichever you choose, just be sure to provide the required API keys to the agent runtime. Its recommended to use a `.env` file to manage your API keys:
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Run your agent locally
+You can now spin up new agents from your terminal, running on your local machine:
+
+```bash
+npx flue run src/agents/assistant.ts --message "Say hello in five words or fewer."
+```
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Run your agent locally
+Congratulations! You just ran your first Flue agent. You can use `flue run` to run agents on your local machine, or in CI environments like [GitHub Actions](https://flueframework.com/docs/ecosystem/deploy/github-actions/) and [GitLab CI/CD](https://flueframework.com/docs/ecosystem/deploy/gitlab-ci/).
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent
+To host your agent remotely, you’ll need to deploy it. Flue uses [Hono](http://hono.dev/) and [Vite](https://vite.dev/) to power its server framework and build pipeline, respectively. Follow the following steps to build your agent for deployment.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 1. Install dependencies
+
+```bash
+npm install @flue/vite hono vite
+```
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 2. Configure the project
+Create two small config files at the project root:
+
+```ts
+import { flue } from "@flue/vite";
+import { defineConfig } from "vite";
+
+export default defineConfig({
+  plugins: [flue()],
+});
+```
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 2. Configure the project
+If you are deploying to Cloudflare, then you should also install `@cloudflare/vite-plugin` and add `cloudflare()` after `flue()` in the Vite plugins array. see the [Cloudflare runtime](https://flueframework.com/docs/guide/cloudflare-target/) guide for more.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 3. Build your app router
+`src/app.ts` is the special file where your Flue app router always lives. Create your [Hono](https://hono.dev/) application instance, mount your agent, and export it so that it gets picked up by your build.
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 3. Build your app router
+
+```ts
+import { createAgentRouter } from "@flue/runtime/routing";
+import { Hono } from "hono";
+import { Assistant } from "./agents/assistant.ts";
+
+// 1. Create your Hono application instance.
+const app = new Hono();
+// 2. Define your agent routes.
+app.route("/agents/assistant", createAgentRouter(Assistant));
+```
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 4. Start the dev server
+As mentioned, Flue leverages Vite to power its dev and build pipeline. To spin up your dev server, run `vite dev`:
+
+```bash
+npx vite dev
+```
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 4. Start the dev server
+Vite spins up your `app.ts` (by default at `http://localhost:5173`) application and servers your agents at the routes that you defined. Test your setup by sending your agent a message — one `POST` per message, `202` on admission:
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy your agent > 4. Start the dev server
+`vite build` will produce a runnable `dist/server.mjs` build output for the `"node"` runtime target, or a deployable Cloudflare Worker when configured with the `"cloudflare"` runtime target.
+
+...
+
+title: Getting Started | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Agent SDK](https://flueframework.com/docs/sdk/overview/) and [React](https://flueframework.com/docs/guide/react/) — build product experiences on top of a deployed agent.
+
+```
+
+**Tool Result:** `TU-0346wWoQZ3eDynKmTkye3i`
+
+```
+
+> Documentation IndexFetch the complete documentation index at: https://trytilde.ai/docs/llms.txt
+> Use this file to discover all available pages before exploring further.
+
+# Start building with Tilde
+
+> Build and operate TypeScript AI agents with secure tools, MCP servers, ChatKit, memory, skills, browser sessions, and portable Tilde configuration.
+> Tilde breaks down what makes Claude Code, Codex, and OpenClaw effective and makes those capabilities available as an integrated product suite.
+> Our mission is to open the hood on these products and give you the same building blocks. Tilde helps developers build purposeful AI agents quickly.
+
+...
+
+- **Tools:** Connect to hundreds of providers with off-the-shelf integrations, add custom tools, and group them in secure MCP servers.
+- **Memory:** Create a persistent brain and personal notebook for one agent, or share it across several agents.
+- **Skills:** Deploy skill registries that group instructions and make them available to agents.
+- **ChatKit:** Integrate with third-party chat providers, trigger agent runs from external webhook events, or schedule recurring prompts.
+  These features are available through cloud APIs that hide the underlying complexity.
+  Use our client-side library, `@trytilde/harness-sdk`, with first-class support for Vercel and Next.js to build and deploy your own cloud agents.
+
+...
+
+## Explore the product suite
+
+<Columns cols={2}>
+<Card title="Tools" href="/docs/tools">
+Connect providers, add custom tools, and expose them through secure MCP servers.
+</Card>
+<Card title="ChatKit" href="/docs/chatkit">
+Connect conversations, webhooks, and scheduled agent runs.
+</Card>
+```
+
+**Tool Result:** `TU-0346wWoR3JFbMoPUcP2maH`
+
+```
+Implemented: a local Flue/Vite demo with one Gherkin agent, Anthropic model, Hono route, React chat, and SQLite conversation persistence; core capture-store semantics are tested, but sweep/archive/plugin packs and production deployment remain planned. No deployment/IaC configuration found.
+
+- **Production entry / E2E:** [apps/dev/src/app.ts#L17-L43](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/app.ts#L17-L43) → [agent definition#L27-L58](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/agents/gherkin-elicitor.ts#L27-L58) → [Flue binding ask/suspend flow#L39-L92](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/src/index.ts#L39-L92) → [browser client bootstrap/replies#L46-L92](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/ui/chat.tsx#L46-L92).
+- **Architecture/dependencies:** core is substrate-free; plugin depends only on core; Flue binding owns dialect. [core exports#L1-L49](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/core/src/index.ts#L1-L49), [plugin scaffold#L3-L30](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/core/src/plugin.ts#L3-L30), [Gherkin tracer#L1-L19](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/plugin-gherkin/src/index.ts#L1-L19), [Flue capabilities#L30-L93](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/src/capabilities.ts#L30-L93).
+- **State/persistence:** implemented capture snapshot (captures/issues/events) and atomic JSON tmp+rename local store; live Flue conversations use SQLite at `BRUNCH_DEV_DB_PATH` or app-local `.data-wipe-me`. [capture model#L44-L166](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/core/src/capture-store.ts#L44-L166), [local store#L14-L76](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/src/local-capture-store.ts#L14-L76), [conversation DB#L1-L24](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/db-path.ts#L1-L24).
+- **Integrations/assumptions:** Anthropic `claude-haiku-4-5`; Flue runtime/SDK/React, Hono, Vite, Valibot. Node target; server and client require separate Vite builds and app-served assets. [agent model#L22-L30](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/agents/gherkin-elicitor.ts#L22-L30), [runtime config#L1-L5](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/flue.config.ts#L1-L5), [build/package commands#L7-L23](file:///Users/lunelson/Code/hashintel/brunch-lite/package.json#L7-L23), [dev build#L7-L28](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/package.json#L7-L28).
+- **Tests/evaluation/observability:** hermetic faux-provider walking skeleton verifies route/tool/reply binding; capture-store and persistence unit tests; CI runs lint/fmt/typecheck/test, where artifact tests build both bundles. [integration flow#L43-L120](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/test/walking-skeleton.integration.ts#L43-L120), [artifact gate#L34-L132](file:///Users/lunelson/Code/hashintel/brunch-lite/test/build-artifact.test.ts#L34-L132), [CI#L30-L54](file:///Users/lunelson/Code/hashintel/brunch-lite/.github/workflows/ci.yml#L30-L54), [open verification gaps#L63-L108](file:///Users/lunelson/Code/hashintel/brunch-lite/test/known-gaps.ts#L63-L108).
+- **Planned vs implemented:** CONTEXT/spec defines target-document session archives, sweeps, packs/projections, re-entry and multi-target architecture, but current binding implements only question transport; the plugin is identity-only. [CONTEXT state contract#L35-L47](file:///Users/lunelson/Code/hashintel/brunch-lite/CONTEXT.md#L35-L47), [planned storage/archive#L448-L471](file:///Users/lunelson/Code/hashintel/brunch-lite/docs/planning/elicitation-kernel/spec.md#L448-L471), [local-only/deploy deferred#L642-L657](file:///Users/lunelson/Code/hashintel/brunch-lite/docs/planning/elicitation-kernel/spec.md#L642-L657).
+- **ADR distinction:** ADR-0001 supersedes the draft spec’s provisional `bl_*` naming: implemented `brunch_*` and durable `brunch-gherkin-elicitor`; future assurance agent remains planned. [ADR decision/consequences#L32-L74](file:///Users/lunelson/Code/hashintel/brunch-lite/docs/adr/0001-brunch-is-the-product-name.md#L32-L74).
+```
+
+## Assistant
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/llms.txt",
+  "fullContent": true,
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/llms.txt",
+  "fullContent": true,
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/",
+  "objective": "Find Flue's authoritative conceptual model and documentation links for agents, hooks, state, tools, routing, testing/evals, observability, persistence, and deployment targets.",
+  "forceRefetch": true
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wXjaMFyTAK0i9dPbqK`
+
+````
+# Tilde
+
+> A platform for building and adding features to AI agents through a cloud API
+
+Tilde lets developers and agents configure off the shelf third-party tools, deploy custom tool endpoints, integrate agent's with third-party chat platforms and webhooks (Chatkit), manage agent skills and provide agents with integrated memory.
+
+## Key features:
+
+- Tools: Off the shelf integration with hundreds of providers, add your own custom tools & spin up secure MCP servers that house them
+- Memory: Create a peristent brain and personal notepad for your agent or share it across multiple agents
+- Skills: Deploy Skills registries to group skills together and make them available to agents
+- ChatKit: Integrate with third party chat providers, have external webhook events trigger agent runs or plan repeat prompts to run on schedule
+
+These features are all exposed through cloud API’s that hide away the detail.
+
+## Client libraries to help integrate with
+
+- Tilde Global MCP: https://api.trytilde.ai/mcp . This MCP server is the defacto way for agents to use and build Tilde. Use this MCP server to configure all runtime resources in Tilde, however this MCP server is not the same as agent MCP server (referenced in Tools product) which are used when wanting to invoke tools that you've configured
+- Tilde Rest API: If you are running in a sandbox that can make HTTP requests, and the Tilde Global MCP server can't perform the function that you would like, read the [canonical OpenAPI spec](https://trytilde.ai/openapi.json) and invoke the API at `https://api.trytilde.ai`. Use Oauth Authorization: Bearer xxx headers or x-api-key if provided by the user, or ask the user.
+- Harness SDK: When implementing a custom agent for a specific purpose, always use Vercel's AI SDK as the base framework and layer in Tilde's harness SDK, [@trytilde/harness-sdk](https://www.npmjs.com/package/@trytilde/harness-sdk) and [git repo here](https://github.com/trytilde/harness-sdk) to create agent endpoints. Read more about this in the ChatKit  page.
+- Any MCP client: Once you've configured an MCP server via Tilde's Tool product, you can connect any MCP client or agent that supports MCP clients to that deployed MCP server to invoke the configured tools. Read the docs pages about connecting your client on this website to find out how to connect popular existing agents via this route to Tilde's Global MCP server. connecting agent MCP server's are slightly different.
+
+## Organization, Team, Auth
+
+- Organisation: The top-level domain object for grouping resources. Use orgs for ownership and billing.
+- Teams / workspaces: Teams are sometimes called workspaces. Use teams for runtime isolation: agents, MCP servers, ChatKit providers, signals, API keys, and tool credentials should be team scoped. If you don't want an agent or human to access a specific tool, put it in a seperate team and don't provide that agent with an API key scoped to the new team.
+- Human users: Humans who sign in and user the paltform
+- Machine users: Often agents. When API keys are generated that are not tied to a human user, a machine user is provisioned, added to the relevant team and the API key associated to them.
+
+## Use Tilde without a human account
+
+If no human has created a Tilde account yet, create a temporary account through the unauthenticated REST endpoint. Do not block setup on human sign-in.
+
+```bash
+curl --request POST https://api.trytilde.ai/api/v1/identity/temporary-accounts \
+  --header "content-type: application/json" \
+  --data '{
+    "label": "code review agent",
+    "human_email": "owner@example.com"
+  }'
+````
+
+Both request fields are optional. The response creates a temporary organization and team and returns `org_id`, `team_id`, `api_key`, `claim_url`, `claim_pin`, `claim_token_expires_at`, and `expires_at`.
+
+1. Store the API key, claim URL, and six-digit PIN securely. Never commit or log them.
+2. Connect to `https://api.trytilde.ai/mcp` with the temporary key in the `x-api-key` header.
+3. Call `tilde_whoami`, then use the returned `team_id` with team-scoped Global MCP functions.
+4. Configure agents, tools, ChatKit, memory, skills, and other resources normally.
+5. Give the human the `claim_url` and `claim_pin` before the temporary account expires.
+
+The temporary account lasts 24 hours. Its claim URL lasts one hour. If the link expires while the account is still active, generate a fresh link with the temporary API key. The PIN does not change.
+Production claim links open under `https://trytilde.ai/app/temporary-accounts/claim/`; the claim API itself remains on `https://api.trytilde.ai`.
+
+```bash
+curl --request POST https://api.trytilde.ai/api/v1/identity/temporary-accounts/claim-url \
+  --header "x-api-key: $TILDE_API_KEY"
+```
+
+### Claim the temporary account
+
+When the human is ready:
+
+1. Sign in to Tilde and select the organization that should own the temporary account.
+2. Open the claim URL and enter the six-digit PIN.
+3. Wait for the claim page to confirm completion.
+4. Reconnect to Global MCP with human OAuth or a new team-scoped API key, then call `tilde_whoami` to find the transferred team.
+5. Update any stored MCP server, agent, or Tilde URLs. Claiming can change their organization-qualified URLs.
+
+Claiming transfers every team and supported resource from the temporary organization into the human's current organization. The temporary API key is revoked, so do not continue using it after the claim succeeds. Five incorrect PIN attempts expire the current claim link; use the temporary API key to generate a fresh link.
+
+## Authentication and scope in Global MCP
+
+1. Call `tilde_whoami` first.
+2. Select the target team from the returned identity. Teams are also called workspaces.
+3. Pass `team_id` to every team-scoped function on the global MCP server. The organization is inferred from the authenticated OAuth token or API key.
+4. Prefer OAuth when acting for a human. Use a team-scoped machine API key for a deployed agent.
+
+If a function returns `approval_url`, show it to the user. Then immediately call the returned `next_tool_name` with `next_tool_arguments` and wait for approval before continuing.
+
+## Rules to follow then integrating
+
+- For all org scoped API endpoints, you must provide the org ID. Preferrably in the domain path, e.g. https://$orgId.api.trytilde.ai/ . In case of any issues, you can provide org ID as a header as "x-tilde-org-id"
+- For all team scoped API endpoints, the route path always contains /team/{team_id}
+- All organisation and team scoped endpoints are available in Global MCP and take these params in the input schema
+- Global MCP and all runtime MCP servers support both [Oauth](https://modelcontextprotocol.io/specification/draft/basic/authorization) and API key headers via "x-api-key"
+- Prefer Oauth over API key where possible and always in cases where you are acting on behalf of a user. Most seperately deployed harness SDK agents will always use machine generated API keys, which are provided when user invokes create agent endpoints
+- For agent, tool endpoints and anywhere else mentioned, always secure the endpoints via the Harness SDK and provide webhook signing secrets which are generated on remote tool server and agent creation to validate inputs
+- When building, use dev tunnels if you need to test and publicaly expose agents and tools from your local environment to the public internet for Tilde to be able to test integration with. This will often require updating the agent or tool configurations to dev tunnel mode
+- Always export state of the Tilde team / workspace you're working in at tilde.state.yaml if you're commiting source code to a repo. This is infrastructure as code file that represents the configuration along with the agent source code that is required to deploy to a new environment.
+
+## Getting started
+
+### Common use cases
+
+#### Build a custom deployed agent
+
+Start from working code. Use the [Hello World agent](https://github.com/trytilde/examples/tree/main/hello-world-agent) for the smallest signed ChatKit endpoint. Use the [code review bot](https://github.com/trytilde/examples/tree/main/code-review-bot) for a production-shaped agent with tools, signals, typed provider context, reverse proxies, and portable state. Browse the full [Tilde examples repository](https://github.com/trytilde/examples) before inventing an integration pattern.
+
+Use the Vercel AI SDK with [`@trytilde/harness-sdk`](https://www.npmjs.com/package/@trytilde/harness-sdk). Keep `chatKitEndpoint`, webhook verification, ChatKit history conversion, and all secrets server-side.
+
+#### Leverage Tilde's tool control plane for an existing agent
+
+Read [Tools over Global MCP](https://trytilde.ai/docs/llms/tools.md), enable tool integrations with third party providers or others. Add them all to an agent MCP and connect it to an existing agent like Openclaw, Hermes, etc. [Follow connect your agent](https://trytilde.ai/docs/connect-your-agent) to see common guides on connecting to existing agents.
+
+## Agent configuration guides
+
+Use Tilde's global MCP server at `https://api.trytilde.ai/mcp` to configure runtime resources. Read the guide for the product you need:
+
+- [Tools over Global MCP](https://trytilde.ai/docs/llms/tools.md)
+- [ChatKit and Signals over Global MCP](https://trytilde.ai/docs/llms/chatkit.md)
+- [Memory banks and wikis over Global MCP](https://trytilde.ai/docs/llms/memory.md)
+- [Skills and registries over Global MCP](https://trytilde.ai/docs/llms/skills.md)
+- [Local development with Dev Tunnels](https://trytilde.ai/docs/llms/dev-tunnels.md)
+- [State export and import over Global MCP](https://trytilde.ai/docs/llms/state.md)
+
+These files are optimized for AI agents. The [human documentation](https://trytilde.ai/docs) explains the same products through the dashboard and SDK.
+
+## Pricing
+
+We are currently in early testing stages. Tilde is currently free, it will move to a SaaS billing model. Because memory banks are hosted, each Memory bank is billed at $20 p/ month, subject to change. These are opt-in only if you deploy and create a Memory bank.
+
+## Links
+
+- Homepage: https://trytilde.ai
+- Docs: https://trytilde.ai/docs
+- Global MCP: https://api.trytilde.ai/mcp
+- API & dashboard base URL: https://api.trytilde.ai
+- Blog: https://trytilde.ai/blog
+- npm (one CLI & Harness SDK): https://www.npmjs.com/package/@trytilde/harness-sdk
+
+````
+
+**Tool Error:** `TU-0346wXjctHi8IuhlaWZWgO`
+
+**Error:** {"message":"Could not read the page: http_error, HTTP 404"}
+
+**Tool Error:** `TU-0346wXjhHIsa3eJobCmBGt`
+
+**Error:** {"message":"Could not read the page: http_error, HTTP 404"}
+
+## Assistant
+
+**Tool Use:** `web_search`
+
+```json
+{
+  "objective": "Locate Flue Framework's authoritative documentation pages covering its agent execution model, hooks/tools, local development, conversation or agent state/persistence, client SDK, testing/observability, and Node/Cloudflare/CI deployment. Prefer flueframework.com official docs and the official GitHub repository.",
+  "max_results": 10,
+  "search_queries": [
+    "site:flueframework.com/docs Flue runtime targets persistence deployment",
+    "site:flueframework.com/docs Flue tools hooks agent lifecycle",
+    "site:flueframework.com/docs Flue testing observability SDK"
+  ]
+}
+````
+
+## User
+
+**Tool Result:** `TU-0346wXseijXSjBXzPBGqyo`
+
+````
+[
+  {
+    "url": "https://flueframework.com/docs/guide/observability",
+    "title": "Observability - Flue",
+    "excerpts": [
+      "---\ndescription: Observe agent activity through the runtime event stream — model turns, tool calls, logs, and token usage — and export it to your observability stack.\ntitle: Observability | Flue\nimage: https://flueframework.com/docs/og4.jpg\n---\n\n[Skip to content](#main-content)\n\nFlue emits everything its agents do — model turns, tool calls, structured logs, compactions, and settlements — as typed **runtime events** your application can observe in process. This surface is separate from the per-conversation message stream a chat UI reads, which belongs to [Routing](https://flueframework.com/docs/guide/routing/) and the [Flue Agent SDK](https://flueframework.com/docs/sdk/overview/).\nThis guide covers the two surfaces and when to use each, subscribing with `observe()`, what the event stream contains, token usage and provider diagnostics on model turns, tool activity and logs, exporting telemetry to Sentry, Braintrust, and OpenTelemetry, and how agent activity surfaces in Cloudflare’s platform observability.\n\n## Two event surfaces\n\nFlue exposes agent activity on two distinct surfaces:\n\n* The **conversation stream** is the product surface: one conversation’s durable, render-ready messages, data parts, and settlements, consumed over HTTP with [createFlueClient(...)](https://flueframework.com/docs/sdk/create-flue-client/) `observe()` / `history()`. [Routing](https://flueframework.com/docs/guide/routing/#reading-the-conversation) covers it.\n* The **runtime event stream** is the operational surface: live activity across every agent in the process — model requests, tool executions, logs, token counts, failures — consumed in process with [observe()](https://flueframework.com/docs/reference/events/#observe) from `@flue/runtime`. That stream is this guide’s subject.\n\nThe two APIs share a name but not a shape: the SDK client’s `observe()` maintains one conversation’s materialized message state, while the runtime’s `observe()` delivers raw activity events. Telemetry, metering, and error reporting belong on the runtime stream. The surfaces share correlation identifiers — a conversation message’s `submissionId` matches the runtime events its submission produced.\n\n## Subscribing with `observe()`\n\n`observe()` from `@flue/runtime` registers a global subscriber for all agent activity in the current process. Register it once at startup, at module top level in `app.ts` (or a module `app.ts` imports):\n\n```ts\n\n...\n\n* **Failures are contained.** A throwing subscriber is logged and skipped — it never halts the agent or other subscribers. Returned promises are observed for rejection but not awaited.\n\nThe subscription is **isolate-scoped and live-only**: it sees activity emitted in the current process from the moment it registers, with no durable replay and no cross-process aggregation. On Node.js one process hosts all agents, so one registration sees everything. On [Cloudflare](https://flueframework.com/docs/guide/cloudflare-target/), each agent conversation runs in its own Durable Object isolate — a subscriber registered from `app.ts` runs in each isolate and sees that isolate’s activity only. One placement caveat, shared with `setProvider()`: [flue run](https://flueframework.com/docs/cli/run/) loads only the agent module, never `app.ts` — register in the agent module when a subscriber must also run under the CLI.\n\n## What the stream contains\n\n...\n\n* `gatewayLogId` — the response’s own Cloudflare AI Gateway log id (`cf-aig-log-id`), for correlating a specific turn with its entry in the gateway dashboard.\n\nBoth are telemetry only — they never affect execution or replay — and are present only when the provider records them. The [Workers AI provider](https://flueframework.com/docs/guide/models/#cloudflare-workers-ai-cloudflare-only) attaches both today. A diagnostic observer for failed turns reads them directly from the event:\n\n```ts\nimport { observe } from '@flue/runtime';\n\nobserve((event) => {\n  if (event.type !== 'turn' || !event.isError) return;\n  console.error('model turn failed', {\n    provider: event.request.providerName,\n    model: event.request.requestedModel,\n    finishReason: event.response.finishReason,\n    providerFinishReason: event.response.providerFinishReason,\n    gatewayLogId: event.response.gatewayLogId,\n    error: event.response.error?.message,\n  });\n});\n```\n\n`request.\n\n...\n\nlog.info('sync started', { records: data.ids.length });\n  const failed = await crm.sync(data.ids);\n  if (failed.length > 0) log.error('sync incomplete', { failed: failed.length });\n  return { synced: data.ids.length - failed.length };\n}\n```\n\n```ts\nimport { observe } from '@flue/runtime';\nimport { logger } from './shared/logger.ts';\n\nobserve((event) => {\n  if (event.type !== 'log') return;\n  logger.log(event.level, event.message, {\n    ...event.attributes,\n    conversation: event.conversationId,\n  });\n});\n```\n\nLog lines are runtime events, not conversation content: they never appear in the messages a client renders, and they reach only in-process subscribers — forward them to your logging backend from an observer, or through one of the integrations below.\n\n## Choose an observability provider\n\nFor production telemetry, Flue ships integrations with three ecosystems rather than a bundled dashboard:\n\n* [Sentry](https://flueframework.\ncom/docs/ecosystem/tooling/sentry/) — terminal failures as issues, every log in Sentry Logs, and optional AI traces with content off by default. Add with `flue add tooling sentry`.\n* [Braintrust](https://flueframework.com/docs/ecosystem/tooling/braintrust/) — LLM tracing: operations as traces with model, tool, task, and compaction spans plus usage. Add with `flue add tooling braintrust`.\n* [OpenTelemetry](https://flueframework.com/docs/ecosystem/tooling/opentelemetry/) — standards-based GenAI spans, metrics, and logs for any OTel-compatible backend. Add `@flue/opentelemetry` to your OTel SDK setup.\n\nThe Sentry and Braintrust [blueprints](https://flueframework.com/docs/cli/add/) generate a source-root module that `app.ts` imports — an event bridge like the ones above, plus provider initialization. Span-producing integrations register through `instrument(...)`, which pairs an observer with an execution interceptor so spans wrap live agent, model, tool, and task execution:\n\n```ts\nimport { createOpenTelemetryInstrumentation } from '@flue/opentelemetry';\nimport { instrument } from '@flue/runtime';\n\ninstrument(createOpenTelemetryInstrumentation());\n```\n\nChoose Sentry when you want failures, logs, and traces in an existing application monitor, Braintrust when you want content-bearing LLM traces for inspection and evaluation, and OpenTelemetry when your organization standardizes on an OTel backend. They compose — an error reporter and a tracer can subscribe side by side. On Cloudflare, each integration exports per isolate and final flushes are best-effort; each tooling page documents its target-specific behavior.\n\n## Cloudflare\n\nOn the [Cloudflare target](https://flueframework.com/docs/guide/cloudflare-target/), agent work is also visible to the platform’s own observability products, with no Flue-side wiring.\nEach agent response runs as one unit of platform work — admission answers immediately, then the response executes start-to-settlement as a single invocation the platform can see and measure. [Workers Logs](https://developers.cloudflare.com/workers/observability/logs/workers-logs/) attribute tool and hook logs to the response that wrote them, and [Workers Traces](https://developers.cloudflare.com/workers/observability/traces/) capture one trace per response — model calls and other subrequests appear as spans inside it. Both are enabled in `wrangler.jsonc`; see [Deploy on Cloudflare](https://flueframework.com/docs/ecosystem/deploy/cloudflare/#observability) for configuration and the [Cloudflare target guide](https://flueframework.com/docs/guide/cloudflare-target/#durable-agent-execution) for the execution model behind the attribution.\n\nAgent-shaped spans are built in — with traces enabled, every response’s trace carries them, no wiring needed.\nTo customize the adapter (content policy, redaction), install it yourself once at `app.ts` module scope, which replaces the default:\n\n```ts\nimport { instrument } from '@flue/runtime';\nimport { createCloudflareTracing } from '@flue/runtime/cloudflare';\n\ninstrument(createCloudflareTracing({ content: false }));\n```\n\nSet [tracing: false](https://flueframework.com/docs/reference/configuration/#tracing) in `flue.config.ts` to drop agent tracing from the build.\n\nEach response’s trace carries an `invoke_agent` span wrapping the run, a `chat` span per model turn with token usage, and an `execute_tool` span per tool call, using the same OpenTelemetry GenAI naming Cloudflare’s own agent tracing emits — Flue agents read natively in the Traces dashboard. The spans carry the conversation by default: input and output messages, system instructions, and tool definitions, arguments, and results, so you can read what the agent actually said and did straight from the trace.\n\n...\n\ncom/docs/sdk/overview/) — the conversation stream your UI consumes.\n* [Agent Hooks](https://flueframework.com/docs/guide/agent-hooks/#event-hooks) — read usage and stamp response metadata from inside the agent.\n* [Sentry](https://flueframework.com/docs/ecosystem/tooling/sentry/), [Braintrust](https://flueframework.com/docs/ecosystem/tooling/braintrust/), and [OpenTelemetry](https://flueframework.com/docs/ecosystem/tooling/opentelemetry/) — per-integration setup and content policies.\n* [Evals](https://flueframework.com/docs/guide/evals/) — turn observed behavior into scored regression checks.\n\n## Docs Navigation\n\nCurrent page: [Observability](https://flueframework.com/docs/guide/observability/)\n\n### Sections\n\n* [Guide](https://flueframework.com/docs/guide/getting-started/)\n* [Reference](https://flueframework.com/docs/reference/agent-api/)\n* [CLI](https://flueframework.com/docs/cli/overview/)\n* [Agent SDK](https://flueframework.com/docs"
+    ]
+  },
+  {
+    "url": "https://flueframework.com/docs/guide/agent-hooks/",
+    "title": "Agent Hooks - Flue",
+    "excerpts": [
+      "---\ndescription: Compose an agent's capabilities — model, tools, skills, state, and lifecycle — with Flue's hook primitives.\ntitle: Agent Hooks | Flue\nimage: https://flueframework.com/docs/og4.jpg\n---\n\n[Skip to content](#main-content)\n\nAn agent function can return instructions, but instructions aren’t much on their own. A real agent needs tools, skills, subagents, a sandbox, and persistent data to work with. All agent functionality and resources come from Flue’s second core primitive — **agent hooks**.\n\nThis guide covers what hooks are, the built-in hooks Flue ships with, and how to compose them into hooks of your own. (New to Flue? Be sure to read the [Agents guide](https://flueframework.com/docs/guide/building-agents/) first.)\n\n## What is an agent hook?\n\nA hook is a plain function that you call inside your agent function’s body to give your agent one new capability. You can spot hooks by their names — they all start with `use`.\nEach built-in hook lets your agent hook into a different feature of the Flue runtime:\n\n* [Model](https://flueframework.com/docs/guide/models/) (`useModel`) selects the LLM that powers the agent.\n* [Sandbox](https://flueframework.com/docs/guide/sandboxes/) (`useSandbox`) provides its filesystem and command-execution environment.\n* [Tools](https://flueframework.com/docs/guide/tools/) (`useTool`) let it call application code and affect external systems.\n* [MCP servers](https://flueframework.com/docs/guide/mcp/) (`useMcpConnection`) mount tools from the open MCP ecosystem.\n* [Skills](https://flueframework.com/docs/guide/skills/) (`useSkill`) provide expertise it can load when needed.\n* [Subagents](https://flueframework.com/docs/guide/subagents/) (`useSubagent`) let it delegate focused work to other agents.\n* [Persisted State](#persisted-state) (`usePersistentState`) preserves custom data across the agent lifetime.\n* [Event Hooks](#event-hooks) (`useAgentStart`, `useAgentFinish`, and others) trigger logic on different lifecycle events.\n* [Data Writers](#streaming-data-to-the-client) (`useDataWriter`) stream structured data to your client UI.\n* [Custom Hooks](#custom-hooks) let you compose new hooks out of the built-ins.\n\n```ts\n'use agent';\nimport { useModel, useSandbox, useSkill, useTool } from '@flue/runtime';\nimport { local } from '@flue/runtime/node';\nimport { searchIssues } from '../tools/search-issues.ts';\nimport reviewChecklist from '../skills/review-checklist/SKILL.md';\n\nexport function TriageAgent() {\n  useModel('anthropic/claude-sonnet-4-6');\n  useSandbox(local());\n  useTool(searchIssues);\n  useSkill(reviewChecklist);\n  return 'Investigate the reported issue and recommend the next action.';\n}\n```\n\nSimilar to React, the agent function _re-renders_ on every model call and re-runs its hooks. Unlike React, resource hooks can be added and removed conditionally.\nThis allows Flue to manage your declared agent capabilities for you automatically, adding and removing resources (tools, skills, subagents, etc.) as your conversation with the agent evolves:\n\n```ts\n'use agent';\nimport { useModel, usePersistentState, useTool } from '@flue/runtime';\nimport refundTool from '../tools/refund.ts';\n\nexport function SupportAgent() {\n  useModel('anthropic/claude-haiku-4-5');\n  const [escalated, setEscalated] = usePersistentState('escalated', false);\n  // Tools can modify persisted state.\n  useTool({\n    name: 'escalate',\n    description: 'Escalate this conversation when the customer needs a refund.',\n    async run() {\n      setEscalated(true);\n      return 'Escalated. The refund tool is now available.';\n    },\n  });\n  // If the agent has determined that the conversation needs escalation,\n  // the \"refund\" tool is unlocked and made available to the agent.\n  if (escalated) {\n    useTool(refundTool);\n  }\nreturn 'Answer customer support questions clearly and accurately.';\n}\n```\n\nFlue handles this complexity for you, announcing each change to the model so the transcript stays coherent. Changing the tool set can invalidate the provider’s prompt cache (see [the conditional-tools note](https://flueframework.com/docs/guide/tools/#conditional-tools)).\n\nEvery built-in hook is documented in the [Agent API](https://flueframework.com/docs/reference/agent-api/) reference.\n\n## Persisted state\n\nAn agent conversation can live for days or months, and along the way the agent learns things worth keeping: which phase of a workflow it’s in, what it has already checked, decisions it has made. `usePersistentState` gives that knowledge a durable home:\n\n```ts\n'use agent';\nimport { useModel, usePersistentState, useTool } from '@flue/runtime';\n\nexport function CaseAssistant() {\n  useModel('anthropic/claude-haiku-4-5');\n  const [phase, setPhase] = usePersistentState('phase', 'gathering');\n\n...\n\ncom/docs/guide/sandboxes/) — configure what an agent can do and where it works.\n* [Subagents](https://flueframework.com/docs/guide/subagents/) — delegate focused work to a specialist agent function.\n* [Durability](https://flueframework.com/docs/guide/durability/) — how persistent state, retries, and recovery work.\n\n## Docs Navigation\n\nCurrent page: [Agent Hooks](https://flueframework.com/docs/guide/agent-hooks/)\n\n### Sections\n\n* [Guide](https://flueframework.com/docs/guide/getting-started/)\n* [Reference](https://flueframework.com/docs/reference/agent-api/)\n* [CLI](https://flueframework.com/docs/cli/overview/)\n* [Agent SDK](https://flueframework.com/docs/sdk/overview/)\n* [Ecosystem](https://flueframework.com/docs/ecosystem/)"
+    ]
+  },
+  {
+    "url": "https://blog.cloudflare.com/agents-platform-flue-sdk",
+    "title": "Bringing more agent harnesses and frameworks to Cloudflare ...",
+    "excerpts": [
+      "Bringing more agent harnesses and frameworks to Cloudflare ...\nFlue agents can run completely headlessly for background tasks, but @flue/react provides native frontend hooks that stream an agent's state,"
+    ]
+  },
+  {
+    "url": "https://github.com/withastro/flue",
+    "title": "withastro/flue: The sandbox agent framework. - GitHub",
+    "excerpts": [
+      "withastro/flue: The sandbox agent framework. - GitHub\n2 days ago · Observability — Monitor your agents and export telemetry with OpenTelemetry, Braintrust, Sentry, or your own observer. Channels — Receive"
+    ]
+  },
+  {
+    "url": "https://github.com/withastro/flue/blob/main/AGENTS.md",
+    "title": "flue/AGENTS.md at main · withastro/flue · GitHub",
+    "excerpts": [
+      "# withastro/flue — AGENTS.md\n\n- Page: GitHub code file\n- URL: https://github.com/withastro/flue/blob/main/AGENTS.md\n- Repository: withastro/flue\n- Path: AGENTS.md\n- Ref: main\n- Lines: 53\n\n---\n\n# Flue\n\nFlue is a TypeScript framework for building autonomous AI agents and running them anywhere. An agent is a plain exported function: hooks in its body compose its capabilities — model (`useModel`), tools, skills, sandboxes, state — and its return value is its instruction. Agents live in durable conversations: accepted input survives crashes, restarts, and redeploys, and interrupted work recovers to a deterministic state. Applications build with Vite (the `flue()` plugin plus an explicit `app.ts` route map) and deploy to Node.js or Cloudflare Workers from the same source, with persistence adapters (SQLite, Postgres, MySQL, MongoDB, Redis, and more), channels that turn provider webhooks (Slack, GitHub, Telegram, ...\n) into agent conversations, and clients — the Flue Agent SDK (`@flue/sdk`), `@flue/react`, and the `flue` CLI — for driving conversations over HTTP or from code. The model layer is [Pi](https://pi.dev)'s provider protocol, used directly.\n\n## Contributing\n\nSee `CONTRIBUTING.md` for the full picture. In short:\n\n- **Bug reports** → https://github.com/withastro/flue/issues\n- **Feature requests** → https://github.com/withastro/flue/discussions\n- **Pull requests** are not accepted; they are automatically closed and converted into one of the two contribution types above.\n\n## Terminology\n\n```\nAgent                         — a capitalized, exported plain function; Flue Hooks in its body attach\n                                tools, instructions, and state, and its returned string is its\n                                instruction; the function name (or its `agentName` string-literal\n                                static) is the agent's durable identity\n\n...\n\nts` is the application's route map, mounting each HTTP-reachable agent (`app.route('/agents/<name>', createAgentRouter(AgentFn))`) and channel (`app.route('/channels/<x>', channel.route())`). Registration comes from the `'use agent'` scan, not from mounting.\n\nA blueprint is a Markdown implementation guide returned by `flue add`; its kind is `sandbox`, `database`, `channel`, or `tooling`.\n\n## Project Structure\n\n- `packages/runtime/` — Runtime library (`@flue/runtime`): sessions, agent harnesses, tools, sandbox plumbing, and the `/config` loader for `flue.config.ts`.\n- `packages/vite/` — The `flue()` Vite plugin (`@flue/vite`): `'use agent'` scan/transform, generated bootstraps, Node dev/build, and the Cloudflare target adapter.\n- `packages/cli/` — CLI (`@flue/cli`): `flue run` transport-free local execution, `init`, blueprint `add`/`update`, and offline `docs`.\n- `examples/` — Integration examples for channels, databases, sandboxes, and deployment targets.\n- `demo/` — Standalone Vite+React chat SPA that connects to any running Flue example server.\n- `apps/docs/` — The documentation site; its content is the source of truth for user-facing docs.\n\nNo tests exist in the repo.\n\n## Development\n\n```\npnpm install\npnpm build          # turbo build across the workspace\npnpm check:types    # typecheck (excludes apps-www)\npnpm format         # format your work\n```"
+    ]
+  },
+  {
+    "url": "https://code.claude.com/docs/en/agent-sdk/hooks",
+    "title": "Intercept and control agent behavior with hooks",
+    "excerpts": [
+      "With hooks, you can: This guide covers how hooks work, how to configure them, and provides examples for common patterns like blocking tools, modifying inputs, and forwarding notifications."
+    ]
+  },
+  {
+    "url": "https://www.npmjs.com/package/%40flue/sdk",
+    "title": "@flue/sdk - npm",
+    "excerpts": [
+      "The first agents were built with raw LLM API calls. This worked for simple chatbots and scripted tasks, but not much else.\n\nAgents like Claude Code and Codex broke the mold. These were _real agents._ Autonomous. You give them a task — not a pre-defined series of steps — and trust them to complete it using the context and tools that you provide.\n\n**Flue unlocks this new architecture for agents.** Its built-in TypeScript harness gives any model the context and environment it needs for truly autonomous work: sessions, tools, skills, instructions, filesystem access, and a secure sandbox to run in. Run your agents locally via CLI or deploy them to your hosted runtime of choice.\n\n## Features\n\nBuild agents that can safely take action, maintain continuity, and connect to the systems where work already happens.\n\n* **[Agents](https://flueframework.com/docs/guide/building-agents/)** — Build agents that can keep context across conversations and events as they autonomously work toward a goal.\n\n...\n\ncom/docs/guide/tools/)** — Connect agents to authenticated tools and services through the open Model Context Protocol ecosystem.\n* **[Observability](https://flueframework.com/docs/guide/observability/)** — Monitor your agents and export telemetry with [OpenTelemetry](https://flueframework.com/docs/ecosystem/tooling/opentelemetry/) , [Braintrust](https://flueframework.com/docs/ecosystem/tooling/braintrust/) , [Sentry](https://flueframework.com/docs/ecosystem/tooling/sentry/) , or your own observer.\n* **[Channels](https://flueframework.com/docs/guide/channels/)** — Receive verified events from Slack, Teams, Discord, GitHub, and more.\n\n## Deploy Anywhere\n\n* **[Node.js](https://flueframework.com/docs/ecosystem/deploy/node/)**\n* **[Cloudflare Workers](https://flueframework.com/docs/ecosystem/deploy/cloudflare/)**\n* **[GitHub Actions](https://flueframework.com/docs/ecosystem/deploy/github-actions/)**\n* **[GitLab CI/CD](https://flueframework.com/docs/ecosystem/deploy/gitlab-ci/)**\n* **[Daytona](https://flueframework.com/docs/ecosystem/sandboxes/daytona/)**\n* **[Render](https://flueframework.com/docs/ecosystem/deploy/render/)**\n\n## Packages\n\n|Package |Description |\n| --- | --- |\n|[`@flue/runtime`](https://github.com/withastro/flue/blob/HEAD/packages/sdk/packages/runtime) |Runtime: harness, sessions, tools, sandbox |\n|[`@flue/vite`](https://github.com/withastro/flue/blob/HEAD/packages/sdk/packages/vite) |Vite plugin: `vite dev` / `vite build` for Node and Cloudflare |\n|[`@flue/cli`](https://github.com/withastro/flue/blob/HEAD/packages/sdk/packages/cli) |CLI ( `flue` binary): local runs, blueprints, offline docs |\n|[`@flue/sdk`](https://github.com/withastro/flue/blob/HEAD/packages/sdk/packages/sdk) |Client SDK for consuming deployed agent conversations |\n|[`@flue/opentelemetry`](https://github.com/withastro/flue/blob/HEAD/packages/sdk/packages/opentelemetry) |OpenTelemetry tracing adapter |\n|[`@flue/postgres`](https://github.\ncom/withastro/flue/blob/HEAD/packages/sdk/packages/postgres) |Postgres persistence adapter |\n\n## Readme\n\n### Keywords\n\nnone\n\n## Package Sidebar\n\n### Install\n\n`npm i @flue/sdk`\n\n### Repository\n\n[github.com/withastro/flue](https://github.com/withastro/flue)\n\n### Homepage\n\n[flueframework.com/](https://flueframework.com/)\n\n### Weekly Downloads\n\n96,434\n\n### Version\n\n2\\.0.3\n\n### License\n\nApache-2.0\n\n### Last publish\n\n2 days ago\n\n### Collaborators\n\n* fredkschott\n  \n  fredkschott\n\n[**Analyze security** with Socket](https://socket.dev/npm/package/%40flue%2Fsdk) [**Check bundle size**](https://bundlephobia.com/package/%40flue%2Fsdk) [**View package health**](https://snyk.io/advisor/npm-package/%40flue%2Fsdk) [**Explore dependencies**](https://npmgraph.js.org/?q=%40flue%2Fsdk)\n\n[**Report** malware](https://www.npmjs.com/support?inquire=security&security-inquire=malware&package=%40flue%2Fsdk&version=2.0.3)\n\n## Footer\n\n[](https://github.com/npm)\n\n[](https://github.com)\n\n### Support"
+    ]
+  },
+  {
+    "url": "https://betterstack.com/community/guides/ai/flue-framework",
+    "title": "Flue: Headless, Programmable AI Agent Framework from the Astro Team | Better Stack Community",
+    "excerpts": [
+      "Back to AI guides\n\n# Flue: Headless, Programmable AI Agent Framework from the Astro Team\n\nStanley Ulili\n\nUpdated on June 8, 2026\n\n###### Contents\n\n* The harness concept\n* Installation and setup\n* Creating an agent\n* Building a workflow with a skill\n* Sandboxes\n* Exposing a workflow as an HTTP endpoint\n* Final thoughts\n\n[Flue](https://github.com/withastro/flue) is an **open-source TypeScript framework for building AI agents** , developed by the Astro team. It was originally built to automate AI workflows inside Astro's own GitHub repositories. Its design is headless and programmable: **agents can run without a human present** , triggered by API calls, webhooks, or cron jobs, and deployable to Node.js or Cloudflare Workers.\n\n## The harness concept\n\nFlue's documentation defines an AI agent as an LLM running inside a harness.\nThe LLM provides reasoning capability; the harness provides the tools, context, memory, and environment the LLM needs to interact with external systems and complete tasks.\n\nWithout a harness, an LLM responds to individual API calls with no persistent state and no tool access. Flue is the programmable harness layer: it provides session management, tool and skill execution, sandbox environments, and a structured output format.\n\nDocumentation page for \"What is an agent?\" illustrating the concept of an LLM running inside a harness\n\n## Installation and setup\n\nCopied!\n\n```\nmkdir flue-tutorial && cd flue-tutorial\n```\n\nCopied!\n\n```\nnpm install @flue/runtime\n```\n\nCopied!\n\n```\nnpm install --save-dev @flue/cli\n```\n\nCreate a `.env` file with your LLM provider API key:\n\n.env\n\nCopied!\n\n```\nANTHROPIC_API_KEY=\"your-anthropic-api-key-here\"\n```\n\nInitialize the project configuration:\n\nCopied!\n\n```\nnpx flue init --target node\n```\n\nThis creates `flue.config.ts` :\n\nflue.config.ts\n\nCopied!\n\n```\nimport { defineConfig } from '@flue/cli/config';\n\nexport default defineConfig({\n  target: 'node',\n});\n```\n\n`target` can be `'node'` (Node.js server using Hono) or `'cloudflare'` (Cloudflare Worker with Durable Objects for persistence).\n\nFlue documentation showing the installation and initialization commands\n\n## Creating an agent\n\nFlue looks for agent definitions in an `agents/` directory. The filename becomes the agent's ID.\n\nCopied!\n\n```\nmkdir agents\n```\n\nagents/hello-world.ts\n\nCopied!\n\n```\nimport { createAgent } from '@flue/runtime';\n\nexport default createAgent(() => ({\n  model: 'anthropic/claude-3.5-sonnet',\n  instructions: 'Tell a funny \"hello world\" engineering joke.',\n}));\n```\n\nConnect to the agent interactively:\n\nCopied!\n\n```\nnpx flue connect hello-world local-session\n```\n\n`local-session` is the instance ID. It identifies this conversation and enables session persistence across interactions.\n\nAfter the agent responds, Flue prints a JSON summary:"
+    ]
+  },
+  {
+    "url": "https://code.claude.com/docs/en/hooks",
+    "title": "Hooks reference - Claude Code Docs",
+    "excerpts": [
+      "Hooks reference - Claude Code Docs\nIn addition to command, HTTP, and MCP tool hooks, Claude Code supports prompt-based hooks (type: \"prompt\") that use an LLM to evaluate whether to allow or block an action, and agent hooks (type: \"agent\") that spawn an agentic verifier with tool access."
+    ]
+  },
+  {
+    "url": "https://www.daytona.io/docs/en/guides/flue/flue-autonomous-bug-fix-agent",
+    "title": "Build an Autonomous Bug-Fix Agent with Flue and Daytona",
+    "excerpts": [
+      "# Build an Autonomous Bug-Fix Agent with Flue and Daytona\n\nCopy for LLM [View as Markdown](https://www.daytona.io/docs/en/guides/flue/flue-autonomous-bug-fix-agent.md) Open\n\nThis guide builds an autonomous bug-fix agent using [Flue](https://flueframework.com/) and [Daytona](https://www.daytona.io/) sandboxes. Given a GitHub issue, the agent reproduces the bug with a failing test, implements the minimal fix, runs the full test suite, and opens a real pull request.\n\nA sandbox is essential for this workflow. The agent clones unknown code, installs unknown dependencies, and executes the project’s test suite — operations that need strict isolation from your host. Daytona provisions a fresh isolated environment for every run and tears it down on completion, so an untrusted repository can never affect your host.\n\n* * *\n\n### 1\\. Workflow Overview\n\nSection titled “1. Workflow Overview”\n\nYou point the agent at an open issue on any GitHub repository.\n\n...\n\n```\n\nFlue boots a webhook server on port `3583` and discovers the `bug-fix` agent automatically:\n\n```\n[flue] Starting dev server (target: node) [flue] Target: node [flue] Found 1 role(s): test-driven-developer [flue] Found 1 agent(s): bug-fix [flue] Webhook agents: bug-fix [flue] Built: dist/server.mjs [flue] Server: http://localhost:3583 [flue] Try: curl -X POST http://localhost:3583/agents/bug-fix/test-1 \\ -H 'Content-Type: application/json' -d '{}' [flue] Press Ctrl+C to stop\n```\n\n#### Trigger the Agent\n\nSection titled “Trigger the Agent”\n\nThere are three equivalent ways to trigger the agent. Pick whichever fits your workflow.\n\n**Option A: drive everything from `.env`** (default sync mode). With `DEMO_REPO=your-username/your-fork` and `DEMO_ISSUE=<number>` set in `.env` , fire an empty payload:\n\nTerminal window\n\n```\ncurl -X POST http://localhost:3583/agents/bug-fix/run-1 \\ -H \" Content-Type: application/json \" \\ -d ' {} '\n```\n\n**Option B: pass the target per call** (default sync mode).\n\n...\n\nThe role is referenced in the skill call ( `role: 'test-driven-developer'` ) and shapes how the agent makes tradeoffs (minimal change, match host code style, never disable existing tests).\n\n#### How `bug-fix.ts` is actually invoked\n\nSection titled “How bug-fix.ts is actually invoked”\n\nNothing in our code calls our agent’s default export directly; Flue’s CLI does. Here’s the full chain from `npm run dev` to `handler(ctx)` :\n\n**Build time ( `flue dev` startup):**\n\n1. `flue dev --target node` calls `dev()` from `@flue/sdk` , which runs `build()` .\n2. `build()` does `fs.readdirSync('.flue/agents')` and keeps any entry matching `/\\.(ts|js|mts|mjs)$/` . Our `bug-fix.ts` matches → agent name is `bug-fix` (filename without extension).\n3. For each agent file, Flue uses the TypeScript AST to find the static `export const triggers = {...}` declaration, validating that `webhook` is `true` or `false` . Our `triggers = { webhook: true }` registers the agent for HTTP access.\n4.\n\n...\n\n[flue] Agent started I'll work through this systematically following the test-driven approach. [flue] tool:start  read  /home/daytona/project/package.json [flue] tool:done   read  (1477 chars) [flue] tool:start  glob  **/*.test.* [flue] tool:done   glob [flue] tool:start  read  /home/daytona/project/src/index.ts [flue] tool:start  read  /home/daytona/project/src/parse.test.ts [flue] tool:done   read  (5864 chars) [flue] tool:done   read  (5082 chars) Now I have a clear picture. Let me verify what `format(Number.MAX_VALUE)` actually produces, then set up the branch and write the failing test: [flue] tool:start  bash  $ node -e \"const out = ms(Number.MAX_VALUE); ...\" [flue] tool:done   bash  (218 chars) I've confirmed the bug: format(Number.MAX_VALUE) produces \"5.696545792019405e+297y\" which the regex in parse() cannot match."
+    ]
+  }
+]
+````
+
+## Assistant
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/building-agents/",
+  "objective": "Extract Flue's agent programming model, runtime lifecycle, identity, local authoring loop, and constraints relevant to an existing TypeScript agent application.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/durability/",
+  "objective": "Extract Flue's guarantees and limitations for durable conversations, persistence, retries, crash/redeploy recovery, idempotency, and Node versus Cloudflare behavior.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/routing/",
+  "objective": "Extract Flue's server/API routing contract, admission and async execution model, conversation endpoints, auth/security boundaries, and app integration requirements.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/evals/",
+  "objective": "Extract Flue's development-time testing and evaluation workflow, local commands, fixture/model behavior, assertions, and CI story.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/ecosystem/deploy/node/",
+  "objective": "Extract the complete operational deployment story for Flue on Node: build artifact, runtime, database/persistence, process model, scaling, required environment, and platform examples.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/ecosystem/deploy/cloudflare/",
+  "objective": "Extract the complete Flue Cloudflare deployment story: build/deploy steps, Durable Object binding/state, execution limits, secrets, migrations, scaling, observability, and platform coupling.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/llms/chatkit.md",
+  "objective": "Extract Tilde's custom agent development and operation model: Harness SDK, Vercel AI SDK, endpoints, triggers/signals/history, security, local development, and deployment requirements.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/llms/dev-tunnels.md",
+  "objective": "Extract Tilde's local development and remote integration testing story, including tunnel setup, configuration changes, security, and failure modes.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/llms/state.md",
+  "objective": "Extract Tilde's infrastructure-as-code/export/import and environment promotion story, including what state captures, secret handling, portability, drift, and deployment workflow.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/connect-your-agent",
+  "objective": "Extract how Tilde integrates into existing agents via MCP, what remains hosted by Tilde versus the application, supported clients, auth requirements, and operational boundaries.",
+  "forceRefetch": true
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wYZNq29Fo2EvdVthHG`
+
+````
+# description: Create an agent, configure its capabilities, and send it messages over time.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+An agent function represents an agent in Flue. In Flue, an agent is a JavaScript function that returns the agent’s `system` prompt instructions. Those instructions are rendered, and then passed to the LLM along with the user and assistant messages that make up some agent conversation or workflow.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+```ts
+// Example: A simple agent, written in Flue.
+function TriageAgent() {
+  return "Investigate the user's issue and recommend the next action.";
+}
+````
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+An agent is always initialized with an ID. You can provide one via the `--id` flag to `flue run` (optional) or the `POST /:id` route of a hosted agent (required). It’s up to you what the ID means — a user ID, a support ticket, a GitHub issue number, or just a random string.
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+
+```ts
+function TriageAgent({ id }) {
+  return `Investigate GitHub issue #${id} and recommend the next action.`;
+}
+```
+
+There are other ways to pass (structured) data to your agent — see [Passing data to the agent](https://flueframework.com/docs/guide/agent-hooks/) in the Agent Hooks guide.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+The agent function _re-renders_ on every turn. That is, every time the model is about to be called, Flue runs your function again and rebuilds its instructions from scratch. The string you return always reflects the agent’s current state at that moment:
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Functions
+If it helps, you can think of an agent function as similar to a React component render function. This is not accidental, as you’ll soon see below: Flue agent functions were intentionally modeled after React to help unlock more expressive, more powerful agent functionality.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Hooks
+An agent function isn’t much on its own. It returns instructions, but a working agent needs more than words — a model, tools, a workspace, memory. To unlock all of that, you’ll reach for Flue’s second core primitive: **agent hooks**.
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Hooks
+
+- [Model](https://flueframework.com/docs/guide/models/) (`useModel`) selects the LLM that powers the agent.
+- [Sandbox](https://flueframework.com/docs/guide/sandboxes/) (`useSandbox`) provides its filesystem and command-execution environment.
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Hooks
+
+- [Persisted State](https://flueframework.com/docs/guide/agent-hooks/) (`usePersistentState`) preserves custom data across the agent lifetime.
+- [Event Hooks](https://flueframework.com/docs/guide/agent-hooks/) (`useAgentStart`, `useAgentFinish`, and others) trigger logic on different lifecycle events.
+  title: Agents | Flue
+  image: https://flueframework.com/docs/og4.jpg > Agent Hooks
+
+````ts
+import { useModel, useSandbox, useSkill, useTool } from '@flue/runtime';
+import { local } from '@flue/runtime/node';
+import { searchIssues } from '../tools/search-issues.ts';
+import reviewChecklist from '../skills/review-checklist/SKILL.md';
+
+function Triage() {
+  useModel('anthropic/claude-sonnet-4-6');
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Agent Hooks
+```ts
+  useSandbox(local());
+  useTool(searchIssues);
+  useSkill(reviewChecklist);
+  return 'Investigate the reported issue and recommend the next action.';
+}
+````
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > “use agent” Directive
+
+```ts
+"use agent";
+import { useModel } from "@flue/runtime";
+
+export function TriageAgent() {
+  useModel("anthropic/claude-sonnet-4-6");
+  return "Investigate the reported issue and recommend the next action.";
+}
+```
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > “use agent” Directive
+Registration is what makes an agent addressable by the rest of your application: `dispatch(...)` can send it messages, and `createAgentRouter(...)` can serve it over HTTP. The exported function’s name also becomes the agent’s durable identity, which keys its conversation storage in the persistent database.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > “use agent” Directive
+To rename the function without a database migration, pin the identity with the [agentName static](https://flueframework.com/docs/reference/agent-api/). Setting an explicit agent name is considered a best-practice by some Flue developers.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > “use agent” Directive
+
+```ts
+"use agent";
+import { useModel } from "@flue/runtime";
+
+export function TriageAgent() {
+  useModel("anthropic/claude-sonnet-4-6");
+  return "Investigate the reported issue and recommend the next action.";
+}
+
+TriageAgent.agentName = "triage-agent";
+```
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent
+There are several ways to interact with an agent. All of them run the same agent and durability APIs — they differ only in how the runtime starts and whether an HTTP server exists.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > CLI
+The easiest way to interact with your agent is locally, with the `flue run` CLI command:
+
+```bash
+flue run src/agents/triage-agent.ts --message "Triage issue 17307"
+```
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > CLI
+This runs one agent module directly — no server, no application build. Pass `--id` to name the conversation so you can continue it across invocations; without it, each run starts a fresh conversation and prints its generated id:
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > CLI
+
+```bash
+flue run src/agents/triage-agent.ts --id issue-17307 --message "Look at issue 17307"
+flue run src/agents/triage-agent.ts --id issue-17307 --message "Any update?"
+```
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > CLI
+Conversations persist between runs — in your project’s configured database, or a local cache file without one. See the [flue run reference](https://flueframework.com/docs/cli/run/) for agent selection, structured output, and the full flag list.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > HTTP
+Agents mounted in your application are served over HTTP (mounting is covered in [Routing](https://flueframework.com/docs/guide/routing/)). Each conversation has its own URL, ending in the conversation id. `POST` a message to it:
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > HTTP
+Prompts are fire-and-forget: the server responds `202` immediately, and the agent’s reply is read from the conversation — `GET` the same URL to follow its events, or use the [Flue Agent SDK](https://flueframework.com/docs/sdk/overview/), which wraps the whole surface (`send()`, `wait()`, `observe()`, `history()`) around one
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > `dispatch()`
+Your application chooses the agent conversation before dispatching the event. `dispatch(...)` accepts it for asynchronous processing rather than waiting for an agent response. Because registration comes from the `'use agent'` scan, an agent used only through `dispatch(...)` needs no mount at all.
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > Standalone scripts
+Finally, you can run agents outside of a Flue application entirely — no server, no `app.ts` — with the more advanced `start()` API. It boots the Flue runtime inside your own Node.js process, which is useful for cron jobs, one-off scripts, and tests:
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > Standalone scripts
+
+```ts
+import { init } from "@flue/runtime";
+import { sqlite, start } from "@flue/runtime/node";
+import { Reporter } from "../src/agents/reporter.ts";
+
+await using flue = await start({
+  agents: [Reporter],
+  db: sqlite("./nightly.db"),
+});
+
+const reporter = init(Reporter, { id: "nightly-2026-07-16" });
+```
+
+...
+
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > Standalone scripts
+Provider credentials come from the process environment, and the `db` option decides whether conversations outlive the script: omit it for in-memory state, or pass an adapter like `sqlite()` so a later run can continue the same conversation.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Interacting with your agent > Standalone scripts
+Inside an already-running Flue application there is no `start()` — call `init()` or `dispatch()` directly. The [Workflows](https://flueframework.com/docs/guide/workflows/) guide covers this scripting surface in depth, from CI pipelines to durable orchestration.
+title: Agents | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Agent Hooks](https://flueframework.com/docs/guide/agent-hooks/) — compose your agent’s capabilities: tools, skills, state, and event hooks.
+- [Agent API](https://flueframework.com/docs/reference/agent-api/) — look up session operations and their results.
+
+```
+
+**Tool Result:** `TU-0346wYZOELetURr1MvNudi`
+
+```
+
+# description: The accepted-work contract — what survives crashes, restarts, and redeploys, and how interrupted agent work recovers.
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Submissions and the accepted-work contract
+
+> Every accepted submission reaches exactly one durable terminal outcome — `completed`, `failed`, or `aborted` — no matter how many crashes happen in between.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Submissions and the accepted-work contract
+response runs as its own submission. Processing happens in **attempts**: a coordinator claims the submission, runs it, and settles it. An interruption consumes the attempt; recovery claims a new one, up to the retry budget.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+A crash leaves no record of itself — the dead process stops writing. Recovery runs when a replacement owner wakes (how that happens is per-target) and works exclusively from durable evidence: the canonical conversation records, the submission’s admission row, and its attempt bookkeeping.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+Recovery proceeds in two phases. First it **converges** the stream: any partially streamed assistant output the dead attempt persisted is closed out as an aborted entry — unconditionally and idempotently, so no crash shape can leave the conversation looking mid-stream.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+| Durable evidence after the input | What recovery does |
+| The input was never persisted | Requeues the submission for a clean first attempt. |
+| A partial response with text or reasoning | Tells the model its stream was interrupted and continues from the durable partial. |title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+| Durable evidence after the input | What recovery does |
+| The input was never persisted | Requeues the submission for a clean first attempt. |
+| A tool turn with unresolved calls | Repairs the tool batch (below), then continues the turn loop. |title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+| Durable evidence after the input | What recovery does |
+| The input was never persisted | Requeues the submission for a clean first attempt. |
+| A transient provider error (rate limit, outage) | Retries the turn after a backoff, under a bounded error budget. |title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+| Durable evidence after the input | What recovery does |
+| The input was never persisted | Requeues the submission for a clean first attempt. |
+| A context-overflow response | Compacts the conversation and retries the turn. |
+| A durable abort intent | Settles aborted. |
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+Tool-batch repair is deliberately conservative. Results that were recorded before the crash are preserved exactly — those calls never run again.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+An unresolved ordinary call is _not_ re-executed, because the runtime cannot know which of its side effects already happened; instead it settles with an explicit unknown-outcome error that the model sees and can react to.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+Two kinds of calls resolve real outcomes instead of markers: durable: true tools re-execute with their completed steps replaying from records, and in-flight delegated tasks resume from their own transcripts.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+The overall discipline is **at-least-once execution over exactly-once recording**. Work that committed durably — recorded responses, recorded tool results, committed state writes — never re-runs.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery after an interruption
+Work that was interrupted before committing re-runs on the next attempt, which includes your [event hook](https://flueframework.com/docs/guide/agent-hooks/) callbacks: their durable effects commit atomically and never duplicate, but an external side effect inside one (an email, a page) may rarely happen
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Retry budget and timeout
+
+```ts
+"use agent";
+import { useModel } from "@flue/runtime";
+
+export function IssueTriage() {
+  useModel("anthropic/claude-opus-4-6");
+  return "Triage the bound issue end-to-end.";
+}
+
+IssueTriage.durability = { maxAttempts: 5, timeoutMs: 7_200_000 };
+```
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Durable tools and `step.do`
+For work that must complete — a payment, a provisioning job, a multi-step sync — declare the tool `durable: true`: its `run` receives `step`, every side effect goes through `step.do(name, fn)`, and recovery re-executes the call instead of marking it interrupted:
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Durable tools and `step.do`
+Each completed `step.do` durably records its returned value before resolving. On recovery the whole call re-runs, completed steps return their recorded values without executing, and execution continues from the first step that never finished.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Durable tools and `step.do`
+
+- **Steps are exactly-once-recorded, at-least-once-executed.** A crash in the window between a step’s function finishing and its record landing re-runs that one step, so steps around external effects should be individually idempotent.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Durable tools and `step.do`
+- **A redeploy can withdraw the contract.** If recovery finds the current render no longer declares the tool — or no longer marks it `durable` — the call falls back to the ordinary interrupted-marker path rather than guessing.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Delegated tasks
+When recovery repairs a tool batch containing an unresolved `task` call, it does not settle the call with a marker — it reattaches to the child’s durable transcript, resumes the child to completion under the same recovery rules described above, and commits the child’s real final result as the parent’s tool outcome.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Delegated tasks
+
+- **A delegate removed by a redeploy.** If the subagent is no longer declared when recovery runs, that one call settles with an error outcome and the parent continues; a renamed or removed delegate cannot be resumed under any retry.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Persisted state
+Every [usePersistentState](https://flueframework.com/docs/guide/agent-hooks/) write is a record in the conversation’s canonical stream, which is why state survives restarts for the life of the conversation.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Persisted state
+Its recovery behavior follows from _when_ writes commit: a write becomes durable atomically with the unit of work that made it. A write from a tool commits with that turn’s tool batch; a write from an event hook commits with the hook seam’s checkpoint.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Persisted state
+If recovery settles the batch as interrupted, the write never happened — the re-attempt renders from the last committed state, exactly matching the work the model actually sees as done.
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Persisted state
+That atomicity is what makes persistent state the correct guard for at-least-once callbacks: a `sent` flag set by the same unit of work that sent the email cannot end up `true` while the work it guarded rolled back.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+On Node, a coordinator inside your server process owns submission processing. Ownership is lease-based: each running submission carries a short lease that the owning process heartbeats while working. Recovery has two triggers:
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+
+- **Startup reconciliation.** A replacement process scans for interrupted work when it boots and requeues it, then begins serving immediately while that work settles in the background.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+  Ordering is preserved per conversation — recovered work runs ahead of newly delivered work, so a restart never reorders a conversation’s timeline.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+- **Periodic lease scans.** While running, the coordinator scans for expired leases, so work stranded by a fast restart — where the new process boots before the old lease expires — is reclaimed within seconds rather than waiting for another restart.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+  Graceful shutdown aborts active submissions at the turn boundary and waits for them to settle; work that does not settle in time is left running with its lease intact, and the next startup reclaims it after expiry.
+  Two consequences for deployment:
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+- **Recovery is only as durable as the database.** With the in-memory default, accepted work survives interruptions within the process lifetime but a restart loses everything; cross-restart recovery requires a durable adapter in [db.ts](https://flueframework.com/docs/guide/database/).
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Node.js recovery
+- **One live owner per conversation.** A shared database lets a _replacement_ process recover accepted work, but it does not make two concurrent owners of the same conversation safe. Multi-replica deployments must route each conversation to one owner and avoid overlapping owners during replacement.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery by target > Cloudflare recovery
+On Cloudflare, every agent conversation is a Durable Object with its own SQLite storage, so ownership is structural — the platform guarantees one live instance per conversation, and there is no lease protocol to operate. Recovery is wake-driven:
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Recovery by target > Cloudflare recovery
+
+- **Wake on start.** Whenever the Durable Object starts — after an eviction, a code deploy, or a platform reset — Flue immediately flags any attempt that was running when the previous instance died and reconciles it before serving new work. The platform’s fiber-recovery callback triggers the same reconciliation path.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Cloudflare recovery
+- **A durable wake schedule.** While unsettled work exists, the object keeps a short self-renewing wake scheduled, so an interrupted submission recovers promptly even if no external request ever arrives to wake the object.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Cloudflare recovery
+  Each wake runs a bounded supervision pass — reconcile, enforce deadlines, start work — and re-arms its successor before doing anything that can fail, so a hung attempt or a failed pass can delay supervision by at most one wake, never break it. Attempt execution runs detached from the wake that started it.
+  title: Durability | Flue
+  image: https://flueframework.com/docs/og4.jpg > Recovery by target > Cloudflare recovery
+  Abort intents, attempt bookkeeping, and settlement records all live in the object’s own storage, so an abort requested while the object was evicted is honored on the next wake. See the [Cloudflare target guide](https://flueframework.com/docs/guide/cloudflare-target/) for the target’s execution model.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > What is deliberately not durable > Keep workspace state separate
+Workspace persistence is a separate, independent choice from conversation persistence: a durable workspace comes from a [sandbox adapter](https://flueframework.com/docs/guide/sandboxes/) that keys the provider workspace on the agent instance id, so every submission — including a recovery attempt — resolves
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > What is deliberately not durable > Code outside the agent
+Flue does not checkpoint arbitrary TypeScript execution and resume a function from its last completed line. The checkpoint boundary is the agent itself: _inside_ it, a durable tool gives application-controlled work resumable `step.do` checkpoints backed by the conversation’s own durability.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > What is deliberately not durable > External side effects
+Recovery never blindly repeats uncertain effectful work, but at-least-once execution means an effect at the boundary can repeat; design external effects to be idempotent, key them on stable ids like `toolCallId` or `step.do` names, and guard one-shot actions with persistent state.
+
+...
+
+title: Durability | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Node.js](https://flueframework.com/docs/guide/node-target/) and [Cloudflare](https://flueframework.com/docs/guide/cloudflare-target/) — target-specific runtime behavior.
+- [Observability](https://flueframework.com/docs/guide/observability/) — watch submissions, settlements, and recovery as they happen.
+
+```
+
+**Tool Result:** `TU-0346wYZP0ejKqJSz9SNtbr`
+
+```
+
+# description: Mount agents, channels, and custom routes explicitly in app.ts.
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg
+This guide covers that route map — `app.ts` — mounting agents with `createAgentRouter(...)`, the URL surface each conversation gets, and how to protect it.
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > `app.ts` is the route map
+Every Flue application has one HTTP entrypoint: `src/app.ts`. Its default export is the server — every agent, channel, and custom route your application serves is mounted there explicitly. Flue does not generate routes from filenames or directory conventions: if a route exists, `app.ts` put it there.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > `app.ts` is the route map
+Flue uses [Hono](https://hono.dev/) by convention, but nothing here is Hono-specific: the default export just needs a fetch-compatible shape, and the routers Flue gives you expose `.fetch` themselves, so they mount in any fetch-based framework.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > `app.ts` is the route map
+
+```ts
+import type { Fetchable } from "@flue/runtime/routing";
+
+const app: Fetchable = {
+  fetch(request, env, ctx) {
+    return new Response("Not found", { status: 404 });
+  },
+};
+
+export default app;
+```
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > `app.ts` is the route map
+A Hono application already satisfies this interface. On Cloudflare, `env` contains bindings and `ctx` is the execution context. On Node.js, `env` contains the Hono Node adapter bindings and `ctx` is `undefined`.
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > `app.ts` is the route map
+Because it’s a plain router, `app.ts` is also where the rest of your application’s HTTP lives: health checks, webhook receivers that [dispatch(...)](https://flueframework.com/docs/guide/building-agents/) into agents, static assets for a chat UI, and channel mounts all compose alongside your agent routes.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+
+````ts
+import { createAgentRouter } from '@flue/runtime/routing';
+import { Hono } from 'hono';
+import { Support } from './agents/support.ts';
+import { Triage } from './agents/triage.ts';
+
+const app = new Hono();
+
+app.route('/agents/support', createAgentRouter(Support));
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+```ts
+app.route('/api/assistants/triage', createAgentRouter(Triage));
+
+export default app;
+````
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+
+- **The URL is yours.** `/agents/<name>` is a convention, not a requirement — mount under `/api`, behind a versioned prefix, anywhere. The mount path is pure routing, and clients address whatever URL you choose.
+  title: Routing | Flue
+  image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+- **The mount path is not the agent’s identity.** Conversations are keyed by the agent’s durable identity — its function name, or an `agentName` static override — never by the URL. You can move a mount without a data migration, and mounting the same agent at two paths serves the same conversations from both.
+  title: Routing | Flue
+  image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+- **It’s a pure factory.** `createAgentRouter(...)` has no side effects and no options; call it any number of times, or never. Everything else about the agent — model, durability, initial-data schema — is declared on the agent module itself, not at the mount.
+  title: Routing | Flue
+  image: https://flueframework.com/docs/og4.jpg > Mounting an agent
+- **Mounting is the exposure decision, not registration.** The ['use agent' scan](https://flueframework.com/docs/guide/building-agents/) is what makes an agent exist; the router only builds an HTTP surface over an already-registered agent.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL
+The id is the same caller-chosen identifier described in the [Agents guide](https://flueframework.com/docs/guide/building-agents/) — a user id, a ticket number, any string — and the conversation is created on the first message it receives. Relative to the mount, the router serves:
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL
+| Route | Purpose |
+| POST /:id | Deliver one message (202 admission). |
+| GET /:id | Read the conversation (snapshot, updates, or live stream). |
+| HEAD /:id | Read conversation stream metadata. |
+| GET /:id/attachments/:attachmentId | Download one attachment’s bytes. |
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > Sending a message
+`POST` the message to the conversation URL. The body is the same `DeliveredMessage` shape a server-side `dispatch(...)` admits — a `user` chat turn or a structured `signal` — optionally alongside `initialData` for instance creation:
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > Sending a message
+Sends are **fire-and-forget**: the server responds `202` as soon as the message is durably admitted, before the agent runs. The response carries the coordinates for following the outcome — the conversation’s stream URL, an opaque resume offset, and a submission id:
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > Sending a message
+
+```json
+{
+  "streamUrl": "https://example.com/agents/support/ticket-8472",
+  "offset": "-1",
+  "submissionId": "sub_01HZX..."
+}
+```
+
+There is no “wait for the reply” mode on this route. The agent’s reply lands in the conversation, and you read it from there.
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > Reading the conversation
+`GET` the same URL to read the conversation. A plain `GET` returns one materialized snapshot — every message reduced to complete, render-ready parts. Query parameters select live modes: `?view=updates&offset=...` reads changes after an offset, with long-polling or server-sent events for continuous streaming.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > The SDK wraps this surface
+A [createFlueClient(...)](https://flueframework.com/docs/sdk/create-flue-client/) client addresses exactly one conversation URL and packages the whole surface — `send()`, `wait()`, `observe()`, `history()`, `abort()`, and `attachmentUrl()` — over the routes above:
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > The SDK wraps this surface
+
+````ts
+import { createFlueClient } from '@flue/sdk';
+
+const conversation = createFlueClient({
+  url: 'https://example.com/agents/support/ticket-8472',
+  token: userToken,
+});
+
+const admission = await conversation.send({
+  message: { kind: 'user', body: 'Can you summarize the open issues in my case?' },
+});
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > The SDK wraps this surface
+```ts
+await conversation.wait(admission);
+const { messages } = await conversation.history();
+````
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > The conversation URL > The SDK wraps this surface
+The client takes no agent name or deployment address — the URL is the whole contract, so the mount layout never leaks into client configuration. For chat UIs, [useFlueAgent({ url })](https://flueframework.com/docs/guide/react/) from `@flue/react` wraps the same client with maintained conversation state.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+A mounted agent has no built-in authentication: **anyone who can reach a conversation URL can talk to that conversation** — send it messages, read its full history, abort its work. There is no per-agent middleware export either.
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+Treat a mount like any other sensitive endpoint and protect it with your application’s normal middleware, layered in `app.ts` before the mount it applies to.
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+There are two checks, and production applications need both:
+
+1. **Authentication** — who is the caller?
+2. **Authorization** — is this caller allowed to access _this conversation id_?
+   title: Routing | Flue
+   image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+   Conversation ids are caller-chosen path segments: without an ownership check, any authenticated user can read another user’s conversation by guessing its id.
+   title: Routing | Flue
+   image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+
+````ts
+import { createAgentRouter } from '@flue/runtime/routing';
+import { Hono } from 'hono';
+import { Support } from './agents/support.ts';
+import { canAccessTicket, verifySession } from './shared/auth.ts';
+
+const app = new Hono();
+
+app.use('/agents/support/*', async (c, next) => {
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+```ts
+  const user = await verifySession(c.req.raw); // your application's auth
+  if (!user) return c.json({ error: 'unauthorized' }, 401);
+
+  // The conversation id is the first path segment after the mount.
+  const [conversationId] = c.req.path.slice('/agents/support/'.length).split('/');
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+```ts
+  if (!(await canAccessTicket(user, conversationId))) {
+    return c.json({ error: 'forbidden' }, 403);
+  }
+  return next();
+});
+app.route('/agents/support', createAgentRouter(Support));
+
+export default app;
+````
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+This is ordinary Hono composition, so anything your framework supports works here: shared middleware over a broader prefix (`app.use('/agents/*', requireUser)`), bearer tokens, session cookies, signature verification, per-route rate limits.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Protecting your agents
+
+- **Server-issued ids.** Instead of trusting caller-chosen ids, derive them from the authenticated principal (`user-${user.id}`) or issue them from your own database. The ownership check then becomes a simple equality test.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting a channel
+Channel objects expose their own `.route()` factory — a separate API from the agent router, but the same kind of pure, mountable sub-router. It serves the provider’s declared routes relative to the mount point:
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting a channel
+
+```ts
+import { channel as slack } from "./channels/slack.ts";
+
+app.route("/channels/slack", slack.route());
+// Slack's Events API endpoint is now POST /channels/slack/events
+```
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Mounting a directory of agents
+
+```ts
+  for (const [exportName, agent] of Object.entries(mod)) {
+    if (typeof agent !== 'function' || !/^[A-Z]/.test(exportName)) continue; // agents are the capitalized exports
+    app.route(`/agents/${agent.agentName ?? exportName}`, createAgentRouter(agent));
+  }
+}
+
+export default app;
+```
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Dispatch-only agents
+Registration comes from the `'use agent'` scan, so any registered agent can receive messages through server-side [dispatch(...)](https://flueframework.com/docs/guide/building-agents/) — from a webhook route in `app.ts`, a [channel](https://flueframework.com/docs/guide/channels/), or a
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Dispatch-only agents
+
+```ts
+// registered, but only this verified webhook can reach it.
+app.post('/webhooks/billing', async (c) => {
+  const event = await verifyBillingWebhook(c.req.raw);
+  const receipt = await dispatch(InvoiceAuditor, {
+    id: event.invoiceId,
+    message: {
+      kind: 'signal',
+```
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Agents](https://flueframework.com/docs/guide/building-agents/) — every way to interact with an agent: CLI, HTTP, `dispatch()`, and standalone scripts.
+- [Agent SDK](https://flueframework.com/docs/sdk/overview/) — the client that wraps a conversation URL.
+
+...
+
+title: Routing | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Streaming Protocol](https://flueframework.com/docs/reference/streaming-protocol/) — the wire protocol behind conversation reads.
+- [Deploy](https://flueframework.com/docs/guide/deploy/) — build `app.ts` and your agents into a deployable server.
+
+```
+
+**Tool Result:** `TU-0346wYZPUtjuXYXtMW0Qlr`
+
+```
+
+# description: Test agent behavior by running an agent against a live model and asserting on what it does.
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > What an eval is
+
+- **Evals are nondeterministic.** The same input can produce different wording, a different tool order, occasionally a different outcome. Assert on the behavioral contract — required tool calls, key facts in the reply, the shape of structured data — rather than exact output strings.
+  title: Evals | Flue
+  image: https://flueframework.com/docs/og4.jpg > What an eval is
+- **Evals spend real tokens and real time.** Every case runs one or more live model turns. Evals therefore live in their own suite, with their own configuration, credentials, timeouts, and run cadence, separate from unit tests.
+  title: Evals | Flue
+  image: https://flueframework.com/docs/og4.jpg > What an eval is
+  Flue has no dedicated eval framework. An eval is a [Vitest](https://vitest.dev) test that drives an agent through the same public surfaces every other caller uses — the in-process [init() handle](https://flueframework.com/docs/reference/agent-api/) or the HTTP conversation surface — and asserts on the result.
+  title: Evals | Flue
+  image: https://flueframework.com/docs/og4.jpg > What an eval is
+  The [vitest-evals](https://flueframework.com/docs/ecosystem/tooling/vitest-evals/) integration layers eval harnesses, judges, and CI reporting on top; see below.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Set up an eval suite
+
+```ts
+import { defineConfig } from "vitest/config";
+
+export default defineConfig({
+  test: {
+    include: ["src/evals/**/*.eval.ts"],
+    testTimeout: 60_000,
+  },
+});
+```
+
+The `60_000` timeout replaces Vitest’s 5-second default, which a single live model turn can exceed. Add a script so the suite runs with one command:
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Set up an eval suite
+
+```json
+{
+  "scripts": {
+    "evals": "vitest run --config vitest.evals.config.ts"
+  }
+}
+```
+
+Eval files live under `src/evals/` and are named for the capability or scenario they evaluate — `service-health.eval.ts`, `refund-policy.eval.ts` — not one file per agent.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Write an eval in-process
+
+```ts
+  const reply = await agent.read(receipt, {
+    onEvent: (chunk) => {
+      if (chunk.type === 'tool-input') toolsCalled.push(chunk.toolName);
+    },
+  });
+
+  expect(reply.text).toContain('operational');
+  expect(toolsCalled).toContain('get_service_status');
+});
+```
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Write an eval in-process
+
+- **Fresh conversation per case.** `init(agent)` without an `id` addresses a new, uniquely named conversation, so cases stay independent — saved conversation history cannot affect other cases. A case that evaluates conversation memory reuses one handle and sends several `dispatch(...)`/`read(...)` pairs through it.
+  title: Evals | Flue
+  image: https://flueframework.com/docs/og4.jpg > Write an eval in-process
+- **The reply is the assertion target.** `reply.text` is the final assistant text, and `reply.data` carries named [useDataWriter](https://flueframework.com/docs/guide/agent-hooks/) parts — the place to assert on structured results. A failed or aborted run rejects `read()` with `AgentRunError`, which fails the test.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Write an eval in-process
+And the eval imports the agent module directly, so the module must load under plain Vitest: an agent that depends on build-resolved imports, such as a [SKILL.md import](https://flueframework.com/docs/guide/skills/), needs the Flue build and should be evaluated over HTTP instead.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+An agent [mounted in app.ts](https://flueframework.com/docs/guide/routing/) can be evaluated through its HTTP surface with the [Flue Agent SDK](https://flueframework.com/docs/sdk/overview/) — the same boundary a deployed application serves, including your route middleware.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+
+````ts
+import { createFlueClient } from '@flue/sdk';
+import { expect, it } from 'vitest';
+
+// The agent's mount URL from app.ts; point FLUE_AGENT_URL at a deployment.
+const mountUrl = process.env.FLUE_AGENT_URL ?? 'http://127.0.0.1:5173/agents/service-status';
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+```ts
+it('checks live service status before answering', async () => {
+  const conversation = createFlueClient({
+    url: `${mountUrl}/eval-${crypto.randomUUID()}`,
+  });
+
+  const admission = await conversation.send({
+    message: { kind: 'user', body: 'Is the checkout service currently operational?' },
+  });
+````
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+
+```ts
+  expect(text).toContain('operational');
+});
+```
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+Prompts are fire-and-forget over HTTP: `send()` admits the message, `wait()` awaits its completion, and `history()` returns the finished conversation — including the assistant reply and its tool-call parts.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Evaluate over HTTP
+
+- **In-process (`start()`)** exercises the agent itself — instructions, model, hooks, tools — and needs provider credentials in the test environment.
+- **HTTP (`@flue/sdk`)** exercises the agent plus `app.ts` routing and middleware, and needs a running dev server or deployment.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals
+[vitest-evals](https://vitest-evals.sentry.dev/docs) extends Vitest with eval harnesses, LLM judges, normalized reports, and CI reporting. Add Flue’s integration with a [blueprint](https://flueframework.com/docs/cli/add/):
+
+```sh
+flue add tooling vitest-evals
+```
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals
+The blueprint creates the eval configuration and scripts from above and generates `src/evals/harness.ts` — a harness that drives one conversation per case through `@flue/sdk` and converts the reply, tool calls, and usage into the normalized `vitest-evals` result.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals
+Setup, generated files, and report commands are documented on the [vitest-evals ecosystem page](https://flueframework.com/docs/ecosystem/tooling/vitest-evals/); a complete runnable project is available in [examples/vitest-evals](https://github.com/withastro/flue/tree/main/examples/vitest-evals).
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals
+
+```ts
+describeEval('service status agent', { harness }, (it) => {
+  it('checks live service status before answering', async ({ run }) => {
+    const result = await run('Is the checkout service currently operational?');
+
+    expect(result.output).toContain('operational');
+```
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals > Judges
+Deterministic assertions cover exact contracts: required tools, prohibited tools, structured output, stable content. For semantic behavior — factual consistency, tone, policy adherence — `vitest-evals` provides **judges**, scorers that grade a result and fail the case below a threshold.
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals > Judges
+
+```ts
+    const result = await run('Is the checkout service currently operational?');
+
+    await expect(result).toSatisfyJudge(FactualityJudge(), {
+      expected: 'The checkout service is currently operational.',
+      threshold: 0.6,
+    });
+  });
+});
+```
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > vitest-evals > Judges
+`createJudge(...)` defines custom judges, deterministic or LLM-backed; the built-in `FactualityJudge`, `ToolCallJudge`, and `StructuredOutputJudge` cover the common rubrics. Judge construction and judge-harness adapters are documented in the [vitest-evals docs](https://vitest-evals.sentry.dev/docs).
+
+...
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+Locally, in-process suites run with one command once provider credentials are in the environment:
+
+```sh
+pnpm run evals
+```
+
+HTTP suites additionally need a reachable target: start the application in another terminal first, or set the suite’s URL variable to a deployed environment:
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+
+```sh
+FLUE_AGENT_URL=https://preview.example.com/agents/service-status pnpm run evals
+```
+
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+In CI, an eval suite is an ordinary Vitest run — it exits non-zero when a case fails, so it gates a pipeline like any other test job.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+Keep it as a separate job from unit tests: live-model runs are slower, spend tokens, and can fail without a code change, so they warrant their own cadence — on merge, on a schedule, or on demand.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+Provider credentials come from CI secrets; for HTTP suites, either build and start the application inside the job or target a preview [deployment](https://flueframework.com/docs/guide/deploy/).
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+For reporting, the vitest-evals blueprint adds an `evals:json` script that writes a `vitest-results.json` artifact. Inspect it locally with `vitest-evals serve vitest-results.json`, or publish it from CI with the `getsentry/vitest-evals` GitHub Action.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Run evals locally and in CI
+Reports can contain prompts, outputs, tool arguments and results, and errors — review retention and access requirements before uploading them.
+title: Evals | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Vitest Evals](https://flueframework.com/docs/ecosystem/tooling/vitest-evals/) — the blueprint, generated harness, and report commands.
+- [Agents](https://flueframework.com/docs/guide/building-agents/) — `start()` and standalone scripts, the same surface evals build on.
+
+```
+
+**Tool Result:** `TU-0346wYZQ53ihGsfj5pXjSM`
+
+```
+
+# description: Build and deploy Flue agents as a Node.js server with Vite.
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg
+This guide walks you through creating your first agent, running it locally, and deploying it anywhere you can run Node.js — a VPS, Docker, Railway, Fly.io, or any cloud platform.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg
+Flue is a Vite plugin: `vite dev` serves the application locally and `vite build` produces the deployable server artifact.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 1. Set up your project
+
+```bash
+mkdir my-flue-server && cd my-flue-server
+npm init -y
+npm install @flue/runtime hono valibot
+npm install -D @flue/vite @flue/cli vite
+```
+
+Add the Vite plugin:
+
+```ts
+import { flue } from "@flue/vite";
+import { defineConfig } from "vite";
+
+export default defineConfig({
+  plugins: [flue()],
+});
+```
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 1. Set up your project
+And the scripts:
+
+```jsonc
+{
+  "scripts": {
+    "dev": "vite dev",
+    "build": "vite build",
+  },
+}
+```
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 2. Create your first agent
+The directive is how an agent joins the application — the build scans your source root for marked modules, every exported function with a capitalized name is an agent, and the function’s name becomes the agent’s durable identity (an optional `Translator.agentName = '...'` string-literal static overrides it).
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 2. Create your first agent
+
+```typescript
+"use agent";
+import { useModel } from "@flue/runtime";
+
+export function Translator() {
+  useModel("openai/gpt-5.5");
+  return "Translate the user message into the requested language. Reply with the translation only.";
+}
+```
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 2. Create your first agent
+Agents that need a filesystem can attach an in-memory [virtual sandbox](https://flueframework.com/docs/guide/sandboxes/) powered by [just-bash](https://github.com/vercel-labs/just-bash) — no container needed.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 3. Create app.ts — the route map
+`app.ts` is the only required file. Its default export owns the request pipeline, and every route is mounted explicitly — `app.ts` IS the routing table:
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 3. Create app.ts — the route map
+
+```typescript
+import { createAgentRouter } from "@flue/runtime/routing";
+import { Hono } from "hono";
+import { Translator } from "./agents/translator.ts";
+
+const app = new Hono();
+
+app.route("/agents/translator", createAgentRouter(Translator));
+app.get("/api/ping", (c) => c.text("pong"));
+```
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 6. Build for production
+
+```bash
+npx vite build
+set -a; source .env; set +a
+node dist/server.mjs
+```
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 6. Build for production
+`vite build` compiles your project into `./dist/server.mjs` without packaging `.env` credentials into the server; the built server reads only the environment supplied when you start it. It uses [Hono](https://hono.dev/) under the hood and listens on port 3000 by default (configurable via `PORT`).
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 6. Build for production
+Your project’s `node_modules` are still needed at runtime — the build externalizes your dependencies rather than bundling them.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 6. Build for production
+To verify the artifact before deploying, `vite preview` serves the built application (it imports `dist/app.mjs` directly, with production behavior), or run it for real with `node dist/server.mjs`.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Deterministic tool calls
+For structured, schema-validated work inside the conversation, give the agent a harness-connected tool with `useTool({ harness: true })`: `run` receives the agent’s runtime (sandbox and model access) and can call back into the model for sub-tasks.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Deterministic tool calls
+
+```typescript
+'use agent';
+import { useModel, useTool } from '@flue/runtime';
+import * as v from 'valibot';
+
+export function Reporter() {
+  useModel('openai/gpt-5.5');
+  useTool({
+    name: 'compile-report',
+    description: 'Compile the weekly metrics report.',
+    input: v.object({ period: v.string() }),
+```
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Subagents
+
+```typescript
+'use agent';
+import { useModel, useSubagent } from '@flue/runtime';
+
+function Analyst() {
+  return 'Focus on quantitative insights, trends, and actionable takeaways.';
+}
+
+export function Reporter() {
+  useSubagent({
+    name: 'analyst',
+```
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Sandbox context
+The agent reads `AGENTS.md` and skills from its sandbox at runtime. With `local()`, that’s your real project root, so any files there are visible. With the virtual sandbox the filesystem starts empty — you’d set up context via `harness.sandbox`. Agents without a sandbox skip workspace discovery entirely.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox
+`local()` is where Node really shines compared to other targets. The agent runs directly against the host filesystem and shell — `cwd` is `process.cwd()`, shell commands go through `child_process`, and `AGENTS.md` and skills are discovered from the project root.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox
+Env exposure is opt-in. By default only shell essentials (`PATH`, `HOME`, locale, etc.) are inherited from `process.env`; anything else — API keys, tokens, deploy credentials — has to be passed explicitly via `local({ env: { ... } })`. That keeps the model’s `bash` tool from seeing host secrets by accident.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox
+
+```typescript
+"use agent";
+import { useModel, useSandbox } from "@flue/runtime";
+import { local } from "@flue/runtime/node";
+
+export function Reviewer() {
+  useModel("anthropic/claude-sonnet-4-6");
+  useSandbox(local());
+  return "Review the codebase and identify potential issues in the area the user names.";
+}
+```
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox
+The agent reads, searches, and modifies files via its built-in tools — read, write, edit, grep, glob, bash. Anything on `$PATH` (`git`, `npm`, `gh`, `docker`) is reachable from the bash tool. Env vars are opt-in via `local({ env: { ... } })` — pass `process.env.GH_TOKEN`, `process.env.NPM_TOKEN`, etc.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox > When to use it
+
+- **Self-hosted coding agents** — review PRs, fix bugs, refactor against the actual repo.
+- **File processing** — read documents, transform data, generate reports from local files.
+- **Dev tooling** — analyze project structure, run linters, generate boilerplate.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Using the local sandbox > When to use it
+No container startup, real project context, fast iteration. If you need a tighter boundary on a specific operation — agent can call it, never sees the underlying secret — wrap it as a custom tool via `useTool(...)` in the agent function. The tool reads `process.env`; the agent only sees the tool’s params and result.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox
+The examples above use either the virtual sandbox or the local sandbox. When you need full isolation per session — each user gets their own Linux environment with git, Node.js, Python, etc. — you want a remote sandbox.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > When to use a remote sandbox
+A **remote sandbox** takes seconds to start (cached images are faster) and gives each session its own fully isolated environment, which multi-tenant and SaaS deployments need.
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Conversation persistence
+On Node.js, canonical agent conversations, attachments, and accepted submissions use in-memory SQLite by default in the built server, so they persist for the lifetime of one process but are lost on restart.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Conversation persistence
+(`vite dev` points the same default at a local disk file so history survives reloads within a dev session.) Add `db.ts` when that state must survive restart or support replacement recovery. A shared database does not remove the requirement for one live Node owner per agent instance.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Conversation persistence
+See [Database](https://flueframework.com/docs/guide/database/) for `db.ts`, SQLite, Postgres, and custom adapter setup. See [Data Persistence API](https://flueframework.com/docs/reference/data-persistence-api/) for the adapter contract.
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Building and deploying
+Flue compiles your project into a Node.js server:
+
+```bash
+# Build
+npx vite build
+
+# Run locally
+node dist/server.mjs
+
+# Run on a custom port
+PORT=8080 node dist/server.mjs
+```
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Building and deploying
+The built server never runs in local dev mode: developer-only error guidance and the dev SQLite file are wired only through `vite dev`, not through environment variables.
+The deployed server exposes exactly the routes `app.ts` mounts. For each mounted agent, relative to its mount:
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Building and deploying
+Flue does not add a health endpoint or inspection routes by default. Define a host-required health route in `app.ts` and compose any operator endpoints behind your own authorization. See [Routing](https://flueframework.com/docs/guide/routing/).
+
+...
+
+title: Deploy Agents on Node.js | Flue
+image: https://flueframework.com/docs/og4.jpg > Building and deploying > Choosing a sandbox strategy
+
+1. **Empty virtual sandbox** — an agent function with just `useModel(...)`. Fast, cheap, stateless. Good for prompt-and-response agents.
+2. **Virtual sandbox with shell setup** — Use `harness.sandbox` to write files and configure the workspace.
+   title: Deploy Agents on Node.js | Flue
+   image: https://flueframework.com/docs/og4.jpg > Building and deploying > Choosing a sandbox strategy
+   Still fast and cheap, good for agents that need small amounts of static context.
+3. **Local sandbox** — `useSandbox(local())` in the agent function. Direct host filesystem and shell access. Ideal for self-hosted agents, CI tasks, and dev tooling — anywhere the host environment already provides isolation.
+   title: Deploy Agents on Node.js | Flue
+   image: https://flueframework.com/docs/og4.jpg > Building and deploying > Choosing a sandbox strategy
+   Import `local` from `@flue/runtime/node` and pass `env: { ... }` to expose specific host env vars to the agent’s shell.
+4. **Remote sandbox** — Full isolated Linux environment via a sandbox adapter. For multi-tenant agents, coding sandboxes, and anything that needs per-session isolation.
+
+```
+
+**Tool Result:** `TU-0346wYZQTIInQmCs4NbXLK`
+
+```
+
+# description: Build and deploy Flue agents on Cloudflare Workers with Vite.
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg
+`flue()` scans your `'use agent'` modules, generates the Worker entry (one Durable Object class per agent), and merges its contributions into your Wrangler config; the Cloudflare
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 3. Create app.ts — the route map
+`app.ts` is the only required file. Its default export owns the request pipeline; each mounted agent route resolves the generated binding and forwards to that agent’s Durable Object, and everything else is just a Hono app running in the Worker isolate:
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Cloudflare requires an explicit migration whenever a Worker adds a Durable Object class. Flue generates the classes and bindings for scanned agents, but your project owns the ordered migration history in `wrangler.jsonc`:
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+
+```jsonc
+{
+  "$schema": "./node_modules/wrangler/config-schema.json",
+  "name": "my-flue-worker",
+  "compatibility_date": "2026-06-01",
+  "compatibility_flags": ["nodejs_compat"],
+  "migrations": [
+    { "tag": "flue-class-FlueTranslatorAgent", "new_sqlite_classes": ["FlueTranslatorAgent"] },
+  ],
+```
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Class names derive from agent identities (the exported function’s name, or its `agentName` static override), with camel boundaries split for the binding: the `Translator` agent produces the class `FlueTranslatorAgent` and the binding `FLUE_TRANSLATOR_AGENT`, and an `IssueTriage` agent would produce
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+`FlueIssueTriageAgent` and `FLUE_ISSUE_TRIAGE_AGENT`. Flue requires `nodejs_compat` and a `compatibility_date` of `2026-04-01` or newer, and validates both at build time.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+**Adding an agent is a triple**: the `'use agent'` file, the `app.route(...)` mount, and a uniquely tagged migration for its new class. Keep deployed migration entries in order and append, never rewrite.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Generated Flue agent classes require Durable Object SQLite: introduce them through `new_sqlite_classes`, not legacy `new_classes`.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Renaming an agent **function** is a storage-identity change — the class name follows the identity, which follows the function name unless an `agentName` static pins it.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Express an identity change with wrangler-native `renamed_classes` (`{ "from": "FlueOldNameAgent", "to": "FlueNewNameAgent" }`) to keep the deployed Durable Objects.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 4. Configure Durable Object migrations
+Renaming the file alone changes nothing, and re-mounting an agent at a different URL is not an identity change — neither needs a migration.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 5. Add your API key
+Use the variable name your provider expects — `ANTHROPIC_API_KEY` for Anthropic, `OPENAI_API_KEY` for OpenAI, and so on. Do not commit local secret files.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 5. Add your API key
+Alternatively, route model traffic through the [Workers AI binding](https://flueframework.com/docs/guide/models/) (`cloudflare/...` model specifiers) and skip API keys entirely.
+For a deployed Worker, add secrets through Wrangler rather than treating a local-development file as production configuration:
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 5. Add your API key
+
+```bash
+npx wrangler secret put ANTHROPIC_API_KEY
+```
+
+For CI or a managed deployment pipeline, `wrangler deploy --secrets-file <path>` is also available when your pipeline provides a protected secrets file.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 7. Build and deploy
+Flue never rewrites your authored `wrangler.jsonc`. It reads it, layers its contributions (the generated `main`, one Durable Object binding per scanned agent) into a generated, gitignored Vite input config (`.flue-vite.wrangler.jsonc`), and hands that to the Cloudflare plugin.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > 7. Build and deploy
+Migration history passes through from your file unchanged. Durable-object bindings whose names collide with Flue’s generated `FLUE_*_AGENT` names are a build error.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending generated Cloudflare Durable Objects
+Flue normally owns each generated agent Durable Object class. When an agent needs native Cloudflare Agents SDK capabilities such as `onStart()`, `schedule()`, `scheduleEvery()`, or `queue()`, export a `cloudflare` extension descriptor from its module:
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending generated Cloudflare Durable Objects
+This is an advanced Cloudflare-only extension point. Flue applies `base` first, then defines its own Durable Object subclass with the generated binding and class identity.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending generated Cloudflare Durable Objects
+For the `Heartbeat` agent, authored Worker code can access the namespace as `env.FLUE_HEARTBEAT_AGENT`, and Wrangler binds that name to `FlueHeartbeatAgent`. Use `base` for native SDK lifecycle hooks and additional named methods.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending generated Cloudflare Durable Objects
+
+```ts
+import * as Sentry from "@sentry/cloudflare";
+
+export const cloudflare = extend({
+  wrap: (Final) =>
+    Sentry.instrumentDurableObjectWithSentry(
+      (env: Env) => ({ dsn: env.SENTRY_DSN }),
+      Final,
+    ),
+});
+```
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending generated Cloudflare Durable Objects
+Both `base` and `wrap` are optional. This module-local export is distinct from the optional source-root `cloudflare.ts` deployment module below. Native SDK callbacks run as Durable Object activity: they do not receive a Flue harness or session automatically.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending the Worker
+Add an optional `src/cloudflare.ts` module (path configurable via the `cloudflare` field in `flue.config.ts`) when your deployment needs native Cloudflare capabilities outside Flue’s generated classes. Named exports become top-level Worker exports, which lets the same Worker define application-owned Durable Objects:
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending the Worker
+
+```jsonc
+{
+  "durable_objects": {
+    "bindings": [
+      { "name": "SALESFORCE_AUTH_CACHE", "class_name": "SalesforceAuthCache" },
+    ],
+  },
+  "migrations": [
+    { "tag": "v2", "new_sqlite_classes": ["SalesforceAuthCache"] },
+  ],
+}
+```
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Hello World > Extending the Worker
+Your agents receive the namespace through `env.SALESFORCE_AUTH_CACHE`. Keep bindings, containers, and ordered migration history in Wrangler configuration; `cloudflare.ts` provides the Worker code exports but does not infer deployment topology.
+An optional default export adds non-HTTP Worker handlers:
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > Setup
+
+1. Install `@cloudflare/sandbox`: `npm install @cloudflare/sandbox`.
+2. Export the Sandbox class from `src/cloudflare.ts`.
+3. Declare the Durable Object binding, migration, and container image in your `wrangler.jsonc` at the project root.
+4. Commit a `Dockerfile` at the path your `containers[].image` points to.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > Example
+
+```jsonc
+{
+  "$schema": "./node_modules/wrangler/config-schema.json",
+  "name": "my-agent",
+  "compatibility_date": "2026-06-01",
+  "compatibility_flags": ["nodejs_compat"],
+  "durable_objects": {
+    "bindings": [{ "class_name": "Sandbox", "name": "Sandbox" }],
+  },
+  "migrations": [
+```
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > Multiple sandboxes
+
+```jsonc
+{
+  "durable_objects": {
+    "bindings": [
+      { "class_name": "PyBoxSandbox", "name": "PyBox" },
+      { "class_name": "NodeSandbox", "name": "NodeBox" },
+    ],
+  },
+  "migrations": [
+    { "tag": "v1", "new_sqlite_classes": ["FlueAssistantAgent"] },
+```
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > Secure egress with outbound Workers
+When your agent runs in a container, it may need to call external APIs — GitHub, npm registries, internal services. The traditional approach is to inject API tokens as environment variables, but that means the agent (and the LLM) has direct access to those secrets.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Connecting a remote sandbox > Secure egress with outbound Workers
+Cloudflare Sandboxes solve this with [outbound Workers](https://blog.cloudflare.com/sandbox-auth/) — a programmable egress proxy that intercepts outgoing HTTP/HTTPS requests from the container. Secrets are injected at the proxy layer, so the container never sees them.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Conversation persistence
+`db.ts` is a Node-only convention — on Cloudflare, Durable Object SQLite is the persistence layer.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Conversation persistence
+Filesystem durability remains a separate decision. The default lightweight sandbox uses an in-memory filesystem and must not be treated as durable merely because conversation state is stored in a Durable Object.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics
+A deployment or code update can reset a Durable Object while an operation is running. Flue handles interrupted Cloudflare operations conservatively:
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics
+| Dispatched agent input | Durable delivery and internal deduplication are keyed by submissionId and persisted submission state. Direct and dispatched inputs to one agent instance share one accepted order. Reconciliation uses the same conservative replay rules. |
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics
+Cloudflare direct prompts and dispatched inputs enter one SQLite-backed submission queue owned by the target agent Durable Object. The attached transport observes accepted backend work but does not own it: losing an HTTP response does not cancel the accepted submission.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics
+For jobs that require durable step-level continuation, implement those steps with [Cloudflare Workflows](https://developers.cloudflare.com/workflows/).
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics > Persisted-format boundary
+Flue stamps every Durable Object database with its persisted format version in a one-row `flue_meta` table the first time it opens it, and refuses to open a database stamped by an unknown or newer format version (for example, after rolling back a deploy).
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics > Persisted-format boundary
+There is no in-place format migration: state stamped by a different format version must be cleared, or its class retired.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Interruption and recovery semantics > Persisted-format boundary
+KV-backed Durable Object classes remain outside this boundary because Cloudflare cannot convert them to SQLite in place — generated Flue agent classes must be introduced with `new_sqlite_classes`.
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Building and deploying
+
+```bash
+# Local development (reads local variables from .dev.vars or .env)
+npx vite dev
+
+# Build the deployable Worker output
+npx vite build
+
+# Configure a deployed secret interactively, then deploy the built output
+npx wrangler secret put ANTHROPIC_API_KEY
+npx wrangler deploy
+```
+
+...
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+Enable Cloudflare’s observability products for the deployed Worker in `wrangler.jsonc`:
+
+```jsonc
+{
+  "observability": {
+    "enabled": true,
+    "traces": { "enabled": true },
+  },
+}
+```
+
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+With logs enabled, tool and hook logs from agent work appear in the [Workers Observability](https://developers.cloudflare.com/workers/observability/) dashboard, attributed to the work that wrote them.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+With traces enabled (open beta), each agent response produces one trace — the Durable Object invocation that ran the response end to end, with Workers AI calls and other subrequests as spans inside it.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+With traces enabled, each trace also carries agent-level spans — `invoke_agent`, `chat` per model turn, `execute_tool` per tool call — with conversation content included; [createCloudflareTracing()](https://flueframework.com/docs/guide/cloudflare-target/) covers customizing content capture, and [tracing:
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+false](https://flueframework.com/docs/reference/configuration/) opts out. See Cloudflare’s [Workers Logs](https://developers.cloudflare.com/workers/observability/logs/workers-logs/) and [Traces](https://developers.cloudflare.com/workers/observability/traces/) documentation for sampling, retention, and pricing.
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+For the runtime-level view — token usage, tool payloads, settlements, and exporters like Sentry and OpenTelemetry — see [Observability](https://flueframework.com/docs/guide/observability/).
+title: Deploy to Cloudflare | Flue
+image: https://flueframework.com/docs/og4.jpg > Observability
+For how agent execution maps onto platform invocations, see the [Cloudflare target guide](https://flueframework.com/docs/guide/cloudflare-target/).
+
+```
+
+**Tool Result:** `TU-0346wYZR3WbutJzB37vQgg`
+
+```
+
+# Configure ChatKit over Tilde Global MCP
+
+## Build the endpoint first
+
+Start from the [Hello World agent](https://github.com/trytilde/examples/tree/main/hello-world-agent). For a provider-rich implementation, use the [code review bot](https://github.com/trytilde/examples/tree/main/code-review-bot).
+
+...
+
+Use Vercel AI SDK and Harness SDK `chatKitEndpoint`. Preserve webhook signature verification, `context.session.history()`, `convertToAiSdkMessages`, streaming, and server-side secrets.
+
+## Register an agent
+
+Call `tilde_register_chatkit_agent` with:
+
+- `team_id`
+- `display_name`
+- `endpoint_url`: an HTTPS URL in production, or an endpoint path such as `api/agent` for local development
+- `local_running_endpoint: true` for a Dev Tunnel endpoint
+- optional `concurrency_policy`: `queue`, `interrupt`, or `queue_and_batch` (defaults to `queue`)
+- optional `memory_bank_ids` to ingest this agent's conversations continuously
+  The create response returns the plaintext Tilde API key and webhook signing key once, plus `message_tool_provider_id`. Give both secrets to the human for secure storage in the agent's server environment. Never print them into source, state, logs, or chat history.
+
+...
+
+## Enable agent-to-agent messaging
+
+1. Take `message_tool_provider_id` from the child agent's registration response, or find its `chatkit_agent_message` provider with `tilde_search_enabled_capabilities`.
+2.
+
+...
+
+Pass `session_id` only to continue an existing child conversation. 4. Immediately call the exposed `wait_for_response` tool with the returned `ticket_id`. 5. Keep the MCP request open. Consume `message_streaming` and `agent_turn_status` progress notifications.
+Clients that omit an MCP progress token receive the same structured payload through `tilde.agent_response` logging notifications. 6. Use the final `response` as the canonical persisted ChatKit message.
+Terminal `status` is `completed`, `failed`, or `cancelled`; queue notifications report `pending` or `running`, the applied concurrency policy, trigger count, and whether the turn was batched.
+Bound tenant, target-agent, and ingress-channel fields are supplied by Tilde and cannot be overridden by the caller. Do not configure the removed pairwise internal-agent ChatKit channel.
+
+...
+
+## Configure a ChatKit provider
+
+Use the Vercel AI Endpoint provider when the user wants to test the agent in [Mission Control](https://api.trytilde.ai/mission-control).
+
+## Trigger work with Signals
+
+Signals turn provider events into ChatKit messages.
+
+1. Call `tilde_list_signal_providers` and inspect the selected provider's signal schemas and authentication requirements.
+2. Call `tilde_create_signal_provider` with the provider-specific `body`.
+3. Call `tilde_create_signal_rule` with a `body` that selects the event type, target agent, action, and stable session-key mapping.
+4. Use one stable session key when related events should continue the same body of work, such as all updates to one Sentry issue or GitHub pull request.
+5. Call `tilde_trigger_fake_signal` to test routing where the provider supports it.
+6. Inspect execution with `tilde_list_signal_deliveries`. Use `tilde_retry_signal_delivery` only for a failed delivery that is safe to repeat.
+   Use `tilde_list_signal_provider_instances` and `tilde_list_signal_rules` before updating or deleting resources. Their mutation functions are `tilde_update_signal_provider`, `tilde_delete_signal_provider`, `tilde_update_signal_rule`, and `tilde_delete_signal_rule`.
+   In application code, handle typed GitHub, Slack, Sentry, and Firecrawl metadata as shown in the [human ChatKit guide](https://trytilde.ai/docs/chatkit). `onUnprocessed` runs once per unprocessed message; later conversions reuse its cached result.
+
+```
+
+**Tool Result:** `TU-0346wYZRXluUcvOZb9lFSY`
+
+```
+
+# Configure local agents with Tilde Dev Tunnels
+
+## Global MCP step
+
+Call `tilde_register_chatkit_agent` with:
+
+- the target `team_id`
+- `display_name`
+- `endpoint_url` set to the local route path, for example `api/hello-world`
+- `local_running_endpoint: true`
+  Give the returned API key and webhook signing key to the human for secure server-side storage.
+
+## Local CLI steps
+
+Ask the user or local coding agent to run:
+
+```bash theme={"system"}
+pnpm add -D @trytilde/cli
+pnpm exec tilde auth login
+pnpm exec tilde tunnel -- pnpm dev
+```
+
+Replace `pnpm dev` with the application's normal development command. If the selected workspace is wrong, run `pnpm exec tilde auth set-team`.
+The CLI starts a managed Cloudflare tunnel and passes the chosen local port to the process as `PORT` and `TUNNEL_PORT`. Keep the process running while Tilde delivers ChatKit messages, webhooks, and tool invocations.
+Signed Harness SDK wrappers such as `chatKitEndpoint` reject ChatKit requests without a valid Tilde signature. That protects the wrapped agent endpoint; it does not secure unrelated routes.
+**Warning:** the tunnel exposes every page and API route served by the development process to the public internet. Disable unneeded routes or protect them with authentication.
+Test the registered agent in [Mission Control](https://api.trytilde.ai/mission-control). Select the same workspace before starting a session. See the [human Dev Tunnels guide](https://trytilde.ai/docs/dev-tunnels).
+
+```
+
+**Tool Result:** `TU-0346wYZS207ke06T65YaKP`
+
+```
+
+# Export and import Tilde state over Global MCP
+
+Tilde resource state is portable even though Tilde does not require Terraform. Keep `tilde.state.yaml` beside a custom agent so another workspace can reproduce its agents, ChatKit providers, tools, MCP servers, skills, wikis, memory bindings, reverse proxies, and relationships.
+
+...
+
+Curated hosted MCP connections export their stable catalog provider identity and declarative endpoint/authentication configuration. Dynamic OAuth client IDs, token endpoints discovered for that registration, access tokens, and refresh tokens are environment-specific and are not exported.
+On import, Tilde repeats discovery and dynamic client registration, then returns a one-time authorization URL. Manual OAuth configuration remains portable, while its user credential is reconnected through the normal pending-credential flow.
+
+...
+
+## Export
+
+1. Call `tilde_export_state` with `format: "yaml"`.
+2. Write the returned `state` string unchanged to `tilde.state.yaml`.
+3. Review and commit the file with the agent source.
+   For custom deployed agents, compare the state file and implementation with the [Hello World agent](https://github.com/trytilde/examples/tree/main/hello-world-agent), the [code review bot](https://github.com/trytilde/examples/tree/main/code-review-bot), and the rest of the [examples repository](https://github.com/trytilde/examples).
+
+## Import
+
+1. Read the complete state file as text.
+2. Call `tilde_validate_state` with `state`, `format: "yaml"`, and any declared string `variables`. Stop if `valid` is false.
+3. Call `tilde_plan_state_import` with the identical state, format, and variables.
+4. Show the plan to the user.
+   Do not apply conflicts, destructive changes, or unexpected replacements without approval.
+5. Call `tilde_import_state` only after the plan is approved.
+6. Poll `tilde_get_state_import` with the returned `import_id` until the status is `applied`, `failed`, or `rolled_back`.
+7. Capture generated outputs the first time an applied result returns them. Applied outputs are one-time secrets and are cleared from later summary reads.
+8. Save any one-time OAuth authorization URL returned in the import outputs and send it to the user immediately.
+9.
+
+...
+
+Never call import as a substitute for plan. Use the same exact state and variables for validation, planning, and application.
+See the [human portable state guide](https://trytilde.ai/docs/terraform) for dashboard, CLI, multi-environment, and Deploy with Tilde workflows.
+
+```
+
+**Tool Result:** `TU-0346wYZSQ9aYfuj7fuQbqG`
+
+```
+
+# Connect your coding agent
+
+> Connect a supported coding agent or MCP client to Tilde.
+> Connect the client where your agent runs to the global Tilde MCP server.
+
+...
+
+## Choose your coding agent
+
+### OpenClaw
+
+<Columns cols={3}>
+<Card title="OpenClaw" icon="https://mintcdn.com/tilde/DzxL_3E1qjA-qfvk/icons/openclaw.svg?fit=max&auto=format&n=DzxL_3E1qjA-qfvk&q=85&s=9e4122bb72065f544c0e74954832b3ad" href="/docs/connect-your-agent/openclaw" horizontal width="120" height="120" data-path="icons/openclaw.svg" />
+</Columns>
+
+...
+
+### Codex + ChatGPT
+
+<Columns cols={3}>
+<Card title="Codex" icon="https://cdn.jsdelivr.net/npm/simple-icons@15.16.0/icons/openai.svg" href="/docs/connect-your-agent/codex" horizontal />
+<Card title="ChatGPT" icon="https://cdn.jsdelivr.net/npm/simple-icons@15.16.0/icons/openai.svg" href="/docs/connect-your-agent/chatgpt" horizontal />
+</Columns>
+
+### MCP
+
+<Columns cols={3}>
+<Card title="Notion" icon="https://cdn.jsdelivr.net/npm/simple-icons@16.28.0/icons/notion.svg" href="/docs/connect-your-agent/notion" horizontal />
+<Card title="Cursor" icon="https://cdn.jsdelivr.net/npm/simple-icons@16.28.0/icons/cursor.svg" href="/docs/connect-your-agent/cursor" horizontal />
+<Card title="VS Code" icon="https://cdn.jsdelivr.net/npm/simple-icons@12.4.0/icons/visualstudiocode.svg" href="/docs/connect-your-agent/vscode" horizontal />
+<Card title="Windsurf" icon="https://cdn.jsdelivr.net/npm/simple-icons@16.28.0/icons/windsurf.svg" href="/docs/connect-your-agent/windsurf" horizontal />
+<Card title="Cline" icon="https://cdn.jsdelivr.net/npm/simple-icons@16.28.0/icons/cline.svg" href="/docs/connect-your-agent/cline" horizontal />
+<Card title="Agent Builder" icon="https://cdn.jsdelivr.net/npm/simple-icons@15.16.0/icons/openai.svg" href="/docs/connect-your-agent/openai-agent-builder" horizontal />
+<Card title="n8n" icon="https://cdn.jsdelivr.net/npm/simple-icons@16.28.0/icons/n8n.svg" href="/docs/connect-your-agent/n8n" horizontal />
+<Card title="MCP URL" icon="network-wired" href="/docs/connect-your-agent/mcp-url" horizontal />
+</Columns>
+<Info>
+The global endpoint infers your organization from your Tilde login. Tools that act on a team require a `team_id`.
+</Info>
+```
+
+## Assistant
+
+**Tool Use:** `librarian`
+
+```json
+{
+  "query": "In the current withastro/flue repository, explain the development and deployment architecture that matters to an existing TypeScript application adopting Flue: package/runtime boundaries, Vite build transformations, Node and Cloudflare target outputs, persistence and concurrency requirements, testing/eval/observability support, release maturity signals, license, and operational lock-in. Cite authoritative repository files and distinguish implemented behavior from docs/roadmap claims. Focus on current main and current package metadata."
+}
+```
+
+**Tool Use:** `librarian`
+
+```json
+{
+  "query": "Across trytilde/harness-sdk and trytilde/examples, explain Tilde's current custom-agent development and deployment architecture: what the open-source Harness SDK implements versus what the hosted Tilde control plane provides, Vercel AI SDK integration, endpoint/signature/history contracts, local tunnel workflow, deployment/platform assumptions, state portability, test/eval/observability support, package/release maturity, license, and operational lock-in. Cite exact authoritative repository files and concrete examples; distinguish implemented SDK behavior from hosted-service documentation claims."
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/chatkit",
+  "objective": "Extract the complete human-facing Tilde custom-agent development story, especially code structure with Vercel AI SDK and Harness SDK, endpoint lifecycle/history, local run/test loop, security, concurrency, signals, and production deployment.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://trytilde.ai/docs/terraform",
+  "objective": "Extract Tilde's practical environment/deployment promotion story, portable state workflow, source control integration, secret outputs, review/apply process, and limitations.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://github.com/trytilde/harness-sdk",
+  "objective": "Establish the Harness SDK's stated scope, installation, runtime requirements, public API, supported hosts, license, release/version status, and relationship to hosted Tilde.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://github.com/trytilde/examples/tree/main/hello-world-agent",
+  "objective": "Extract the actual minimal Tilde agent repository structure, development commands, endpoint code, required secrets, tests, and deployment setup.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://github.com/trytilde/examples/tree/main/code-review-bot",
+  "objective": "Extract the production-shaped Tilde agent architecture, development workflow, integrations, testing, portable state, reverse proxy, deployment setup, and operational requirements.",
+  "forceRefetch": true
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wZD6foCHaJ0kjMsPrs`
+
+````
+## Adoption architecture
+
+### Package and runtime boundaries
+
+Flue is an ESM package family rather than one monolithic SDK:
+
+- `@flue/runtime`: agent hooks, sessions, routing, durability, tools, and target-specific subpaths.
+- `@flue/vite`: compile/build integration.
+- `@flue/cli`: local execution, scaffolding, blueprints, and offline docs—not the build system.
+- `@flue/sdk` / `@flue/react`: clients for deployed conversations.
+- Optional persistence, channel, and OpenTelemetry packages.
+
+These boundaries are reflected in the [repository package table](https://github.com/withastro/flue/blob/main/README.md#L65-L75) and actual [`@flue/runtime` exports](https://github.com/withastro/flue/blob/main/packages/runtime/package.json#L12-L68), including distinct `./node`, `./cloudflare`, `./routing`, `./adapter`, and internal build-only entrypoints.
+
+Practical constraints:
+
+- ESM only.
+- Runtime/Vite/CLI packages are currently **2.0.3**.
+- Node consumers require **Node ≥22.19**; `@flue/vite` peers on **Vite 8** ([runtime metadata](https://github.com/withastro/flue/blob/main/packages/runtime/package.json#L70-L103), [Vite metadata](https://github.com/withastro/flue/blob/main/packages/vite/package.json#L22-L55)).
+- The runtime directly adopts Hono, Pi’s model/provider protocol, Valibot, and MCP client machinery ([dependencies](https://github.com/withastro/flue/blob/main/packages/runtime/package.json#L86-L95)).
+
+An existing application therefore keeps ordinary TypeScript modules and an explicit `app.ts` router, but Flue must own the agent compilation/runtime path.
+
+## Vite transformations
+
+This is implemented build behavior, not merely a documented convention:
+
+1. Vite scans modules carrying a real directive-prologue `'use agent'`.
+2. Capitalized exported functions become agent definitions.
+3. The transform appends runtime identity bindings without rewriting the authored function. Durable identity is injected as a build-time string, so minification does not change storage identity ([transform implementation](https://github.com/withastro/flue/blob/main/packages/vite/src/use-agent-transform.ts#L1-L15), [injected imports and bindings](https://github.com/withastro/flue/blob/main/packages/vite/src/use-agent-transform.ts#L39-L77)).
+4. Generated virtual modules join the scanned agents, providers, runtime configuration, `app.ts`, and target bootstrap.
+
+Flue 2.0 explicitly removed `flue dev/build` and file-based route creation: Vite owns dev/build, while `app.ts` owns every HTTP mount. This is recorded as a shipped breaking change, not roadmap material ([changelog](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L28-L35)).
+
+Build-resolved facilities such as `SKILL.md` imports require this Vite graph; they will not necessarily load under plain Vitest or `ts-node`-style execution ([eval limitation](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/evals.md#L77-L85)).
+
+## Target outputs
+
+### Node
+
+`vite build` emits:
+
+- `dist/server.mjs`: self-starting HTTP server, defaulting to `PORT=3000`, with graceful signal handling.
+- `dist/app.mjs`: non-listening application artifact used by preview or embeddable hosts.
+
+The production entry is concrete source code ([Node entry](https://github.com/withastro/flue/blob/main/packages/vite/src/bootstrap/node-entry.ts#L1-L30)); artifact-based `vite preview` is listed as shipped in 2.0.0 ([changelog](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L74-L75)).
+
+### Cloudflare
+
+Configuration is:
+
+```ts
+plugins: [flue(), cloudflare({ config: flueWorkerConfig() })]
+````
+
+Flue must come first. The official Cloudflare Vite plugin owns workerd, Wrangler configuration resolution, build output, preview, and deployment. Flue contributes:
+
+- `virtual:flue/worker`;
+- one Durable Object binding/class per scanned agent;
+- `nodejs_compat`;
+- a minimum compatibility-date validation.
+
+The user continues to own migrations, R2/container bindings, and other Wrangler configuration ([customizer contract](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-worker-config.ts#L1-L40), [applied fields](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-worker-config.ts#L163-L191)). Flue currently requires a compatibility date of at least `2026-04-01` ([validation](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-worker-config.ts#L194-L218)).
+
+The generated Worker imports the application and all scanned agents, registers them, exports one Agents-SDK-derived Durable Object class per agent, and optionally registers Workers AI and native tracing ([generator](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-entry.ts#L1-L18), [class generation](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-entry.ts#L53-L96), [generated imports/registration](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-entry.ts#L104-L175)).
+
+## Persistence and concurrency
+
+### Node
+
+The production default is process-local, in-memory SQLite. It provides ordered operation inside one process but loses state on restart. Durable restart recovery requires a Node-only `db.ts` adapter such as SQLite, Postgres, MySQL, MongoDB, libSQL, or Redis.
+
+A shared database does **not** make active-active replicas safe. Flue requires one live owner per conversation; deployments must use sticky/partitioned routing and avoid overlapping replacement owners ([documented operational contract](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/durability.md#L119-L133)).
+
+### Cloudflare
+
+Each agent conversation maps to a Durable Object with SQLite. Required Wrangler migrations must use `new_sqlite_classes`; legacy KV-backed classes cannot be converted in place. This is enforced at runtime, not just documented ([SQLite check](https://github.com/withastro/flue/blob/main/packages/runtime/src/cloudflare/agent-execution-store.ts#L53-L73)).
+
+Cloudflare supplies structural single ownership. Flue persists conversation, attachment, queue, attempt, abort, and settlement state in DO SQLite and maintains wake-driven supervision ([recovery behavior](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/durability.md#L135-L142)).
+
+Across targets, processing is exactly-once-recorded but at-least-once-executed; external effects must be idempotent. Runtime source explicitly warns that Cloudflare processing may retry ([dispatch contract](https://github.com/withastro/flue/blob/main/packages/runtime/src/runtime/flue-app.ts#L51-L69)). “Durable tools” checkpoint `step.do` results but still cannot guarantee an external effect occurred only once ([durability semantics](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/durability.md#L65-L94)).
+
+Sandbox files are independent of conversation persistence; an ephemeral sandbox is rebuilt during recovery unless the application provisions a durable workspace ([boundary](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/durability.md#L144-L150)).
+
+## Tests, evals, and observability
+
+Implemented support includes:
+
+- Vitest unit suites throughout published packages and Cloudflare integration tests in `@flue/vite` ([package scripts](https://github.com/withastro/flue/blob/main/packages/vite/package.json#L30-L35)).
+- Public runtime store-contract test utilities for third-party persistence adapters ([runtime exports](https://github.com/withastro/flue/blob/main/packages/runtime/package.json#L53-L64)).
+- In-process testing/evals through `start()` + `init()`.
+- End-to-end HTTP evals through `@flue/sdk`.
+- A `vitest-evals` blueprint/example.
+
+Flue explicitly says it has **no dedicated eval framework**; Vitest and `vitest-evals` are integration patterns, not a built-in managed evaluator ([eval guide](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/evals.md#L7-L18), [supported boundaries](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/evals.md#L47-L85), [HTTP evaluation](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/evals.md#L86-L126)).
+
+Observability has two distinct implemented surfaces:
+
+- Durable, client-facing conversation streams.
+- Live, process/isolate-local runtime events via `observe()`.
+
+Runtime events include model turns, tools, logs, usage/cost, compaction, recovery, and settlement identifiers. They are synchronous, live-only, not replayed, and not aggregated across processes or Durable Objects ([event semantics](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/observability.md#L9-L43), [event inventory](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/observability.md#L45-L68)).
+
+Export options are OpenTelemetry, Sentry and Braintrust integrations—not a Flue-hosted dashboard ([integrations](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/observability.md#L158-L175)). Cloudflare builds additionally install native tracing by default, becoming effective when Workers Traces is enabled ([generated tracing block](https://github.com/withastro/flue/blob/main/packages/vite/src/cloudflare-entry.ts#L150-L160)).
+
+## Maturity signals
+
+Current metadata and changelog indicate a newly stabilized but rapidly changing project:
+
+- Current packages are **2.0.3**, released 2026-08-04 ([changelog](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L1-L9)).
+- 2.0.0 landed only days earlier and replaced major beta architecture: build commands, routing, workflows, agent definitions, tools, persistence format, SDK addressing, and client semantics ([breaking-change section](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L28-L45)).
+- 2.0.1–2.0.3 immediately fixed durability hangs, Cloudflare dependency resolution, tracing, and provider behavior ([2.0.1 fixes](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L19-L26), [2.0.3 fix](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L3-L7)).
+- Persisted beta stores are rejected and have no migration path ([format change](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L61-L61)).
+
+Thus “2.0” is released implementation, but compatibility history shows substantial recent churn. Documentation claims around future UI/dev experiences should not be treated as shipped; for example, the changelog calls the browser demo merely the basis for a **future** `flue dev` experience ([changelog](https://github.com/withastro/flue/blob/main/CHANGELOG.md#L44-L44)).
+
+## License and operational lock-in
+
+The repository and package metadata use **Apache-2.0** ([root metadata](https://github.com/withastro/flue/blob/main/package.json#L1-L9), [license text](https://github.com/withastro/flue/blob/main/LICENSE#L1-L12)).
+
+Lock-in differs by target:
+
+- **Framework/build lock-in:** agent directives, generated identities, virtual Vite modules, persisted record formats, and `app.ts` registration tie the application to Flue’s compiler/runtime.
+- **Node:** comparatively portable hosting and interchangeable persistence adapters, but the one-owner-per-conversation rule complicates horizontal scaling.
+- **Cloudflare:** strong operational coupling to Workers, Agents SDK, Durable Objects, DO SQLite, Wrangler migrations, compatibility dates, alarms/wakes, Workers AI, and optionally native tracing. Moving these conversations elsewhere requires application-level export/migration; Cloudflare persistence adapters are not substitutable with `db.ts`.
+- **Provider/sandbox lock-in:** reduced but not eliminated. Pi provider objects and thin sandbox adapters allow alternate vendors, while Cloudflare-native AI/sandbox/workspace choices deepen platform dependence.
+- **Workflow lock-in:** Flue deliberately removed its own workflow engine and expects external systems such as Temporal, Inngest, or Cloudflare Workflows, reducing framework lock-in but transferring durability concerns to that chosen platform ([documented boundary](https://github.com/withastro/flue/blob/main/apps/docs/src/content/docs/guide/durability.md#L152-L162)).
+
+```
+
+**Tool Result:** `TU-0346wZD8QZxwqYoDlTH2N7`
+
+```
+
+## Architecture boundary
+
+Tilde’s model is **bring-your-own agent runtime, hosted control plane**:
+
+- Your application owns the model call, prompts, AI loop, and HTTP route. The examples implement these as Next.js handlers using Vercel AI SDK `streamText`—for example, the minimal agent loads hosted history, converts messages, calls OpenAI, and streams a UI response ([route.ts, L21-L57](https://github.com/trytilde/examples/blob/main/hello-world-agent/app/api/hello-world/route.ts#L21-L57)).
+- The hosted Tilde service owns or brokers agent registration, channels, sessions/history, Signals ingress/routing, MCP configuration, credentials, reverse proxies, and invocation of the configured endpoint. That division is documented by the code-review flow ([README.md, L25-L51](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L25-L51)) and represented declaratively in state files ([sentry state, L138-L173](https://github.com/trytilde/examples/blob/main/sentry-remediation-bot/tilde.state.yaml#L138-L173)).
+
+The hosted capabilities above are **documentation/state-schema claims**, not implementations present in these repositories. The SDK is a client and endpoint-adapter layer over Tilde APIs; it does not contain the control-plane server.
+
+## What the Harness SDK actually implements
+
+The published SDK surface comprises a core API client, React bindings, Vercel-AI server/client adapters, and CLI ([README.md, L5-L17](https://github.com/trytilde/harness-sdk/blob/main/README.md#L5-L17)). Concrete implemented behavior includes:
+
+- Authenticated HTTP clients for ChatKit, message/event history, MCP, and skills ([client.ts, L7-L25](https://github.com/trytilde/harness-sdk/blob/main/packages/core/src/client.ts#L7-L25)).
+- Config normalization, Tilde API defaults, organization subdomains, bearer/API-key authentication, and injectable `fetch` ([config.ts, L20-L75](https://github.com/trytilde/harness-sdk/blob/main/packages/core/src/config.ts#L20-L75)).
+- Paginated session messages and event history against hosted `/api/v1/team/...` APIs ([messages.ts, L6-L69](https://github.com/trytilde/harness-sdk/blob/main/packages/core/src/chatkit/messages.ts#L6-L69)).
+- Signed ChatKit endpoint handling, request validation, typed provider context, timeout/abort propagation, history access, and structured console logging ([handler.ts, L96-L159](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L96-L159), [L161-L211](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L161-L211), [L315-L370](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L315-L370)).
+- MCP URL/client helpers, process-local tools, and signed remote-tool discovery/invocation handlers ([README.md, L50-L105](https://github.com/trytilde/harness-sdk/blob/main/README.md#L50-L105), [L167-L193](https://github.com/trytilde/harness-sdk/blob/main/README.md#L167-L193)).
+
+It does **not** implement model hosting, a scheduler, durable storage, Signals infrastructure, credential vaulting, hosted MCP providers, sandbox execution, or deployment infrastructure.
+
+## Vercel AI SDK integration
+
+The integration is an adapter rather than a proprietary agent framework:
+
+1. `chatKitEndpoint` verifies and validates Tilde’s request.
+2. `context.session.history()` retrieves hosted history.
+3. `convertToAiSdkMessages` maps Tilde messages/signals to AI SDK `UIMessage`s.
+4. Application code calls normal AI SDK APIs such as `convertToModelMessages`, `streamText`, `stepCountIs`, and `toUIMessageStreamResponse`.
+5. `createMCPClient` exposes Tilde’s remote MCP tools as AI SDK tools.
+
+The production code-review loop demonstrates all of these pieces ([route.ts, L24-L45](https://github.com/trytilde/examples/blob/main/code-review-bot/app/api/code-review/route.ts#L24-L45), [L61-L106](https://github.com/trytilde/examples/blob/main/code-review-bot/app/api/code-review/route.ts#L61-L106)). Typed conversion supports text, reasoning, files, dynamic tools, approvals, sources, and arbitrary data parts ([chatkit-request.ts, L3-L93](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-request.ts#L3-L93)); it also has provider-specific handlers for Sentry, GitHub, and Firecrawl signals ([chatkit-message.ts, L343-L386](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-message.ts#L343-L386), [L671-L697](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-message.ts#L671-L697)).
+
+## Endpoint, signature, and history contracts
+
+### Signature
+
+Inbound requests require:
+
+- `x-tilde-webhook-id`
+- `x-tilde-timestamp`
+- `x-tilde-signature`
+
+The signature is:
+
+```text
+hmac-sha256=hex(HMAC-SHA256(key, timestamp + "." + rawBody))
+```
+
+The SDK defaults to a five-minute timestamp tolerance and uses constant-time comparison ([webhook.ts, L4-L19](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/webhook.ts#L4-L19), [L49-L88](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/webhook.ts#L49-L88), [L110-L132](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/webhook.ts#L110-L132)). Tests cover valid, missing, stale, and invalid signatures ([webhook.test.ts, L62-L97](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/test/webhook.test.ts#L62-L97)).
+
+### Invocation context
+
+The endpoint additionally requires organization, team, and session headers; user/external-user headers are optional ([handler.ts, L33-L38](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L33-L38), [L161-L205](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L161-L205)). The body is `{ chatId?, messages }`, with strict validation of message roles and parts ([chatkit-request.ts, L83-L125](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-request.ts#L83-L125)).
+
+### History
+
+History is not sent as the entire request transcript. The handler exposes a session client backed by Tilde’s hosted history API. With no paging options it loads all 100-item pages, sorts by creation time, and removes messages duplicated in the current request ([handler.ts, L215-L265](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L215-L265), [L440-L464](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L440-L464)). Converted AI-SDK representations may also be cached back into ChatKit ([chatkit-message.ts, L567-L586](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-message.ts#L567-L586), [L700-L731](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/chatkit-message.ts#L700-L731)).
+
+## Local tunnel workflow
+
+The current first-party workflow is:
+
+```bash
+tilde tunnel -- next dev --webpack -p '$TUNNEL_PORT'
+```
+
+The CLI authenticates with Tilde, obtains a hosted Cloudflare connector token, starts `cloudflared`, selects a local port, proxies the managed ingress port to it, and injects tunnel/port environment variables ([tunnel.ts, L49-L89](https://github.com/trytilde/harness-sdk/blob/main/packages/cli/src/tunnel.ts#L49-L89), [L92-L154](https://github.com/trytilde/harness-sdk/blob/main/packages/cli/src/tunnel.ts#L92-L154)). The SDK’s own Next.js example documents this exact command ([README.md, L47-L61](https://github.com/trytilde/harness-sdk/blob/main/examples/nextjs-agent/README.md#L47-L61)).
+
+The public examples’ prose sometimes says only “public HTTPS tunnel” or “Tilde development tunnel” ([hello-world README, L82-L84](https://github.com/trytilde/examples/blob/main/hello-world-agent/README.md#L82-L84), [code-review README, L124-L135](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L124-L135)). Therefore ordinary tunnels can satisfy reachability, but the managed tunnel command depends on Tilde authentication and Tilde-issued Cloudflare configuration.
+
+## Deployment and platform assumptions
+
+The wire-level handler uses standard Fetch `Request`/`Response`, so it is not intrinsically Vercel-only. Nevertheless, the supported examples assume:
+
+- Next.js route handlers;
+- Node 22 for examples;
+- Vercel deployment and environment variables;
+- AI SDK-compatible streaming;
+- provider-specific function-duration limits.
+
+The minimal guide requires a Vercel account and deploys with `vercel deploy --prod` ([README.md, L10-L16](https://github.com/trytilde/examples/blob/main/hello-world-agent/README.md#L10-L16), [L68-L76](https://github.com/trytilde/examples/blob/main/hello-world-agent/README.md#L68-L76)). The larger examples export `maxDuration = 300` and warn that the Vercel plan must support it ([code-review README, L151-L165](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L151-L165)). State explicitly identifies the provider as `chatkit.http-vercel-ai-sdk` ([hello-world state, L9-L17](https://github.com/trytilde/examples/blob/main/hello-world-agent/tilde.state.yaml#L9-L17)).
+
+Thus portability to another Node/Fetch host looks technically plausible, but these repositories provide no authoritative deployment recipe or support commitment for another platform.
+
+## State portability
+
+Tilde resources can be represented as YAML and imported/exported with the CLI ([SDK README, L20-L29](https://github.com/trytilde/harness-sdk/blob/main/README.md#L20-L29)). State can describe agents, channels, providers, Signal rules, MCP servers, credential setup placeholders, and reverse-proxy profiles. References use logical state addresses, allowing IDs to be remapped on import; runtime endpoint IDs and secrets are omitted ([sentry README, L36-L43](https://github.com/trytilde/examples/blob/main/sentry-remediation-bot/README.md#L36-L43)).
+
+Portability is intentionally incomplete:
+
+- Endpoint URLs remain deployment-specific variables ([hello-world state, L4-L17](https://github.com/trytilde/examples/blob/main/hello-world-agent/tilde.state.yaml#L4-L17)).
+- Generated API keys/signing keys are one-time outputs.
+- GitHub App IDs, installation IDs, private keys, webhook secrets, and generated proxy profile IDs cannot be committed in state ([code-review README, L81-L101](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L81-L101)).
+- Imported resources still target Tilde-specific provider IDs and APIs.
+
+State therefore supports moving/reconstructing configuration **between Tilde environments**, not moving the whole control plane to another vendor.
+
+## Testing, evals, and observability
+
+### Implemented
+
+The SDK has unit tests, package-wide Vitest scripts, and an MCP E2E suite ([package.json, L10-L22](https://github.com/trytilde/harness-sdk/blob/main/package.json#L10-L22)). Endpoint tests cover signing, validation, timeout/abort behavior, context, history, and typed metadata; the signature cases are concrete examples above.
+
+Runtime observability consists primarily of:
+
+- structured endpoint logs with request/session IDs, verification, history-page timings, status, and elapsed time ([handler.ts, L96-L118](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L96-L118), [L379-L404](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/src/handler.ts#L379-L404));
+- application-level AI SDK callbacks such as `onStepFinish`, `onFinish`, `onAbort`, and `onError` ([code-review route, L81-L100](https://github.com/trytilde/examples/blob/main/code-review-bot/app/api/code-review/route.ts#L81-L100));
+- hosted message and event-history read APIs.
+
+### Not demonstrated
+
+There is no eval framework, benchmark suite, prompt regression system, tracing exporter, OpenTelemetry integration, dashboard implementation, or documented hosted eval product in these repositories. The examples repository has only a small Sentry session-key regression test script ([package.json, L13-L15](https://github.com/trytilde/examples/blob/main/sentry-remediation-bot/package.json#L13-L15)); the code-review example has no test script ([package.json, L24-L30](https://github.com/trytilde/examples/blob/main/code-review-bot/package.json#L24-L30)). Its production checklist says what operators should monitor, but that is guidance—not supplied observability infrastructure ([README.md, L184-L199](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L184-L199)).
+
+## Maturity and license
+
+The packages are early-stage:
+
+- core SDK `0.1.2`;
+- Vercel AI Node package `0.2.0`;
+- CLI `0.1.0`  
+  ([core package.json, L1-L5](https://github.com/trytilde/harness-sdk/blob/main/packages/core/package.json#L1-L5), [Vercel package.json, L1-L5](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/package.json#L1-L5), [CLI package.json, L1-L5](https://github.com/trytilde/harness-sdk/blob/main/packages/cli/package.json#L1-L5)).
+
+Publishing does have validation, smoke tests, ordered releases, retry-safe CI, and OIDC plans ([README.md, L235-L263](https://github.com/trytilde/harness-sdk/blob/main/README.md#L235-L263)). Still, the low versions, narrow example set, generated API surface, and explicit warning about Modal’s unstable pre-1.0 API indicate evolving contracts.
+
+Crucially, “open-source” should not be equated with permissively licensed:
+
+- `trytilde/examples` is explicitly MIT ([LICENSE, L1-L20](https://github.com/trytilde/examples/blob/main/LICENSE#L1-L20)).
+- `trytilde/harness-sdk` has no repository LICENSE file, and published package manifests say `UNLICENSED` ([core package.json, L3-L9](https://github.com/trytilde/harness-sdk/blob/main/packages/core/package.json#L3-L9), [Vercel package.json, L3-L9](https://github.com/trytilde/harness-sdk/blob/main/packages/vercel-ai-node/package.json#L3-L9)). Its source is publicly visible, but the repositories do not grant an open-source license.
+
+## Operational lock-in
+
+**Low lock-in:** prompts, model choice, AI SDK loop, application code, and deployed endpoint remain yours. OpenAI is merely the examples’ provider, and the SDK example also supports a caller-selected OpenAI-compatible endpoint ([SDK example README, L3-L8](https://github.com/trytilde/harness-sdk/blob/main/examples/nextjs-agent/README.md#L3-L8)).
+
+**Material Tilde lock-in:** sessions/history, channels, Signals ingestion and routing, provider normalization, hosted MCP catalogs, credential brokerage, reverse proxies, managed tunnel identities, and state resource types all call Tilde-specific APIs. The code-review agent depends operationally on Tilde to inject GitHub/Modal credentials and proxy network access ([README.md, L37-L51](https://github.com/trytilde/examples/blob/main/code-review-bot/README.md#L37-L51)); Sentry deliberately sends to Tilde’s durable ingress rather than the application ([sentry README, L36-L38](https://github.com/trytilde/examples/blob/main/sentry-remediation-bot/README.md#L36-L38)).
+
+Replacing Tilde would not require rewriting the model loop, but would require rebuilding those control-plane services and translating the signature, session/history, Signals, MCP, credential, and proxy contracts. The strongest lock-in is therefore **operational control-plane state and brokered integrations**, not the agent’s inference code.
+
+```
+
+**Tool Result:** `TU-0346wZD96umkW8WaxAlAUD`
+
+```
+
+# ChatKit
+
+> Connect conversations and external events to your agent.
+> ChatKit connects an agent endpoint to the places where work begins. It stores sessions and messages, delivers each turn as a signed HTTPS request, and streams the agent's response back to the channel. There are three ways to trigger an agent run through ChatKit:
+
+1. **Chat providers**: These are first-class integrations with third-party chat providers.
+2. **Vercel AI SDK chat provider**: This managed provider exposes your agent through a Vercel AI SDK-compatible endpoint for custom clients.
+3. **Signals**: These are events from third-party providers that Tilde delivers to your agent.
+
+...
+
+## Set up ChatKit
+
+<Steps>
+<Step title="Create the endpoint">
+Wrap your route with `chatKitEndpoint`. It verifies Tilde's signature and gives the handler the current session, new messages, provider metadata, and ChatKit client.
+```
+```bash theme={"system"}
+pnpm add @ai-sdk/openai ai @trytilde/harness-sdk @trytilde/harness-sdk-vercel-ai-node
+```
+
+```typescript app/api/agent/route.ts theme={"system"}
+import { openai } from "@ai-sdk/openai";
+import {
+  chatKitEndpoint,
+  convertToAiSdkMessages,
+  createClient,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+import { consumeStream, convertToModelMessages, streamText } from "ai";
+
+export const POST = chatKitEndpoint({
+  client: createClient({
+    apiKey: process.env.TILDE_API_KEY!,
+    orgId: process.env.TILDE_ORG_ID!,
+    teamId: process.env.TILDE_TEAM_ID!,
+  }),
+  webhookSigningKey: process.env.TILDE_WEBHOOK_SIGNING_KEY!,
+  async handler(request, context) {
+    const history = await context.session.history();
+    const messages = await convertToAiSdkMessages({
+      messages: [...history.items, ...context.messages],
+      chatkit: context.chatkit,
+    });
+    const result = streamText({
+      abortSignal: request.signal,
+      messages: await convertToModelMessages(messages),
+      model: openai("gpt-5.5"),
+    });
+
+    return result.toUIMessageStreamResponse({
+      consumeSseStream: consumeStream,
+      originalMessages: messages,
+    });
+  },
+});
+```
+
+```
+
+...
+
+</Step>
+<Step title="Register the agent">
+Open Tilde, select your workspace, and go to **ChatKit** → **Agents**. Register the endpoint and copy the one-time API key and webhook signing key into your app's environment.
+```
+
+For local development, enable **Local running endpoint** and run the app through a Dev Tunnel. For production, enter the deployed HTTPS endpoint.
+
+Registration also creates a credentialless **Message agent** tool provider bound to this agent. Add its `message` and `wait_for_response` tools to any Tilde MCP server when another agent should invoke it.
+
+```
+</Step>
+<Step title="Connect a channel and test">
+Go to **ChatKit** → **Configure Chat Providers** and choose where people will talk to the agent. Link the provider to your registered agent, then open [Mission Control](https://api.trytilde.ai/mission-control) to start a test session.
+</Step>
+</Steps>
+
+### Test your agent in Mission Control
+Use [Mission Control](https://api.trytilde.ai/mission-control) to invoke your agent directly and test conversations. Select the correct workspace and agent, then start a session and send a message.
+<Info>
+Mission Control requires the **Vercel AI Endpoint** ChatKit provider to be enabled for your agent.
+</Info>
+
+### Provider-specific message metadata
+Supported chat providers add validated metadata to the endpoint context. Use the provider-specific property inside your `chatKitEndpoint` handler.
+<Tabs>
+<Tab title="GitHub">
+GitHub messages expose repository, issue, pull request, comment, and event metadata through `context.github`.
+```
+
+```typescript app/api/code-review/route.ts theme={"system"}
+import {
+  chatKitEndpoint,
+  createClient,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+
+export const POST = chatKitEndpoint({
+  client: createClient({
+    apiKey: process.env.TILDE_API_KEY!,
+    orgId: process.env.TILDE_ORG_ID!,
+    teamId: process.env.TILDE_TEAM_ID!,
+  }),
+  webhookSigningKey: process.env.TILDE_WEBHOOK_SIGNING_KEY!,
+  async handler(_request, context) {
+    console.log({
+      event: context.github?.event,
+      owner: context.github?.owner,
+      repo: context.github?.repo,
+      pullNumber: context.github?.pull_number,
+      issueNumber: context.github?.issue_number,
+    });
+
+    // ...rest of your agent code.
+  },
+});
+```
+
+```
+
+...
+
+```
+
+```typescript app/api/slack-agent/route.ts theme={"system"}
+import {
+  chatKitEndpoint,
+  createClient,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+
+export const POST = chatKitEndpoint({
+  client: createClient({
+    apiKey: process.env.TILDE_API_KEY!,
+    orgId: process.env.TILDE_ORG_ID!,
+    teamId: process.env.TILDE_TEAM_ID!,
+  }),
+  webhookSigningKey: process.env.TILDE_WEBHOOK_SIGNING_KEY!,
+  async handler(_request, context) {
+    console.log({
+      teamId: context.slack?.team_id,
+      channelId: context.slack?.channel_id,
+      threadTimestamp: context.slack?.thread_ts,
+      userId: context.slack?.user,
+    });
+
+    // ...rest of your agent code.
+  },
+});
+```
+
+````
+
+...
+
+## Work with session context
+`context.messages` contains the new input for the current turn. Load `context.session.history()` when the model needs the earlier conversation, then convert both collections together.
+```typescript theme={"system"}
+const history = await context.session.history();
+const messages = await convertToAiSdkMessages({
+  messages: [...history.items, ...context.messages],
+  chatkit: context.chatkit,
+});
+````
+
+The context also includes `sessionId`, team and organization IDs, the invoking user when known, and typed metadata for supported providers such as `context.slack` and `context.github`.
+
+## Handle unprocessed content
+
+`convertToAiSdkMessages` automatically converts standard text and reasoning parts. It also caches transformed message parts for later model requests, improving prompt caching and agent performance. Use `onUnprocessed` for content that needs application-specific handling before it can be sent to a model.
+
+- `fileUpload` receives each unprocessed file part and its parent message.
+- `firecrawl` maps page-monitoring and completed-check signals to typed message converters.
+- `github` maps GitHub issue, pull request, and CI signal types to typed message converters.
+- `sentry` maps a signal type, such as `sentry.issue.created`, to a typed message converter.
+- Return an AI SDK message or part to include it. Return `null` to omit it.
+- Handlers can be asynchronous. If a handler throws, message conversion fails.
+  ChatKit invokes `onUnprocessed` once for each unprocessed message, then caches the result. Subsequent conversions reuse the cached value instead of invoking the handler again.
+  <Tabs>
+  <Tab title="File uploads">
+  Use `createChatKitAttachmentFilePartHandler` to download ChatKit attachments with Tilde authentication and convert them into model-safe AI SDK file parts.
+
+````
+```typescript app/api/agent/route.ts theme={"system"}
+import type { Client } from "@trytilde/harness-sdk";
+import {
+  type ChatKitEndpointContext,
+  convertToAiSdkMessages,
+  createChatKitAttachmentFilePartHandler,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+
+async function convertTurn(
+  client: Client,
+  context: ChatKitEndpointContext,
+) {
+  const history = await context.session.history();
+
+  return convertToAiSdkMessages({
+    messages: [...history.items, ...context.messages],
+    chatkit: context.chatkit,
+    onUnprocessed: {
+      fileUpload: createChatKitAttachmentFilePartHandler(client, context),
+    },
+  });
+}
+````
+
+Supported media is downloaded and passed to the model as an inline file. Unsupported stored attachments become a text part containing the file name, media type, and download URL.
+
+```
+
+...
+
+```
+
+```typescript app/api/github-agent/route.ts theme={"system"}
+import {
+  type ChatKitEndpointContext,
+  convertToAiSdkMessages,
+  type GitHubSignalByType,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+import type { UIMessage } from "ai";
+
+type PullRequestOpened =
+  GitHubSignalByType["github.pull_request.opened"];
+
+function pullRequestOpenedMessage(
+  signal: PullRequestOpened,
+): UIMessage {
+  const { repository, pull_request } = signal.data;
+
+  return {
+    id: signal.id,
+    role: "user",
+    parts: [{
+      type: "text",
+```
+
+...
+
+````
+```typescript app/api/web-monitor/route.ts theme={"system"}
+import {
+  type ChatKitEndpointContext,
+  convertToAiSdkMessages,
+  type FirecrawlSignalByType,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+import type { UIMessage } from "ai";
+
+type PageChanged =
+  FirecrawlSignalByType["firecrawl.monitor.page.changed"];
+
+function pageChangedMessage(signal: PageChanged): UIMessage {
+  const { monitor, page } = signal.data;
+
+  return {
+    id: signal.id,
+    role: "user",
+    parts: [{
+      type: "text",
+      text: `Review changes to ${page.url} from monitor ${monitor.id}.`,
+    }],
+  };
+}
+
+async function messagesForFirecrawlTurn(
+  context: ChatKitEndpointContext,
+) {
+  const history = await context.session.history();
+
+  return convertToAiSdkMessages({
+    messages: [...history.items, ...context.messages],
+    chatkit: context.chatkit,
+    onUnprocessed: {
+      firecrawl: {
+        "firecrawl.monitor.page.changed": pageChangedMessage,
+      },
+    },
+  });
+}
+````
+
+Firecrawl also exposes `same`, `new`, `removed`, and `error` page events, plus `firecrawl.monitor.check.completed` for the completed check summary.
+
+```
+
+...
+
+```
+
+```typescript app/api/sentry-agent/route.ts theme={"system"}
+import {
+  type ChatKitEndpointContext,
+  convertToAiSdkMessages,
+  type SentrySignalByType,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+import type { UIMessage } from "ai";
+
+type IssueCreated =
+  SentrySignalByType["sentry.issue.created"];
+
+function issueCreatedMessage(signal: IssueCreated): UIMessage {
+  const { issue } = signal.data.data;
+
+  return {
+    id: signal.id,
+    role: "user",
+    parts: [{
+      type: "text",
+      text: `Investigate ${issue.shortId ?? issue.id}: ${issue.title}`,
+    }],
+  };
+}
+
+async function messagesForSentryTurn(
+  context: ChatKitEndpointContext,
+) {
+  const history = await context.session.history();
+
+  return convertToAiSdkMessages({
+    messages: [...history.items, ...context.messages],
+    chatkit: context.chatkit,
+    onUnprocessed: {
+      sentry: {
+```
+
+...
+
+## Let agents invoke other agents through MCP
+
+- `message` accepts Vercel AI SDK-compatible UI message parts, persists the inbound ChatKit message, and immediately returns a ticket and session ID.
+
+...
+
+## Trigger work from events via Signals
+
+```typescript app/api/sentry-remediation/route.ts theme={"system"}
+import {
+  chatKitEndpoint,
+  convertToAiSdkMessages,
+  createClient,
+  type SentrySignalByType,
+} from "@trytilde/harness-sdk-vercel-ai-node";
+import type { UIMessage } from "ai";
+
+type IssueCreatedSignal = SentrySignalByType["sentry.issue.created"];
+
+function sentryIssueCreatedMessage(signal: IssueCreatedSignal): UIMessage {
+  const { issue } = signal.data.data;
+
+  return {
+    id: signal.id,
+    role: "user",
+    parts: [
+      {
+        type: "text",
+        text: `Investigate Sentry issue ${issue.shortId ?? issue.id}: ${issue.title}`,
+      },
+    ],
+  };
+}
+
+export const POST = chatKitEndpoint({
+  client: createClient({
+    apiKey: process.env.TILDE_API_KEY!,
+    orgId: process.env.TILDE_ORG_ID!,
+    teamId: process.env.TILDE_TEAM_ID!,
+  }),
+  webhookSigningKey: process.env.TILDE_WEBHOOK_SIGNING_KEY!,
+  async handler(_request, context) {
+    const history = await context.session.history();
+    const messages = await convertToAiSdkMessages({
+      messages: [...history.items, ...context.messages],
+      chatkit: context.chatkit,
+      onUnprocessed: {
+        sentry: {
+          "sentry.issue.created": sentryIssueCreatedMessage,
+        },
+      },
+    });
+
+    // ...rest of your agent code.
+  },
+});
+```
+
+## ChatKit and memory
+
+ChatKit preserves the messages inside a session. Memory stores selected knowledge that should be available across sessions, channels, or agents. Use both when an agent needs conversational continuity and longer-lived organizational context.
+
+```
+
+**Tool Result:** `TU-0346wZDAHTj3BzD9umt279`
+
+```
+
+# Terraform
+
+> Export, share, and reproduce portable Tilde resource state.
+> Well, not exactly. Tilde does not require a Terraform provider, but all Tilde resource state is portable. This makes it easy to share a setup and reproduce it across development, staging, and production workspaces.
+
+## The `tilde.state.yaml` file
+
+`tilde.state.yaml` describes the desired configuration for resources in a workspace. It can include ChatKit agents and providers, MCP servers, tool providers, skill registries, wikis, memory-bank bindings, reverse proxies, and their relationships.
+State files can declare variables for values that change between environments, such as an agent endpoint URL. They do not contain API keys, signing keys, third-party credentials, conversation history, or other runtime content.
+
+...
+
+Hosted MCP provider connections preserve their catalog provider identity, endpoint configuration, authentication mode, tool provider, and MCP mappings. API keys, bearer tokens, OAuth client secrets, access tokens, and refresh tokens remain encrypted credential references rather than state values.
+OAuth providers that use dynamic client registration must register a new client in the destination environment because the redirect URI and client registration belong to the source environment. Import recreates the provider and returns a one-time authorization URL.
+
+...
+
+Commit `tilde.state.yaml` with your application so reviewers can see which Tilde resources it expects.
+
+## Export state from a workspace
+
+<Tabs>
+<Tab title="Tilde">
+1. Select the workspace you want to export.
+2. Go to **Settings** → **Team settings** → **State**.
+3. Open the **Export** tab and click **Export**.
+```
+Tilde downloads the workspace configuration as `tilde.state.yaml`.
+```
+</Tab>
+<Tab title="CLI">
+`bash theme={"system"}     pnpm add -D @trytilde/cli     pnpm exec tilde auth login     pnpm exec tilde state export ./tilde.state.yaml     `
+</Tab>
+</Tabs>
+
+## Import state manually
+
+1. Select the destination workspace.
+2. Go to **Settings** → **Team settings** → **State**.
+3. Open the **Import** tab and upload `tilde.state.yaml`.
+4. Provide any variables requested by the file.
+5. Review the validation result and resource plan, then apply it.
+6.
+
+...
+
+You can perform the same workflow from the CLI:
+
+```bash theme={"system"}
+pnpm exec tilde auth login
+pnpm exec tilde state import ./tilde.state.yaml ./tilde-state-import-outputs.yaml
+```
+
+The CLI shows the plan before applying it. Add `--auto-apply` only in a trusted automated workflow where the state change has already been reviewed.
+
+## Add a Deploy with Tilde button
+
+Add the button to a project's `README.md` when its repository contains a `tilde.state.yaml` file.
+[![Deploy with Tilde](https://api.trytilde.ai/deploy-button.svg)](https://api.trytilde.ai/deploy?repository-url=https%3A%2F%2Fgithub.com%2Ftrytilde%2Fexamples&state-path=hello-world-agent%2Ftilde.state.yaml)
+Clicking the button opens Tilde, asks the user to select a workspace, reads the state file from GitHub, collects its variables, and shows the import plan before creating resources.
+Use this Markdown and replace both query parameters with your repository and state-file path:
+
+...
+
+`repository-url` must point to a GitHub repository over HTTPS. `state-path` must be a relative path to a YAML file, so monorepos can use a value such as `agents/code-review/tilde.state.yaml`.
+
+## Manage multiple environments
+
+Keep one reviewed state file as the shared baseline. Use variables for environment-specific endpoints and reconnect credentials separately in each workspace. Import the same state into development, staging, and production, then review each plan before applying it.
+<Warning>
+State imports can update or replace existing configuration. Review conflicts, destructive changes, requested variables, and pending credentials before applying a plan.
+</Warning>
+
+```
+
+**Tool Result:** `TU-0346wZDAfiU8OT6NjrEOz4`
+
+```
+
+# trytilde/harness-sdk
+
+- Page: GitHub repository
+- URL: https://github.com/trytilde/harness-sdk
+- Stars: 0
+- Forks: 0
+- Default branch: main
+- Created: 2026-06-08T14:46:39.000Z
+- Commits: 60
+
+## Top-level files
+
+- .agents/skills/
+- .github/workflows/
+- .greptile/
+- examples/nextjs-agent/
+- packages/
+- scripts/
+- specs/
+- test/e2e/
+- .env.e2e.example
+- .gitignore
+- .sops.yaml
+- AGENTS.md
+- Makefile
+- README.md
+- biome.json
+- openapi-ts.config.ts
+- openapi.cloud.json
+- package.json
+- pnpm-lock.yaml
+- pnpm-workspace.yaml
+- secrets.example.yaml
+- tsconfig.base.json
+- vitest.config.ts
+- vitest.e2e.config.ts
+
+# Tilde Harness SDK
+
+TypeScript SDK packages for Tilde Harness APIs.
+
+## Packages
+
+- `@trytilde/harness-sdk` : core client, MCP helpers, ChatKit helpers, and message history.
+- `@trytilde/harness-sdk-react` : React provider and ChatKit hooks.
+- `@trytilde/harness-sdk-vercel-ai-node` : ChatKit webhook verification and Vercel AI SDK route helpers.
+- `@trytilde/harness-sdk-vercel-ai-react` : React helpers for Vercel AI SDK ChatKit UIs.
+- `@trytilde/cli` : Tilde terminal CLI, published with `tilde` and `t` binaries.
+
+## Install
+
+```shell
+pnpm add @trytilde/harness-sdk @trytilde/harness-sdk-react @trytilde/harness-sdk-vercel-ai-node @trytilde/harness-sdk-vercel-ai-react
+pnpm add -D @trytilde/cli
+```
+
+## CLI
+
+```shell
+tilde auth login
+tilde auth whoami
+tilde auth set-team
+tilde state import ./tilde-state.yaml ./tilde-import-output.json
+tilde state import ./tilde-state.yaml ./tilde-import-output.json --auto-apply
+tilde state export ./tilde-state.yaml
+```
+
+...
+
+## Core Config
+
+```ts
+import { createClient, createConfig } from "@trytilde/harness-sdk";
+
+const tilde = createClient(
+  createConfig({
+    orgId: "org-example",
+    teamId: "team_123",
+    apiKey: process.env.TILDE_API_KEY,
+    // Optional. Starts cloudflared for local agents/tools using apiKey.
+    tunnel: true,
+    // Optional. Defaults to process.env.TILDE_BASE_API_URL or https://api.trytilde.com.
+    baseApiUrl: "https://api.trytilde.com",
+  }),
+);
+```
+
+## MCP Server URL
+
+```ts
+const server = await tilde.mcp.createServer({
+  id: "my-agent-tools",
+  name: "My Agent Tools",
+  isDynamicToolDiscovery: true
+});
+
+console.log(server.url);
+
+await tilde.mcp.addFunction({
+  serverId: server.id,
+  toolSourceTypeId: "tool-source-type",
+  toolGroupSourceTypeId: "tool-group-source-type",
+```
+
+...
+
+`client.mcp.getServerUrl({ id })` returns the raw Streamable HTTP MCP URL for AI SDK clients and other MCP-capable runtimes.
+
+## MCP Local Tools
+
+Wrap an existing MCP client to add process-local tools. Local tools are exposed
+alongside remote MCP tools, execute in-process, and are split out of `MULTI_EXECUTE_TOOL` calls automatically.
+
+```ts
+import { createMCPClient } from "@ai-sdk/mcp";
+import { wrapMcpClientWithLocalTools } from "@trytilde/harness-sdk";
+
+const mcp = await createMCPClient({
+  transport: {
+    type: "http",
+    url: tilde.mcp.getServerUrl({ id: "my-agent-tools" })
+  }
+});
+
+const wrappedMcp = wrapMcpClientWithLocalTools({
+```
+
+...
+
+## Vercel AI MCP Client
+
+Use the Vercel AI node package to create an `@ai-sdk/mcp` client with Tilde
+MCP URL construction and `x-api-key` authentication. Tools passed in the map are
+registered as local tools alongside the remote MCP server tools.
+
+```ts
+import { jsonSchema, tool } from "ai";
+import { createClient } from "@trytilde/harness-sdk";
+import { createMCPClient } from "@trytilde/harness-sdk-vercel-ai-node";
+
+const client = createClient({
+  orgId: process.env.TILDE_ORG_ID!,
+  teamId: process.env.TILDE_TEAM_ID!,
+  apiKey: process.env.TILDE_API_KEY!,
+});
+```
+
+...
+
+## Remote Custom Tool Endpoint
+
+Expose Zod-validated remote tools with signed discovery and invocation
+handlers. The invocation URL defaults to the incoming request URL, with
+optional `baseUrl` and `endpointPath` overrides for proxies.
+
+```ts
+import { toolEndpoint } from "@trytilde/harness-sdk-vercel-ai-node";
+import { z } from "zod";
+
+export const { GET, POST } = toolEndpoint({
+  webhookSigningKey: process.env.TILDE_CUSTOM_TOOL_SIGNING_KEY!,
+  provider: { name: "Example tools", version: "1.0.0" },
+  tools: [
+    {
+      id: "greet",
+      name: "Greet",
+      description: "Greet a person by name.",
+      inputSchema: z.object({ name: z.string() }),
+      outputSchema: z.object({ greeting: z.string() }),
+      async fn({ name }) {
+        return { greeting: `Hello, ${name}!` };
+      },
+    },
+  ],
+});
+```
+
+## React ChatKit Hooks
+
+```tsx
+import {
+  TildeProvider,
+  useChatKitSessionEvents,
+} from "@trytilde/harness-sdk-react";
+
+function Events({ sessionId }: { sessionId: string }) {
+  const events = useChatKitSessionEvents({ sessionId, pollIntervalMs: 3000 });
+  return <pre>{JSON.stringify(events.items, null, 2)}</pre>;
+}
+
+export function App() {
+  return (
+    <TildeProvider config={{ baseUrl, teamId, apiKey }}>
+      <Events sessionId="00000000-0000-0000-0000-000000000000" />
+    </TildeProvider>
+  );
+}
+```
+
+...
+
+## Examples
+
+- `examples/nextjs-agent` : Next.js agent using Tilde ChatKit signed webhooks, dynamic MCP, and the Vercel AI SDK.
+
+## Development
+
+```shell
+pnpm install
+pnpm sdk:refresh
+pnpm lint
+```
+
+## Publishing
+
+The public runtime packages are versioned together and published in dependency
+order:
+
+1. `@trytilde/api-client`
+2. `@trytilde/harness-sdk`
+3. `@trytilde/harness-sdk-vercel-ai-node`
+   Validate the release tarballs without publishing:
+
+```shell
+pnpm build
+pnpm release:validate
+pnpm release:smoke
+pnpm release:publish -- --dry-run
+```
+
+The `Publish npm packages` GitHub workflow runs the complete validation suite
+and skips package versions that already exist, so a partially completed release
+can be retried safely.
+The first npm release requires an `NPM_TOKEN` secret because trusted publishing
+can only be configured after each package exists. After the first release,
+configure each package to trust `trytilde/harness-sdk` and `publish.yml` , then
+remove the long-lived token. The workflow already grants the required OIDC
+permission.
+Package builds use Vite and tests use Vitest. The generated OpenAPI types are internal. Add public APIs through hand-authored wrappers.
+
+```
+
+**Tool Result:** `TU-0346wZDB3mr7DNz5HcIPeR`
+
+```
+
+# Hello World Agent
+
+The smallest complete Tilde agent: one signed ChatKit endpoint and one Vercel
+UI channel. It uses Next.js and the Vercel AI SDK to keep a conversation with
+an OpenAI model.
+This project is the source for the Tilde [quickstart](https://docs.trytilde.ai/quickstart) .
+
+## Prerequisites
+
+- Node.js 22 or newer and pnpm 10.
+- A Tilde account and team.
+- An OpenAI API key.
+- A Vercel account.
+
+...
+
+## 2. Create a public endpoint
+
+The route loads its secrets only when Tilde invokes it, so the first deployment
+can build before you configure the environment.
+
+```shell
+vercel deploy
+```
+
+Your ChatKit endpoint is the deployment URL plus `/api/hello-world` .
+
+## 3. Import Tilde state
+
+Use the endpoint from the previous step when Tilde asks for `HELLO_WORLD_CHATKIT_ENDPOINT_URL` .
+[Deploy with Tilde](https://api.trytilde.ai/deploy?repository-url=https%3A%2F%2Fgithub.com%2Ftrytilde%2Fexamples&state-path=hello-world-agent%2Ftilde.state.yaml)
+The state creates:
+
+- the **Hello World** HTTP agent;
+- a **Hello World UI** ChatKit channel for testing.
+  Save the one-time `api_key` and `webhook_signing_key` outputs from `chatkit/agent/hello-world` .
+
+...
+
+## 4. Configure the environment
+
+| Variable | Value |
+| `OPENAI_API_KEY` | Your OpenAI API key. |
+| `OPENAI_MODEL` | Defaults to `gpt-5.4` . |
+| `TILDE_API_KEY` | The agent's one-time `api_key` output. |
+| `TILDE_BASE_URL` | Defaults to `https://api.trytilde.ai` . |
+| `TILDE_ORG_ID` | Your Tilde organization ID. |
+| `TILDE_TEAM_ID` | Your Tilde team ID. |
+
+...
+
+## 5. Deploy and test
+
+```shell
+vercel deploy --prod
+```
+
+If the production hostname differs from the first deployment, update `HELLO_WORLD_CHATKIT_ENDPOINT_URL` to the production endpoint and re-import the
+state. Open **ChatKit** , select **Hello World UI** , and send:
+
+```
+Say hello in one sentence.
+```
+
+For local development, run `pnpm dev` and expose port 3000 through a public
+HTTPS tunnel. Update the ChatKit agent endpoint to the tunnel URL plus `/api/hello-world` before testing.
+
+```
+
+**Tool Result:** `TU-0346wZDBY4SYyoJfdIRTGK`
+
+```
+
+# trytilde/examples — code-review-bot
+
+## Contents
+
+- app/api/code-review/
+- lib/
+- .env.example
+- .gitignore
+- README.md
+- eslint.config.mjs
+- next-env.d.ts
+- next.config.ts
+- package.json
+- pnpm-lock.yaml
+- tilde.state.yaml
+- tsconfig.json
+
+# Code Review Bot
+
+A production-oriented GitHub code review agent built with Next.js, the Vercel
+AI SDK, Tilde, and Modal.
+Tag the installed GitHub App in a pull request. Tilde turns the GitHub event
+into a signed ChatKit message, invokes the Vercel endpoint, exposes an
+allowlisted set of GitHub MCP tools, and brokers short-lived access to GitHub
+and Modal without giving their long-lived credentials to the model.
+
+## What It Does
+
+- Handles full reviews, incremental reviews, and follow-up questions.
+- Reads PR metadata, patches, commits, earlier reviews, and repository guidance.
+- Clones the PR through Tilde's Git HTTPS reverse proxy.
+- Runs bounded repository-native checks in a request-scoped Modal sandbox.
+
+...
+
+## Architecture
+
+```
+sequenceDiagram
+    participant Developer
+    participant GitHub
+    participant Tilde
+    participant Vercel
+    participant Modal
+
+    Developer->>GitHub: Tag the bot on a PR
+    GitHub->>Tilde: GitHub App webhook
+    Tilde->>Vercel: Signed ChatKit request + typed GitHub metadata
+    Vercel->>Tilde: Connect to allowlisted MCP server
+    Vercel->>Tilde: Open Modal gRPC reverse proxy
+    Tilde->>Modal: Inject Modal credentials
+    Vercel->>Modal: Create isolated review sandbox
+    Modal->>Tilde: Clone via Git HTTPS reverse proxy
+    Tilde->>GitHub: Inject installation token
+    Vercel->>Tilde: Post review through GitHub MCP tools
+    Tilde->>GitHub: Inline comments + review summary
+```
+
+Loading
+The model never receives a GitHub installation token or Modal API key. The
+ephemeral sandbox configures Git once to rewrite GitHub URLs through Tilde and
+adds the Tilde proxy headers to its global Git configuration. Sandbox egress is
+restricted to Tilde, and the configuration disappears when the sandbox stops.
+
+## Prerequisites
+
+- Node.js 22 or newer and pnpm 10.
+- A Tilde account and team.
+- A Modal workspace API key.
+- A GitHub organization where you can create and install a GitHub App.
+- An OpenAI API key.
+- A Vercel project for deployment.
+
+## 1. Install
+
+```shell
+pnpm install
+cp .env.example .env.local
+```
+
+## 2. Import Tilde State
+
+Set `CODEX_REVIEW_CHATKIT_ENDPOINT_URL` when importing [`tilde.state.yaml`](https://github.com/trytilde/examples/blob/main/code-review-bot/tilde.state.yaml) to the complete endpoint you intend to use.
+[Deploy with Tilde](https://api.trytilde.ai/deploy?repository-url=https%3A%2F%2Fgithub.com%2Ftrytilde%2Fexamples&state-path=code-review-bot%2Ftilde.state.yaml)
+For local development, use the public URL from your Tilde development tunnel.
+Use the deploy button above, or import the file from Mission Control and provide
+the variable when prompted.
+The state creates:
+
+- the HTTP/Vercel ChatKit agent;
+- pending GitHub and Modal credential setup items;
+- GitHub and Modal tool providers;
+- a static MCP server containing the GitHub review and Modal inspection
+  operations used by this agent.
+  State cannot contain a GitHub App ID, installation ID, private key, webhook
+  secret, or generated reverse-proxy profile ID. Those are credential-setup
+  outputs and must not be committed.
+
+## 3. Complete Credentials
+
+Open **Settings > Team > Pending credentials** in Tilde.
+
+1. Complete GitHub setup. Tilde creates a GitHub App from a manifest, asks
+   where to install it, stores its private key and webhook secret, and creates
+   GitHub REST and Git HTTPS reverse-proxy profiles.
+2. Complete Modal setup with the workspace ID, API key ID, and API key secret.
+   Tilde creates the Modal gRPC reverse-proxy profile.
+3. In the resulting GitHub ChatKit provider, set **Code Review** as the default
+   agent and restrict the repository allowlist for production.
+   The GitHub App should be installed only on repositories the bot is allowed to
+   review. Tilde-generated permissions should be reviewed before installation.
+
+...
+
+## 4. Configure Environment
+
+| Variable | Value |
+| `TILDE_API_KEY` | API key output from `chatkit/agent/code-review` |
+| `TILDE_WEBHOOK_SIGNING_KEY` | Webhook signing key from the same agent |
+| `TILDE_GITHUB_GIT_PROXY_PROFILE_ID` | Profile using provider `github_git_https` |
+| `TILDE_MODAL_PROXY_PROFILE_ID` | Profile using provider `modal_sandbox` |
+| `TILDE_ORG_ID` | Organization ID from Team > General information |
+| `TILDE_TEAM_ID` | Team ID from Team > General information |
+
+...
+
+## 5. Run Locally
+
+```shell
+pnpm dev
+```
+
+Expose port 3000 through the Tilde development tunnel, then set the ChatKit
+agent endpoint to:
+
+```
+https://YOUR_TUNNEL/api/code-review
+```
+
+Tag the GitHub App in an existing pull request:
+
+```
+@your-app-name review this PR
+```
+
+For an explicit complete rerun:
+
+```
+@your-app-name full review
+```
+
+...
+
+## 6. Deploy to Vercel
+
+Add every value from `.env.example` to the Vercel project. Mark API keys and
+signing keys sensitive; IDs, model names, and base URLs do not need to be
+secret.
+
+```shell
+vercel deploy --prod
+```
+
+Update `chatkit/agent/code-review` to the production endpoint and re-import the
+state, or edit the endpoint in Mission Control.
+The route exports `maxDuration = 300` . Confirm that the selected Vercel plan
+supports the required function duration.
+
+...
+
+## Production Checklist
+
+- Limit GitHub App installation and the Tilde repository allowlist.
+- Keep the MCP server static; do not enable GitHub mutation tools unrelated to
+  reviews.
+- Configure Git proxy authentication only inside the ephemeral sandbox.
+- Use webhook signature verification and reject stale requests.
+- Keep sandbox CPU, memory, execution time, output, and idle lifetime bounded.
+- Restrict sandbox egress to the configured Tilde reverse-proxy host.
+- Do not inject platform credentials into the sandbox.
+- Keep request timeout below the hosting platform's hard function limit and
+  await idempotent MCP and sandbox cleanup.
+- Re-read GitHub state after every write.
+- Monitor tool errors, model finish reasons, review duration, and sandbox
+  termination failures.
+- Pin dependency versions and review updates to Modal's pre-1.0 JavaScript SDK.
+
+## Files
+
+- [`app/api/code-review/route.ts`](https://github.com/trytilde/examples/blob/main/code-review-bot/app/api/code-review/route.ts) : ChatKit
+  endpoint and Vercel AI SDK loop.
+- [`lib/code-review/prompt.ts`](https://github.com/trytilde/examples/blob/main/code-review-bot/lib/code-review/prompt.ts) : review behavior and
+  output contract.
+- [`lib/code-review/sandbox.ts`](https://github.com/trytilde/examples/blob/main/code-review-bot/lib/code-review/sandbox.ts) : Modal lifecycle,
+  Git proxy setup, and pull-request checkout.
+- [`lib/tilde.ts`](https://github.com/trytilde/examples/blob/main/code-review-bot/lib/tilde.ts) : the single configured Harness SDK client.
+- [Tilde Harness SDK](https://github.com/trytilde/harness-sdk) : ChatKit, MCP,
+  reverse-proxy, and typed provider-context integration.
+- [`tilde.state.yaml`](https://github.com/trytilde/examples/blob/main/code-review-bot/tilde.state.yaml) : portable Tilde resources.
+
+...
+
+## Limitations
+
+Modal's JavaScript SDK currently marks its underlying gRPC API as unstable.
+Pin the SDK and test upgrades before deployment.
+
+````
+
+## Assistant
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '1,220p' package.json && printf '\\n--- apps/dev/package.json ---\\n' && sed -n '1,220p' apps/dev/package.json && printf '\\n--- binding package ---\\n' && sed -n '1,180p' packages/binding-flue/package.json",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+````
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '1,180p' apps/dev/src/app.ts && printf '\\n--- agent ---\\n' && sed -n '1,180p' apps/dev/src/agents/gherkin-elicitor.ts && printf '\\n--- config ---\\n' && sed -n '1,120p' apps/dev/flue.config.ts && sed -n '1,160p' apps/dev/vite.config.ts",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '1,240p' packages/binding-flue/src/index.ts && printf '\\n--- capabilities ---\\n' && sed -n '1,220p' packages/binding-flue/src/capabilities.ts && printf '\\n--- local store ---\\n' && sed -n '1,200p' packages/binding-flue/src/local-capture-store.ts",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '1,220p' CONTEXT.md && printf '\\n--- spec deployment section ---\\n' && sed -n '620,675p' docs/planning/elicitation-kernel/spec.md && printf '\\n--- known gaps ---\\n' && sed -n '1,180p' test/known-gaps.ts",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '1,180p' apps/dev/test/walking-skeleton.integration.ts && printf '\\n--- build artifact test ---\\n' && sed -n '1,180p' test/build-artifact.test.ts && printf '\\n--- CI ---\\n' && sed -n '1,120p' .github/workflows/ci.yml",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "git status --short --branch && printf '\\n--- recent ADR titles ---\\n' && rg -n '^#|^Status:|^## (Decision|Context|Consequences)' docs/adr docs/planning/elicitation-kernel/spec.md | sed -n '1,160p'",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wblVbGwhMXTxu1qmbp`
+
+```
+{
+  "output": "{\n  \"name\": \"brunch-lite\",\n  \"private\": true,\n  \"type\": \"module\",\n  \"description\": \"Elicitation harness — agentic interviewing against pluggable elicitation targets\",\n  \"workspaces\": [\"packages/*\", \"apps/*\"],\n  \"scripts\": {\n    \"lint\": \"oxlint --fix --deny-warnings .\",\n    \"lint:check\": \"oxlint --deny-warnings .\",\n    \"fmt\": \"oxfmt .\",\n    \"fmt:check\": \"oxfmt --check .\",\n    \"typecheck\": \"tsc -p tsconfig.json\",\n    \"test\": \"bun test\",\n    \"build\": \"bun run --filter '@brunch/*' build\",\n    \"smoke\": \"bun run lint:check && bun run fmt:check && bun run typecheck && bun test\"\n  },\n  \"devDependencies\": {\n    \"@anthropic-ai/sdk\": \"^0.116.0\",\n    \"@types/bun\": \"^1.3.0\",\n    \"oxfmt\": \"^0.5.0\",\n    \"oxlint\": \"^1.42.0\",\n    \"typescript\": \"^5.9.0\",\n    \"vite\": \"^8\"\n  }\n}\n\n--- apps/dev/package.json ---\n{\n  \"name\": \"@brunch/dev\",\n  \"version\": \"0.0.0\",\n  \"private\": true,\n  \"type\": \"module\",\n  \"description\": \"The dev/demo vehicle: local dev loop, target gallery, diagnostic probe surface. Not the product.\",\n  \"scripts\": {\n    \"dev\": \"vite dev\",\n    \"build\": \"vite build && vite build --config vite.client.config.ts\"\n  },\n  \"dependencies\": {\n    \"@brunch/binding-flue\": \"workspace:*\",\n    \"@brunch/core\": \"workspace:*\",\n    \"@brunch/plugin-gherkin\": \"workspace:*\",\n    \"@flue/react\": \"^2.0.3\",\n    \"@flue/runtime\": \"^2.0.3\",\n    \"@flue/sdk\": \"^2.0.3\",\n    \"hono\": \"^4.6.0\",\n    \"react\": \"^19.0.0\",\n    \"react-dom\": \"^19.0.0\",\n    \"valibot\": \"^1.4.2\"\n  },\n  \"devDependencies\": {\n    \"@earendil-works/pi-ai\": \"^0.83.0\",\n    \"@flue/vite\": \"^2.0.3\",\n    \"@types/react\": \"^19.0.0\",\n    \"@types/react-dom\": \"^19.0.0\",\n    \"vite\": \"^8\"\n  }\n}\n\n--- binding package ---\n{\n  \"name\": \"@brunch/binding-flue\",\n  \"version\": \"0.0.0\",\n  \"private\": true,\n  \"type\": \"module\",\n  \"description\": \"The Flue binding: implements the substrate-capability list and owns the storage-port implementation.\",\n  \"exports\": {\n    \".\": \"./src/index.ts\"\n  },\n  \"dependencies\": {\n    \"@brunch/core\": \"workspace:*\",\n    \"@flue/runtime\": \"^2.0.3\",\n    \"valibot\": \"^1.4.2\"\n  }\n}\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wblYKVSlMujnM0HrOX`
+
+```
+{
+  "output": "/**\n * The dev app's route map — the \"mount\" half of the thin host (spec §12.1).\n *\n * The dev app is chartered with three roles, none of them \"the product\"\n * (spec §12.5): the local dev loop against every plugin, the colleague-facing\n * target-gallery demo, and the diagnostic probe surface. Milestone one keeps\n * affordance renderers here rather than in a ui package.\n */\n\nimport { readFile } from 'node:fs/promises';\nimport { createAgentRouter } from '@flue/runtime/routing';\nimport { Hono } from 'hono';\nimport { GherkinElicitor } from './agents/gherkin-elicitor.ts';\nimport { assetHandler } from './assets.ts';\nimport { GHERKIN_AGENT_ROUTE } from './routes.ts';\n\nconst app = new Hono();\n\n// One route per target agent. The gallery grows an entry per plugin; gherkin\n// is the tracer that wires end-to-end first (spec §13). The browser and mount\n// share the route constant; Flue still keys storage on the agent's independent,\n// pinned identity.\napp.route(`/agents/${GHERKIN_AGENT_ROUTE}`, createAgentRouter(GherkinElicitor));\n\n// The flue dev controller owns the whole request space — no fall-through to\n// vite's html serving — so the ui is app-served, in dev and in production\n// alike (spec §10, recorded facts).\n//\n// Two different files, because two different builds produce them: in dev, the\n// source `index.html` whose script tag vite resolves live; in production, the\n// client build's emitted `index.html`, whose script tag points at a real\n// bundled asset. `@flue/vite` emits the server environment only, so that\n// client build is a second, plain vite build — without it the ui tree would\n// have no build coverage at all.\nconst uiRoot = new URL(import.meta.env?.DEV === false ? './client/' : '../', import.meta.url);\n\napp.get('/', async (c) => c.html(await readFile(new URL('index.html', uiRoot), 'utf8')));\n\n// Production only: in dev, vite serves the module graph under /src. A\n// wildcard, not `:file` — bundlers may emit nested asset paths.\napp.get('/assets/*', assetHandler(uiRoot));\n\nexport default app;\n\n--- agent ---\n'use agent';\n/**\n * The gherkin elicitor (spec §12.5: one agent per target).\n *\n * Named as a noun — the thing, not the act — and read target-first, so the\n * family sorts together as targets multiply: `gherkin-elicitor`,\n * `assurance-elicitor`.\n *\n * The product is the harness library in a thin host-authored agent — Flue's\n * build-time scan makes the alternative structurally unavailable, since a\n * library cannot ship a pre-registered agent (spec §12.1). So this module is\n * deliberately thin: it mounts harness capability and holds no elicitation\n * semantics of its own.\n *\n * Three recorded Flue constraints are honoured here by construction (spec §10):\n * the `'use agent'` directive is the file's first statement; `agentName` is a\n * pinned string literal, because conversation storage keys on it; and the tool\n * set is static, because prompt-cache economics forbid per-question tool\n * swapping.\n */\n\nimport { useElicitation } from '@brunch/binding-flue';\nimport { gherkin } from '@brunch/plugin-gherkin';\nimport { useModel, type AgentProps } from '@flue/runtime';\nimport * as v from 'valibot';\n\nexport function GherkinElicitor(_props: AgentProps) {\n  useModel('anthropic/claude-haiku-4-5');\n  return useElicitation(gherkin);\n}\n\n/**\n * Pinned, and never to be edited: conversation storage keys on this literal,\n * so changing it orphans every existing conversation. Flue requires a string\n * literal here because build targets derive durable identifiers from it before\n * any user code runs.\n *\n * Product-prefixed on purpose, and this is the one place the prefix is not\n * cosmetic. Agent identities are global per application, and the September\n * demo shell is chartered to mount this library alongside the Petrinaut\n * libraries — a bare `gherkin-elicitor` could collide with another library's\n * agent, and the collision would land on durable conversation storage.\n *\n * The exported symbol stays the shorter `GherkinElicitor` because it reads\n * better at the mount site; `agentName` exists precisely to let durable\n * identity and source-level name differ.\n */\nGherkinElicitor.agentName = 'brunch-gherkin-elicitor';\n\n/**\n * Session→document binding (spec §9.1, adjudication L4): a new session's\n * `initialData` carries the target-document id, validated once at creation and\n * immutable thereafter — Flue's own lane for a target descriptor. Dispatching\n * to an existing conversation id resumes that session against the current state\n * of its target-document.\n */\nGherkinElicitor.initialData = v.object({\n  targetDocumentId: v.pipe(v.string(), v.nonEmpty()),\n});\n\n--- config ---\nimport { defineConfig } from '@flue/runtime/config';\n\nexport default defineConfig({\n  target: 'node',\n});\nimport { flue } from '@flue/vite';\nimport { defineConfig } from 'vite';\n\n// No @vitejs/plugin-react: the flue plugin's dev controller owns the whole\n// request space and hands every request to app.ts, with no fall-through to\n// vite's html middleware — so index.html is app-served and react-refresh's\n// preamble injection would never run (recorded Flue fact, spec §10). Vite's\n// core esbuild transform still compiles the .tsx modules.\nexport default defineConfig({\n  plugins: [flue()],\n});\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wblbY0gbCrUkZxeF98`
+
+```
+{
+  "output": "/**\n * `@brunch/binding-flue` — the Flue binding.\n *\n * One binding per substrate. It implements the substrate-capability list\n * (spec §10), owns the storage-port implementation (spec §9.6), and is the\n * only shell allowed to know Flue's dialect: **the harness imports no\n * substrate; a binding imports both** (spec §4).\n *\n * Every time mechanism wants to land in here, the second-binding test applies\n * (spec §14.2): genuinely substrate-specific, or mechanism leaking into Flue's\n * dialect?\n */\n\nimport {\n  AskInput,\n  FreeTextAffordance,\n  toolName,\n  type FreeTextAffordanceValue,\n  type Plugin,\n} from '@brunch/core';\nimport {\n  useAgentStart,\n  useDataWriter,\n  useDelivery,\n  usePersistentState,\n  useTool,\n} from '@flue/runtime';\n\nexport { CAPABILITIES, type Capability, type Provision } from './capabilities.ts';\nexport { createLocalCaptureStore } from './local-capture-store.ts';\n\n/**\n * Mount the elicitation harness in a Flue agent.\n *\n * Flue has no ask-the-user primitive, so the harness owns the turn-suspension\n * protocol: a `terminate: true` ask tool, the pending affordance in\n * per-session state, and the answer arriving as a fresh dispatch (spec §7.4).\n */\nexport function useElicitation(plugin: Plugin): string {\n  const delivery = useDelivery();\n  const [pending, setPending] = usePersistentState<FreeTextAffordanceValue | null>(\n    'pendingAffordance',\n    null,\n  );\n  const writeAffordance = useDataWriter('affordance', { schema: FreeTextAffordance });\n\n  useAgentStart((ctx) => {\n    if (delivery.kind !== 'user' || pending === null) return;\n\n    setPending(null);\n    ctx.append({\n      kind: 'signal',\n      type: 'affordance-reply-bound',\n      tagName: 'affordance-reply-bound',\n      body: `The immediately preceding user message is mechanically bound as the reply to this pending affordance:\\n\\n${pending.markdown}`,\n      attributes: { affordanceId: pending.id },\n    });\n  });\n\n  useTool({\n    name: toolName('ask'),\n    description:\n      'Ask one free-text question and suspend this turn for the person’s reply. A second ask in the same tool batch is rejected.',\n    input: AskInput,\n    output: FreeTextAffordance,\n    run({ data, toolCallId }) {\n      const affordance: FreeTextAffordanceValue = {\n        id: `affordance_${toolCallId}`,\n        form: 'free-text',\n        markdown: data.question,\n        payload: { question: data.question },\n      };\n\n      setPending((current) => {\n        if (current !== null) {\n          throw new Error(\n            `An interactive affordance is already pending (${current.id}); wait for its reply before asking another question.`,\n          );\n        }\n        return affordance;\n      });\n      writeAffordance(affordance);\n\n      return { output: affordance, terminate: true };\n    },\n  });\n\n  return [\n    `You are interviewing someone to elicit ${plugin.targetDomain}.`,\n    `Ask one question at a time with ${toolName('ask')}.`,\n    'Continue the conversation after each reply, using the harness-provided reply binding as a mechanical fact.',\n  ].join('\\n\\n');\n}\n\n--- capabilities ---\n/**\n * The substrate-capability list (spec §10), recorded as data.\n *\n * This is the core/binding seam, the portability pressure test, and the early\n * smell detector all at once: porting means reimplementing this list, and\n * exotic Flue-shaped entries appearing in it is the smell. Keeping it as a\n * checkable record rather than prose is what lets the second-binding test\n * (spec §14.2) be asked of every future addition — \"genuinely\n * substrate-specific, or mechanism leaking into Flue's dialect?\"\n *\n * Binding-size asymmetry is expected, not failure: each binding absorbs what\n * its substrate lacks or forbids.\n */\n\n/** How a binding satisfies one capability. */\nexport type Provision =\n  /** The substrate offers it directly. */\n  | 'native'\n  /** The substrate lacks or forbids it; the binding supplies it itself. */\n  | 'absorbed';\n\nexport interface Capability {\n  readonly id: number;\n  readonly name: string;\n  readonly provision: Provision;\n  /** How this binding satisfies it, in Flue's dialect. */\n  readonly mechanism: string;\n}\n\nexport const CAPABILITIES: readonly Capability[] = [\n  {\n    id: 1,\n    name: 'Register a tool',\n    provision: 'native',\n    mechanism: 'defineTool / useTool',\n  },\n  {\n    id: 2,\n    name: 'Contribute instructions',\n    provision: 'native',\n    mechanism: 'render return',\n  },\n  {\n    id: 3,\n    name: 'Persist per-conversation state',\n    provision: 'native',\n    mechanism: 'usePersistentState, atomic with its unit of work',\n  },\n  {\n    id: 4,\n    name: 'Emit an affordance payload',\n    provision: 'native',\n    mechanism: 'data channel + tool output parts',\n  },\n  {\n    id: 5,\n    name: 'Suspend for reply',\n    provision: 'absorbed',\n    mechanism: 'no ask primitive: terminate:true + pending-affordance slot + fresh dispatch',\n  },\n  {\n    id: 6,\n    name: 'Private model call',\n    provision: 'native',\n    mechanism: 'harness.prompt scratch conversation',\n  },\n  {\n    id: 7,\n    name: 'Subscribe to the would-stop lifecycle seam',\n    provision: 'native',\n    mechanism:\n      'useAgentFinish + ctx.append; fires on suspensions, so the pending guard is load-bearing; loop-guarded',\n  },\n  {\n    id: 8,\n    name: 'Read the durable entry projection with provenance-discriminating entry kinds',\n    provision: 'absorbed',\n    mechanism:\n      'no in-process API: public history projection over self-HTTP; `purpose` discriminates provenance',\n  },\n  {\n    id: 9,\n    name: 'Inject typed non-user signal entries',\n    provision: 'native',\n    mechanism: \"ctx.append / dispatch({kind:'signal'}); projects structurally non-user\",\n  },\n  {\n    id: 10,\n    name: 'Provide a transactional durable store outside conversation state',\n    provision: 'absorbed',\n    mechanism:\n      'Flue neither provides nor forbids; the binding owns the storage-port implementation',\n  },\n];\n\n--- local store ---\nimport {\n  applyCaptureStoreCommand,\n  createEmptyCaptureStoreSnapshot,\n  parseCaptureStoreSnapshot,\n  type CaptureStore,\n  type CaptureStoreCommand,\n  type CaptureStoreResult,\n  type CaptureStoreSnapshot,\n} from '@brunch/core';\nimport { randomUUID } from 'node:crypto';\nimport { mkdir, readFile, rename, rm, writeFile } from 'node:fs/promises';\nimport { dirname, resolve } from 'node:path';\n\nconst writesByPath = new Map<string, Promise<void>>();\n\nclass LocalCaptureStore implements CaptureStore {\n  readonly #path: string;\n\n  constructor(path: string) {\n    this.#path = resolve(path);\n  }\n\n  async read(): Promise<CaptureStoreSnapshot> {\n    await writesByPath.get(this.#path);\n    return this.#readFile();\n  }\n\n  async execute(command: CaptureStoreCommand): Promise<CaptureStoreResult> {\n    const previous = writesByPath.get(this.#path) ?? Promise.resolve();\n    const operation = previous.then(async () => {\n      const result = applyCaptureStoreCommand(await this.#readFile(), command);\n      if (result.ok) await this.#writeFile(result.snapshot);\n      return result;\n    });\n    const settled = operation.then(\n      () => undefined,\n      () => undefined,\n    );\n    writesByPath.set(this.#path, settled);\n    void settled.finally(() => {\n      if (writesByPath.get(this.#path) === settled) writesByPath.delete(this.#path);\n    });\n    return operation;\n  }\n\n  async #readFile(): Promise<CaptureStoreSnapshot> {\n    try {\n      return parseCaptureStoreSnapshot(JSON.parse(await readFile(this.#path, 'utf8')));\n    } catch (error) {\n      if (\n        error instanceof Error &&\n        'code' in error &&\n        (error as NodeJS.ErrnoException).code === 'ENOENT'\n      ) {\n        return createEmptyCaptureStoreSnapshot();\n      }\n      throw error;\n    }\n  }\n\n  async #writeFile(snapshot: CaptureStoreSnapshot): Promise<void> {\n    await mkdir(dirname(this.#path), { recursive: true });\n    const temporaryPath = `${this.#path}.${randomUUID()}.tmp`;\n    try {\n      await writeFile(temporaryPath, `${JSON.stringify(snapshot, null, 2)}\\n`, {\n        encoding: 'utf8',\n        flag: 'wx',\n      });\n      await rename(temporaryPath, this.#path);\n    } finally {\n      await rm(temporaryPath, { force: true });\n    }\n  }\n}\n\nexport const createLocalCaptureStore = (path: string): CaptureStore => new LocalCaptureStore(path);\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wblefITqctRFXexOWS`
+
+```
+{
+  "output": "# Elicitation Kernel\n\nVocabulary for the elicitation-kernel effort: a standalone architecture generalizing brunch's elicitor into agentic interviewing against pluggable elicitation targets.\n\n## Language\n\n### Shells\n\n**Substrate**:\nThe agent framework the system is built on — the Pi family, Flue — including the embedding environment's concerns: deploy target, storage-port implementation, artifact delivery, model/provider. (The retired term \"host\" silently bundled these with interface concerns; they split into substrate and UI. The charter non-goal \"harness-agnostic core\" predates this glossary and reads \"substrate-agnostic\".)\n_Avoid_: harness (for Pi/Flue), platform, host (for the embedding environment)\n\n**UI**:\nThe interface shell: whatever affords user interaction — rendering, input, reply transport. Not bound to GUI or TUI; a chat channel qualifies.\n_Avoid_: host, host-interface, frontend, client\n\n**Harness**:\nThe middle shell and the essence of the effort: the generic capability layer of the elicitation system — mechanism and orchestration (the conversation loop, the `ask` API, capture envelope, issue queue, sweep bookkeeping). Injected into plugins as a narrow context; never owned by them.\n_Avoid_: kernel, core, elicitor (as a shell name — \"elicitor\" may name the whole system). Exempt compound: **kernel card** (below). \"Kernel invariants\" renamed **harness invariants** (spec §14.1).\n\n**Plugin**:\nThe innermost shell: target-defining policy. Declares packs, forms, and validators; composes at authoring time; receives harness capabilities by injection. Mostly policy — mechanism stays in the harness.\n_Avoid_: extension, pack (a pack is a unit *within* a plugin)\n\n**Binding**:\nThe substrate-facing adapter between harness and substrate: implements the harness's named substrate-capability list (tool registration, instruction assembly, persistent state, affordance emission, suspend-for-reply, private model call) in one substrate's dialect. One per substrate; the harness imports no substrate, a binding imports both. Bindings vary in size — each absorbs what its substrate lacks or forbids.\n_Avoid_: adapter (generic), integration, wrapper\n\n### Sessions & durability\n\n**Target-domain**:\nThe artifact family being elicited — what a plugin defines (gherkin scenarios, assurance arguments, BPMN). The family half of the former bare \"target\".\n_Avoid_: target-paradigm; bare \"target\" where family/instance is ambiguous\n\n**Target-document**:\nThe durable unit sessions attach to: one target-domain, its capture store, and its session history. Named by its purpose — its authoritative state is the capture store plus session logs, never the rendered artifact (renders are derived, cacheable, disposable). Endures independently of any session; never locks — completion is a derived status, not a write gate.\n_Avoid_: spec (as the unit name), workpiece, case, target-output\n\n**Session**:\nOne substrate conversation — the full log of entries (user, agent, tool calls, injected state messages), matching Pi's session model. Per-session state is exactly: the evidence log, the swept high-water mark, the pending-affordance slot. Sessions go quiet rather than close; any session is resumable against the current state of its target-document.\n_Avoid_: sitting, conversation (as a distinct concept)\n\n**Capture store**:\nThe durable, session-independent truth of a target-document: captures, issues, events. Written only by atomic sweep application (serialized); statuses and projections derive from it at read time.\n\n**Re-entry briefing**:\nThe state message the harness injects when a session resumes after the world moved: computed facts only — unswept tail, world-moved delta, open issues, pending affordance. Authored on behalf of the user in the transcript (Pi's custom-entry convention) but distinguished from true user entries in the data model, and never citable as capture evidence.\n_Avoid_: sync message, forced re-sweep\n\n### Interaction\n\n**Affordance**:\nA structured interactive element (question form, choice strip, questionnaire) emitted into the conversation stream as a rendered enhancement. Not a state machine — the conversation stays primary, and an affordance's payload is evidence in the session like any other entry.\n_Avoid_: exchange, exchange pair, terminal (brunch's retired turn-by-turn ontology)\n\n**Capture**:\nExtraction of structured evidence — envelope plus plugin-typed payload — from session entries. Produced by sweeps, never written directly during conversation.\n_Avoid_: extraction, harvest\n\n**Sweep**:\nAn idempotent pass over a settled range of session entries that produces captures. Re-sweeping a range never double-captures.\n\n**Settlement**:\nThe agent-judged event marking a range of conversation (a vein closing) ready to sweep. Always range-level, never per-question.\n_Avoid_: exchange completion\n\n**Interpretation render**:\nThe harness-owned affordance form showing current captured state — the harness frames envelope semantics; the plugin's renderer definition (typed against its own payload shapes) supplies the content view when provided, with a harness default (plain JSON view) otherwise.\n_Avoid_: digest (brunch's form)\n\n### Envelope & packs\n\n**Intermediate representation (IR)**:\nThe elicited description a target-document accumulates: the set of active captures, read through the plugin's declared payload type system. Not a second store — every consolidated view (entity graph, net, completion table) is a read-time projection over active captures, and the rendered artifact is one projection of the IR, never the IR itself. Defining a plugin's IR means defining its payload type system.\n_Avoid_: knowledge store, domain model (as a stored unit), staging area\n\n**Capture envelope**:\nThe harness-defined, domain-free wrapper around an opaque plugin payload: harness-minted id, evidence spans, epistemic status, confidence, value-xor-absence, alternatives grouping, one `supersedes` link. The hourglass waist. No stored status — envelope status (`active | superseded | retracted`) derives at read time from links and events.\n\n**Evidence span**:\nA capture's provenance link: a **quoted excerpt** (primary, the model-facing citation currency) plus a **pointer** (session id + entry range, harness-derived — entry identity is harness-side vocabulary only). Anchors only on true user and user-affordance-payload entries.\n\n**Epistemic status**:\n`explicit | inferred | tentative | defaulted | external-lookup` — how a capture's content relates to what the user actually said. Distinct from confidence; excluded from capture identity.\n\n**Absence state**:\nA first-class capture value where an answer would be: `unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred` (`not-mentioned` is a computed fact, not a sweepable capture). Never collapses to null.\n_Avoid_: null, missing (as the stored representation)\n\n**Supersession**:\nThe explicit correction mechanism, single-hop over active heads only. Two channels: the creation-time `supersedes` link (sweep-time correction) and the resolution record (issue-time adjudication). Superseded captures stay visible — corrections don't erase history.\n\n**Resolution record**:\nThe explicit capture-store event that alone closes a `conflicting` issue (and, with no successor capture, expresses retraction). Must cite the true user's utterance as evidence.\n\n**Issue**:\nTyped, stored backpressure to the elicitation controller: `missing / ambiguous / conflicting / invalid / unsupported / unmapped / low-confidence`, with factual attributes. Two producers, namespaced: plugin ops (payload level) and the harness itself (envelope level). Closes only explicitly.\n_Avoid_: advisory (a different thing, below)\n\n**Advisory**:\nA computed, ephemeral, non-blocking fact the harness surfaces to the agent (unaccounted ask, unswept tail, world-moved delta). Never stored in the capture store; never gates anything.\n\n**Pack**:\nA unit within a plugin: **ElicitationPack** (kernel cards, completion contract, clarification hints) or **ProjectionPack** (`project` + `validate`, optional `reconcile`, annotated shapes, typed loss reports). Packs are shapes-to-fill plus behavioral guidance, per Principle v2.\n\n**Kernel card**:\nThe pack-content unit of elicitation guidance: Detects / Goal / contrastive Questions / Artifacts (brunch `BEHAVIORAL_KERNELS.md` lineage — \"kernel\" here names a small unit of behavioral guidance, not a shell; the compound is the glossary's one sanctioned \"kernel\" use). Splits by ownership: domain cards are plugin pack content; a harness-shipped **generic strategy quiver** (cards over envelope vocabulary — conflict, ambiguity, weak evidence) is named in spec §11.5, not designed.\n\n**PluginContext**:\nThe narrow injected context through which a plugin receives harness capabilities (the ask API, envelope, issue queue, sweep bookkeeping). The plugin's entire world at runtime; the four operations remain pure (snapshot-in/deltas-out) regardless.\n\n**Storage port**:\nThe harness-defined contract for the capture store (atomic sweep application, envelope invariants as store-level refusals), implemented by the binding for its deploy target. Plugins are storage-blind. Scope includes the **session-log archive** (archive-on-read; spec §9.6): session logs live with the target-document, retained indefinitely — the substrate's conversation store is the live transport copy, never the provenance record.\n\n### September demo\n\n**Demo shell**:\nThe one-off application built for the 17–18 September demo: consumes the elicitation library (harness + plugin + binding) and the Petrinaut libraries, owns the UI, session persistence, and elicitor runtime. Explicitly disposable — not a product commitment; neither library consumes the other.\n_Avoid_: \"the app\", standalone brunch, demo app (unqualified)\n\n**Artifact boundary**:\nThe decided integration posture between elicitor and Petrinaut (FE-1362): the elicitor emits a versioned net file plus scenario; Petrinaut consumes it through its published parser and import-with-autolayout path. The rejected alternative was library coupling (one library consuming the other).\n_Avoid_: file handoff (undersells it), integration (generic)\n\n**Revision story**:\nThe working-hypothesis demo spine (FE-1363; recommended to PM, not ratified): a sped-up recorded elicitation (conversation, interpretation surface, and growing net visible together) plus a bounded live segment in which a few turns elicit a fact forcing a structural revision of the net, run before/after in Petrinaut.\n_Avoid_: live demo (unqualified — the live part is one bounded segment, not the format)\n\n### Simulation & evaluation\n\n**Situation pack**:\nThe interviewee-side bundle defining a user-to-be-simulated: situation, scenario, and persona — knowledge and motivations, some facts deliberately coloured by the persona's perspective. Private to the agent (or human) playing the user. Invariant: never authored from, or shaped to mirror, the IR — the elicitor's job is to excavate across that wall.\n_Avoid_: fact pack (undersells the persona; collides with the answer key), persona pack (too narrow)\n\n**Answer key**:\nThe modeller-side list of facts the reference net needs, derived from the reference model — the evaluation rubric for what an elicitation should have excavated from a situation pack. Satisfies PRO-99's \"written list of all facts necessary to make the net\". Sits on the elicitor-team side of the wall; never part of the situation pack.\n_Avoid_: fact list (ambiguous with situation-pack content)\n\n**Walking skeleton**:\nA prototype that proves a transport or integration end-to-end on the real substrate (e.g. a real Flue agent + web UI) with stubbed internals.\n\n**Logic-prototype**:\nA prototype that locks down mechanism semantics (e.g. capture sweeps, settlement) in isolation, without the full host substrate.\n\n--- spec deployment section ---\nthe second-binding test keeps passing. **Publishing posture: workspace-internal**; the publishable\nshape is exactly the package boundaries above, but publishing waits on the real name and an\nexternal consumer.\n\n### 12.3 Naming & tool namespacing\n\nArchitectural strings name **identity, not function**: tool prefix derived from the product name —\nprovisionally `bl_*`, never `elicit_*`. All model-facing tools are harness-owned (plugins expose\noperations, not tools); core names operations abstractly, the binding renders substrate tool\nnames. The name-fog eventually resolves every provisional string; nothing bakes \"elicit\" or\n\"brunch\" into structure.\n\n### 12.4 Schemas and the SDK\n\n**Valibot throughout** — Flue locks it at every boundary; a Standard-Schema waist would buy\ncomfort at the cost of a conversion seam that can silently drop constraints (the silent-coercion\nsmell). SDK surface (core's exports): evidence anchoring, capture identity, issue construction,\nschema validation, retries, idempotency, state-delta application, tracing, test fixtures, the\nlocal simulation harness (\"debugging should not require reading an entire agent transcript\"), plus\nthe testing machinery of §14.4 (schema-driven arbitraries, the command alphabet, mutation\noperators, fixture freeze/replay format).\n\n### 12.5 Dev app, deploy, remote parity\n\n- **Dev app chartered with three roles** (roles, not features): the local dev loop against both\n  plugins; the colleague-facing **target-gallery demo** (parallel tabbed sessions across targets);\n  the **diagnostic probe surface** (provisional affordance renderers now; the exploded-view\n  instrumented readout when that fog graduates). One agent per target (`ElicitGherkin`,\n  `ElicitAssurance`): static per-agent tool sets, and the shape Cloudflare forces anyway.\n- **UI affordance package deferred**, named as intended: React renderers + reply transport over\n  `@flue/react`; non-React hosts build on `@flue/sdk`. Milestone one keeps renderers in the dev\n  app.\n- **Milestone one is local-only**, with **remote-parity constraints pinned now** so nothing\n  local-only creeps in: one-agent-many-conversations; pinned `agentName`; the storage port owned\n  outside the plugin (harness-defined, binding-implemented, §9.6); no dynamic agent creation.\n  Deploy-target choice waits on an infra conversation and blocks nothing here.\n- **CI smoke** = `vite build` + the simulation suite (no model key, no flake); an optional\n  secret-gated real-model `flue run` smoke once a provider key exists.\n\n### 12.6 Version axes (named, none implemented)\n\nAPI contract / plugin implementation / concept-schema / target-schema / persisted state. A change\nto a field's meaning is not a serializer change; the future migration story must be able to decide\nreuse / mechanical migration / reinterpretation-from-evidence / re-elicit.\n\n## 13. Dev targets and milestone one\n\n**Portfolio**: `plugin-gherkin` (tracer) + `plugin-assurance` (second target; forces the pack swap\nand the evidence-graded envelope); BPMN/process-mining named third; full elicit-lean deferred.\n**Hybrid order**: **both packs are authored before the pack interface freezes** (the two-targets-\non-each-axis rule, applied at design time — the trivial target must not freeze the contract before\nthe hard target has stressed it); **gherkin wires end-to-end first** as the cheap mechanism proof,\nassurance immediately after.\n\n### 13.1 Gherkin (milestone one)\n\n\n--- known gaps ---\n/**\n * The gaps this codebase knows it has.\n *\n * Spec §14.5 names five open verification items. Prose decays: an item nobody\n * runs into is an item nobody closes, and the ones here are exactly the kind\n * that stay invisible — a substrate behaviour nobody has driven, a durability\n * claim nobody has restarted into.\n *\n * So each gap is a record with a `closed` predicate that runs on every `bun\n * test`. Two things follow, and the second is the point:\n *\n * - while a gap is open, it is listed in the run output rather than forgotten;\n * - **when a gap's condition becomes true, the suite goes red** and stays red\n *   until someone deletes the entry. Closing a gap by accident is not allowed\n *   to pass silently — somebody has to look at it, confirm it, and record it\n *   on the ticket that owns it.\n *\n * The failure message is therefore an instruction, not a complaint.\n */\n\nimport { join } from 'node:path';\nimport { filesIn, REPO_ROOT, sourceFiles, workspacePackages } from './workspace.ts';\n\nexport interface KnownGap {\n  /** Short stable handle, used in test names. */\n  readonly id: string;\n  /** Spec section that names the item. */\n  readonly spec: string;\n  /** The Linear issue that owns closing it. */\n  readonly ticket: string;\n  /** What is not yet known, in one sentence. */\n  readonly gap: string;\n  /** What closing it requires — the thing a follow-up slice actually does. */\n  readonly closes: string;\n  /**\n   * True once the gap is demonstrably closed. Kept cheap and structural: this\n   * runs on every test invocation, so it may look at the tree but never at a\n   * model, a network, or a substrate.\n   */\n  readonly closed: () => boolean;\n}\n\n/**\n * A gap that a follow-up test closes is closed only when a test carrying the\n * citation `closes-gap: <id>` actually runs somewhere under `dir`:\n * registering a test and asserting something. Content rather than a filename,\n * because a filename check fails in both directions — `touch`ing the guessed\n * path \"closed\" a gap with nothing verified, while a real closure under any\n * other name stayed \"open\" forever and rotted the banner.\n *\n * The citation is a deliberate token, not any prose mention of the id: a test\n * that merely *talks about* the gap must not close it (the same cry-wolf\n * failure the directive check had with comments that mention `'use agent'`).\n */\nconst closedByTest = (dir: string, gapId: string): boolean =>\n  filesIn(join(REPO_ROOT, dir)).some(\n    (file) =>\n      file.text.includes(`closes-gap: ${gapId}`) &&\n      /\\b(?:test|it)\\s*\\(/.test(file.text) &&\n      file.text.includes('expect('),\n  );\n\nexport const KNOWN_GAPS: readonly KnownGap[] = [\n  {\n    id: 'restart-durability',\n    spec: '§14.5',\n    ticket: 'FE-1396',\n    gap: 'The capture store survives restart (proven in the ticket-13 prototype), but conversation-store durability with a real db.ts has never been driven across a restart.',\n    closes:\n      'A test under apps/dev/test that boots the dev app, holds a conversation, restarts the process, and resumes the same conversation id — citing `closes-gap: <this id>`.',\n    closed: () => closedByTest('apps/dev/test', 'restart-durability'),\n  },\n  {\n    id: 'compaction-vs-durable-history',\n    spec: '§9.7, §14.5',\n    ticket: 'FE-1386',\n    gap: 'No session has been driven across a compaction boundary, so whether Flue compaction leaves the durable entry projection intact is unverified — and evidence pointers bind to that projection.',\n    closes:\n      'A test under packages/binding-flue/test driving a session past compaction and asserting every capture’s evidence pointer still resolves through the session-log archive — citing `closes-gap: <this id>`.',\n    closed: () => closedByTest('packages/binding-flue/test', 'compaction-vs-durable-history'),\n  },\n  {\n    id: 'history-projection-paging',\n    spec: '§14.5',\n    ticket: 'FE-1391',\n    gap: 'The durable-history projection is read over self-HTTP; paging past ~1000 entries and binding base-URL discovery are both untested.',\n    closes:\n      'The binding’s history reader covering a paged projection, tested under packages/binding-flue/test — citing `closes-gap: <this id>`.',\n    closed: () => closedByTest('packages/binding-flue/test', 'history-projection-paging'),\n  },\n  {\n    id: 'interpretation-render-plugin-seam',\n    spec: '§7.6, §14.5',\n    ticket: 'FE-1394',\n    gap: 'The plugin-supplied renderer seam for the interpretation render has never been exercised, because no real pack exists yet.',\n    closes: 'A plugin supplying a renderer definition typed against its own payload shapes.',\n    closed: () => {\n      // Not a filename check: the seam is exercised once the plugin's source\n      // exports a renderer, wherever that export lives — and an empty file at\n      // a guessed path exports nothing.\n      const plugin = workspacePackages().find((pkg) => pkg.name === '@brunch/plugin-gherkin');\n      return (\n        plugin !== undefined &&\n        sourceFiles(plugin).some((file) =>\n          /export\\s+(?:const|function|class)\\s+\\w*[Rr]enderer/.test(file.text),\n        )\n      );\n    },\n  },\n];\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wblhIcclqrKPea7ip0`
+
+```
+{
+  "output": "// hermetic-substrate-test: faux-provider\nimport {\n  fauxAssistantMessage,\n  fauxProvider,\n  fauxToolCall,\n  type Context,\n} from '@earendil-works/pi-ai';\nimport { toolName } from '@brunch/core';\nimport { createFlueClient } from '@flue/sdk';\nimport { start } from '@flue/runtime/node';\nimport app from '../src/app.ts';\nimport { GherkinElicitor } from '../src/agents/gherkin-elicitor.ts';\nimport { GHERKIN_AGENT_ROUTE } from '../src/routes.ts';\n\nconst ask = toolName('ask');\nconst faux = fauxProvider({\n  provider: 'anthropic',\n  models: [{ id: 'claude-haiku-4-5' }],\n});\n\nlet replyContext: Context | undefined;\nfaux.setResponses([\n  fauxAssistantMessage(\n    [fauxToolCall(ask, { question: 'What outcome should the scenario describe?' })],\n    { stopReason: 'toolUse' },\n  ),\n  (context) => {\n    replyContext = context;\n    return fauxAssistantMessage([fauxToolCall(ask, { question: 'Who initiates that outcome?' })], {\n      stopReason: 'toolUse',\n    });\n  },\n  fauxAssistantMessage(\n    [\n      fauxToolCall(ask, { question: 'What happens first?' }),\n      fauxToolCall(ask, { question: 'What happens second?' }),\n    ],\n    { stopReason: 'toolUse' },\n  ),\n  fauxAssistantMessage('Waiting for the accepted question to be answered.'),\n]);\n\nconst flue = await start({\n  agents: [GherkinElicitor],\n  providers: [faux.provider],\n});\n\ntry {\n  const fetchApp = ((input: RequestInfo | URL, init?: RequestInit) =>\n    Promise.resolve(\n      app.fetch(input instanceof Request ? input : new Request(input, init)),\n    )) as typeof fetch;\n  const conversationId = `walking-skeleton-${crypto.randomUUID()}`;\n  const client = createFlueClient({\n    url: `http://brunch.test/agents/${GHERKIN_AGENT_ROUTE}/${conversationId}`,\n    fetch: fetchApp,\n  });\n\n  const kickoff = await client.send({\n    message: { kind: 'user', body: 'Begin the interview.' },\n    initialData: { targetDocumentId: 'walking-skeleton-test' },\n  });\n  await client.wait(kickoff);\n\n  const firstHistory = await client.history();\n  const firstParts = firstHistory.messages.flatMap((message) => message.parts);\n  const firstAsk = firstParts.find(\n    (part) =>\n      part.type === 'dynamic-tool' && part.toolName === ask && part.state === 'output-available',\n  );\n  const firstAskOutput =\n    firstAsk?.type === 'dynamic-tool' && firstAsk.state === 'output-available'\n      ? firstAsk.output\n      : undefined;\n\n  const answer = await client.send({\n    message: { kind: 'user', body: 'A shopper completes checkout.' },\n  });\n  await client.wait(answer);\n\n  const secondAnswer = await client.send({\n    message: { kind: 'user', body: 'The shopper initiates it.' },\n  });\n  await client.wait(secondAnswer);\n\n  const history = await client.history();\n  const finalAssistant = [...history.messages]\n    .reverse()\n    .find((message) => message.role === 'assistant');\n  const finalAskParts =\n    finalAssistant?.parts.filter((part) => part.type === 'dynamic-tool' && part.toolName === ask) ??\n    [];\n\n  console.log(\n    `WALKING_SKELETON_RESULT ${JSON.stringify({\n      boundReplyReachedModel:\n        JSON.stringify(replyContext).includes('A shopper completes checkout.') &&\n        JSON.stringify(replyContext).includes('affordance-reply-bound'),\n      durableOutput:\n        JSON.stringify(firstAskOutput).includes('What outcome should the scenario describe?') &&\n        JSON.stringify(firstAskOutput).includes('\"form\":\"free-text\"'),\n      markdownFloor: firstParts.some(\n        (part) =>\n          part.type === 'data-affordance' &&\n          JSON.stringify(part.data).includes('What outcome should the scenario describe?'),\n      ),\n      noInstructionWake: !JSON.stringify(history.messages)\n        .toLowerCase()\n        .includes('instructions updated'),\n      secondAskRejected:\n        finalAskParts.filter(\n          (part) => part.type === 'dynamic-tool' && part.state === 'output-available',\n        ).length === 1 &&\n        finalAskParts.filter(\n          (part) => part.type === 'dynamic-tool' && part.state === 'output-error',\n        ).length === 1,\n    })}`,\n  );\n} finally {\n  await flue.stop();\n}\n\n--- build artifact test ---\n/**\n * What the build actually emitted — checked against the artifact, not the source.\n *\n * `test/boundaries.test.ts` catches a misplaced `'use agent'` directive by\n * reading the source. This checks the same property from the other end: that\n * the agent really is registered in the emitted bundle. The distinction earns\n * its keep because the failure mode here is silent — `@flue/vite` drops a\n * module that stops looking like an agent module and the build stays green, so\n * \"it compiled\" says nothing about whether the app has any agents in it.\n *\n * Any future change that quietly stops an agent, its route, or the conversation\n * store from reaching the bundle fails here, whatever the cause: a directive\n * moved, a config path changed, an entry dropped from the scan glob.\n */\n\nimport { beforeAll, describe, expect, test } from 'bun:test';\nimport { existsSync, readdirSync, readFileSync } from 'node:fs';\nimport { join } from 'node:path';\nimport {\n  agentModules,\n  MODEL_KEY_NAME,\n  pinnedIdentities,\n  REPO_ROOT,\n  workspacePackages,\n} from './workspace.ts';\n\nconst DEV_APP = join(REPO_ROOT, 'apps/dev');\nconst DIST = join(DEV_APP, 'dist');\nconst CLIENT = join(DIST, 'client');\n\n/** Everything the server build emitted, concatenated. */\nlet bundle = '';\n\nbeforeAll(async () => {\n  // Build here rather than depending on a prior `bun run build`, so `bun test`\n  // alone is a complete signal and CI ordering cannot make this vacuous. The\n  // *root* build, not the dev app's own: CI has no separate Build step, so\n  // this is where every workspace package's build script gets exercised —\n  // building only apps/dev would let the next package's broken build merge\n  // green.\n  const built = Bun.spawnSync(['bun', 'run', 'build'], {\n    cwd: REPO_ROOT,\n    env: { ...process.env, NODE_ENV: 'production' },\n  });\n  if (built.exitCode !== 0) {\n    throw new Error(\n      `workspace build failed:\\n${built.stdout.toString()}\\n${built.stderr.toString()}`,\n    );\n  }\n  bundle = readdirSync(DIST)\n    .filter((entry) => entry.endsWith('.mjs'))\n    .map((entry) => readFileSync(join(DIST, entry), 'utf8'))\n    .join('\\n');\n});\n\n/** The pinned identity of every agent module in the dev app, read from source. */\nfunction declaredAgentIdentities(): string[] {\n  const dev = workspacePackages().find((pkg) => pkg.relPath === 'apps/dev')!;\n  return agentModules(dev).flatMap(pinnedIdentities);\n}\n\ndescribe('the emitted server bundle', () => {\n  test('exists', () => {\n    expect(existsSync(DIST)).toBe(true);\n    expect(bundle.length).toBeGreaterThan(0);\n  });\n\n  test('registers every declared agent under its pinned identity', () => {\n    // The check that matters. A `'use agent'` directive that is not the first\n    // statement builds green and simply never registers — the app boots with no\n    // agents and nothing says so until a conversation fails to start.\n    //\n    // Asserted against the emitted `__flueBindAgentModule(Fn, { identity })`\n    // call rather than the bare string, because the string survives that\n    // failure: the `agentName` assignment is still in the bundle as ordinary\n    // dead code once the module stops being scanned as an agent.\n    const bound = new Set(\n      [...bundle.matchAll(/__flueBindAgentModule\\([^)]*identity:\\s*[\"']([^\"']+)[\"']/g)].map(\n        (match) => match[1]!,\n      ),\n    );\n    const identities = declaredAgentIdentities();\n    expect(identities.length).toBeGreaterThan(0);\n    for (const identity of identities) {\n      expect({ identity, bound: bound.has(identity) }).toEqual({ identity, bound: true });\n    }\n  });\n\n  test('mounts the agent router and wires the conversation store', () => {\n    // Without db.ts reaching the bundle, conversations are process-memory and a\n    // restart loses them — a difference invisible until something restarts.\n    //\n    // Witnessed by strings that exist only in the app's own modules. The\n    // obvious witnesses are vacuous: `createAgentRouter` survives in a\n    // bootstrap JSDoc comment and `sqlite` in the bootstrap's unconditional\n    // default-adapter fallback, so both match even when the mount or db.ts\n    // never reach the bundle. (Bare `/agents/` is no better — a bundler\n    // region comment for `src/agents/` carries it.)\n    expect(bundle).toContain('route(`/agents/'); // app.ts's mount call\n    expect(bundle).toContain('BRUNCH_DEV_DB_PATH'); // db.ts's env override\n    expect(bundle).toContain('.data-wipe-me'); // db.ts's default store path\n  });\n\n  test('carries no model key', () => {\n    const modelKey = new RegExp(`${MODEL_KEY_NAME}\\\\s*[:=]\\\\s*['\"][^'\"]+['\"]`);\n    expect(bundle).not.toMatch(modelKey);\n  });\n});\n\ndescribe('the emitted client bundle', () => {\n  // `@flue/vite` emits the server environment only, so the ui tree is built by\n  // a second plain vite config. Without these, a client-side break would be\n  // invisible to CI — the Flue build would go green having never transformed a\n  // line of it.\n  test('emits html and a bundled entry', () => {\n    expect(existsSync(join(CLIENT, 'index.html'))).toBe(true);\n    expect(existsSync(join(CLIENT, 'assets/index.js'))).toBe(true);\n  });\n\n  test('the emitted html points at the built asset, not at source', () => {\n    // The failure this catches: shipping the source index.html, whose script\n    // tag names a .tsx module nothing serves in production.\n    const html = readFileSync(join(CLIENT, 'index.html'), 'utf8');\n    expect(html).toContain('/assets/index.js');\n    expect(html).not.toContain('.tsx');\n  });\n\n  test('the entry really bundled its dependencies', () => {\n    // A near-empty chunk would mean the entry resolved to nothing.\n    const entry = readFileSync(join(CLIENT, 'assets/index.js'), 'utf8');\n    expect(entry.length).toBeGreaterThan(10_000);\n  });\n});\n\n// The production asset route is tested in `apps/dev/test/assets.test.ts`,\n// against the handler module directly: the emitted server bundle targets\n// node (`node:sqlite`), so it cannot be imported and driven under `bun test`.\n\n--- CI ---\n# The CI smoke (spec §12.5): `vite build` plus the simulation suite — no model\n# key, no substrate, no flake. An optional secret-gated real-model `flue run`\n# smoke is named in the spec and deliberately absent until a provider key\n# exists; the suite asserts that it has not drifted in.\nname: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\njobs:\n  smoke:\n    runs-on: ubuntu-latest\n    steps:\n      # Full-SHA pins: org policy refuses tag-pinned actions (the job fails at\n      # setup before any step runs). Comments carry the tag each SHA matched.\n      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4\n\n      - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2\n        with:\n          bun-version: '1.3.14'\n\n      - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4\n        with:\n          path: ~/.bun/install/cache\n          key: ${{ runner.os }}-bun-${{ hashFiles('bun.lock') }}\n          restore-keys: ${{ runner.os }}-bun-\n\n      - run: bun install --frozen-lockfile\n\n      - name: Lint\n        run: bun run lint:check\n\n      - name: Formatting\n        run: bun run fmt:check\n\n      - name: Typecheck\n        run: bun run typecheck\n\n      # Reads the repository tree and the harness contract; touches no model\n      # and no substrate. Three suites, with different jobs: boundaries makes\n      # the spec §4/§12.2 invariants enforceable rather than aspirational;\n      # build-artifact checks what was actually emitted, because a Flue build\n      # that silently drops an agent still exits 0; known-gaps keeps the spec\n      # §14.5 open items visible and goes red when one closes unremarked.\n      #\n      # The build gate lives inside this step: build-artifact's beforeAll\n      # runs the full build (Flue server environment plus the plain client\n      # build that @flue/vite does not do) so that `bun test` alone is a\n      # complete signal. A separate Build step would build the app a second\n      # time for no additional coverage.\n      - name: Test\n        run: bun test\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wblkuA634jFxIvG1kG`
+
+```
+{
+  "output": "## ln/fe-1390-capture-store...origin/ln/fe-1390-capture-store\n\n--- recent ADR titles ---\ndocs/planning/elicitation-kernel/spec.md:1:# Elicitation Kernel — Specification\ndocs/planning/elicitation-kernel/spec.md:3:Status: draft for review\ndocs/planning/elicitation-kernel/spec.md:15:## 1. Purpose\ndocs/planning/elicitation-kernel/spec.md:32:## 2. Non-goals and seams\ndocs/planning/elicitation-kernel/spec.md:48:## 3. Vocabulary\ndocs/planning/elicitation-kernel/spec.md:65:## 4. Architecture: four shells and a binding\ndocs/planning/elicitation-kernel/spec.md:91:## 5. The capture envelope\ndocs/planning/elicitation-kernel/spec.md:137:### 5.1 Absence states\ndocs/planning/elicitation-kernel/spec.md:178:## 6. Operations, validation strata, issues\ndocs/planning/elicitation-kernel/spec.md:180:### 6.1 Plugin operations\ndocs/planning/elicitation-kernel/spec.md:203:### 6.2 Two validation strata\ndocs/planning/elicitation-kernel/spec.md:218:### 6.3 Issues vs. advisories\ndocs/planning/elicitation-kernel/spec.md:231:### 6.4 Operation cadence is orchestration policy\ndocs/planning/elicitation-kernel/spec.md:239:## 7. Questioning-UX contract\ndocs/planning/elicitation-kernel/spec.md:241:### 7.1 No exchange-pair ontology\ndocs/planning/elicitation-kernel/spec.md:249:### 7.2 Baseline forms and the markdown floor\ndocs/planning/elicitation-kernel/spec.md:262:### 7.3 One live affordance (adjudicated, C6)\ndocs/planning/elicitation-kernel/spec.md:277:### 7.4 Turn suspension, reply binding, and the wake wart (adjudicated, C7)\ndocs/planning/elicitation-kernel/spec.md:299:### 7.5 Transport outcomes (adjudicated, L9)\ndocs/planning/elicitation-kernel/spec.md:307:### 7.6 Interpretation render\ndocs/planning/elicitation-kernel/spec.md:315:### 7.7 Recorded transport facts (Flue)\ndocs/planning/elicitation-kernel/spec.md:324:## 8. Capture mechanics: settlement, sweep, supersession\ndocs/planning/elicitation-kernel/spec.md:326:### 8.1 Settlement: trigger and judgment\ndocs/planning/elicitation-kernel/spec.md:338:### 8.2 Harness-resolved evidence anchoring\ndocs/planning/elicitation-kernel/spec.md:347:### 8.3 Sweep idempotence\ndocs/planning/elicitation-kernel/spec.md:356:### 8.4 Supersession: single-hop, two channels\ndocs/planning/elicitation-kernel/spec.md:368:### 8.5 Resolution records\ndocs/planning/elicitation-kernel/spec.md:374:### 8.6 Unaccounted-ask advisory\ndocs/planning/elicitation-kernel/spec.md:381:### 8.7 Resume-time sweep reconciliation\ndocs/planning/elicitation-kernel/spec.md:387:## 9. Sessions, durability, and the storage port\ndocs/planning/elicitation-kernel/spec.md:389:### 9.1 Durable target-document, transient sessions, sweep as the only bridge\ndocs/planning/elicitation-kernel/spec.md:407:### 9.2 Per-session state and concurrency\ndocs/planning/elicitation-kernel/spec.md:420:### 9.3 Re-entry briefing\ndocs/planning/elicitation-kernel/spec.md:431:### 9.4 Provenance: only the true user's side is evidence\ndocs/planning/elicitation-kernel/spec.md:441:### 9.5 Completion is derived, never a gate\ndocs/planning/elicitation-kernel/spec.md:448:### 9.6 The storage port (adjudicated, C1)\ndocs/planning/elicitation-kernel/spec.md:473:### 9.7 Context compaction vs. the durable log\ndocs/planning/elicitation-kernel/spec.md:499:## 10. The substrate-capability list\ndocs/planning/elicitation-kernel/spec.md:530:## 11. Plugins and packs\ndocs/planning/elicitation-kernel/spec.md:532:### 11.1 What a plugin owns\ndocs/planning/elicitation-kernel/spec.md:542:### 11.2 Pack form and Principle v2\ndocs/planning/elicitation-kernel/spec.md:553:### 11.3 The smallest honest plugin\ndocs/planning/elicitation-kernel/spec.md:560:### 11.4 Pattern guidance (inherited from brunch, as patterns not mechanism)\ndocs/planning/elicitation-kernel/spec.md:568:### 11.5 Generic strategy cards (named, not designed)\ndocs/planning/elicitation-kernel/spec.md:589:## 12. Shipping shape\ndocs/planning/elicitation-kernel/spec.md:591:### 12.1 Root\ndocs/planning/elicitation-kernel/spec.md:599:### 12.2 Package topology (intended structure; nothing scaffolded during the map)\ndocs/planning/elicitation-kernel/spec.md:624:### 12.3 Naming & tool namespacing\ndocs/planning/elicitation-kernel/spec.md:632:### 12.4 Schemas and the SDK\ndocs/planning/elicitation-kernel/spec.md:642:### 12.5 Dev app, deploy, remote parity\ndocs/planning/elicitation-kernel/spec.md:659:### 12.6 Version axes (named, none implemented)\ndocs/planning/elicitation-kernel/spec.md:665:## 13. Dev targets and milestone one\ndocs/planning/elicitation-kernel/spec.md:674:### 13.1 Gherkin (milestone one)\ndocs/planning/elicitation-kernel/spec.md:680:### 13.2 The assurance argument\ndocs/planning/elicitation-kernel/spec.md:700:### 13.3 Derived labels, the ledger, and the validator's honest stance\ndocs/planning/elicitation-kernel/spec.md:718:## 14. Acceptance material\ndocs/planning/elicitation-kernel/spec.md:720:### 14.1 The ten harness invariants (restated in envelope vocabulary; enforced as test properties)\ndocs/planning/elicitation-kernel/spec.md:740:### 14.2 The five proof obligations (contract acceptance criteria)\ndocs/planning/elicitation-kernel/spec.md:748:### 14.3 Gating tests and review vocabulary\ndocs/planning/elicitation-kernel/spec.md:757:### 14.4 Testing strategy\ndocs/planning/elicitation-kernel/spec.md:777:### 14.5 Open verification items (named, with homes)\ndocs/planning/elicitation-kernel/spec.md:793:## Appendix A — Adjudications\ndocs/adr/0001-brunch-is-the-product-name.md:1:# ADR-0001: `brunch` is the product name, and it may appear in structure\ndocs/adr/0001-brunch-is-the-product-name.md:4:Status: accepted\ndocs/adr/0001-brunch-is-the-product-name.md:8:## Context\ndocs/adr/0001-brunch-is-the-product-name.md:32:## Decision\ndocs/adr/0001-brunch-is-the-product-name.md:51:## Why the agent identity carries the product prefix\ndocs/adr/0001-brunch-is-the-product-name.md:65:## Consequences\n",
+  "exitCode": 0
+}
+```
+
+## Assistant
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "rg -n \"BRUNCH_DEV_DB_PATH|sqlite\\(|db\\.ts|dbPath\" apps/dev packages test -g '*.ts' -g '*.json' && printf '\\n--- files ---\\n' && rg --files apps/dev | sort",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "sed -n '380,530p' docs/planning/elicitation-kernel/spec.md && sed -n '720,792p' docs/planning/elicitation-kernel/spec.md && printf '\\n--- boundaries ---\\n' && sed -n '1,220p' test/boundaries.test.ts",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/database/",
+  "objective": "Extract current Flue Node database adapter setup, supported stores, schema/migration ownership, deployment topology, and limits relevant to converting this project's local SQLite persistence into production persistence.",
+  "forceRefetch": true
+}
+```
+
+**Tool Use:** `read_web_page`
+
+```json
+{
+  "url": "https://flueframework.com/docs/guide/deploy/",
+  "objective": "Extract Flue's framework-level deployment decision tree and target tradeoffs, especially Node vs Cloudflare and constraints that matter to this project's current Node app.",
+  "forceRefetch": true
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wc1p3MauwgskU7O6CJ`
+
+```
+{
+  "output": "test/boundaries.test.ts:342:    // `db.ts` — Flue's build-time scan makes shipping a pre-registered agent\ntest/boundaries.test.ts:344:    for (const file of ['src/app.ts', 'src/db.ts']) {\napps/dev/src/db.ts:18:export default sqlite(conversationDbPath());\ntest/known-gaps.ts:68:    gap: 'The capture store survives restart (proven in the ticket-13 prototype), but conversation-store durability with a real db.ts has never been driven across a restart.',\napps/dev/src/db-path.ts:7: * the exact restart-durability failure `db.ts` exists to prevent. From `src/`\napps/dev/src/db-path.ts:11: * Kept apart from `db.ts` so it stays importable under `bun test`: the\napps/dev/src/db-path.ts:19:  // '' through to sqlite(), which opens an anonymous temporary database\napps/dev/src/db-path.ts:21:  const override = process.env.BRUNCH_DEV_DB_PATH;\ntest/build-artifact.test.ts:90:    // Without db.ts reaching the bundle, conversations are process-memory and a\ntest/build-artifact.test.ts:96:    // default-adapter fallback, so both match even when the mount or db.ts\ntest/build-artifact.test.ts:100:    expect(bundle).toContain('BRUNCH_DEV_DB_PATH'); // db.ts's env override\ntest/build-artifact.test.ts:101:    expect(bundle).toContain('.data-wipe-me'); // db.ts's default store path\napps/dev/test/db-path.test.ts:8: * Tested against `db-path.ts` rather than `db.ts`, because the adapter module\napps/dev/test/db-path.test.ts:23:  const originalOverride = process.env.BRUNCH_DEV_DB_PATH;\napps/dev/test/db-path.test.ts:27:    if (originalOverride === undefined) delete process.env.BRUNCH_DEV_DB_PATH;\napps/dev/test/db-path.test.ts:28:    else process.env.BRUNCH_DEV_DB_PATH = originalOverride;\napps/dev/test/db-path.test.ts:32:    delete process.env.BRUNCH_DEV_DB_PATH;\napps/dev/test/db-path.test.ts:43:    process.env.BRUNCH_DEV_DB_PATH = './relative/on-purpose.db';\napps/dev/test/db-path.test.ts:48:    // sqlite('') would open an anonymous temporary database deleted on close\napps/dev/test/db-path.test.ts:50:    process.env.BRUNCH_DEV_DB_PATH = '';\n\n--- files ---\napps/dev/flue.config.ts\napps/dev/index.html\napps/dev/package.json\napps/dev/src/agents/gherkin-elicitor.ts\napps/dev/src/app.ts\napps/dev/src/assets.ts\napps/dev/src/db-path.ts\napps/dev/src/db.ts\napps/dev/src/routes.ts\napps/dev/src/ui/chat.tsx\napps/dev/src/ui/main.tsx\napps/dev/src/ui/styles.css\napps/dev/test/assets.test.ts\napps/dev/test/db-path.test.ts\napps/dev/test/walking-skeleton.integration.ts\napps/dev/test/walking-skeleton.test.ts\napps/dev/vite.client.config.ts\napps/dev/vite.config.ts\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wc1qW3vv33A67vRyQU`
+
+````
+{
+  "output": "\n### 8.7 Resume-time sweep reconciliation\n\nA session ending between settlement judgment and sweep leaves an unswept tail — a computable fact\n(entries above the high-water mark). On resume the harness surfaces it as an advisory (inside the\nre-entry briefing, §9.3) and the agent judges whether to sweep before proceeding.\n\n## 9. Sessions, durability, and the storage port\n\n### 9.1 Durable target-document, transient sessions, sweep as the only bridge\n\n- **Target-document** = one target-domain + its capture store + its session history. Its\n  authoritative state is **the capture store plus all session logs — never the render**.\n  Projections, renders, and artifacts are strictly derived: cacheable, disposable. Session logs\n  are durable truth too: discarding swept logs would dead-end every capture's evidence pointers.\n  **Conversations are themselves documents** (amended on review 2026-08-11): each session log is\n  kept as reference, indefinitely, and lives **with** the target-document in the same persistence\n  home — the storage port's session-log archive (§9.6) — so evidence pointers resolve against\n  the target-document's own store, never against whatever the substrate happens to retain.\n- **Session** = one substrate conversation. Sessions **never formally close** — they go quiet and\n  stay resumable; \"ended\" would be a fiction the harness cannot verify.\n- **Session→document binding** (adjudicated, L4): a new session's `initialData` carries the\n  target-document id (validated once at creation, immutable — Flue's own lane for a target\n  descriptor). Dispatching to an existing conversation id resumes that session against the current\n  state of its target-document; a new id opens a new session against the named document. Plugin\n  choice is conversation-lifetime-immutable for the same reason.\n\n### 9.2 Per-session state and concurrency\n\nStrictly per-session state is **exactly three things**: the evidence log, the swept high-water\nmark, the pending-affordance slot. (The private scratchpad is *not* session state — pattern\nguidance only; its natural Flue home is the `harness.prompt` scratch conversation, §11.4.)\n\nConcurrency is **interleaved-only** for milestone one: the store is serialized (sweeps validate\nand apply atomically — a transactional guarantee, not a session lock); staleness is optimistic —\nthe single-hop supersession refusal doubles as the stale-session guard, and the refusal carries\nthe world-moved facts. Refusal granularity is **whole-sweep atomic**; re-proposing is cheap once\nthe advisory is digested. No locking, no merge, no sync events; true simultaneous-sweep\ncoordination stays fog until a real concurrent consumer appears.\n\n### 9.3 Re-entry briefing\n\nWhen a session resumes after the world moved, the harness injects a **state message** on the\nuser's behalf (Pi's custom-entry convention; on Flue, a typed `kind: 'signal'` entry). Content is\ncomputed facts only: unswept tail, world-moved delta (captures created/superseded and issues\nopened/closed since this session's last sweep; anchor = session start if it never swept), open\nissues, pending unanswered affordance. Advisory-only — the agent weighs; nothing is forced. A\n**minimal user-visible insertion notice** accompanies every injected state message. Ticket 13\nproved the briefing in all three shapes (fresh, resumed, post-restart) and observed it produce\nunscripted conversational conflict-surfacing.\n\n### 9.4 Provenance: only the true user's side is evidence\n\nThe data model **distinguishes true user entries from injected on-behalf-of-user entries**.\nCapture evidence spans anchor only on true user (and user-affordance-payload) entries; injected\nbriefings live in the log honestly but are **never citable as capture evidence** — and on Flue\nthis is mechanically enforced, since signals appear structurally non-user in the entry projection\n(a capture citing an injected entry is refused at validation). Reconciliation with harness invariant 1 (Appendix A,\nC5): user-derived captures cite user entries; `defaulted` / `external-lookup` captures cite a\ndeclared default or documented transformation instead.\n\n### 9.5 Completion is derived, never a gate\n\nA target-document has no lock and no terminal state: completion-contract satisfaction is a\nread-time derived status (§5's derived-status family). A user returning with a correction after\n\"done\" is the motivating story. Semantic completeness and representation completeness remain\nseparate assessments; each issue records its origin.\n\n### 9.6 The storage port (adjudicated, C1)\n\n**The storage port is harness-defined and binding-implemented; plugins are storage-blind.** The\nharness defines the port's contract (the capture-store operations and their envelope invariants,\nenforced as store-level refusals); the binding implements it for its deploy target; the plugin\nnever touches persistence. Reconciliation with the shipping-shape's \"host-owned storage\": the\nsubstrate's *conversation* storage (Flue's `db.ts`) stays host-authored because Flue requires it\nof the consuming app; the harness's *capture store* is the storage port, implemented in\n`packages/binding-flue` (and any future binding). The remote-parity constraint reads accordingly: the\nstorage port is owned **outside the plugin** (§12.5).\n\n**The port's scope is the capture store plus the session-log archive** (amended on review\n2026-08-11): session logs attached to a target-document live with it, retained indefinitely.\nThe mechanism is **archive-on-read** — whenever the binding reads the durable entry projection\n(every sweep, every briefing computation), it retains the entries it read in the\ntarget-document store. At minimum, every entry a capture points to must be retrievable from the\narchive forever; the substrate's conversation store remains the live transport copy, never the\nprovenance record.\n\n**Milestone-one local store**: binding-owned; the format is binding-internal **but constrained** —\nit must provide whole-sweep-atomic application and refusals with serialized writes (adjudicated,\nL13; a flat append-only text file does not qualify unaided). The ticket-13 skeleton's shape (JSON\nfile, tmp+rename atomic, in-process serialization) is the proven floor; it holds the session-log\narchive alongside captures, issues, and events.\n\n### 9.7 Context compaction vs. the durable log\n\nPi-family substrates compact long transcripts, with custom compaction definitions controlling\nwhich entry kinds survive in the context the model re-reads — ordinary user and agent messages\nare normally summarized away. This never touches the spec's durability claims, **provided one\nconstraint holds, stated here as part of the storage contract**:\n\n- **Compaction may shrink what the model re-reads, never what the store can resolve.** Evidence\n  pointers and the sweep machinery bind to the **durable entry projection** (capability 8, §10),\n  not to the model's context window. A binding must guarantee the durable projection is\n  compaction-independent; a substrate whose compaction prunes durable history is a substrate whose\n  binding must preserve the pruned entries itself (binding absorption, as with capability 10).\n  The session-log archive (§9.6) is that preservation mechanism, already in place: compaction\n  cannot remove anything the archive holds.\n- Two existing mechanisms already cushion the model-side loss: **excerpt-primary evidence spans**\n  (§5) keep every capture citable and self-contained even where durable access degrades, and the\n  **re-entry briefing** (§9.3) already treats \"the model no longer remembers\" as a normal state —\n  a compacted session is informationally a resumed one. Per-session harness state (high-water\n  mark, pending-affordance slot) lives outside the transcript and cannot be compacted away.\n- If a binding supplies a compaction definition, injected signals and affordance tool parts need\n  no protected status: briefings are recomputable facts and affordance identity is durable on\n  tool output parts — only true user entries are irreplaceable, and the archive holds those.\n\nWhether Flue's compaction (if and as it ships one) preserves the durable-history projection\nunmodified is **unverified** — named in §14.5.\n\n## 10. The substrate-capability list\n\nThe core/binding seam, the portability pressure test, and the early-smell detector: porting =\nreimplementing this list; exotic Flue-shaped entries appearing here is the smell. **Ten entries**\n(six from the shipping-shape resolution, four added by the sweep-seam skeleton):\n\n| # | Capability | Flue status |\n|---|---|---|\n| 1 | Register a tool | native (`defineTool`/`useTool`) |\n| 2 | Contribute instructions | native (render return) |\n| 3 | Persist per-conversation state | native (`usePersistentState`, atomic with its unit of work) |\n| 4 | Emit an affordance payload | native (data channel + tool output parts) |\n| 5 | Suspend-for-reply | **absorbed**: no ask primitive; `terminate: true` + pending slot + fresh dispatch (§7.4) |\n| 6 | Private model call | native (`harness.prompt` scratch conversation) |\n| 7 | Subscribe to the would-stop lifecycle seam, with same-response signal steering | native (`useAgentFinish` + `ctx.append`; fires on suspensions — pending guard load-bearing; loop-guarded) |\n| 8 | Read the session's durable entry projection, with provenance-discriminating entry kinds | **binding-absorbed**: no in-process API; public history projection over self-HTTP; `purpose` discriminates provenance |\n| 9 | Inject typed non-user signal entries, same-response and as deliveries | native (`ctx.append` / `dispatch({kind:'signal'})`; projects structurally non-user) |\n| 10 | Provide a transactional durable store outside conversation state | **binding-absorbed** entirely (Flue neither provides nor forbids) |\n\nBinding-size asymmetry is expected, not failure: each binding absorbs what its substrate lacks or\nforbids. Core names operations abstractly; the binding renders substrate tool names.\n\n**Recorded Flue facts the implementation must respect**: `@flue/vite` requires vite ^8 and the\n`'use agent'` directive as the file's first statement; `agentName` must be a string literal and\nmust be pinned (conversation storage keys on it); the dev controller owns the whole request space,\nso the ui is a separate app or app-served assets; tool schemas are Valibot, frozen at module load;\ntool names are globally unique per render with reserved names; prompt-cache economics forbid\nper-question tool swapping (one stable tool set + state-driven instructions); subagents are\nconversationally sterile; non-React hosts build on `@flue/sdk`; without `db.ts` conversations are\nprocess-memory (restart loses them; the capture store survives independently — proven, ticket 13).\n\n## 11. Plugins and packs\n### 14.1 The ten harness invariants (restated in envelope vocabulary; enforced as test properties)\n\n1. **No value without provenance.** Every projected value traces to a capture (with evidence\n   spans), a declared default, or a documented transformation.\n2. **No silent conflict resolution.** Contradictory active captures resolve only via an explicit\n   resolution record or supersession event.\n3. **No silent projection loss.** Relevant active captures that cannot be represented appear in\n   the typed loss report.\n4. **Corrections don't erase history.** Superseded captures remain inspectable and never active.\n5. **Retries are semantically idempotent.** A retried operation or re-swept range never creates a\n   second user assertion (content-keyed capture identity).\n6. **Issues are namespaced to their producer.** A plugin/target-domain requirement never silently\n   becomes a harness-level requirement; harness envelope issues are namespaced to the harness.\n7. **Plugin failures are atomic.** A failed operation leaves no partially applied deltas; sweeps\n   apply whole or refuse whole.\n8. **Equivalent state produces equivalent projection.** Projection is a function of the\n   capture-store snapshot, never of discovery order.\n9. **Unknown remains distinct from false.** Absence states never collapse to null or negation.\n10. **Explicit remains distinct from inferred and defaulted.** Epistemic status never collapses.\n\n### 14.2 The five proof obligations (contract acceptance criteria)\n\nIndependent variability · semantic conservation · explicit transformation · controlled elicitation\n· local implementation — judged as in the criteria doc, against the hourglass. Companion tests:\n**smallest-honest-plugin** (every contract addition checked against the bar it raises) and its\nsibling the **second-binding test** (every time mechanism wants to land in the binding: \"genuinely\nsubstrate-specific, or mechanism leaking into Flue's dialect?\").\n\n### 14.3 Gating tests and review vocabulary\n\nGating: **reprojection / projector substitution** (capture once, project into materially different\ntargets, verify agreement); **minimal pairs** (\"the budget is / might be €20,000\"); **black-box\nauthoring** (public SDK + docs to a developer who hasn't read core; count concepts, boilerplate,\nescape hatches). Review vocabulary (named smells): opaque payload waist, giant context bag,\nschema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden\ntarget leakage.\n\n### 14.4 Testing strategy\n\n**Generation-first fixtures over a deterministic replay driver**; everything runs in plain\n`bun test` — no model, no substrate. Hand-written fixtures are seeds; the corpus is generated:\n\n- Properties come from the **harness contract** — the ten invariants above are literally\n  properties; generators come from the **plugin's declarations**, never its implementation\n  (`arbitraryFromSchema`: Valibot → fast-check arbitraries), plus negative-space properties for\n  plugin code (validators total — never throw, always typed issues; `project` never emits an\n  undeclared loss category).\n- Where dynamics are the subject: **model-based command-sequence testing** (`fc.commands`) over\n  the envelope-derived alphabet — utter · settle-range · sweep · correct · contradict ·\n  reply-with-absence · redirect.\n- Language realism: a **model as offline generator, never CI oracle** — a model plays respondent\n  against the plugin's own kernel cards, varied by persona/curveball, plus a mutation library\n  generalizing minimal pairs (epistemic-status flips, absence injections, supersession\n  injections). Outputs freeze as replayable fixtures; **regenerate when declarations change**.\n- Shrunk counterexamples are minimal pathological conversations: pinned as regressions and read\n  first as type-design feedback on envelope/payload types.\n\n### 14.5 Open verification items (named, with homes)\n\n- **Interpretation-render plugin-renderer seam** — exercised once real packs exist (milestone-one\n  build, both plugins).\n- **Restart durability of the full stack** — the capture store survives restart (proven, ticket\n  13); conversation-store durability with a real `db.ts` is untested (milestone-one dev app).\n- **Wake-wart residue** — §7.4's no-interpolation ruling removes the cause observed in ticket 10;\n  confirm no other instruction-state write path re-triggers advisory wakes (milestone-one binding).\n- **History-projection paging** (>1000 entries) and binding base-URL discovery — binding\n  implementation details flagged by ticket 13.\n- **Compaction vs. durable history** (§9.7) — verify that Pi/Flue compaction leaves the durable\n  entry projection unmodified (or scope what the binding must preserve itself); no prototype has\n  driven a session across a compaction boundary (milestone-one binding).\n\n---\n\n\n--- boundaries ---\n/**\n * The architectural boundaries, as tests rather than as documentation.\n *\n * Spec §4 and §12.2 state the dependency direction as invariants; an invariant\n * nobody can run is a wish. These are the mechanical checks — they read the\n * real tree, so a package added later is governed without opting in.\n *\n * Two of them are load-bearing beyond tidiness, because the Flue build is\n * silent about the failure: a `'use agent'` directive that is not the file's\n * first statement builds green and simply never registers the agent.\n */\n\nimport { describe, expect, test } from 'bun:test';\nimport { readFileSync } from 'node:fs';\nimport { join } from 'node:path';\nimport {\n  AGENT_DIRECTIVE_STATEMENT,\n  agentModules,\n  allDependencies,\n  filesIn,\n  importedPackages,\n  MODEL_KEY_NAME,\n  packageOf,\n  pinnedIdentities,\n  REPO_ROOT,\n  sourceFiles,\n  testFiles,\n  workspacePackages,\n  type WorkspacePackage,\n} from './workspace.ts';\n\nconst PACKAGES = workspacePackages();\n\nconst CORE = '@brunch/core';\n/** Any substrate package. The harness may never name one; a binding must. */\nconst SUBSTRATE_SCOPES = ['@flue/', '@earendil-works/'];\n\nconst isSubstrate = (name: string): boolean =>\n  SUBSTRATE_SCOPES.some((scope) => name.startsWith(scope));\nconst byRole = (role: string): WorkspacePackage[] =>\n  PACKAGES.filter((pkg) => pkg.dir.startsWith(`${role}-`));\n\ntest('every workspace package is one the spec topology names', () => {\n  // Derived from the spec's own §12.2 topology block instead of a second\n  // hand-written list here. The spec names *intended* structure — some\n  // entries are not scaffolded yet — so the direction checked is disk ⊆\n  // spec: a package the spec does not name is loud, while an\n  // intended-but-unbuilt one is not a failure. (The old hardcoded equality\n  // would have failed the next legitimate package instead of governing it.)\n  const spec = readFileSync(join(REPO_ROOT, 'docs/planning/elicitation-kernel/spec.md'), 'utf8');\n  const topology = /### 12\\.2[^\\n]*\\n[\\s\\S]*?```\\n([\\s\\S]*?)```/.exec(spec)?.[1];\n  expect(topology).toBeDefined();\n  const named = new Set(\n    [...topology!.matchAll(/^((?:packages|apps)\\/[\\w-]+)(?=\\s|$)/gm)].map((match) => match[1]!),\n  );\n  expect(named.size).toBeGreaterThan(0);\n  for (const pkg of PACKAGES) {\n    expect({ pkg: pkg.relPath, inSpec: named.has(pkg.relPath) }).toEqual({\n      pkg: pkg.relPath,\n      inSpec: true,\n    });\n  }\n});\n\ntest('every package is actually scanned', () => {\n  // Without this, a package the file walker misses passes every file-level\n  // invariant vacuously — the substrate-import ban, the plugin-resolves-core\n  // rule, and the schema-library ban would all iterate an empty list and go\n  // green. A silent exemption is worse than no check at all.\n  for (const pkg of PACKAGES) {\n    expect({ pkg: pkg.relPath, scanned: sourceFiles(pkg).length > 0 }).toEqual({\n      pkg: pkg.relPath,\n      scanned: true,\n    });\n  }\n});\n\ndescribe('role prefixes name what a package is architecturally (spec §12.2)', () => {\n  test('every package under packages/ is core or carries a role prefix', () => {\n    for (const pkg of PACKAGES.filter((p) => p.kind === 'package')) {\n      expect(pkg.dir).toMatch(/^(core|plugin-[a-z0-9-]+|binding-[a-z0-9-]+)$/);\n    }\n  });\n\n  test('no package uses an avoided role noun', () => {\n    // The glossary's own noun is `binding`; `adapter-*` and `wrapper-*` are\n    // avoided terms, and `elicit-*` names function rather than identity.\n    for (const pkg of PACKAGES) {\n      expect(pkg.dir).not.toMatch(/^(adapter|wrapper|elicit)-/);\n    }\n  });\n\n  test('the manifest name matches the role-prefixed directory', () => {\n    for (const pkg of PACKAGES) {\n      expect(pkg.name).toBe(`@brunch/${pkg.dir}`);\n    }\n  });\n});\n\ndescribe('dependency direction (spec §4, §12.2)', () => {\n  test('the harness imports no substrate', () => {\n    const core = PACKAGES.find((pkg) => pkg.name === CORE);\n    expect(core).toBeDefined();\n    expect(allDependencies(core!).filter(isSubstrate)).toEqual([]);\n    for (const file of sourceFiles(core!)) {\n      const substrateImports = importedPackages(file).filter((s) => isSubstrate(packageOf(s)));\n      expect({ file: file.relPath, substrateImports }).toEqual({\n        file: file.relPath,\n        substrateImports: [],\n      });\n    }\n  });\n\n  test('the harness depends on no binding and no plugin', () => {\n    const core = PACKAGES.find((pkg) => pkg.name === CORE)!;\n    for (const dependency of allDependencies(core)) {\n      expect(dependency).not.toMatch(/^@brunch\\/(binding|plugin)-/);\n    }\n  });\n\n  test('plugins resolve core only — never the binding, never Flue', () => {\n    const plugins = byRole('plugin');\n    expect(plugins.length).toBeGreaterThan(0);\n    for (const plugin of plugins) {\n      const workspaceDeps = allDependencies(plugin).filter((d) => d.startsWith('@brunch/'));\n      expect(workspaceDeps).toEqual([CORE]);\n      expect(allDependencies(plugin).filter(isSubstrate)).toEqual([]);\n\n      for (const file of sourceFiles(plugin)) {\n        for (const specifier of importedPackages(file)) {\n          const pkg = packageOf(specifier);\n          expect(isSubstrate(pkg)).toBe(false);\n          if (pkg.startsWith('@brunch/')) expect(pkg).toBe(CORE);\n        }\n      }\n    }\n  });\n\n  test('a binding imports both', () => {\n    const bindings = byRole('binding');\n    expect(bindings.length).toBeGreaterThan(0);\n    for (const binding of bindings) {\n      const deps = allDependencies(binding);\n      expect(deps).toContain(CORE);\n      expect(deps.some(isSubstrate)).toBe(true);\n    }\n  });\n\n  test('bindings depend on no plugin — the harness discovers plugins, not the substrate', () => {\n    for (const binding of byRole('binding')) {\n      for (const dependency of allDependencies(binding)) {\n        expect(dependency).not.toMatch(/^@brunch\\/plugin-/);\n      }\n    }\n  });\n});\n\ndescribe('the direction is physical, not merely declared', () => {\n  // Bun's isolated linker gives each package only what it declares, so a\n  // forbidden import cannot even resolve. This asserts that property holds\n  // rather than assuming it — a hoisted node_modules would quietly restore\n  // every forbidden path.\n  const resolvesFrom = (pkg: WorkspacePackage, specifier: string): boolean => {\n    try {\n      Bun.resolveSync(specifier, pkg.path);\n      return true;\n    } catch {\n      return false;\n    }\n  };\n\n  // Probed with the substrate packages the bindings actually declare, and\n  // with every binding by name — derived from the tree, so a new substrate\n  // dependency or a second binding is probed without opting in.\n  const substratePackages = [\n    ...new Set(byRole('binding').flatMap((b) => allDependencies(b).filter(isSubstrate))),\n  ];\n\n  test('a plugin cannot resolve the substrate or a binding', () => {\n    expect(substratePackages.length).toBeGreaterThan(0);\n    for (const plugin of byRole('plugin')) {\n      for (const specifier of substratePackages) {\n        expect({\n          plugin: plugin.dir,\n          specifier,\n          resolves: resolvesFrom(plugin, specifier),\n        }).toEqual({ plugin: plugin.dir, specifier, resolves: false });\n      }\n      for (const binding of byRole('binding')) {\n        expect(resolvesFrom(plugin, binding.name)).toBe(false);\n      }\n      expect(resolvesFrom(plugin, CORE)).toBe(true);\n    }\n  });\n\n  test('core cannot resolve the substrate', () => {\n    const core = PACKAGES.find((pkg) => pkg.name === CORE)!;\n    for (const specifier of substratePackages) {\n      expect({ specifier, resolves: resolvesFrom(core, specifier) }).toEqual({\n        specifier,\n        resolves: false,\n      });\n    }\n  });\n});\n\ndescribe('Valibot is the schema library at every boundary (spec §12.4)', () => {\n  // Flue locks Valibot at every boundary. A Standard-Schema waist would buy\n  // comfort at the cost of a conversion seam that can silently drop\n  // constraints — the silent-coercion smell.\n  const OTHER_SCHEMA_LIBRARIES = [\n    'zod',\n    'yup',\n    'joi',\n    'ajv',\n    'superstruct',\n    'arktype',\n    'io-ts',\n    'runtypes',\n    '@sinclair/typebox',\n",
+  "exitCode": 0
+}
+````
+
+**Tool Result:** `TU-0346wc1sSzlBgZObWLTQez`
+
+````
+# description: Configure where Flue durably stores agent conversations, from the in-memory default to SQLite, Postgres, and beyond.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg
+This guide covers what Flue stores, how the `db.ts` entry module works, the in-memory default and its limits, the built-in `sqlite()`
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg
+adapter, and the ecosystem of adapters for Postgres, libSQL, and other backends.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg
+One note up front: the database is a **Node.js** concern.
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The `db.ts` entry module
+To choose a database, create a `db.ts` file in your project’s [source directory](https://flueframework.com/docs/guide/project-layout/) and default-export a persistence adapter:
+```ts
+import { sqlite } from '@flue/runtime/node';
+
+export default sqlite('./data/flue.db');
+````
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The `db.ts` entry module
+Like `app.ts`, the `db.ts` entry is discovered by convention — `vite dev`, `vite build`, and `flue run` all resolve it from the source root (`.flue/`, `src/`, or the project root) and connect it at startup.
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The `db.ts` entry module
+Flue calls the adapter’s `migrate()` once at boot to create or verify its tables, then awaits `connect()` — so an unreachable or misconfigured database fails at startup, not in the middle of your first conversation.
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The in-memory default
+Without a `db.ts`, Flue runs on in-memory SQLite. Everything works — conversations, persisted state, recovery within the process lifetime — but **a restart loses everything**: every conversation, every accepted submission, every piece of state.
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The in-memory default
+| Command | Without db.ts |
+| vite dev | A cache file (node_modules/.cache/flue/dev.db) — history survives code reloads, resets when the dev server cold-starts. |
+| vite build | In-memory — the deployed server keeps state only for the process lifetime. |
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The in-memory default
+With a `db.ts`, all three use your adapter, so development runs against the same storage shape as production.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The built-in `sqlite()` adapter
+The `sqlite()` adapter ships with the runtime and needs no extra dependencies — it runs on Node’s built-in `node:sqlite` module. Point it at a file path for storage that survives restarts:
+
+```ts
+import { sqlite } from "@flue/runtime/node";
+
+export default sqlite("./data/flue.db");
+```
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The built-in `sqlite()` adapter
+The adapter creates the file (and any missing parent directories) on first boot and opens it in WAL mode. Calling `sqlite()` with no argument — or with `':memory:'` — gives you the same in-memory database as the default.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > The built-in `sqlite()` adapter
+A file-backed SQLite database covers a single-host deployment: it survives process restarts and redeploys on the same machine, but not the loss of the host itself. When state must survive host loss, or multiple replicas need to share it, use an external database.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+Flue publishes adapters for the major database ecosystems, each available as a [blueprint](https://flueframework.com/docs/cli/add/) — a Markdown implementation guide your coding agent applies, rather than a package installer. The blueprint name is the backend’s lowercase name:
+
+```sh
+flue add database postgres
+```
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+| Backend | Adapter package |
+| [Postgres](https://flueframework.com/docs/ecosystem/databases/postgres/) | @flue/postgres |
+| [Supabase](https://flueframework.com/docs/ecosystem/databases/supabase/) | @flue/postgres |
+| [Turso](https://flueframework.com/docs/ecosystem/databases/turso/) | @flue/libsql |title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+| Backend | Adapter package |
+| [Postgres](https://flueframework.com/docs/ecosystem/databases/postgres/) | @flue/postgres |
+| [Supabase](https://flueframework.com/docs/ecosystem/databases/supabase/) | @flue/postgres |
+| [MySQL](https://flueframework.com/docs/ecosystem/databases/mysql/) | @flue/mysql |title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+| Backend | Adapter package |
+| [Postgres](https://flueframework.com/docs/ecosystem/databases/postgres/) | @flue/postgres |
+| [Supabase](https://flueframework.com/docs/ecosystem/databases/supabase/) | @flue/postgres |
+| [MongoDB](https://flueframework.com/docs/ecosystem/databases/mongodb/) | @flue/mongodb |title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+| Backend | Adapter package |
+| [Postgres](https://flueframework.com/docs/ecosystem/databases/postgres/) | @flue/postgres |
+| [Supabase](https://flueframework.com/docs/ecosystem/databases/supabase/) | @flue/postgres |
+| [Redis](https://flueframework.com/docs/ecosystem/databases/redis/) | @flue/redis |
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+There are no migrations to run by hand with any adapter. `migrate()` provisions Flue’s tables idempotently on first boot, reuses them on restart, and stamps a format version — a database written by an incompatible Flue version refuses to start rather than corrupting state.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+A shared database does **not** enable active-active scaling. A durable external database lets a replacement process recover accepted work and lets replicas share conversation state, but each agent conversation still needs exactly one live Node owner at a time.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Ecosystem adapters
+See [Durability](https://flueframework.com/docs/guide/durability/) for the ownership rules and what recovery actually replays.
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Writing a custom adapter
+If your backend isn’t in the catalog, you can implement the storage contract yourself. An adapter is an object with `connect()` (returning the three stores — submissions, conversation streams, and attachments), plus optional `migrate()` and `close()`; the types live in `@flue/runtime/adapter`:
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Writing a custom adapter
+
+```ts
+import type { PersistenceAdapter } from '@flue/runtime/adapter';
+
+export default {
+  migrate() {
+    /* create or verify backing storage */
+  },
+  connect() {
+    return { submissionStore, conversationStreamStore, attachmentStore };
+  },
+  close() {
+    /* release connections */
+  },
+```
+
+...
+
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Choosing a database
+| Situation | Choice |
+| Local development | The defaults — add db.ts only to develop against production storage |
+| Single-host Node deployment | File-backed sqlite() |
+| Cloudflare deployment | Nothing to configure — Durable Object SQLite is automatic |
+| A backend not in the catalog | A custom PersistenceAdapter |
+title: Database | Flue
+image: https://flueframework.com/docs/og4.jpg > Next steps
+
+- [Durability](https://flueframework.com/docs/guide/durability/) — what recovery replays after an interruption, and the one-live-owner rule.
+- [Data Persistence API](https://flueframework.com/docs/reference/data-persistence-api/) — the full adapter and store contracts.
+  title: Database | Flue
+  image: https://flueframework.com/docs/og4.jpg > Next steps
+- [Postgres](https://flueframework.com/docs/ecosystem/databases/postgres/) and the other ecosystem database pages — per-backend setup, configuration, and caveats.
+- [Deploy Agents on Node.js](https://flueframework.com/docs/ecosystem/deploy/node/) — provisioning a database alongside your server.
+
+```
+
+**Tool Result:** `TU-0346wc1u7jQutZpaOA2e1X`
+
+```
+
+# description: Build your Flue application into a deployable artifact and ship it to the Node.js or Cloudflare target.
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Build with Vite
+
+1. **Resolves the project.** It discovers [flue.config.ts](https://flueframework.com/docs/reference/configuration/) and locates your entry modules (`app.ts` required; `db.ts` and `cloudflare.ts` optional).
+2.
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Choose a target
+Flue builds for two targets:
+
+- **Node.js** produces a self-starting server you can run anywhere Node runs: a VM, a container, or a managed host.
+- **Cloudflare** produces a Worker where each agent runs inside its own Durable Object, with durable state and global addressability out of the box.
+  title: Deploy | Flue
+  image: https://flueframework.com/docs/og4.jpg > Choose a target
+  When `target` is unset, `flue()` auto-detects it from the Vite plugin array: with `@cloudflare/vite-plugin` present the target is `'cloudflare'`, otherwise `'node'`. An explicit [target](https://flueframework.com/docs/reference/configuration/) overrides detection.
+  title: Deploy | Flue
+  image: https://flueframework.com/docs/og4.jpg > Deploy on Node.js
+  `vite build` bundles the application into two Node entries: the self-starting `dist/server.mjs`, and the non-listening `dist/app.mjs` chunk it imports:
+
+```bash
+vite build
+node dist/server.mjs
+```
+
+Three things to know before shipping the artifact:
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Node.js
+
+- **Environment:** the built server does not load `.env` — supply provider keys and other configuration when you start it. It listens on port `3000` by default; set `PORT` to change it.
+- **Dependencies:** application dependencies are externalized, not bundled.
+  title: Deploy | Flue
+  image: https://flueframework.com/docs/og4.jpg > Deploy on Node.js
+  Deploy the artifact alongside its `node_modules`, or in a container that installs them.
+- **State:** without a [db.ts](https://flueframework.com/docs/guide/database/) adapter, conversations live in process-local memory and a restart loses them. Configure a durable adapter before deploying anything you care about.
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Node.js
+For runtime details — state and durability, process ownership, multi-replica rules, environment and secrets — see the [Node.js target guide](https://flueframework.com/docs/guide/node-target/).
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+On Cloudflare, `flue()` cooperates with the official `@cloudflare/vite-plugin`, which owns workerd dev, build output, preview, and deploy. `flue()` must come **before** `cloudflare()` in the plugins array; the wrong order is diagnosed with an error.
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+Flue’s job is generating the Worker inputs the Cloudflare plugin consumes: a Worker entry that registers your scanned agents and exports one Durable Object class per agent, plus your authored `wrangler.jsonc` merged with the generated bindings. Add both generated paths to `.gitignore`:
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+Two things stay yours to author in `wrangler.jsonc`: the `nodejs_compat` compatibility flag, and the **Durable Object migrations** — an append-only record of your deployments that Flue never writes.
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+Every deployed agent needs a migration entry for its generated class, so adding an agent is always a triple: the agent, its mount in `app.ts` (skip for dispatch-only agents), and a new migration tag:
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+
+```jsonc
+{
+  "name": "my-flue-worker",
+  "compatibility_date": "2026-06-01",
+  "compatibility_flags": ["nodejs_compat"],
+  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["FlueTriageAgent"] }],
+}
+```
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+Build and deploy through the Cloudflare plugin: `vite build`, then deploy against the config it emits into `dist/`.
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Deploy on Cloudflare
+For the full walkthrough, see [Deploy Agents on Cloudflare](https://flueframework.com/docs/ecosystem/deploy/cloudflare/); for runtime behavior — generated classes and bindings, durable execution, service bindings — see the [Cloudflare target guide](https://flueframework.com/docs/guide/cloudflare-target/).
+
+...
+
+title: Deploy | Flue
+image: https://flueframework.com/docs/og4.jpg > Docs Navigation > Sections
+
+- [Guide](https://flueframework.com/docs/guide/getting-started/)
+- [Reference](https://flueframework.com/docs/reference/agent-api/)
+- [CLI](https://flueframework.com/docs/cli/overview/)
+- [Agent SDK](https://flueframework.com/docs/sdk/overview/)
+- [Ecosystem](https://flueframework.com/docs/ecosystem/)
+
+````
+
+## Assistant
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "nl -ba apps/dev/src/db.ts && printf '\\n--- db path ---\\n' && nl -ba apps/dev/src/db-path.ts && printf '\\n--- project config versions ---\\n' && rg -n '\"(@flue/|ai\"|@trytilde|next|vercel|cloudflare)' package.json apps packages bun.lock | sed -n '1,160p'",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+````
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "nl -ba CONTEXT.md | sed -n '1,130p' && printf '\\n--- package/app selected ---\\n' && nl -ba apps/dev/package.json | sed -n '1,100p' && nl -ba apps/dev/src/app.ts | sed -n '1,100p' && nl -ba apps/dev/src/agents/gherkin-elicitor.ts | sed -n '20,110p'",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "nl -ba packages/binding-flue/src/capabilities.ts | sed -n '1,150p' && printf '\\n--- binding ask ---\\n' && nl -ba packages/binding-flue/src/index.ts | sed -n '25,120p' && printf '\\n--- local store selected ---\\n' && nl -ba packages/binding-flue/src/local-capture-store.ts | sed -n '1,120p'",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+**Tool Use:** `shell_command`
+
+```json
+{
+  "command": "nl -ba docs/planning/elicitation-kernel/spec.md | sed -n '642,661p' && nl -ba test/known-gaps.ts | sed -n '60,118p' && nl -ba .github/workflows/ci.yml | sed -n '1,100p'",
+  "workdir": "/Users/lunelson/Code/hashintel/brunch-lite"
+}
+```
+
+## User
+
+**Tool Result:** `TU-0346wcH56DvMLrbCjD29Xd`
+
+```
+{
+  "output": "     1\t/**\n     2\t * The substrate's conversation storage — host-authored because Flue requires\n     3\t * it of the consuming app (spec §9.6, adjudication C1).\n     4\t *\n     5\t * Not to be confused with the capture store: that is the harness's storage\n     6\t * port, harness-defined and implemented in `@brunch/binding-flue`, and plugins are\n     7\t * blind to both. This file holds only the live transport copy of conversations.\n     8\t * The provenance record is the target-document's own session-log archive.\n     9\t *\n    10\t * Without this file conversations are process-memory and a restart loses them\n    11\t * (recorded Flue fact, spec §10). Restart durability of the full stack is an\n    12\t * open verification item (spec §14.5) that this file exists to make testable.\n    13\t */\n    14\t\n    15\timport { sqlite } from '@flue/runtime/node';\n    16\timport { conversationDbPath } from './db-path.ts';\n    17\t\n    18\texport default sqlite(conversationDbPath());\n\n--- db path ---\n     1\t/**\n     2\t * Where the conversation store lives, resolved before the adapter opens it.\n     3\t *\n     4\t * Anchored to this module's location — the way `app.ts` anchors `uiRoot` —\n     5\t * never to the launch directory: a cwd-relative default silently creates a\n     6\t * fresh empty database when the app is launched from anywhere else, which is\n     7\t * the exact restart-durability failure `db.ts` exists to prevent. From `src/`\n     8\t * and from the emitted `dist/` bundle alike, `../.data-wipe-me/` resolves to\n     9\t * the package directory.\n    10\t *\n    11\t * Kept apart from `db.ts` so it stays importable under `bun test`: the\n    12\t * adapter module pulls in `@flue/runtime/node`, which cannot be driven there.\n    13\t */\n    14\t\n    15\timport { fileURLToPath } from 'node:url';\n    16\t\n    17\texport function conversationDbPath(): string {\n    18\t  // Truthiness, not nullish, on purpose: a set-but-empty override would pass\n    19\t  // '' through to sqlite(), which opens an anonymous temporary database\n    20\t  // deleted on close — silently non-durable again.\n    21\t  const override = process.env.BRUNCH_DEV_DB_PATH;\n    22\t  return override\n    23\t    ? override\n    24\t    : fileURLToPath(new URL('../.data-wipe-me/conversations.db', import.meta.url));\n    25\t}\n\n--- project config versions ---\nbun.lock:23:        \"@flue/react\": \"^2.0.3\",\nbun.lock:24:        \"@flue/runtime\": \"^2.0.3\",\nbun.lock:25:        \"@flue/sdk\": \"^2.0.3\",\nbun.lock:33:        \"@flue/vite\": \"^2.0.3\",\nbun.lock:44:        \"@flue/runtime\": \"^2.0.3\",\nbun.lock:238:    \"@flue/react\": [\"@flue/react@2.0.3\", \"\", { \"peerDependencies\": { \"@flue/sdk\": \"2.0.3\", \"react\": \">=18\" } }, \"sha512-6Yd5EVUhCFyypFUyZ1RjPhre/NG06nUHPru7wITQnCjzi2syF1U2bP3sl9jJj0cqznHhsXl3fPXU8sPRo/3+DQ==\"],\nbun.lock:240:    \"@flue/runtime\": [\"@flue/runtime@2.0.3\", \"\", { \"dependencies\": { \"@earendil-works/pi-agent-core\": \"^0.83.0\", \"@earendil-works/pi-ai\": \"^0.83.0\", \"@hono/node-server\": \"^2.0.3\", \"@modelcontextprotocol/client\": \"2.0.0\", \"@valibot/to-json-schema\": \"^1.3.0\", \"hono\": \"^4.8.3\", \"js-yaml\": \"^5.2.1\", \"ulidx\": \"^2.4.1\", \"valibot\": \"^1.1.0\" } }, \"sha512-RfWyZG9x2hlDb1264XTESX42tzzG3AA8er3XjaTIxIMh28pTD91zKd9Jh6PFXKeTkZegLsGiJKDxmiCddlyeug==\"],\nbun.lock:242:    \"@flue/sdk\": [\"@flue/sdk@2.0.3\", \"\", { \"dependencies\": { \"@durable-streams/client\": \"^0.2.6\" } }, \"sha512-ZD5HZGeVxWu0/G6KYrpOh1RGGBpvk/i9QojWMykNzVrH0w4g3nTPdZN9kY4JvYh/+aRtqTrwb3c1Tb3hUm8BIg==\"],\nbun.lock:244:    \"@flue/vite\": [\"@flue/vite@2.0.3\", \"\", { \"dependencies\": { \"@flue/runtime\": \"2.0.3\", \"@hono/node-server\": \"^2.0.3\", \"agents\": \"^0.20.1\", \"magic-string\": \"^1.0.0\", \"tinyglobby\": \"^0.2.15\", \"ulidx\": \"^2.4.1\" }, \"peerDependencies\": { \"vite\": \"^8.0.0\" } }, \"sha512-Klrl+vFzp+z9sYQ+yc7k/yxGrjWMvjoeKtzEZ+wgYwzLfai1sR9iYlMrpLg2ORTH8KqZ+kHvKR0Y2l8wHIvSIA==\"],\nbun.lock:420:    \"agents\": [\"agents@0.20.1\", \"\", { \"dependencies\": { \"@babel/plugin-proposal-decorators\": \"^8.0.2\", \"@cfworker/json-schema\": \"^4.1.1\", \"@rolldown/plugin-babel\": \"^0.2.3\", \"cron-schedule\": \"^6.0.0\", \"esbuild\": \"^0.28.1\", \"mimetext\": \"^3.0.28\", \"nanoid\": \"^5.1.16\", \"partyserver\": \"^0.5.8\", \"partysocket\": \"1.3.0\", \"yaml\": \"^2.9.0\", \"yargs\": \"^18.0.0\" }, \"peerDependencies\": { \"@ai-sdk/react\": \"^3.0.0 || ^4.0.0\", \"@cloudflare/codemode\": \">=0.5.0\", \"@modelcontextprotocol/client\": \"2.0.0\", \"@modelcontextprotocol/sdk\": \"1.30.0\", \"@modelcontextprotocol/server\": \"2.0.0\", \"@tanstack/ai\": \">=0.10.2 <1.0.0\", \"@x402/core\": \"^2.0.0\", \"@x402/evm\": \"^2.0.0\", \"ai\": \"^6.0.0 || ^7.0.0\", \"chat\": \"^4.29.0\", \"just-bash\": \"^3.0.0\", \"react\": \"^19.0.0\", \"vite\": \">=6.0.0 <9.0.0\", \"zod\": \"^4.0.0\" }, \"optionalPeers\": [\"@ai-sdk/react\", \"@cloudflare/codemode\", \"@tanstack/ai\", \"@x402/core\", \"@x402/evm\", \"ai\", \"chat\", \"just-bash\", \"vite\"], \"bin\": { \"agents\": \"dist/cli/index.js\" } }, \"sha512-HQRYMeZpD3k8djYBH7atRPojZMee3NvmXkzsmMWXfdHZ94vMljmWqSsD1XZd70LovHyQrw6/R81AZZIsRiFM6Q==\"],\napps/dev/package.json:15:    \"@flue/react\": \"^2.0.3\",\napps/dev/package.json:16:    \"@flue/runtime\": \"^2.0.3\",\napps/dev/package.json:17:    \"@flue/sdk\": \"^2.0.3\",\napps/dev/package.json:25:    \"@flue/vite\": \"^2.0.3\",\npackages/binding-flue/package.json:12:    \"@flue/runtime\": \"^2.0.3\",\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wcH5aLjZifjeDM0vJM`
+
+```
+{
+  "output": "     1\t# Elicitation Kernel\n     2\t\n     3\tVocabulary for the elicitation-kernel effort: a standalone architecture generalizing brunch's elicitor into agentic interviewing against pluggable elicitation targets.\n     4\t\n     5\t## Language\n     6\t\n     7\t### Shells\n     8\t\n     9\t**Substrate**:\n    10\tThe agent framework the system is built on — the Pi family, Flue — including the embedding environment's concerns: deploy target, storage-port implementation, artifact delivery, model/provider. (The retired term \"host\" silently bundled these with interface concerns; they split into substrate and UI. The charter non-goal \"harness-agnostic core\" predates this glossary and reads \"substrate-agnostic\".)\n    11\t_Avoid_: harness (for Pi/Flue), platform, host (for the embedding environment)\n    12\t\n    13\t**UI**:\n    14\tThe interface shell: whatever affords user interaction — rendering, input, reply transport. Not bound to GUI or TUI; a chat channel qualifies.\n    15\t_Avoid_: host, host-interface, frontend, client\n    16\t\n    17\t**Harness**:\n    18\tThe middle shell and the essence of the effort: the generic capability layer of the elicitation system — mechanism and orchestration (the conversation loop, the `ask` API, capture envelope, issue queue, sweep bookkeeping). Injected into plugins as a narrow context; never owned by them.\n    19\t_Avoid_: kernel, core, elicitor (as a shell name — \"elicitor\" may name the whole system). Exempt compound: **kernel card** (below). \"Kernel invariants\" renamed **harness invariants** (spec §14.1).\n    20\t\n    21\t**Plugin**:\n    22\tThe innermost shell: target-defining policy. Declares packs, forms, and validators; composes at authoring time; receives harness capabilities by injection. Mostly policy — mechanism stays in the harness.\n    23\t_Avoid_: extension, pack (a pack is a unit *within* a plugin)\n    24\t\n    25\t**Binding**:\n    26\tThe substrate-facing adapter between harness and substrate: implements the harness's named substrate-capability list (tool registration, instruction assembly, persistent state, affordance emission, suspend-for-reply, private model call) in one substrate's dialect. One per substrate; the harness imports no substrate, a binding imports both. Bindings vary in size — each absorbs what its substrate lacks or forbids.\n    27\t_Avoid_: adapter (generic), integration, wrapper\n    28\t\n    29\t### Sessions & durability\n    30\t\n    31\t**Target-domain**:\n    32\tThe artifact family being elicited — what a plugin defines (gherkin scenarios, assurance arguments, BPMN). The family half of the former bare \"target\".\n    33\t_Avoid_: target-paradigm; bare \"target\" where family/instance is ambiguous\n    34\t\n    35\t**Target-document**:\n    36\tThe durable unit sessions attach to: one target-domain, its capture store, and its session history. Named by its purpose — its authoritative state is the capture store plus session logs, never the rendered artifact (renders are derived, cacheable, disposable). Endures independently of any session; never locks — completion is a derived status, not a write gate.\n    37\t_Avoid_: spec (as the unit name), workpiece, case, target-output\n    38\t\n    39\t**Session**:\n    40\tOne substrate conversation — the full log of entries (user, agent, tool calls, injected state messages), matching Pi's session model. Per-session state is exactly: the evidence log, the swept high-water mark, the pending-affordance slot. Sessions go quiet rather than close; any session is resumable against the current state of its target-document.\n    41\t_Avoid_: sitting, conversation (as a distinct concept)\n    42\t\n    43\t**Capture store**:\n    44\tThe durable, session-independent truth of a target-document: captures, issues, events. Written only by atomic sweep application (serialized); statuses and projections derive from it at read time.\n    45\t\n    46\t**Re-entry briefing**:\n    47\tThe state message the harness injects when a session resumes after the world moved: computed facts only — unswept tail, world-moved delta, open issues, pending affordance. Authored on behalf of the user in the transcript (Pi's custom-entry convention) but distinguished from true user entries in the data model, and never citable as capture evidence.\n    48\t_Avoid_: sync message, forced re-sweep\n    49\t\n    50\t### Interaction\n    51\t\n    52\t**Affordance**:\n    53\tA structured interactive element (question form, choice strip, questionnaire) emitted into the conversation stream as a rendered enhancement. Not a state machine — the conversation stays primary, and an affordance's payload is evidence in the session like any other entry.\n    54\t_Avoid_: exchange, exchange pair, terminal (brunch's retired turn-by-turn ontology)\n    55\t\n    56\t**Capture**:\n    57\tExtraction of structured evidence — envelope plus plugin-typed payload — from session entries. Produced by sweeps, never written directly during conversation.\n    58\t_Avoid_: extraction, harvest\n    59\t\n    60\t**Sweep**:\n    61\tAn idempotent pass over a settled range of session entries that produces captures. Re-sweeping a range never double-captures.\n    62\t\n    63\t**Settlement**:\n    64\tThe agent-judged event marking a range of conversation (a vein closing) ready to sweep. Always range-level, never per-question.\n    65\t_Avoid_: exchange completion\n    66\t\n    67\t**Interpretation render**:\n    68\tThe harness-owned affordance form showing current captured state — the harness frames envelope semantics; the plugin's renderer definition (typed against its own payload shapes) supplies the content view when provided, with a harness default (plain JSON view) otherwise.\n    69\t_Avoid_: digest (brunch's form)\n    70\t\n    71\t### Envelope & packs\n    72\t\n    73\t**Intermediate representation (IR)**:\n    74\tThe elicited description a target-document accumulates: the set of active captures, read through the plugin's declared payload type system. Not a second store — every consolidated view (entity graph, net, completion table) is a read-time projection over active captures, and the rendered artifact is one projection of the IR, never the IR itself. Defining a plugin's IR means defining its payload type system.\n    75\t_Avoid_: knowledge store, domain model (as a stored unit), staging area\n    76\t\n    77\t**Capture envelope**:\n    78\tThe harness-defined, domain-free wrapper around an opaque plugin payload: harness-minted id, evidence spans, epistemic status, confidence, value-xor-absence, alternatives grouping, one `supersedes` link. The hourglass waist. No stored status — envelope status (`active | superseded | retracted`) derives at read time from links and events.\n    79\t\n    80\t**Evidence span**:\n    81\tA capture's provenance link: a **quoted excerpt** (primary, the model-facing citation currency) plus a **pointer** (session id + entry range, harness-derived — entry identity is harness-side vocabulary only). Anchors only on true user and user-affordance-payload entries.\n    82\t\n    83\t**Epistemic status**:\n    84\t`explicit | inferred | tentative | defaulted | external-lookup` — how a capture's content relates to what the user actually said. Distinct from confidence; excluded from capture identity.\n    85\t\n    86\t**Absence state**:\n    87\tA first-class capture value where an answer would be: `unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred` (`not-mentioned` is a computed fact, not a sweepable capture). Never collapses to null.\n    88\t_Avoid_: null, missing (as the stored representation)\n    89\t\n    90\t**Supersession**:\n    91\tThe explicit correction mechanism, single-hop over active heads only. Two channels: the creation-time `supersedes` link (sweep-time correction) and the resolution record (issue-time adjudication). Superseded captures stay visible — corrections don't erase history.\n    92\t\n    93\t**Resolution record**:\n    94\tThe explicit capture-store event that alone closes a `conflicting` issue (and, with no successor capture, expresses retraction). Must cite the true user's utterance as evidence.\n    95\t\n    96\t**Issue**:\n    97\tTyped, stored backpressure to the elicitation controller: `missing / ambiguous / conflicting / invalid / unsupported / unmapped / low-confidence`, with factual attributes. Two producers, namespaced: plugin ops (payload level) and the harness itself (envelope level). Closes only explicitly.\n    98\t_Avoid_: advisory (a different thing, below)\n    99\t\n   100\t**Advisory**:\n   101\tA computed, ephemeral, non-blocking fact the harness surfaces to the agent (unaccounted ask, unswept tail, world-moved delta). Never stored in the capture store; never gates anything.\n   102\t\n   103\t**Pack**:\n   104\tA unit within a plugin: **ElicitationPack** (kernel cards, completion contract, clarification hints) or **ProjectionPack** (`project` + `validate`, optional `reconcile`, annotated shapes, typed loss reports). Packs are shapes-to-fill plus behavioral guidance, per Principle v2.\n   105\t\n   106\t**Kernel card**:\n   107\tThe pack-content unit of elicitation guidance: Detects / Goal / contrastive Questions / Artifacts (brunch `BEHAVIORAL_KERNELS.md` lineage — \"kernel\" here names a small unit of behavioral guidance, not a shell; the compound is the glossary's one sanctioned \"kernel\" use). Splits by ownership: domain cards are plugin pack content; a harness-shipped **generic strategy quiver** (cards over envelope vocabulary — conflict, ambiguity, weak evidence) is named in spec §11.5, not designed.\n   108\t\n   109\t**PluginContext**:\n   110\tThe narrow injected context through which a plugin receives harness capabilities (the ask API, envelope, issue queue, sweep bookkeeping). The plugin's entire world at runtime; the four operations remain pure (snapshot-in/deltas-out) regardless.\n   111\t\n   112\t**Storage port**:\n   113\tThe harness-defined contract for the capture store (atomic sweep application, envelope invariants as store-level refusals), implemented by the binding for its deploy target. Plugins are storage-blind. Scope includes the **session-log archive** (archive-on-read; spec §9.6): session logs live with the target-document, retained indefinitely — the substrate's conversation store is the live transport copy, never the provenance record.\n   114\t\n   115\t### September demo\n   116\t\n   117\t**Demo shell**:\n   118\tThe one-off application built for the 17–18 September demo: consumes the elicitation library (harness + plugin + binding) and the Petrinaut libraries, owns the UI, session persistence, and elicitor runtime. Explicitly disposable — not a product commitment; neither library consumes the other.\n   119\t_Avoid_: \"the app\", standalone brunch, demo app (unqualified)\n   120\t\n   121\t**Artifact boundary**:\n   122\tThe decided integration posture between elicitor and Petrinaut (FE-1362): the elicitor emits a versioned net file plus scenario; Petrinaut consumes it through its published parser and import-with-autolayout path. The rejected alternative was library coupling (one library consuming the other).\n   123\t_Avoid_: file handoff (undersells it), integration (generic)\n   124\t\n   125\t**Revision story**:\n   126\tThe working-hypothesis demo spine (FE-1363; recommended to PM, not ratified): a sped-up recorded elicitation (conversation, interpretation surface, and growing net visible together) plus a bounded live segment in which a few turns elicit a fact forcing a structural revision of the net, run before/after in Petrinaut.\n   127\t_Avoid_: live demo (unqualified — the live part is one bounded segment, not the format)\n   128\t\n   129\t### Simulation & evaluation\n   130\t\n\n--- package/app selected ---\n     1\t{\n     2\t  \"name\": \"@brunch/dev\",\n     3\t  \"version\": \"0.0.0\",\n     4\t  \"private\": true,\n     5\t  \"type\": \"module\",\n     6\t  \"description\": \"The dev/demo vehicle: local dev loop, target gallery, diagnostic probe surface. Not the product.\",\n     7\t  \"scripts\": {\n     8\t    \"dev\": \"vite dev\",\n     9\t    \"build\": \"vite build && vite build --config vite.client.config.ts\"\n    10\t  },\n    11\t  \"dependencies\": {\n    12\t    \"@brunch/binding-flue\": \"workspace:*\",\n    13\t    \"@brunch/core\": \"workspace:*\",\n    14\t    \"@brunch/plugin-gherkin\": \"workspace:*\",\n    15\t    \"@flue/react\": \"^2.0.3\",\n    16\t    \"@flue/runtime\": \"^2.0.3\",\n    17\t    \"@flue/sdk\": \"^2.0.3\",\n    18\t    \"hono\": \"^4.6.0\",\n    19\t    \"react\": \"^19.0.0\",\n    20\t    \"react-dom\": \"^19.0.0\",\n    21\t    \"valibot\": \"^1.4.2\"\n    22\t  },\n    23\t  \"devDependencies\": {\n    24\t    \"@earendil-works/pi-ai\": \"^0.83.0\",\n    25\t    \"@flue/vite\": \"^2.0.3\",\n    26\t    \"@types/react\": \"^19.0.0\",\n    27\t    \"@types/react-dom\": \"^19.0.0\",\n    28\t    \"vite\": \"^8\"\n    29\t  }\n    30\t}\n     1\t/**\n     2\t * The dev app's route map — the \"mount\" half of the thin host (spec §12.1).\n     3\t *\n     4\t * The dev app is chartered with three roles, none of them \"the product\"\n     5\t * (spec §12.5): the local dev loop against every plugin, the colleague-facing\n     6\t * target-gallery demo, and the diagnostic probe surface. Milestone one keeps\n     7\t * affordance renderers here rather than in a ui package.\n     8\t */\n     9\t\n    10\timport { readFile } from 'node:fs/promises';\n    11\timport { createAgentRouter } from '@flue/runtime/routing';\n    12\timport { Hono } from 'hono';\n    13\timport { GherkinElicitor } from './agents/gherkin-elicitor.ts';\n    14\timport { assetHandler } from './assets.ts';\n    15\timport { GHERKIN_AGENT_ROUTE } from './routes.ts';\n    16\t\n    17\tconst app = new Hono();\n    18\t\n    19\t// One route per target agent. The gallery grows an entry per plugin; gherkin\n    20\t// is the tracer that wires end-to-end first (spec §13). The browser and mount\n    21\t// share the route constant; Flue still keys storage on the agent's independent,\n    22\t// pinned identity.\n    23\tapp.route(`/agents/${GHERKIN_AGENT_ROUTE}`, createAgentRouter(GherkinElicitor));\n    24\t\n    25\t// The flue dev controller owns the whole request space — no fall-through to\n    26\t// vite's html serving — so the ui is app-served, in dev and in production\n    27\t// alike (spec §10, recorded facts).\n    28\t//\n    29\t// Two different files, because two different builds produce them: in dev, the\n    30\t// source `index.html` whose script tag vite resolves live; in production, the\n    31\t// client build's emitted `index.html`, whose script tag points at a real\n    32\t// bundled asset. `@flue/vite` emits the server environment only, so that\n    33\t// client build is a second, plain vite build — without it the ui tree would\n    34\t// have no build coverage at all.\n    35\tconst uiRoot = new URL(import.meta.env?.DEV === false ? './client/' : '../', import.meta.url);\n    36\t\n    37\tapp.get('/', async (c) => c.html(await readFile(new URL('index.html', uiRoot), 'utf8')));\n    38\t\n    39\t// Production only: in dev, vite serves the module graph under /src. A\n    40\t// wildcard, not `:file` — bundlers may emit nested asset paths.\n    41\tapp.get('/assets/*', assetHandler(uiRoot));\n    42\t\n    43\texport default app;\n    20\t */\n    21\t\n    22\timport { useElicitation } from '@brunch/binding-flue';\n    23\timport { gherkin } from '@brunch/plugin-gherkin';\n    24\timport { useModel, type AgentProps } from '@flue/runtime';\n    25\timport * as v from 'valibot';\n    26\t\n    27\texport function GherkinElicitor(_props: AgentProps) {\n    28\t  useModel('anthropic/claude-haiku-4-5');\n    29\t  return useElicitation(gherkin);\n    30\t}\n    31\t\n    32\t/**\n    33\t * Pinned, and never to be edited: conversation storage keys on this literal,\n    34\t * so changing it orphans every existing conversation. Flue requires a string\n    35\t * literal here because build targets derive durable identifiers from it before\n    36\t * any user code runs.\n    37\t *\n    38\t * Product-prefixed on purpose, and this is the one place the prefix is not\n    39\t * cosmetic. Agent identities are global per application, and the September\n    40\t * demo shell is chartered to mount this library alongside the Petrinaut\n    41\t * libraries — a bare `gherkin-elicitor` could collide with another library's\n    42\t * agent, and the collision would land on durable conversation storage.\n    43\t *\n    44\t * The exported symbol stays the shorter `GherkinElicitor` because it reads\n    45\t * better at the mount site; `agentName` exists precisely to let durable\n    46\t * identity and source-level name differ.\n    47\t */\n    48\tGherkinElicitor.agentName = 'brunch-gherkin-elicitor';\n    49\t\n    50\t/**\n    51\t * Session→document binding (spec §9.1, adjudication L4): a new session's\n    52\t * `initialData` carries the target-document id, validated once at creation and\n    53\t * immutable thereafter — Flue's own lane for a target descriptor. Dispatching\n    54\t * to an existing conversation id resumes that session against the current state\n    55\t * of its target-document.\n    56\t */\n    57\tGherkinElicitor.initialData = v.object({\n    58\t  targetDocumentId: v.pipe(v.string(), v.nonEmpty()),\n    59\t});\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wcH6r2hqVDTUuS3lYy`
+
+```
+{
+  "output": "     1\t/**\n     2\t * The substrate-capability list (spec §10), recorded as data.\n     3\t *\n     4\t * This is the core/binding seam, the portability pressure test, and the early\n     5\t * smell detector all at once: porting means reimplementing this list, and\n     6\t * exotic Flue-shaped entries appearing in it is the smell. Keeping it as a\n     7\t * checkable record rather than prose is what lets the second-binding test\n     8\t * (spec §14.2) be asked of every future addition — \"genuinely\n     9\t * substrate-specific, or mechanism leaking into Flue's dialect?\"\n    10\t *\n    11\t * Binding-size asymmetry is expected, not failure: each binding absorbs what\n    12\t * its substrate lacks or forbids.\n    13\t */\n    14\t\n    15\t/** How a binding satisfies one capability. */\n    16\texport type Provision =\n    17\t  /** The substrate offers it directly. */\n    18\t  | 'native'\n    19\t  /** The substrate lacks or forbids it; the binding supplies it itself. */\n    20\t  | 'absorbed';\n    21\t\n    22\texport interface Capability {\n    23\t  readonly id: number;\n    24\t  readonly name: string;\n    25\t  readonly provision: Provision;\n    26\t  /** How this binding satisfies it, in Flue's dialect. */\n    27\t  readonly mechanism: string;\n    28\t}\n    29\t\n    30\texport const CAPABILITIES: readonly Capability[] = [\n    31\t  {\n    32\t    id: 1,\n    33\t    name: 'Register a tool',\n    34\t    provision: 'native',\n    35\t    mechanism: 'defineTool / useTool',\n    36\t  },\n    37\t  {\n    38\t    id: 2,\n    39\t    name: 'Contribute instructions',\n    40\t    provision: 'native',\n    41\t    mechanism: 'render return',\n    42\t  },\n    43\t  {\n    44\t    id: 3,\n    45\t    name: 'Persist per-conversation state',\n    46\t    provision: 'native',\n    47\t    mechanism: 'usePersistentState, atomic with its unit of work',\n    48\t  },\n    49\t  {\n    50\t    id: 4,\n    51\t    name: 'Emit an affordance payload',\n    52\t    provision: 'native',\n    53\t    mechanism: 'data channel + tool output parts',\n    54\t  },\n    55\t  {\n    56\t    id: 5,\n    57\t    name: 'Suspend for reply',\n    58\t    provision: 'absorbed',\n    59\t    mechanism: 'no ask primitive: terminate:true + pending-affordance slot + fresh dispatch',\n    60\t  },\n    61\t  {\n    62\t    id: 6,\n    63\t    name: 'Private model call',\n    64\t    provision: 'native',\n    65\t    mechanism: 'harness.prompt scratch conversation',\n    66\t  },\n    67\t  {\n    68\t    id: 7,\n    69\t    name: 'Subscribe to the would-stop lifecycle seam',\n    70\t    provision: 'native',\n    71\t    mechanism:\n    72\t      'useAgentFinish + ctx.append; fires on suspensions, so the pending guard is load-bearing; loop-guarded',\n    73\t  },\n    74\t  {\n    75\t    id: 8,\n    76\t    name: 'Read the durable entry projection with provenance-discriminating entry kinds',\n    77\t    provision: 'absorbed',\n    78\t    mechanism:\n    79\t      'no in-process API: public history projection over self-HTTP; `purpose` discriminates provenance',\n    80\t  },\n    81\t  {\n    82\t    id: 9,\n    83\t    name: 'Inject typed non-user signal entries',\n    84\t    provision: 'native',\n    85\t    mechanism: \"ctx.append / dispatch({kind:'signal'}); projects structurally non-user\",\n    86\t  },\n    87\t  {\n    88\t    id: 10,\n    89\t    name: 'Provide a transactional durable store outside conversation state',\n    90\t    provision: 'absorbed',\n    91\t    mechanism:\n    92\t      'Flue neither provides nor forbids; the binding owns the storage-port implementation',\n    93\t  },\n    94\t];\n\n--- binding ask ---\n    25\t  usePersistentState,\n    26\t  useTool,\n    27\t} from '@flue/runtime';\n    28\t\n    29\texport { CAPABILITIES, type Capability, type Provision } from './capabilities.ts';\n    30\texport { createLocalCaptureStore } from './local-capture-store.ts';\n    31\t\n    32\t/**\n    33\t * Mount the elicitation harness in a Flue agent.\n    34\t *\n    35\t * Flue has no ask-the-user primitive, so the harness owns the turn-suspension\n    36\t * protocol: a `terminate: true` ask tool, the pending affordance in\n    37\t * per-session state, and the answer arriving as a fresh dispatch (spec §7.4).\n    38\t */\n    39\texport function useElicitation(plugin: Plugin): string {\n    40\t  const delivery = useDelivery();\n    41\t  const [pending, setPending] = usePersistentState<FreeTextAffordanceValue | null>(\n    42\t    'pendingAffordance',\n    43\t    null,\n    44\t  );\n    45\t  const writeAffordance = useDataWriter('affordance', { schema: FreeTextAffordance });\n    46\t\n    47\t  useAgentStart((ctx) => {\n    48\t    if (delivery.kind !== 'user' || pending === null) return;\n    49\t\n    50\t    setPending(null);\n    51\t    ctx.append({\n    52\t      kind: 'signal',\n    53\t      type: 'affordance-reply-bound',\n    54\t      tagName: 'affordance-reply-bound',\n    55\t      body: `The immediately preceding user message is mechanically bound as the reply to this pending affordance:\\n\\n${pending.markdown}`,\n    56\t      attributes: { affordanceId: pending.id },\n    57\t    });\n    58\t  });\n    59\t\n    60\t  useTool({\n    61\t    name: toolName('ask'),\n    62\t    description:\n    63\t      'Ask one free-text question and suspend this turn for the person’s reply. A second ask in the same tool batch is rejected.',\n    64\t    input: AskInput,\n    65\t    output: FreeTextAffordance,\n    66\t    run({ data, toolCallId }) {\n    67\t      const affordance: FreeTextAffordanceValue = {\n    68\t        id: `affordance_${toolCallId}`,\n    69\t        form: 'free-text',\n    70\t        markdown: data.question,\n    71\t        payload: { question: data.question },\n    72\t      };\n    73\t\n    74\t      setPending((current) => {\n    75\t        if (current !== null) {\n    76\t          throw new Error(\n    77\t            `An interactive affordance is already pending (${current.id}); wait for its reply before asking another question.`,\n    78\t          );\n    79\t        }\n    80\t        return affordance;\n    81\t      });\n    82\t      writeAffordance(affordance);\n    83\t\n    84\t      return { output: affordance, terminate: true };\n    85\t    },\n    86\t  });\n    87\t\n    88\t  return [\n    89\t    `You are interviewing someone to elicit ${plugin.targetDomain}.`,\n    90\t    `Ask one question at a time with ${toolName('ask')}.`,\n    91\t    'Continue the conversation after each reply, using the harness-provided reply binding as a mechanical fact.',\n    92\t  ].join('\\n\\n');\n    93\t}\n\n--- local store selected ---\n     1\timport {\n     2\t  applyCaptureStoreCommand,\n     3\t  createEmptyCaptureStoreSnapshot,\n     4\t  parseCaptureStoreSnapshot,\n     5\t  type CaptureStore,\n     6\t  type CaptureStoreCommand,\n     7\t  type CaptureStoreResult,\n     8\t  type CaptureStoreSnapshot,\n     9\t} from '@brunch/core';\n    10\timport { randomUUID } from 'node:crypto';\n    11\timport { mkdir, readFile, rename, rm, writeFile } from 'node:fs/promises';\n    12\timport { dirname, resolve } from 'node:path';\n    13\t\n    14\tconst writesByPath = new Map<string, Promise<void>>();\n    15\t\n    16\tclass LocalCaptureStore implements CaptureStore {\n    17\t  readonly #path: string;\n    18\t\n    19\t  constructor(path: string) {\n    20\t    this.#path = resolve(path);\n    21\t  }\n    22\t\n    23\t  async read(): Promise<CaptureStoreSnapshot> {\n    24\t    await writesByPath.get(this.#path);\n    25\t    return this.#readFile();\n    26\t  }\n    27\t\n    28\t  async execute(command: CaptureStoreCommand): Promise<CaptureStoreResult> {\n    29\t    const previous = writesByPath.get(this.#path) ?? Promise.resolve();\n    30\t    const operation = previous.then(async () => {\n    31\t      const result = applyCaptureStoreCommand(await this.#readFile(), command);\n    32\t      if (result.ok) await this.#writeFile(result.snapshot);\n    33\t      return result;\n    34\t    });\n    35\t    const settled = operation.then(\n    36\t      () => undefined,\n    37\t      () => undefined,\n    38\t    );\n    39\t    writesByPath.set(this.#path, settled);\n    40\t    void settled.finally(() => {\n    41\t      if (writesByPath.get(this.#path) === settled) writesByPath.delete(this.#path);\n    42\t    });\n    43\t    return operation;\n    44\t  }\n    45\t\n    46\t  async #readFile(): Promise<CaptureStoreSnapshot> {\n    47\t    try {\n    48\t      return parseCaptureStoreSnapshot(JSON.parse(await readFile(this.#path, 'utf8')));\n    49\t    } catch (error) {\n    50\t      if (\n    51\t        error instanceof Error &&\n    52\t        'code' in error &&\n    53\t        (error as NodeJS.ErrnoException).code === 'ENOENT'\n    54\t      ) {\n    55\t        return createEmptyCaptureStoreSnapshot();\n    56\t      }\n    57\t      throw error;\n    58\t    }\n    59\t  }\n    60\t\n    61\t  async #writeFile(snapshot: CaptureStoreSnapshot): Promise<void> {\n    62\t    await mkdir(dirname(this.#path), { recursive: true });\n    63\t    const temporaryPath = `${this.#path}.${randomUUID()}.tmp`;\n    64\t    try {\n    65\t      await writeFile(temporaryPath, `${JSON.stringify(snapshot, null, 2)}\\n`, {\n    66\t        encoding: 'utf8',\n    67\t        flag: 'wx',\n    68\t      });\n    69\t      await rename(temporaryPath, this.#path);\n    70\t    } finally {\n    71\t      await rm(temporaryPath, { force: true });\n    72\t    }\n    73\t  }\n    74\t}\n    75\t\n    76\texport const createLocalCaptureStore = (path: string): CaptureStore => new LocalCaptureStore(path);\n",
+  "exitCode": 0
+}
+```
+
+**Tool Result:** `TU-0346wcH9sEIeJxJQiBiuM9`
+
+```
+{
+  "output": "   642\t### 12.5 Dev app, deploy, remote parity\n   643\t\n   644\t- **Dev app chartered with three roles** (roles, not features): the local dev loop against both\n   645\t  plugins; the colleague-facing **target-gallery demo** (parallel tabbed sessions across targets);\n   646\t  the **diagnostic probe surface** (provisional affordance renderers now; the exploded-view\n   647\t  instrumented readout when that fog graduates). One agent per target (`ElicitGherkin`,\n   648\t  `ElicitAssurance`): static per-agent tool sets, and the shape Cloudflare forces anyway.\n   649\t- **UI affordance package deferred**, named as intended: React renderers + reply transport over\n   650\t  `@flue/react`; non-React hosts build on `@flue/sdk`. Milestone one keeps renderers in the dev\n   651\t  app.\n   652\t- **Milestone one is local-only**, with **remote-parity constraints pinned now** so nothing\n   653\t  local-only creeps in: one-agent-many-conversations; pinned `agentName`; the storage port owned\n   654\t  outside the plugin (harness-defined, binding-implemented, §9.6); no dynamic agent creation.\n   655\t  Deploy-target choice waits on an infra conversation and blocks nothing here.\n   656\t- **CI smoke** = `vite build` + the simulation suite (no model key, no flake); an optional\n   657\t  secret-gated real-model `flue run` smoke once a provider key exists.\n   658\t\n   659\t### 12.6 Version axes (named, none implemented)\n   660\t\n   661\tAPI contract / plugin implementation / concept-schema / target-schema / persisted state. A change\n    60\t      file.text.includes('expect('),\n    61\t  );\n    62\t\n    63\texport const KNOWN_GAPS: readonly KnownGap[] = [\n    64\t  {\n    65\t    id: 'restart-durability',\n    66\t    spec: '§14.5',\n    67\t    ticket: 'FE-1396',\n    68\t    gap: 'The capture store survives restart (proven in the ticket-13 prototype), but conversation-store durability with a real db.ts has never been driven across a restart.',\n    69\t    closes:\n    70\t      'A test under apps/dev/test that boots the dev app, holds a conversation, restarts the process, and resumes the same conversation id — citing `closes-gap: <this id>`.',\n    71\t    closed: () => closedByTest('apps/dev/test', 'restart-durability'),\n    72\t  },\n    73\t  {\n    74\t    id: 'compaction-vs-durable-history',\n    75\t    spec: '§9.7, §14.5',\n    76\t    ticket: 'FE-1386',\n    77\t    gap: 'No session has been driven across a compaction boundary, so whether Flue compaction leaves the durable entry projection intact is unverified — and evidence pointers bind to that projection.',\n    78\t    closes:\n    79\t      'A test under packages/binding-flue/test driving a session past compaction and asserting every capture’s evidence pointer still resolves through the session-log archive — citing `closes-gap: <this id>`.',\n    80\t    closed: () => closedByTest('packages/binding-flue/test', 'compaction-vs-durable-history'),\n    81\t  },\n    82\t  {\n    83\t    id: 'history-projection-paging',\n    84\t    spec: '§14.5',\n    85\t    ticket: 'FE-1391',\n    86\t    gap: 'The durable-history projection is read over self-HTTP; paging past ~1000 entries and binding base-URL discovery are both untested.',\n    87\t    closes:\n    88\t      'The binding’s history reader covering a paged projection, tested under packages/binding-flue/test — citing `closes-gap: <this id>`.',\n    89\t    closed: () => closedByTest('packages/binding-flue/test', 'history-projection-paging'),\n    90\t  },\n    91\t  {\n    92\t    id: 'interpretation-render-plugin-seam',\n    93\t    spec: '§7.6, §14.5',\n    94\t    ticket: 'FE-1394',\n    95\t    gap: 'The plugin-supplied renderer seam for the interpretation render has never been exercised, because no real pack exists yet.',\n    96\t    closes: 'A plugin supplying a renderer definition typed against its own payload shapes.',\n    97\t    closed: () => {\n    98\t      // Not a filename check: the seam is exercised once the plugin's source\n    99\t      // exports a renderer, wherever that export lives — and an empty file at\n   100\t      // a guessed path exports nothing.\n   101\t      const plugin = workspacePackages().find((pkg) => pkg.name === '@brunch/plugin-gherkin');\n   102\t      return (\n   103\t        plugin !== undefined &&\n   104\t        sourceFiles(plugin).some((file) =>\n   105\t          /export\\s+(?:const|function|class)\\s+\\w*[Rr]enderer/.test(file.text),\n   106\t        )\n   107\t      );\n   108\t    },\n   109\t  },\n   110\t];\n     1\t# The CI smoke (spec §12.5): `vite build` plus the simulation suite — no model\n     2\t# key, no substrate, no flake. An optional secret-gated real-model `flue run`\n     3\t# smoke is named in the spec and deliberately absent until a provider key\n     4\t# exists; the suite asserts that it has not drifted in.\n     5\tname: CI\n     6\t\n     7\ton:\n     8\t  push:\n     9\t    branches: [main]\n    10\t  pull_request:\n    11\t\n    12\tjobs:\n    13\t  smoke:\n    14\t    runs-on: ubuntu-latest\n    15\t    steps:\n    16\t      # Full-SHA pins: org policy refuses tag-pinned actions (the job fails at\n    17\t      # setup before any step runs). Comments carry the tag each SHA matched.\n    18\t      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4\n    19\t\n    20\t      - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2\n    21\t        with:\n    22\t          bun-version: '1.3.14'\n    23\t\n    24\t      - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4\n    25\t        with:\n    26\t          path: ~/.bun/install/cache\n    27\t          key: ${{ runner.os }}-bun-${{ hashFiles('bun.lock') }}\n    28\t          restore-keys: ${{ runner.os }}-bun-\n    29\t\n    30\t      - run: bun install --frozen-lockfile\n    31\t\n    32\t      - name: Lint\n    33\t        run: bun run lint:check\n    34\t\n    35\t      - name: Formatting\n    36\t        run: bun run fmt:check\n    37\t\n    38\t      - name: Typecheck\n    39\t        run: bun run typecheck\n    40\t\n    41\t      # Reads the repository tree and the harness contract; touches no model\n    42\t      # and no substrate. Three suites, with different jobs: boundaries makes\n    43\t      # the spec §4/§12.2 invariants enforceable rather than aspirational;\n    44\t      # build-artifact checks what was actually emitted, because a Flue build\n    45\t      # that silently drops an agent still exits 0; known-gaps keeps the spec\n    46\t      # §14.5 open items visible and goes red when one closes unremarked.\n    47\t      #\n    48\t      # The build gate lives inside this step: build-artifact's beforeAll\n    49\t      # runs the full build (Flue server environment plus the plain client\n    50\t      # build that @flue/vite does not do) so that `bun test` alone is a\n    51\t      # complete signal. A separate Build step would build the app a second\n    52\t      # time for no additional coverage.\n    53\t      - name: Test\n    54\t        run: bun test\n",
+  "exitCode": 0
+}
+```
+
+## Assistant
+
+### Bottom line
+
+**Keep Flue as this project’s agent substrate.** Tilde is not a like-for-like replacement: Flue supplies the agent runtime, lifecycle, persistence semantics, and deployable server; Tilde supplies a hosted control plane around an agent runtime you build separately—principally with Vercel AI SDK.
+
+Tilde may later be useful alongside Flue for managed MCP tools, credentials, channels, and event ingress. Re-platforming brunch-lite onto it now would add work without resolving the project’s current risks.
+
+_Assessment current to 14 August 2026._
+
+```diagram
+Flue
+┌────┐    ┌─────────────────────────┐    ┌──────────────┐
+│ UI │───▶│ Your Flue runtime/server│───▶│ Model + tools│
+└────┘    │ Conversations + recovery│    └──────────────┘
+          └────────────┬────────────┘
+                       ▼
+                  Your database
+
+Tilde
+┌────────────────┐    ┌────────────────────┐    ┌────────────────────┐
+│ Chat / signals │───▶│ Tilde cloud        │───▶│ Your AI SDK endpoint│
+└────────────────┘    │ History, credentials│    │ commonly on Vercel │
+                      │ tools, routing      │    └──────────┬─────────┘
+                      └────────────────────┘               ▼
+                                                    Model + agent loop
+```
+
+### Comparative assessment
+
+| Concern                     | Flue                                                                                                                                                | Tilde                                                                                                                                                                   |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **What it is**              | Open-source TypeScript agent runtime and application framework.                                                                                     | Hosted agent control plane plus endpoint/client SDKs.                                                                                                                   |
+| **Programming model**       | Agent functions and React-like hooks for models, tools, state, lifecycle, data parts, skills and subagents.                                         | Ordinary Vercel AI SDK loops wrapped in a signed `chatKitEndpoint`; Tilde does not own the inference loop.                                                              |
+| **Local development**       | `flue run` for one agent; `vite dev` for the application; in-process execution and HTTP tests. No cloud account required beyond the model provider. | Requires a Tilde workspace, registered endpoint, one-time credentials and usually a managed public Cloudflare tunnel. Mission Control provides a useful remote test UI. |
+| **Testing**                 | Public in-process and HTTP surfaces; Vitest-based eval guidance; typed runtime events and OTel, Sentry and Braintrust integrations.                 | SDK unit-testability and AI SDK callbacks, but cloud integrations require remote testing. No comparable documented eval or tracing framework.                           |
+| **Conversation durability** | Explicit accepted-work and recovery contract; persistent state is atomic with runtime work. External effects remain at-least-once.                  | Hosted ChatKit preserves sessions and queues turns, but the documented SDK supplies no Flue-equivalent durable execution or arbitrary atomic per-conversation state.    |
+| **Deployment**              | Builds the actual agent server: Node anywhere or Cloudflare Workers/Durable Objects.                                                                | Tilde deploys/configures control-plane resources. Your agent endpoint must be deployed separately; first-party examples assume Next.js/Vercel.                          |
+| **Scaling**                 | Cloudflare gives structural single ownership. Node requires one live owner per conversation even with a shared database.                            | Tilde handles ingress and queue policies, while endpoint execution remains subject to the chosen serverless host’s duration and failure model.                          |
+| **Infrastructure as code**  | Conventional source, Vite, database and host configuration; Wrangler migrations on Cloudflare.                                                      | Strong `tilde.state.yaml` export/plan/import story for Tilde resources, but it excludes secrets, credentials, conversation history and application infrastructure.      |
+| **Portability**             | Apache-2.0; portable Node hosting, with deeper Cloudflare coupling if that target is chosen.                                                        | Agent/model code remains yours, but history, signals, credentials, MCP catalog and routing depend on Tilde’s SaaS.                                                      |
+| **Maturity**                | Current 2.0.3 release is substantial but follows a recent architectural rewrite.                                                                    | Very early: SDK packages are around 0.1–0.2. The public SDK repository is marked `UNLICENSED`; only the examples are MIT.                                               |
+
+Sources: [Flue durability](https://flueframework.com/docs/guide/durability/), [Node deployment](https://flueframework.com/docs/ecosystem/deploy/node/), [Cloudflare deployment](https://flueframework.com/docs/ecosystem/deploy/cloudflare/), [Tilde ChatKit](https://trytilde.ai/docs/chatkit), [dev tunnels](https://trytilde.ai/docs/llms/dev-tunnels.md), [portable state](https://trytilde.ai/docs/terraform), and the [Tilde Harness SDK](https://github.com/trytilde/harness-sdk).
+
+### Import for brunch-lite
+
+The project already isolates Flue correctly rather than allowing it to define the domain model:
+
+- The substrate-neutral harness and plugin boundary is explicit in [CONTEXT.md](file:///Users/lunelson/Code/hashintel/brunch-lite/CONTEXT.md#L17-L27).
+- The ten substrate requirements are recorded in the [Flue capability list](file:///Users/lunelson/Code/hashintel/brunch-lite/packages/binding-flue/src/capabilities.ts#L30-L93).
+- The actual agent remains thin in [gherkin-elicitor.ts](file:///Users/lunelson/Code/hashintel/brunch-lite/apps/dev/src/agents/gherkin-elicitor.ts#L22-L59).
+- The project already has a hermetic faux-model walking skeleton and emitted-artifact checks.
+
+That architecture makes a future Tilde binding possible, but it would be substantial. Tilde does not natively replace several capabilities brunch-lite currently obtains from Flue:
+
+- atomic `usePersistentState`;
+- lifecycle hooks and same-response signal injection;
+- structured conversation data writers;
+- durable accepted-work recovery;
+- the current suspend-and-resume protocol.
+
+Tilde ChatKit history could replace the live conversation transport, and Signals would improve managed event ingress. The capture store would nevertheless remain application-owned: Tilde Memory is not a substitute for brunch-lite’s transactional capture store, evidence archive and whole-sweep refusal semantics.
+
+#### Recommended course
+
+1. **Finish milestone one on Flue.** This matches the existing local-only decision in the [spec](file:///Users/lunelson/Code/hashintel/brunch-lite/docs/planning/elicitation-kernel/spec.md#L642-L657).
+2. **Deploy the current demo on a single Node host first**, using persistent storage for both SQLite and the JSON capture store. The current application is Node-specific.
+3. Before exposing it remotely:
+   - close the existing [restart-durability gap](file:///Users/lunelson/Code/hashintel/brunch-lite/test/known-gaps.ts#L63-L80);
+   - add authentication and per-conversation authorization—the current mounted Flue route is public;
+   - add runtime telemetry;
+   - settle persisted-state versioning and backup expectations.
+4. **Do not select Cloudflare casually.** Flue conversations map well to Durable Objects, but brunch-lite’s target-document spans multiple sessions. Its capture store therefore still needs a separate cross-conversation persistence design, and the current filesystem-backed implementation cannot move unchanged.
+5. **Revisit Tilde only when managed integrations become a concrete requirement.** The lowest-risk experiment would be consuming a Tilde-managed MCP server from the existing Flue agent. That tests its strongest proposition—tool and credential brokerage—without replacing the proven runtime.
+6. Treat adoption of the Tilde SDK as requiring a **licensing, data-governance and vendor review** while its package remains unlicensed and its SaaS pricing and contracts are still evolving.
diff --git a/libs/@hashintel/brunch-agent/docs/reference/hash-sails-public-report.pdf b/libs/@hashintel/brunch-agent/docs/reference/hash-sails-public-report.pdf
new file mode 100644
index 00000000000..becd6380da9
Binary files /dev/null and b/libs/@hashintel/brunch-agent/docs/reference/hash-sails-public-report.pdf differ
diff --git a/libs/@hashintel/brunch-agent/docs/reference/voice-implementation-recommendation-pplx.md b/libs/@hashintel/brunch-agent/docs/reference/voice-implementation-recommendation-pplx.md
new file mode 100644
index 00000000000..2096abb88f2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/voice-implementation-recommendation-pplx.md
@@ -0,0 +1,44 @@
+## Recommendation
+
+Use **ElevenLabs Speech Engine** first if your elicitation agent already has bespoke orchestration, state, tools, and an LLM loop. It is explicitly designed to put voice around an existing chat agent: ElevenLabs handles browser audio, transcription, TTS, connection lifecycle, turn-taking, and interruption detection, while your server receives transcripts plus history and streams text back. In TypeScript, an interruption aborts the in-flight LLM operation through an `AbortSignal`. [elevenlabs](https://elevenlabs.io/docs/overview/capabilities/speech-engine)
+
+That fits your concern particularly well: your demo remains a text-/event-driven elicitation agent internally, and voice becomes an adapter at the edge. The trade-off is a cascaded pipeline—ASR → your model/agent → TTS—so it will generally have less native conversational prosody and potentially more latency than a true speech-to-speech model.
+
+## Assessment of the options
+
+| Option                       | Fit for your demo                                                                                      | What you still own                                                                                                                                                                                                                                                                                           |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **ElevenLabs Speech Engine** | **Best initial choice** if you need your own elicitation logic, model choice, tools, and state machine | Your agent endpoint and streaming textual response; not audio turn-taking/interruption plumbing. [elevenlabs](https://elevenlabs.io/docs/overview/capabilities/speech-engine)                                                                                                                                |
+| **Gemini Live API**          | Strong native-audio alternative if conversational quality itself is central to the demo                | A stateful WebSocket integration and your tool/orchestration boundary. It supports barge-in, transcripts, proactive-audio controls, and function calling, but remains preview. [ai.google](https://ai.google.dev/gemini-api/docs/live-api)                                                                   |
+| **OpenAI Realtime**          | Strong option if you are happy to place the conversational model directly in OpenAI’s Realtime session | Some integration semantics remain—especially if you choose WebSockets rather than WebRTC. OpenAI recommends WebRTC for browser audio; with WebSockets, you own playback and explicit response truncation on interruptions. [platform.openai](https://platform.openai.com/docs/guides/realtime-conversations) |
+| **xAI Grok Voice**           | Worth a spike, especially if you want native speech-to-speech plus tool/MCP support                    | A realtime integration and evaluation of quality/reliability for your particular elicitation style. It has server VAD, adjustable silence/prefix padding, browser ephemeral tokens, and tool support. [docs.x](https://docs.x.ai/developers/model-capabilities/audio/speech-to-speech)                       |
+
+## Corrections to the note
+
+- I would not base a plan on **“GPT-Live-1”** as an available public API target. The current public OpenAI API documentation describes `gpt-realtime` / `gpt-realtime-mini` through the Realtime API, with WebRTC or WebSocket connections, VAD, interruptions, and function calling. [platform.openai](https://platform.openai.com/docs/guides/realtime-conversations)
+- **Gemini Live** is publicly usable in preview, not merely nominally available. It is a native streaming voice/vision API over a stateful WebSocket and exposes interruption (“barge-in”), transcription, tool use, and response-timing controls. Preview still matters: treat it as a demo dependency, pin model versions, and retain a fallback. [ai.google](https://ai.google.dev/gemini-api/docs/live-api)
+- **ElevenLabs Conversational AI is not limited to support/sales.** Their fully hosted product may be positioned that way, but Speech Engine is specifically for developers attaching voice to a custom agent and retaining control over model, routing, context, and tools. [elevenlabs](https://elevenlabs.io/docs/overview/capabilities/speech-engine)
+- xAI’s protocol is **OpenAI-Realtime-shaped**, but not something I would call drop-in compatible. Its docs use familiar events such as `session.update`, `conversation.item.create`, and `response.create`, but add xAI-specific behavior—including remote MCP tools and `force_message`. Keep a thin provider adapter rather than assuming protocol portability. [docs.x](https://docs.x.ai/developers/model-capabilities/audio/speech-to-speech)
+
+## Suggested demo shape
+
+```text
+Browser
+  ↕ managed voice transport / turn-taking
+ElevenLabs Speech Engine
+  ↕ transcript + history / streamed response
+Your elicitation service
+  ├─ elicitation state machine
+  ├─ agent / LLM calls
+  ├─ tool calls and persistence
+  └─ structured event log + transcript
+```
+
+Keep the **authoritative elicitation state in your backend**, not in the voice provider’s conversation history. Treat each voice turn as an input event carrying: transcript, timestamps, confidence if available, interruption/cancellation status, and a monotonically increasing turn ID. On barge-in, abort the current agent generation and invalidate any subsequent TTS chunks from that turn.
+
+## Practical approach
+
+1. Build the demo with **ElevenLabs Speech Engine + your existing text agent**.
+2. Use WebRTC in the browser when the provider supports it; it avoids much of the brittle client audio work and generally gives better media handling. OpenAI explicitly recommends WebRTC for browser output, and ElevenLabs’ voice SDK uses WebRTC by default. [platform.openai](https://platform.openai.com/docs/guides/realtime-conversations)
+3. Run one short A/B spike against **Gemini Live native audio** only if the demo’s value depends on the agent sounding unusually socially fluent—acknowledgements, hesitation, overlap, and nuanced interruption behavior.
+4. Keep a visible transcript and a push-to-talk fallback. It protects the demo from VAD ambiguity and lets you present the elicitation mechanics even if open-mic voice behavior is imperfect. OpenAI’s own documentation notes that push-to-talk can avoid VAD failures and feel responsive. [platform.openai](https://platform.openai.com/docs/guides/realtime-conversations)
diff --git a/libs/@hashintel/brunch-agent/docs/reference/yannis-dora-lu-transcript-2026-08-11.md b/libs/@hashintel/brunch-agent/docs/reference/yannis-dora-lu-transcript-2026-08-11.md
new file mode 100644
index 00000000000..4f0b60b5228
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/reference/yannis-dora-lu-transcript-2026-08-11.md
@@ -0,0 +1,239 @@
+Speaker 1: Got it. I'm going to start.
+Lu Nelson (You): So we'll— should we wait for Dora to join?
+Speaker 1: Yeah, of course.
+Lu Nelson (You): I'll just try and frame: Dora and I talked yesterday, I guess, and what we talked about was, well, the challenge that we face right now if— given that there's a goal to demo something in September with a flow of elicitation, so an eliciting agent that would actually elicit a model for a cyber-physical system.
+Lu Nelson (You): And I think there's scraps of this description that are living in different documents and linear issues and stuff like that at this point, but basically, in its most maximalist version, it's like, let's have a demo that shows in which a domain expert basically is interviewed by an agent and a model is elicited, which, like, showcases all the way up to the SD-CPN level of complexity of a cyber-physical model.
+Lu Nelson (You): And so defining that is— Request a record to the cloud. Sure.
+Speaker 3: Sorry, I'm just requesting so we—
+Speaker 4: Recording in progress.
+Lu Nelson (You): That's cool. So yeah, so I think then that makes— that gives me just a lot of questions, because in order for, broadly speaking, in order for an eliciting agent to do this job specifically, it doesn't need a checklist or a questionnaire.
+Lu Nelson (You): It really actually needs strategies and policies. Like, it needs— it needs strategies, heuristics, policies, things to check, things to look for, how to respond to certain kinds of questions, an ordering of— a kind of strategic ordering of questions in order to let answers inform subsequent questions, this kind of thing.
+Lu Nelson (You): So that's kind of why I want to talk to you, because I wanted to sort of see if I could just take a shot at asking you how you would do it.
+Lu Nelson (You): If you were trying to model a situation, a system, a process, how do you go about asking questions, let's say, of a domain expert? Where do you start?
+Lu Nelson (You): What kinds of questions do you ask? And so on.
+Yannis Zachos: Yeah. Before I kind of start answering, I guess I just want to understand a little bit what's the— because I guess there's already an AI assistant within PetriKnot that is kind of doing what you're describing.
+Lu Nelson (You): Well, yes and no, because it's— because what it's doing is it's asking you directly for a PetriKnot model, which assumes that you— to some extent, it collapses some of those steps, because it says— it kind of expects you to understand some of the implications of what you might be asking for, or like, why you would ask for a PetriKnot in the first place. I think the point is rather to wind this back a couple of degrees to a point where we're— before we talk about PetriKnots or
+Lu Nelson (You): we introduce the PetriKnot as the way to model this thing dynamically and to visualize it dynamically, we're trying to build a— we're just saying we're trying to model this system. So we're trying to capture, essentially, what are all the things we need to know about this system, and then we will project that into a PetriKnot or with some combination of— maybe that can be done in some combination of deterministic and non-deterministic ways to interpret kind of a thorough elicited description of a dynamic system and then
+Lu Nelson (You): project that into a PetriKnot. But going directly to a PetriKnot, you have an agent who basically knows about PetriKnots but doesn't necessarily know about any of the— any of the kind of requirements, conditions, or, like, constraints and so on of creating a good model of a cyber-physical system.
+Lu Nelson (You): It doesn't know anything about that. It knows— it knows something as training data about PetriKnots, so if you tell it what you want to model, it can maybe generate a reasonable representation of that in terms of places and transitions and so on.
+Lu Nelson (You): But it doesn't necessarily know anything about how to effectively elicit and capture a description of a cyber-physical system.
+Lu Nelson (You): The PetriKnot projection is a second-degree step, or it's like a later step.
+Yannis Zachos: I see.
+Yannis Zachos: Okay, yeah, I mean, I'm just trying to envision, you know, what would, like, that elicited specification include that would not be part of the PetriKnot. So what would be the output of the first step of the elicitation agent that, I guess, would then be passed on in a second step to either the existing AI assistant or maybe the existing elicitation agent is going to take care of the entire flow of going from description of a cyber-physical system from, yeah, elicit— so first step, elicitation of a
+Yannis Zachos: cyber-physical system, and then representation of that cyber-physical system as the PetriKnot. So I'm just trying to figure out what's the output in the first step that would not fit into the— would not fit into the PetriKnot description of it.
+Yannis Zachos: Like, what would not be reflected on the PetriKnot but we would need to elicit in any case.
+Lu Nelson (You): Right.
+Yannis Zachos: So, I mean, you mentioned constraints and all that, but yeah, I don't know, it's a bit abstract at the moment that I'm struggling to kind of understand exactly what that would look like. I don't know if you have any specific examples in mind that might shed some light on this.
+Lu Nelson (You): Let's see. One of the examples that is kind of— and this is sort of called out in the sales document, I believe, is the idea of the sort of decision layer. Like, basically, decision policies are not— it notes this as a gap, that there's an open question whether policies belong in the net or whether some kind of separate policy annotation or object would have to be created.
+Lu Nelson (You): So, like, policies in transitions that decide when two transitions want to do the same thing, or like, they want access to the same thing, then there's, like, there's a policy layer required, which currently doesn't have a representation in the net.
+Lu Nelson (You): And I think there's a series of other— there's probably a series of other things. Like, what did I come up with here?
+Lu Nelson (You): Penalty weights, goals, rationale, unwritten constraints, validation criteria. These are all things that you want to capture in an interview and you want to capture in some type of intermediate representation, but they don't necessarily have a canonical place to live in the PetriKnot.
+Lu Nelson (You): Thus, I see PetriKnots more as a projection of an intermediate representation, which remains to be designed. You know, I don't know what that representation contains, but I think figuring out what the schema of that looks like is part of the task that we're facing.
+Lu Nelson (You): So one of them is, like, how do you describe to the agent how it should go about doing this, and then also how do you describe what's the output shape that the agent needs to fulfill? It actually needs both of those things.
+Yannis Zachos: Yeah, I see. Yeah, yes, I mean, it's always, I think, just having that Petri— so the end goal of producing a PetriKnot in mind, I guess, might be really good for grounding the agent in any case, even in the first elicitation step.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Because I think it's just going to make things concrete in any case. I think one of the things that I would see as something that's not currently represented on a PetriKnot and is useful and actually hopefully will be represented on a PetriKnot eventually are these kind of business constraints where you're kind of trying to elicit, you know, so on the cyber— on the physical, this would be— I mean, I guess on the physical constraints, physical constraints tend to be differential equations, which are already represented in place
+Yannis Zachos: dynamics.
+Yannis Zachos: So it might be something like a conservation law, like number of tokens in equals number of tokens out, or it might be— actually, that's not a tech— technically, that's not being represented in the dynamics equation, but it can be something like conservation of momentum, you know, classical physical laws. So that's definitely something.
+Yannis Zachos: But again, that would also fit into the place dynamics. So any other physical constraints?
+Yannis Zachos: I think there are— there is a subset of physical constraints that are not represented on the PetriKnot. I think one of them is token conservation, that, you know, whatever this transition— I mean, I'm referring to these examples with the— I'm referring to PetriKnots to explain these examples because I think it's a bit easier, but obviously we can just think of a way to abstract away from PetriKnots.
+Yannis Zachos: But yeah, so basically, like, a transition would produce the same amount of tokens as it consumed, always, which is something that refers to the construction of the PetriKnot and specifically the Arc weights. So that's definitely something like that.
+Yannis Zachos: So the— yeah, just going back to constraints, mostly the physical are the ones that I mentioned. So differential equations and other types of physical laws, usually equation-based.
+Yannis Zachos: So most of that is going to be equation-based. The cyber stuff, I think this is where you open up the allowable set of constraints to be a bit more abstract in the sense that they kind of need to encode this business logic.
+Yannis Zachos: Business logic meaning that it's— I see business logic as a bit of an abstraction to— that's not— like, business logic captures certain components, perhaps, of a PetriKnot, but that's not— it's not necessarily represented well within a PetriKnot, and it's something that you want to elicit.
+Yannis Zachos: Examples of business constraints, I guess, can be— might be, like, internal— might be, like, kind of regulations, perhaps, that would prohibit certain sort of behaviors to be simulated.
+Yannis Zachos: So we wouldn't want to be simulate— we wouldn't want to simulate behaviors that are strictly prohibited.
+Yannis Zachos: So that's one set of constraints, or regulatory constraints, really. That's the kind of business logic there.
+Yannis Zachos: Trying to envision what else would be part of that.
+Yannis Zachos: So other types of constraints.
+Yannis Zachos: I mean, there might be just— so that's something that we kind of, like, that's the point with Clarion as well, that, you know, there's always the shoes and manuals of how to do processes was the kind of status— you know, modus operandi of things. So there's one thing you could capture, which is not technically a constraint, I guess.
+Yannis Zachos: It's more like the theoretical execution of a process.
+Lu Nelson (You): I think that's kind of— that's kind of in the zone of what I meant by policies, you know?
+Yannis Zachos: Right.
+Lu Nelson (You): Like, I think that there are sort of operational— in lots of situations, you're likely to have kind of operational policies, which are maybe just— they range anywhere from local, socially established conventions, almost, to things that might be defined by strict regulations or some kind of strict rules that's just inherited by the situation, or any number of other things, but basically that don't have— that don't have some way of living in the net but might dictate that the net has to be constructed in a certain way, or
+Lu Nelson (You): that you basically have to add some logic to the simulation, some kind of arbitrary logic in some way to dictate, like, what happens under these certain special conditions that doesn't have a standard way of being expressed in the STCPN.
+Lu Nelson (You): I don't know.
+Yannis Zachos: Yeah, I think— sorry, I'm not— I was just going to say that maybe the way I'm envisioning this is, like, you have the theoretical PetriKnot and the actual PetriKnot. Like, theoretically, what you should be doing based on the brochure and the manuals and the policies, and the actual, which is what you're actually doing, you're observing through event logs.
+Lu Nelson (You): Yeah.
+Yannis Zachos: And it ends up being almost like you have a compliance application use case where you're saying, like, this is what should be happening based on your manuals, and this is what's actually happening based on your event logs.
+Yannis Zachos: I think that would be something that's useful. Other things that I think would be useful are data feeds, kind of, because a lot of— I mean, if we're going to go too overweight to deploying this— by the way, sorry, I interrupted you.
+Yannis Zachos: I don't know if you wanted to add something on top of—
+Lu Nelson (You): Well, I wanted to say, we— I set the meeting only for half an hour, and I didn't know— I don't know if either of you have more time than that, but it's— as I prepared it, I realized quite quickly that I think the discussion could go for a lot longer than half an hour. So I want to see maybe how— if we want to contain this to half an hour, then I want to maybe just try to throw a few questions at you and see how you
+Lu Nelson (You): sort of would answer those, because they're helpful to me. So shall we do it that way, or do you want to try?
+Yannis Zachos: Yeah, yeah, no, no, no. It's best to— yeah, yeah, yeah, let's stick to that, and then we can always— I mean, and I just want to make sure that this is also useful for generating PetriKnot use cases for DORAS's benefit as well, right? Because I think there's some things that we should elicit potentially, like kinds of questions we should be asking to a PetriKnot that, you know, might be feeding into what an agent will be eliciting.
+Yannis Zachos: So the— so like the constraints that we were talking about is something that should be elicited, and also that's something that when we do build a use case for a PetriKnot, like a specific example of a PetriKnot, we should kind of note down these questions that, you know, the PetriKnot should ask, should answer, actually, by simulating.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Yeah. Just want to make sure that this is also to DORAS's benefit as well. Yeah, please go through the questions that you have.
+Lu Nelson (You): Yeah, so I have— I have too many questions, but let me— let me ask a few. I won't— let me see. I will skip these ones.
+Lu Nelson (You): Let me just clarify. Do you— have you modeled— have you modeled systems by, like, just by basically talking to somebody from the domain, or, like, what do you typically— what are the inputs you've used in the past in order to sort of build a model of something?
+Yannis Zachos: Yeah, I mean, that's a good question because it's a very undocumented process. I mean, typically, in my PhD, what I've done is I usually do a literature review of what's the state-of-the-art representation of a system.
+Yannis Zachos: So if I'm modeling, say, traffic, I'd be looking into traffic simulators, for example. Like, you have microscopic, macroscopic, so there's different kind of levels of granularity.
+Lu Nelson (You): Right.
+Yannis Zachos: So my approach there would be do a literature review. So I guess what the agent would do, perhaps equivalently, if I were to replicate this, would be to do a web crawl of papers, perhaps, on things, because I think.
+Lu Nelson (You): Well, we could— we certainly could include that as part of the process, but I think the thing we're— the thing we're really aiming for is a process where a human is at the center of it. So the use case is like— and it's not— this is one that we want to demonstrate is like a cyber-physical, so on, but it applies to a lot of different things that you might want to model. Like, we're also trying— I'm also trying to build this in a way that can
+Lu Nelson (You): be generalized. So STCPNs and cyber-physical systems is like a plug-in to this system, right?
+Lu Nelson (You): Like, so it's going to describe a lot about, like, what are the specific kinds of things we need to find out, and in what way should we go about finding those things out, and what are the things we definitely have to fulfill as, like, our output to this. And— but that plugs into a system which just generally also has capabilities for understanding how to, like— for pursuing some different strategies of interviewing humans, like setting up questions and trying to sort of order questions by leverage, or— it's
+Lu Nelson (You): very— it's all kinds of different things, but basically try to work towards some kind of elicitation goal. So if it's human-oriented, like, let's say— and this is maybe, therefore, not a very fitting thing, but you're modeling some type of production plant, you're talking directly to the master scheduler of the plant, what are the first five questions you ask? Like, what are the— what are the first things you're going to— you're going to probe to try to figure out the shape of this system?
+Yannis Zachos: I think the way that I would approach it, if I were to formalize it, would be kind of like trying to generate almost what, I guess, the unstructured and structured ingestion would do for, like— so try to build a knowledge graph of everything.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Understand entities and connections between entities, and then just have a— like, have a symbolic representation of how these things are connected. So just build a knowledge graph, essentially. So the questions for doing that, I guess, it's almost a bit difficult to ask a practitioner because it's— if the level of abstraction is really high, then it's very difficult to reason— for them to reason, I'd say, I would argue, because I think.
+Lu Nelson (You): Yeah, yeah, yeah. No, that's absolutely one of the central challenges of this thing, is, like, how do you— how do you— how do you make a— how do you figure out how to approach people who are not— they're not acquainted with the terminology around PetriKnots or mathematically modeling their system, or in terms of mathematical or logical formalisms, they're not doing any of that. They just know how to run the system.
+Lu Nelson (You): They know— they know what the policies are. They know what the analyses are that they usually do.
+Lu Nelson (You): Like your document says, like, they've got a spreadsheet and they've got a— they've got a playbook that sort of tells them what to do, right? Like, that's how they know their system.
+Lu Nelson (You): So how do you— so what kind of questions do you ask to this person?
+Yannis Zachos: I would say— okay, so I would say I would give them first context of, like, let's say this is a production planner, and they obviously might be working on different tasks, but there's a task that's related, perhaps, to, I don't know, a choice of production of planning parameters.
+Yannis Zachos: So I would say, describe to me your workflow of— that involves, like, describe to me the workflow for choosing planning parameters.
+Yannis Zachos: They're the ones that are choosing the parameters, for example. Let's assume that they are so that we can make this concrete.
+Yannis Zachos: So describe your workflow in steps. And then what I would try to do is they give me back some feedback— they give me back some series of steps, and then I kind of— we have this back and forth and reiteratively refine— iteratively refine the description that I'm eliciting under the hood.
+Lu Nelson (You): Yeah.
+Yannis Zachos: So there's an abstract one, then ideally there's a confidence score behind each part of the workflow, and then I say, okay, for the part of the workflow that is— that has really high— low confidence, ask questions there. Can you please elaborate on this part?
+Lu Nelson (You): Right.
+Yannis Zachos: Obviously, there comes a point where— where do you stop asking questions, really? And what's the maximally— like, what's the— I guess, the minimum set of questions you need to answer— to ask to get a meaningful representation without tiring the user? Because I guess, since we want this to be human-driven, we want to be mindful of user experience, so.
+Lu Nelson (You): True enough.
+Yannis Zachos: Yeah, so.
+Lu Nelson (You): Also a challenge in itself.
+Yannis Zachos: Yeah.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Yeah.
+Lu Nelson (You): We run into that one before too.
+Yannis Zachos: So I guess, also, I think what we need to— so apart from giving— so I think initially, when you give context to the person, we should give context not only as to, like, what's the workflow that we're interested in, but also what is the end goal? Like, what are we trying to achieve here? Like, okay, obviously— I mean, for us, we just want to understand what— basically how they work and what rules they follow and what is their thinking strategy behind something.
+Lu Nelson (You): Right. And under the hood, we want to identify all the moving parts, and we want to start to map them to our formalisms, right?
+Yannis Zachos: Yeah.
+Lu Nelson (You): So we want to start to have a sense of, like, what are the places that are involved here? What are the— what are the things that are going to become places? What's going to become transitions?
+Lu Nelson (You): What's going to become tokens and token types? Where are those things maybe dynamic?
+Lu Nelson (You): Where are those things stochastic, et cetera, et cetera? Like, where are we going to— where are we going to introdu— where do we see the dynamism?
+Lu Nelson (You): Where are we going to introduce stochastics and that kind of stuff? Like, this is the thing.
+Lu Nelson (You): So we're trying to map those things without confusing them with those terminologies, necessarily.
+Yannis Zachos: And I think— yeah, so with regards to that as well, I think the context that we initially provide, which is, like, so far I've just talked about how do you do— how do you choose planning parameters. I would say also, ideally, we either have a set of— an idea of what success is, or we ask them to define success, and then based on— like, obviously, they want to succeed in their job, so we would say something like, okay, how do you succeed in doing this thing? So
+Yannis Zachos: just prompting them in directions where they need to formalize their thinking process for how they go about doing things. And then— but I don't know— but I don't know if that's going to be something that we would need to know a priori and provide as initial context in the— before we ask the first question, or if it's something that we would need to elicit as well. Ideally, I think if we can sort of have a very good first prompt that contextualizes as best as possible and specific
+Yannis Zachos: — like, makes the question— the line of questioning quite specific, I think that would be great. I don't know how this would go about. We'd probably need some brochures or something that— or at least, like, the organizational chart, right, to understand where this person fits within the company.
+Lu Nelson (You): Oh, yeah. Oh, yeah, right. Even information about the person that's being spoken to could be interesting.
+Yannis Zachos: Yeah.
+Lu Nelson (You): Yeah, of course.
+Yannis Zachos: So something to ground the conversation, because obviously we want to do that. Like, we— obviously we want to squeeze the most out of what we've got without asking questions, and then it's more about squeezing the rest out of the person, so.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Yeah, so I think it's just questions like, how do you make sure you're successful in this? Are you blocked by any other processes or any other people? So we'd give us.
+Lu Nelson (You): One strategy is, like, you can also ask them, can you describe a bad day? Like, can you describe when this goes badly? Can you describe either— either, like, a specific bad day that ever happened to you or that you ever witnessed, or maybe the thing that you— like, that keeps you up at night that you're afraid might happen one day, right?
+Lu Nelson (You): Like, just describe those things, because they can tell you a lot.
+Yannis Zachos: Absolutely. So yeah, average day, best day, worst day pretty much covers 80% of all days, pretty much, right? Maybe 90% even of all days, so.
+Yannis Zachos: I guess also, yeah, that's a good point, because, like, you want to capture things that are rarely happening, stuff that we might not even have event logs for.
+Lu Nelson (You): Yeah.
+Yannis Zachos: For example. So that's a good point.
+Lu Nelson (You): Sometimes the intuition about the more kind of, like, black swan type of things is only living in the heads of the people who know that system really well. Like, the data wouldn't even tell you that that's— that that's a possibility, right?
+Yannis Zachos: Yeah. And I think, perhaps, then if we see that— like, there might be a line of questioning where you see that they describe a bad day or potentially, like, what's keeping them up at night, and then we almost construct a theoretical scenario of what might happen and how they would deal with it. So if we see them not being creative with their answers, we can just be like, you know, imagine that, you know, you've described to me that you're doing this X, Y, and Z.
+Yannis Zachos: Imagine that while you're doing Y, all of a sudden you get a call that, you know.
+Lu Nelson (You): Right.
+Yannis Zachos: Z is whatever.
+Lu Nelson (You): Right.
+Yannis Zachos: Like, as specific as possible.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Perhaps we already know initially what things are likely to go wrong, so part of the question might be, like, where do you— where are you— where are you least confident that things are going to go smoothly?
+Lu Nelson (You): Yeah.
+Yannis Zachos: In which part of the process you're least confident things are going to go smoothly? And then when they— so they perhaps identify some part of the process, and then we're like, you know, what if this happened? Or we just start coming up with scenarios of how things could potentially go.
+Yannis Zachos: I mean, there's always— I mean, there's going to be an unbounded number of scenarios here, so.
+Lu Nelson (You): Yeah, yeah, yeah, for sure. But I think you landed on a really interesting thing earlier, which is when you think about what you said about the user experience and not wanting to tire the user too much, is— is— and then you talked about, like, how could you ground the conversation in knowledge about the context and maybe even knowledge about the user that's being spoken to. I think that's a really good idea, because probably to prime this elicitation and set it up well, there probably is at least
+Lu Nelson (You): some degree of material that could already be fetched in advance in order to sort of set the agent up so they understand, like, what are we talking about here? What is this— what is this— what does this thing do? What are the potential things that we are thinking about trying to gain insight about or optimize or whatever the goal might be?
+Lu Nelson (You): Like, you might be able to identify kind of quite a few of those lines and boundaries first and set a context, and then set up the agent to ask the human, like, more consequential, focused questions, rather than have the human have to provide a lot of exhaustive information that might actually exist in documents or in other descriptions of the system.
+Speaker 3: Yeah, because there's also.
+Speaker 4: I would ask to anticipate that we would— like, the user would upload data or PDFs process documents that could be used as context, just as you would refer to a code base for, like, prior derivations. And I think it would be really good if we can see what Claude can do now. Say, like, if you said, I want to model a process, like, go through an elicitation process, and see what it naturally does rather than us specifying, like, every single thing, because I think at the moment
+Speaker 4: AI is quite good already at, like, modeling processes as PetriKnots. So we should just try and fill any missing gaps rather than doing it from scratch.
+Lu Nelson (You): Okay. Yeah, that's worth— it's worth using that as a kind of control example from the beginning. Like, can we— but we do have to figure out a— we do have to figure out a good solution to the problem that we've faced all the way along with elicitation, which is that an honest elicitation takes time.
+Lu Nelson (You): Like, it's pretty hard to make them— to do them and then evaluate whether they were any good.
+Speaker 4: Yeah.
+Lu Nelson (You): Unless you can kind of— because you can't strictly script it, because it'll always be slightly different since it's generative, and it's generative at each step.
+Speaker 4: Yeah.
+Lu Nelson (You): And so— so it becomes hard to— it becomes hard to, like, you could— you could— you could do it— you could run through it with Claude, and then you could run through it with a more, I don't know, somehow methodical or structured system.
+Speaker 4: I agree. Even the same person could give different answers on a different hour in the same process, so it's hard to compare, for sure.
+Lu Nelson (You): Right, it's hard to compare, especially since, like, normally in real comparisons you want to do multiples of each one and then be able to, like, really compare those things, but that would take, like, an incredible amount of time. So we have to figure out some reasonable proxy or something for this. But.
+Speaker 4: Yeah.
+Lu Nelson (You): So.
+Speaker 4: Also, one thing on the UX side. I think what Nora pointed out in her Zulip message a while ago, which we should definitely adopt, is that one of the things that makes the elicitation process feel much slower is, like, waiting between questions. And she said that some— she's seen what others might do is, like, you ask— you're thinking a question ahead, so you're asking a question immediately.
+Speaker 4: You're not waiting for that turn, but you're, like, thinking what the next question should be based on the current answer, like, the question after that.
+Lu Nelson (You): Right.
+Speaker 4: So you're, like, reducing— you're reducing— or we should think about, like, batching questions together. So, like, the agent has, like, four questions at a time to ask, and they go through four very quickly, and then it thinks. Like, I think we need to.
+Lu Nelson (You): Yeah. That's what I've— that's what I've— that's what I've been doing a little more recently, and I find it works. It works well, but it's also subject to a kind of horizon problem.
+Lu Nelson (You): Like, the model can easily generate, like, nine questions for you, but the problem is that after you answer the first three, the fourth, fifth, and sixth already are at risk of being stale, because, like, your answers to the first three might be different than what the model expected.
+Speaker 4: For sure.
+Lu Nelson (You): And then already the next ones are out of line with that. So sometimes it's good for it to ask you, like, three, maybe four questions at a time.
+Speaker 4: Yeah.
+Lu Nelson (You): And it's usually, like, good sort of high-impact questions, and then it will think and then come up with, like, three or four more.
+Speaker 4: But can you not prompt the agent to batch questions that are almost, like, unrelated to each other in terms of answering— the answer of one will not impact the other, like, to the best of its ability, obviously? It's complicated.
+Lu Nelson (You): Yeah.
+Speaker 4: It's hard to make that so that.
+Lu Nelson (You): Yeah, definitely try to do that.
+Yannis Zachos: I can see— I mean, just on that, I think a way I'm— like, implementation-wise, what I'm thinking of here is, I guess, how initially AI was applied, right, where you had— it was applied to, like, chess, where you had, like, trees of decisions that fan out, where here you have lines of questioning that are fanning out.
+Lu Nelson (You): Yeah.
+Yannis Zachos: And you're just pruning paths along this tree depending on the answers that you get. So perhaps you have— you know, you come up with— maybe you query— you do a mixture of experts approach where you query a bunch of agents to give you different lines of questioning, you reduce them as— or batch them as Dora suggests, and then based— so you decide which line of questioning is going to maximally increase our understanding of the system that we don't already have from ingested information, whether unstructured or structured.
+Yannis Zachos: So whatever part of the knowledge graph we are least confident about, and then you ask— you ask that— you start that line of questioning. Depending on the answer, you might prune it, because there might be like, oh, no, no, no, actually we don't do that.
+Yannis Zachos: So— and your follow-up questions perhaps depended on— on— assumed that the person was doing X, but they tell you that they're not doing it. So like, okay, let's prune this line of questioning and go to the next one, or adjust dynamically there.
+Yannis Zachos: Like, can I— instead of just pruning the entire line of questioning, can I generate new children questions, like, in the tree of things?
+Lu Nelson (You): Yeah.
+Yannis Zachos: So this kind of tree representation of question— of lines of questioning.
+Lu Nelson (You): Yeah.
+Yannis Zachos: Sounds to me like— so to formalize it for an agent, right, something that the agent understands and can ground themselves on.
+Lu Nelson (You): Yeah. Yeah, it's just— it's just tricky. Like, they— they— they don't necessarily come together strictly in trees.
+Lu Nelson (You): Like, it's just the extent to which it would really work, like, sort of branching options is just sometimes less than you might think. Like, sometimes the questions are more open-ended.
+Lu Nelson (You): At least necessarily at the beginning, they're more open-ended than you might think, and there isn't really a way to, like, map discrete branches off of those. But yeah, to whatever— to the extent that it's possible, we can try and do that.
+Lu Nelson (You): Okay. What I was going to propose, since we're already over the half hour, is what if I put up a Notion document kind of with the questions that I had, and you could answer— you could try answering them or commenting on the questions or, like, whatever, but see— that'll give you also more time to think about it and maybe counterpoint or counterpropose your own better questions or whatever, but that would help to fill in some of those blanks.
+Lu Nelson (You): And then I think off of that, I can also generate better questions, and we can, like, converge on something else. But— so it'd be a bit of a churning kind of process, but I think that might be— to do it sort of async might be an efficient way to go.
+Yannis Zachos: Just to be clear, you're talking about questions that you would— that the agent would ask or questions?
+Lu Nelson (You): Some of the questions I had for you, actually, like, along these lines of— like, these lines of, like, okay, imagine you're the one needing to sort of talk to a human to gather whatever you need to know in order to, like, successfully, comprehensively model this system in the way— according to the— according to the also very important aspects that you want to make sure you model in this system, because you want to make sure your model delivers a greater insight value than their current system of, like,
+Lu Nelson (You): spreadsheets and playbooks or whatever, right? So, like, what is the stuff you're looking for and the kinds of— you know, it's basically— it's that— it's that— that's the angle, right? Trying to.
+Yannis Zachos: Can— can I suggest that perhaps we can go through the list? I mean, I don't want to keep Dora on the call if she needs to be somewhere else, but can we just go through the list? I can try to answer things now, and if there's something that I think I need to think— have a think about, we can do that async.
+Yannis Zachos: But let's— I would rather, like, get the— if there's a question, we can just get out of the way now, if you've got time as well, Lu.
+Lu Nelson (You): Okay, well, there are—
+Speaker 4: I'm sorry.
+Lu Nelson (You): The thing is there— there are quite a few. Like, in a way, like, so the first question I had was, like, your— was the one I said earlier, if you're standing in front of the person who's— the person in charge of, like, allocation, scheduling, whatever, and, you know, what are your— what kinds of things do you ask, and what's— what element, like, what's model facet or structural element does this answer feed? Are you— are you trying to establish structure, color, rates, constraints, objectives?
+Lu Nelson (You): Which dependency order would you ask these questions in, i.e., which things are likely to affect— which things— which answers do you want to have upstream of further questions that you want to ask downstream? Which ones are— which sort of effect order are you— are you thinking about in ordering your questions for answers?
+Lu Nelson (You): Which kind of answers do you ask for as numbers, and which ones are you looking for as kind of distributions or as— just as stories or scenarios? And this is also that— leads into that question of, like, when do you ask about bad days, good days, and so on?
+Lu Nelson (You): How do you elicit things that nobody wrote down? Taxonomies, penalty weights, unwritten constraints.
+Lu Nelson (You): What kind of phrasings would you actually use to try to— to try to elicit that from a domain expert? How much of a net do you assemble from recurring structures or recurring motifs, like queues and buffers, resource pools, failure, repair, changeover, inspection, etc., versus inventing fresh things?
+Lu Nelson (You): Like, are there kind of macro patterns that you're looking for that you would want to identify that you could specifically kind of label as a feature of the net, even while you're sort of figuring out where the rest of it would be? If so, could we enumerate that as a catalog?
+Lu Nelson (You): That's a potentially high-leverage question for the— for the question of, like, the agent's strategy, because if— if nets can be built out of repeatable motifs or— or figures or clusters or something, then you— then that's quite— that's something quite strong. Like, or it's like a— it's another level of abstraction that the— that the model can use for mapping things to, aside from just thinking places, transitions, tokens, and token colors, and so on.
+Lu Nelson (You): Like, you could think— you could— it could also look for sort of pattern clusters. Yeah, and, like, how do you understand as you're getting— when you're getting close to being done?
+Lu Nelson (You): Like, what kind of— what sort of set of things is, like, minimal to understanding— to being able to say with any degree of confidence that you can build it? Structure, topology, types, colors, rates, distributions, initial markings, data bindings, other validations.
+Yannis Zachos: Yeah, I mean.
+Lu Nelson (You): You know, so— it goes on and on. Like, there's obviously a lot, right, and we want to try and get it, but— but get the right, yeah, I guess, level of it also for the agent so it's not somehow too massive and overwhelming at the same time.
+Yannis Zachos: Yeah, I mean, I mean, these are all excellent questions, but, I mean, to be honest with you, I just— with regards to elicitation of patterns, what I've just done in the past is just use the AI assistant and just use Claude to help me refine the prompt or reverse engineer the prompt based on— like, literally, the only two things I've done is use the AI assistant in Patreon to generate pattern nets and just follow that line of— so it's not like I've— I mean, these are all
+Yannis Zachos: excellent questions, but I can't say that I'm anywhere near, you know, knowledgeable enough to give sensible answers that you wouldn't otherwise get from— from Claude, really, on this matter. I mean, yeah, I mean, the only different thing I've done once— I tried it at least— was find a paper of a model, of a pseudo-physical model, and put it in Claude and say, "Reverse engineer the prompt for generating a pattern in a version of this model," which it wasn't— the model wasn't a pattern in a model,
+Yannis Zachos: it was a different model. It was like a discrete event simulator or something like that, and I just literally, like, screenshotted it and said to Claude, "Reverse engineer the prompt for generating a pattern for it."
+Lu Nelson (You): Yeah, yeah, yeah.
+Yannis Zachos: So that— these are literally the only two things I've done. I haven't actually— like, even when we went to Clarion, I mean, we didn't actually do any pattern elicitation from them. I mean, we— they talked about a bunch of different stuff that's very domain-specific and, frankly, I didn't even know beforehand.
+Yannis Zachos: So I— I'm afraid I don't have the very, like, refined.
+Lu Nelson (You): Okay. No, that's fine. I mean, that's a— that's a very— that's a useful— it's obviously a useful learning in itself, that sort of— so I think we're still then, therefore, somewhere in the process of figuring out how to— how to orient ourselves and figuring out what exactly we need in order to make this viable.
+Lu Nelson (You): But I think that this is— for me personally, I'm still working out the viability of these things. We've got— we've got a description of things that we want to have for the September MVP, but in the terms by which it's described, yeah, there's a lot of stuff that's unclear to me as to whether we really have the pieces we need to put together for that, or whether we would just be relying on something as basic as just the model.
+Speaker 4: I mean, we definitely have to iterate on this. So I— like, we should build something that we can easily change. And I— I guess, like, in the most basic version, we'd just be doing what the current AI in PetriNorth is doing.
+Speaker 4: Like, even just capturing all the assumptions it's made from, like, a one-shot prompt to build that PetriNet and, like, actually store it as, like, a graph and then, like, build on that. Because, like, isn't— I guess, like, in my head, it's like, are we not just prompting the agent to kind of carry out some elicitation process and be like, "Make sure you capture this, XYZ," but then really it's like, we need to refine that.
+Speaker 4: Like, we're not really in the position to refine that right now completely.
+Lu Nelson (You): Well, how— yeah, no, I agree, we're not. But— but how can we be? Is the question in my mind.
+Lu Nelson (You): For sure, yes, we— we can make something— I mean, we can start with something as simple as possible. We can start with something very broad.
+Lu Nelson (You): And—
+Speaker 4: Yeah.
+Lu Nelson (You): But as such, we're still going to be pretty far away from, like, let's— let's elicit a pseudo-physical model that actually showcases STCPNs. Like, an STCPN pseudo-physical model needs to be—
+Speaker 4: But why can't you do that, like, one shot already?
+Lu Nelson (You): Can you, though? Like, what— what do you—
+Speaker 4: I mean, I can describe— I can describe a process, and it will model it as an STCPN.
+Lu Nelson (You): It will model it as an STCPN, but it won't necessarily showcase STCPNs. Like, out of the current— out of the current things that we have.
+Speaker 4: I— I also don't know if it should always be an STCPN. Sometimes it might be an SPN or a CPN if that is the best way to model something. The goal shouldn't be like, "This needs to be an STCPN."
+Lu Nelson (You): Yeah, many of them— well, that's why I say— that's my point. Many of the use cases I think that we have so far, they don't necessarily need to be— they don't necessarily model as STCPNs. They can be normal-colored PetriNets.
+Lu Nelson (You): Or maybe they're stochastic— maybe they have stochasticity, but the stochasticity, the dynamism, and the coloring, and all the— and, like, all the features out of the— out of the use cases that we've listed or that we've described or listed as things we might want to describe, there's very few that are fully— like, are fully proving out the full capabilities of STCPNs. When you want— when, you know, the description says, "Showcase STCPNs."
+Lu Nelson (You): I'm just pointing it out.
+Speaker 4: Okay.
+Lu Nelson (You): The goal— the goal statement for September said, "Showcase STCPNs." We're— we're poor on things that showcase STCPNs as such. We don't have anything that really strains that, and building that kind of a model is actually pretty— it's a pretty sophisticated thing.
+Lu Nelson (You): I don't know. Maybe— I would— I wouldn't imagine that Claude can do it in one shot, but maybe I'm wrong.
+Lu Nelson (You): Because the amount of description you need in order to qualify what's— what's going in there and why does— how does it work and why does it work that way is more than you can do in one shot, unless you literally have the entire thing pre-described effectively, all you're asking. At that point, you're not— you'd skip elicitation and just say, "Project this as a net" and that's fine, but that's a different task.
+Lu Nelson (You): If we want an elicitor— if we want to showcase an elicitor agent, then we have to actually elicit it.
+Speaker 4: Yeah, I— I understand. I guess what I'm trying to ask is, like, how does this— like, can we build an architecture whereby we can update the way that the elicitor asks these questions easily, rather than committing to something from the get-go?
+Lu Nelson (You): Yes, we can do that. Yeah, we can do that.
+Speaker 4: Cool. Awesome.
+Lu Nelson (You): Okay. All right. I will try to write this up and produce something that maybe will indicate the next questions that we need to figure out.
+Speaker 4: Yeah, cool.
+Yannis Zachos: Cool stuff.
+Lu Nelson (You): All right. Thanks— thanks to both of you.
+Yannis Zachos: Thank you.
+Speaker 4: Bye.
+Yannis Zachos: Thank you, guys. Take care.
+Lu Nelson (You): Bye.
+Speaker 4: Bye.
+Yannis Zachos: Bye-bye.
+Speaker 3: Record.
diff --git a/libs/@hashintel/brunch-agent/docs/spec.md b/libs/@hashintel/brunch-agent/docs/spec.md
new file mode 100644
index 00000000000..26d06ccffec
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/docs/spec.md
@@ -0,0 +1,865 @@
+# Elicitation Kernel — Specification
+
+Status: draft for review
+Assembled: 2026-08-10, from the resolved
+[wayfinder map](history/planning/elicitation-kernel/map.md) (tickets 01–13), the two inbox references
+([challenges](reference/agentic-elicitation-challenges-2026-08-06T10-02-41Z.md),
+[criteria](reference/agentic-elicitation-criteria-2026-08-06T14-11-18Z.md)), and the
+[2026-08-10 consistency pre-pass](history/planning/elicitation-kernel/notes/consistency-prepass-2026-08-10.md).
+Contradiction adjudications are collected in [Appendix A](#appendix-a--adjudications).
+
+"Elicitation kernel" and "brunch-lite" are working labels; the real product name is unresolved
+fog. No architectural string bakes in either label (see [Naming](#123-naming--tool-namespacing)).
+
+---
+
+## 1. Purpose
+
+A standalone architecture that generalizes brunch's elicitor into **agentic interviewing against
+pluggable elicitation targets**: a harness library on the Pi-family substrate (Flue first),
+deployable local and remote, in which an agent conducts a free-flowing interview, emits structured
+question affordances as conversation enhancements, and captures evidence-anchored structured
+meaning into a durable target-document through idempotent sweeps — for any target-domain a plugin
+defines.
+
+The governing design principle (adopted from the challenges doc):
+
+> Capture meaning and evidence before committing to representation. Let semantic requirements and
+> destination requirements both generate issues, but keep their origins explicit.
+
+Greenfield reimplementation: brunch is reference architecture (prior art to critique), never shared
+code. The system is fully decoupled from brunch's September MVP.
+
+## 2. Non-goals and seams
+
+- **Substrate-agnostic core is a non-goal.** Every named consumer is Pi-family. Portability is a
+  _pressure test_, not a build target: the substrate-capability list (§10) and the second-binding
+  test (§14.2) keep a hypothetical second binding demonstrably small, but no second binding is
+  built or maintained.
+- **No privileged downstream consumer.** This is a general elicitation product; the spec names no
+  handoff to any specified tool. Whatever consumes an elicited target-document — human readers,
+  build tooling, another agent — does so through the same read-time derivation surface as any
+  other reader (§6.1, §9.1), and nothing in this spec depends on such a consumer existing. (The
+  map charter's "elicitor→executor seam" was brunch adoption leakage, dropped on review
+  2026-08-10.)
+- **Deferred plugin-ecosystem machinery** (named, not designed): simultaneous multi-plugin
+  composition, plugin removal, full replay, capability negotiation, version/migration machinery.
+  The spec names the five version axes (§12.6) and implements none.
+
+## 3. Vocabulary
+
+The canonical glossary is context [`CONTEXT.md`](../CONTEXT.md) — shells (substrate / ui / harness
+/ plugin / binding), sessions and durability (target-domain / target-document / session / capture
+store / re-entry briefing), and interaction terms (affordance / capture / sweep / settlement /
+interpretation render), now extended with the envelope vocabulary this spec relies on (capture
+envelope, evidence span, epistemic status, absence state, resolution record, supersession, pack,
+issue, advisory, kernel card, PluginContext, storage port).
+
+Two rulings on surviving "kernel" compounds (the glossary otherwise avoids the word):
+
+- **Kernel card** survives as a term of art for the pack-content unit (brunch
+  `BEHAVIORAL_KERNELS.md` lineage — "kernel" there names a small unit of behavioral guidance, not
+  a shell). Added to the glossary with that note.
+- **"Kernel invariants" renames to harness invariants** (§14.1) — they are harness-enforced test
+  properties, and the shell they belong to is the harness.
+
+## 4. Architecture: four shells and a binding
+
+```text
+substrate  (Pi family / Flue: deploy target, model/provider, conversation storage)
+   ↑ implemented against by
+binding    (one per substrate; implements the capability list §10; absorbs what its substrate lacks)
+   ↑ imported by
+harness    (the product: mechanism + orchestration — loop, ask API, envelope, issues, sweeps, store)
+   ↑ injects PluginContext into
+plugin     (target policy: packs, forms, validators, payload shapes)
+                                          ui (rendering, input, reply transport, identity)
+```
+
+- **Agent-forward hybrid**: agent judgment owns the conversation loop; deterministic mechanism
+  ships as tools; typed issues are the backpressure channel. Facts computed, weights judged — the
+  harness computes issue facts (blocks-required-criterion, origin, can-default); the agent weighs
+  them qualitatively. No scoring engine, no stored ranking, no question-budget machinery: the
+  challenges doc's priority formula is prose the agent thinks with, never a computed score.
+- **Inversion of control** (Hollywood principle): the plugin declares and registers; the harness
+  discovers, orders, invokes. Harness capabilities — the ask API, capture envelope, issue queue,
+  sweep bookkeeping — reach the plugin only as a **narrow injected PluginContext**. Composition is
+  the plugin's at authoring time; control flow is the harness's at runtime. Schema ownership
+  follows capability ownership: the shell that defines a capability owns its affordance schemas.
+- The **harness imports no substrate**; a binding imports both. **Plugins depend on core only**
+  (§12.2). The ui renders parts and transports replies; it owns no elicitation semantics.
+
+## 5. The capture envelope
+
+The hourglass waist: harness-defined, domain-free — semantically rich, structurally minimal.
+Everything domain-shaped is opaque plugin payload; the runtime reasons about provenance,
+uncertainty, conflict, completeness, and loss without understanding domains.
+
+A capture carries:
+
+- **`id`** — harness-minted, durable. Distinct from identity-for-deduplication: the **dedup key is
+  content-derived** — evidence spans + payload (or absence state) — with **epistemic status
+  excluded** from the key, so revising the epistemic reading of unchanged evidence requires
+  explicit supersession, never a silent update. Both notions coexist by design (minted id for
+  reference, content key for idempotence).
+- **Evidence spans** — each span is a **quoted excerpt plus a pointer** (session id + entry
+  range). The excerpt is primary at proposal time and is the **model-facing citation currency**;
+  the pointer is **derived by the harness**, which alone can see the entry projection
+  (harness-resolved anchoring, §8.2). The stored capture carries **both**: quote-to-entry
+  resolution happens exactly once, at sweep application; every later reader navigates by pointer
+  into the session-log archive (§9.6), never by text search. Spans anchor only on true user and user-affordance-payload
+  entries (§9.4); `defaulted` / `external-lookup` captures cite a declared default or documented
+  transformation instead of a user span (Appendix A, C5).
+- **Epistemic status** — `explicit | inferred | tentative | defaulted | external-lookup`. Distinct
+  from confidence. (This is the one legal enum; ticket 10's prototype value `stated` was drift.)
+- **Confidence** — qualitative, never a scalar-for-everything.
+- **Value XOR absence state** — exactly one. Absence states are first-class capture values (§5.1).
+- **Alternatives grouping** — more than one live interpretation of the same evidence may coexist
+  until explicitly resolved.
+- **One `supersedes` link** — creation-time, single-hop, active-heads-only (§8.4).
+- **Opaque plugin-typed payload.** No harness edges, no graph, no kind taxonomy — structure is
+  payload business. Conflict and equivalence are typed issues referencing capture ids, not edges.
+
+**No stored status field.** Envelope status (`active | superseded | retracted`) is **derived at
+read time** from supersession links, resolution records, and retraction events. This is one
+instance of the general rule:
+
+> **No status is ever written; every status is computed at read time from stored captures, issues,
+> and events.** Three strata: **envelope status** (harness-computed from links and events),
+> **completion status** (harness-computed by running plugin-declared criteria), and **domain
+> labels** (plugin-computed by stratified derivation over its own payload graph, §13.3 — invoked
+> via `project` at read time under cadence-as-policy, §6.4).
+
+**Retraction** (adjudicated — no prior ticket specified it): a retraction is an explicit stored
+event in the same family as resolution records — it must cite the true user's utterance as
+evidence and names no successor capture. Derived envelope status then reads `retracted`. There is
+no other path to `retracted`.
+
+### 5.1 Absence states
+
+`unknown-to-user | not-yet-decided | not-applicable | explicitly-absent | declined | deferred` as
+capture values, plus `not-mentioned` as a **computed fact only** (adjudicated): captures require
+evidence spans, and "not mentioned" has no utterance to anchor to — it is output of completion
+evaluation and plugin `validate`, never a sweepable capture.
+
+Distinctions that must not collapse:
+
+- `not-yet-decided` — the user states the decision has not been made (a fact about the world).
+- `deferred` — the user postpones answering (a fact about the interview).
+- `explicitly-absent` ("we have no deadline") ≠ `unknown-to-user` ("I don't know the deadline").
+- `declined` ≠ `deferred` (amended on review 2026-08-11): a decline is a **boundary** — re-asking
+  is an interviewing error, and the gap closes only through an explicit act (a declared default,
+  or a descoped requirement); a deferral is an **invitation** — re-raising it later is correct
+  interviewing, and completion evaluation chases it (§8.6). Collapsing them makes the agent
+  either nag someone who refused or forget someone who said "later".
+
+The absence strip's three labels map: **don't-know → `unknown-to-user`**, **not-applicable →
+`not-applicable`**, **decide-later → `deferred`**.
+
+This enum is a working set, validated only against the milestone-one targets. Fine epistemic
+distinctions have a record of arriving late and mattering (brunch took real time to separate the
+character of an _assumption_ from a _known-unknown_), so extension pressure is expected rather
+than a design failure — absence states are envelope vocabulary, so an extension is a
+concept-schema-axis change (§12.6), cheap while the ecosystem is workspace-internal. Naming new
+states for behavioral activation (the way "fog of war" carries a whole stance in one image) is
+kernel-card-grade work: pick words the agent can _act_ from, not taxonomy for its own sake.
+
+**Explicit vs. inferred absence is a transport fact** (adjudicated, C4): inbound reply transport is
+string-only, and a bare string cannot distinguish a one-tap `not-applicable` from typed prose. The
+harness therefore defines a **reserved reply encoding** — a sentinel-format string the ui emits
+for structured affordance taps (absence-strip taps, choice selections). A reply parsing as that
+encoding, arriving while its affordance occupies the pending-affordance slot, is
+transport-explicit; every other reply is conversational, and absences read from it carry
+`epistemic_status: inferred`. Structured taps are an **optional ui capability, not a
+requirement**: no ui is obliged to afford single-tap buttons at all — the contract says only that
+_if_ a ui affords them, tap-ness rides the encoding. A ui that only affords the markdown floor
+never produces the encoding and honestly yields inferred-only absences. Tap-ness must be a
+transport fact to earn `explicit`; nothing else may claim it.
+
+## 6. Operations, validation strata, issues
+
+### 6.1 Plugin operations
+
+- **Required**: `project` (captures → draft artifact + **typed loss report**: `mapped-exactly /
+normalized / approximate / collapsed / omitted / defaulted / unrepresentable`) and `validate`
+  (→ typed issues). `project` also computes the plugin's domain labels (§13.3) — read-time
+  derivation is projection. (The operation keeps the canon name `project`; in running prose this
+  spec prefers the noun — "produce a projection" — because the verb collides with everyday
+  senses.)
+- **Optional**: `reconcile` — dedup/merge over the plugin's own payload structure; the harness
+  calls it when present.
+- **Agent-native**: `observe` — noticing is the agent's work, guided by pack kernel cards;
+  code-level extractors are an optimization, never the required path.
+- **Calling convention — pure, snapshot-in/deltas-out** (adjudicated, C2): every operation
+  receives an **immutable state snapshot** and returns observations/issues/deltas; the harness
+  validates and applies. Operations never address storage, the user, or the model. This purity is
+  load-bearing: it buys atomic plugin failure, semantically idempotent retries, tracing, and the
+  cadence-as-policy freedom in §6.4. Ticket 12's clause "storage addressable only via
+  PluginContext-passed methods" is scoped to **non-operation plugin code**; milestone one defines
+  **no** storage-addressable PluginContext methods at all, and any future ones must be read-only
+  and unavailable inside the four operations.
+- **Backpressure**: validators and projectors never ask the user; they return typed issues the
+  agent consumes.
+
+### 6.2 Two validation strata
+
+- **Envelope-level, harness-owned**: hard invariants enforced as **refusals** (provenance
+  required; value-xor-absence; single-hop supersession over active heads; citations resolve to
+  true user entries) plus computed facts raised as **advisories** or generic `possibly-equivalent`
+  issues (same-evidence duplicate actives; near-identical payload text — the harness compares
+  payloads as strings without understanding them). A flat-record plugin gets duplicate detection
+  free, strengthening the smallest-honest-plugin bar.
+- **Payload-level, plugin-owned** (`validate` / `reconcile`): everything domain-shaped. Two live
+  examples from the ticket-13 skeleton that the envelope _cannot_ catch, both plugin-`validate`
+  territory: a payload **smuggling an absence** (`payload: "not-yet-decided"` as a value), and
+  **compound payloads making supersession lossy** (a capture bundling date+time superseded by one
+  carrying date+venue silently drops the time — capture granularity is plugin `validate` /
+  kernel-card guidance).
+
+### 6.3 Issues vs. advisories
+
+- An **issue** is stored, typed backpressure: vocabulary `missing / ambiguous / conflicting /
+invalid / unsupported / unmapped / low-confidence` plus factual attributes (origin, references,
+  can-default). Issues close only explicitly; `conflicting` closes **only** via a resolution
+  record (§8.5). Two producers, **namespaced to their producer** (harness envelope issues vs.
+  plugin issues under their plugin/target-domain namespace) — restating criteria-doc invariant 6:
+  a target-originated requirement never silently becomes a semantic requirement.
+- An **advisory** is a **computed, ephemeral fact** — surfaced to the agent at trigger or read
+  time, never stored in the capture store, never blocking (adjudicated, L6). Named advisories:
+  the unaccounted-ask advisory (§8.6), the resume-time unswept-tail advisory (§8.7), the
+  world-moved briefing content (§9.3), multi-match anchoring notes (§8.2).
+
+### 6.4 Operation cadence is orchestration policy
+
+Snapshot purity means the harness may run `project` / `validate` / `reconcile` at any time without
+changing outcomes. **Sweep-completion is the default trigger**; read-time invocation (for
+projections, derived labels, completion) is equally legal. Cadence is stated harness policy, not
+correctness — observed live in ticket 13, where the model swept at reply time without waiting for
+a nudge, harmlessly.
+
+## 7. Questioning-UX contract
+
+### 7.1 No exchange-pair ontology
+
+The free-flowing conversation is primary. A structured question is an **affordance** — a rendered
+enhancement committed to the session as evidence, not a state machine. There is no pending-exchange
+concept, no terminal union, no recovery scan, no cardinality rule beyond §7.3. Ask invocations
+commit structured payloads to the session; answers, cancellations, and redirects are all session
+evidence, interpreted at sweep time.
+
+### 7.2 Baseline forms and the markdown floor
+
+The harness fixes three baseline question shapes — free-text, single-choice, multi-choice — plus
+**questionnaire chaining** as a first-class baseline. A questionnaire is **one affordance with
+multiple steps**: the payload carries all N questions, the ui walks them locally, answers return
+as evidence (individually or batched), the agent interprets on settlement — zero intermediate
+model turns. Plugins add custom forms through the plugin API as progressive enhancement keyed on
+the form tag; every form carries a **markdown floor** so a ui that knows only the envelope renders
+everything. Plugin form payloads are **opaque at the tool boundary** (`v.any()` slot inside typed
+envelope fields) and validated harness-side against plugin declarations on read-back — tool
+schemas are frozen at module load, so per-render plugin parameterization is impossible by
+construction.
+
+### 7.3 One live affordance (adjudicated, C6)
+
+Transport truth from the ticket-10 skeleton: writes to the fixed data channel materialize
+last-write-wins per assistant message — the channel is a **current-affordance surface**, not a
+log. Therefore:
+
+- **Durable identity and payload for every affordance ride the ask tool's output part** (Flue
+  blesses tool output parts for exactly this). The channel write is live-render sugar for the one
+  pending interactive affordance.
+- **The ask tool rejects a second interactive affordance in the same batch — as mechanism, not
+  instruction.** The one-live-affordance rule is per assistant message.
+- Non-interactive affordances (the interpretation render, §7.6) ride their own tool output parts
+  and never occupy the channel slot, so an ask plus an interpretation render in one batch cannot
+  clobber each other.
+
+### 7.4 Turn suspension, reply binding, and the wake wart (adjudicated, C7)
+
+Flue has no ask-the-user primitive; the harness owns the turn-suspension protocol: a
+`terminate: true` ask tool + the pending affordance in per-session state + the answer arriving as
+a fresh dispatch.
+
+The pending question is **not interpolated into instructions**. Ticket 10's interpolation caused
+the wake wart (an "instructions updated" advisory waking the model for a wasted turn per ask) and
+ticket 13 showed those hidden advisories also corrupt entry numbering. Instead:
+
+- The pending affordance lives in the **pending-affordance slot** (per-session state, §9.2) and is
+  narrated inside the **ask tool's result**, so the model retains conversational awareness through
+  ordinary context adjacency.
+- **Reply binding is harness-mechanical**: at most one affordance is pending (§7.3), so a reply
+  dispatch arriving while the slot is occupied is bound to that affordance by the harness. No echo
+  token, and no reliance on the model remembering an id — consistent with harness-resolved
+  anchoring (§8.2). The model's _interpretation_ of the reply happens at sweep time, citing the
+  quoted reply text.
+- Judgment prompts must never be the model's only source of mechanical facts (ticket 13): any
+  fact the harness owns (pending affordance, unswept tail) reaches the model through tool results
+  or signals, not only through instruction text.
+
+### 7.5 Transport outcomes (adjudicated, L9)
+
+Interpretation evidence records a small transport-outcome vocabulary, distinct from epistemic
+absence: **`answered | redirected | unanswered`**. `redirected` covers cancellation-by-topic-change
+(observed working in ticket 10); `unanswered` is an ask still unaccounted when its range settles
+(pairing with the unaccounted-ask advisory, §8.6). Brunch's `unavailable` is retired: the markdown
+floor guarantees a render path everywhere.
+
+### 7.6 Interpretation render
+
+The one affordance form that must be harness-owned, since it renders envelope vocabulary: captures
+with epistemic status, absence states, live alternatives, derived statuses. The plugin **may**
+supply a renderer definition typed against its own payload shapes; the harness default is a plain
+JSON view (smallest-honest-plugin holds). React vs. accept are two capture semantics, not exchange
+steps. The renderer seam is exercised once real packs exist (§14.5).
+
+### 7.7 Recorded transport facts (Flue)
+
+Outbound rich (Valibot-validated data parts, dynamic-tool outputs); **inbound string-only** —
+answer typing/validation happens entirely harness-side on read-back (hence §5.1's reply
+encoding); unknown part types silently dropped (hence the markdown floor); data-part
+materialization is update-in-place at every layer, intermediate values visible live only. Messages
+carry `purpose` and `display`; **the ui must filter on them** (injected signals arrive
+`display: 'diagnostic'`). Mixed batches suspend correctly when the terminating result is present.
+
+## 8. Capture mechanics: settlement, sweep, supersession
+
+### 8.1 Settlement: trigger and judgment
+
+Settlement is **agent-judged and range-level** (a vein closing), never per-question. It decomposes:
+
+- **Trigger** — the substrate's would-stop lifecycle seam (capability 7, §10). The harness
+  computes facts (the unswept tail) and steers a settlement-check signal into a same-response
+  continuation turn. Two load-bearing guards from ticket 13: the seam **fires on suspensions
+  too**, so the pending-affordance guard must suppress nudges into a suspended ask turn; and the
+  nudge is itself a session entry, so the trigger is **loop-guarded** (never re-nudge the same
+  latest user entry).
+- **Judgment** — the agent decides _whether_ the range has settled; declining is legal.
+
+### 8.2 Harness-resolved evidence anchoring
+
+Entry identity is **harness-side vocabulary only**. The model cites **verbatim user quotes**; the
+harness — the only party that can see the entry projection — resolves each quote to its entry:
+candidates are true-user entries only; no match refuses with a repair hint; multiple matches
+anchor the latest with an advisory note. Sequence numbers and range bounds never appear in the
+model-facing tool contract. (Ticket 13, HITL round 1: the model's quotes were flawless and its
+sequence guesses never converged — five sweeps, five numberings.)
+
+### 8.3 Sweep idempotence
+
+Mechanical idempotence is the harness guarantee, via content-keyed capture identity (§5):
+re-sweeping a range never double-captures **and can repair omissions** — identity is
+content-based, not range-based. This is **load-bearing, not optional**, under at-least-once tool
+re-execution (Flue fact, ticket 13). Semantic re-interpretation (a fresh judgment re-phrasing the
+same fact) is deliberately not a harness concern: that is plugin `reconcile` plus
+`possibly-equivalent` issues.
+
+### 8.4 Supersession: single-hop, two channels
+
+Supersession is single-hop over **active heads only** — superseding an already-superseded capture
+is refused. That refusal is simultaneously the lost-update guard and the stale-session guard
+(§9.2): a corrector must confront the current head, so history stays a chain, never a silently
+forking tree. Superseded captures remain visible forever.
+
+**Two supersession channels**, named: the creation-time `supersedes` **link** (sweep-time
+correction) and the **resolution record** (issue-time adjudication between already-existing
+alternatives). The winning capture keeps its original epistemic status; authority lives in the
+record; envelope status derives at read time (§5).
+
+### 8.5 Resolution records
+
+A `conflicting` issue closes **only** via an explicit resolution record — a capture-store event
+citing the true user's utterance as evidence. A bare close is refused; a record citing the agent's
+words is refused. This is the "no silent conflict resolution" invariant moved from wire to store.
+
+### 8.6 Unaccounted-ask advisory
+
+A swept range containing an ask with no reply and no capture citing it makes the harness report
+the fact — and block nothing. The re-ask path runs through plugin `validate` → typed issues, with
+completion evaluation as the backstop for unresolved deferrals on required concepts. Absences are
+evidence, not agenda.
+
+### 8.7 Resume-time sweep reconciliation
+
+A session ending between settlement judgment and sweep leaves an unswept tail — a computable fact
+(entries above the high-water mark). On resume the harness surfaces it as an advisory (inside the
+re-entry briefing, §9.3) and the agent judges whether to sweep before proceeding.
+
+## 9. Sessions, durability, and the storage port
+
+### 9.1 Durable target-document, transient sessions, sweep as the only bridge
+
+- **Target-document** = one target-domain + its capture store + its session history. Its
+  authoritative state is **the capture store plus all session logs — never the render**.
+  Projections, renders, and artifacts are strictly derived: cacheable, disposable. Session logs
+  are durable truth too: discarding swept logs would dead-end every capture's evidence pointers.
+  **Conversations are themselves documents** (amended on review 2026-08-11): each session log is
+  kept as reference, indefinitely, and lives **with** the target-document in the same persistence
+  home — the storage port's session-log archive (§9.6) — so evidence pointers resolve against
+  the target-document's own store, never against whatever the substrate happens to retain.
+- **Session** = one substrate conversation. Sessions **never formally close** — they go quiet and
+  stay resumable; "ended" would be a fiction the harness cannot verify.
+- **Session→document binding** (adjudicated, L4): a new session's `initialData` carries the
+  target-document id (validated once at creation, immutable — Flue's own lane for a target
+  descriptor). Dispatching to an existing conversation id resumes that session against the current
+  state of its target-document; a new id opens a new session against the named document. Plugin
+  choice is conversation-lifetime-immutable for the same reason.
+
+### 9.2 Per-session state and concurrency
+
+Strictly per-session state is **exactly three things**: the evidence log, the swept high-water
+mark, the pending-affordance slot. (The private scratchpad is _not_ session state — pattern
+guidance only; its natural Flue home is the `harness.prompt` scratch conversation, §11.4.)
+
+Concurrency is **interleaved-only** for milestone one: the store is serialized (sweeps validate
+and apply atomically — a transactional guarantee, not a session lock); staleness is optimistic —
+the single-hop supersession refusal doubles as the stale-session guard, and the refusal carries
+the world-moved facts. Refusal granularity is **whole-sweep atomic**; re-proposing is cheap once
+the advisory is digested. No locking, no merge, no sync events; true simultaneous-sweep
+coordination stays fog until a real concurrent consumer appears.
+
+### 9.3 Re-entry briefing
+
+When a session resumes after the world moved, the harness injects a **state message** on the
+user's behalf (Pi's custom-entry convention; on Flue, a typed `kind: 'signal'` entry). Content is
+computed facts only: unswept tail, world-moved delta (captures created/superseded and issues
+opened/closed since this session's last sweep; anchor = session start if it never swept), open
+issues, pending unanswered affordance. Advisory-only — the agent weighs; nothing is forced. A
+**minimal user-visible insertion notice** accompanies every injected state message. Ticket 13
+proved the briefing in all three shapes (fresh, resumed, post-restart) and observed it produce
+unscripted conversational conflict-surfacing.
+
+### 9.4 Provenance: only the true user's side is evidence
+
+The data model **distinguishes true user entries from injected on-behalf-of-user entries**.
+Capture evidence spans anchor only on true user (and user-affordance-payload) entries; injected
+briefings live in the log honestly but are **never citable as capture evidence** — and on Flue
+this is mechanically enforced, since signals appear structurally non-user in the entry projection
+(a capture citing an injected entry is refused at validation). Reconciliation with harness invariant 1 (Appendix A,
+C5): user-derived captures cite user entries; `defaulted` / `external-lookup` captures cite a
+declared default or documented transformation instead.
+
+### 9.5 Completion is derived, never a gate
+
+A target-document has no lock and no terminal state: completion-contract satisfaction is a
+read-time derived status (§5's derived-status family). A user returning with a correction after
+"done" is the motivating story. Semantic completeness and representation completeness remain
+separate assessments; each issue records its origin.
+
+### 9.6 The storage port (adjudicated, C1)
+
+**The storage port is harness-defined and binding-implemented; plugins are storage-blind.** The
+harness defines the port's contract (the capture-store operations and their envelope invariants,
+enforced as store-level refusals); the binding implements it for its deploy target; the plugin
+never touches persistence. Reconciliation with the shipping-shape's "host-owned storage": the
+substrate's _conversation_ storage (Flue's `db.ts`) stays host-authored because Flue requires it
+of the consuming app; the harness's _capture store_ is the storage port, implemented in
+`packages/binding-flue` (and any future binding). The remote-parity constraint reads accordingly: the
+storage port is owned **outside the plugin** (§12.5).
+
+**The port's scope is the capture store plus the session-log archive** (amended on review
+2026-08-11): session logs attached to a target-document live with it, retained indefinitely.
+The mechanism is **archive-on-read** — whenever the binding reads the durable entry projection
+(every sweep, every briefing computation), it retains the entries it read in the
+target-document store. At minimum, every entry a capture points to must be retrievable from the
+archive forever; the substrate's conversation store remains the live transport copy, never the
+provenance record.
+
+**Milestone-one local store**: binding-owned; the format is binding-internal **but constrained** —
+it must provide whole-sweep-atomic application and refusals with serialized writes (adjudicated,
+L13; a flat append-only text file does not qualify unaided). The ticket-13 skeleton's shape (JSON
+file, tmp+rename atomic, in-process serialization) is the proven floor; it holds the session-log
+archive alongside captures, issues, and events.
+
+### 9.7 Context compaction vs. the durable log
+
+Pi-family substrates compact long transcripts, with custom compaction definitions controlling
+which entry kinds survive in the context the model re-reads — ordinary user and agent messages
+are normally summarized away. This never touches the spec's durability claims, **provided one
+constraint holds, stated here as part of the storage contract**:
+
+- **Compaction may shrink what the model re-reads, never what the store can resolve.** Evidence
+  pointers and the sweep machinery bind to the **durable entry projection** (capability 8, §10),
+  not to the model's context window. A binding must guarantee the durable projection is
+  compaction-independent; a substrate whose compaction prunes durable history is a substrate whose
+  binding must preserve the pruned entries itself (binding absorption, as with capability 10).
+  The session-log archive (§9.6) is that preservation mechanism, already in place: compaction
+  cannot remove anything the archive holds.
+- Two existing mechanisms already cushion the model-side loss: **excerpt-primary evidence spans**
+  (§5) keep every capture citable and self-contained even where durable access degrades, and the
+  **re-entry briefing** (§9.3) already treats "the model no longer remembers" as a normal state —
+  a compacted session is informationally a resumed one. Per-session harness state (high-water
+  mark, pending-affordance slot) lives outside the transcript and cannot be compacted away.
+- If a binding supplies a compaction definition, injected signals and affordance tool parts need
+  no protected status: briefings are recomputable facts and affordance identity is durable on
+  tool output parts — only true user entries are irreplaceable, and the archive holds those.
+
+Whether Flue's compaction (if and as it ships one) preserves the durable-history projection
+unmodified is **unverified** — named in §14.5.
+
+## 10. The substrate-capability list
+
+The core/binding seam, the portability pressure test, and the early-smell detector: porting =
+reimplementing this list; exotic Flue-shaped entries appearing here is the smell. **Ten entries**
+(six from the shipping-shape resolution, four added by the sweep-seam skeleton):
+
+| #   | Capability                                                                              | Flue status                                                                                                           |
+| --- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| 1   | Register a tool                                                                         | native (`defineTool`/`useTool`)                                                                                       |
+| 2   | Contribute instructions                                                                 | native (render return)                                                                                                |
+| 3   | Persist per-conversation state                                                          | native (`usePersistentState`, atomic with its unit of work)                                                           |
+| 4   | Emit an affordance payload                                                              | native (data channel + tool output parts)                                                                             |
+| 5   | Suspend-for-reply                                                                       | **absorbed**: no ask primitive; `terminate: true` + pending slot + fresh dispatch (§7.4)                              |
+| 6   | Private model call                                                                      | native (`harness.prompt` scratch conversation)                                                                        |
+| 7   | Subscribe to the would-stop lifecycle seam, with same-response signal steering          | native (`useAgentFinish` + `ctx.append`; fires on suspensions — pending guard load-bearing; loop-guarded)             |
+| 8   | Read the session's durable entry projection, with provenance-discriminating entry kinds | **binding-absorbed**: no in-process API; public history projection over self-HTTP; `purpose` discriminates provenance |
+| 9   | Inject typed non-user signal entries, same-response and as deliveries                   | native (`ctx.append` / `dispatch({kind:'signal'})`; projects structurally non-user)                                   |
+| 10  | Provide a transactional durable store outside conversation state                        | **binding-absorbed** entirely (Flue neither provides nor forbids)                                                     |
+
+Binding-size asymmetry is expected, not failure: each binding absorbs what its substrate lacks or
+forbids. Core names operations abstractly; the binding renders substrate tool names.
+
+**Recorded Flue facts the implementation must respect**: `@flue/vite` requires vite ^8 and the
+`'use agent'` directive as the file's first statement; `agentName` must be a string literal and
+must be pinned (conversation storage keys on it); the dev controller owns the whole request space,
+so the ui is a separate app or app-served assets; tool schemas are Valibot, frozen at module load;
+tool names are globally unique per render with reserved names; prompt-cache economics forbid
+per-question tool swapping (one stable tool set + state-driven instructions); subagents are
+conversationally sterile; non-React hosts build on `@flue/sdk`; without `db.ts` conversations are
+process-memory (restart loses them; the capture store survives independently — proven, ticket 13).
+
+## 11. Plugins and packs
+
+### 11.1 What a plugin owns
+
+Target policy only: its **own payload structure** (graph, flat list — never universal; namespaced
+concepts); **ElicitationPack** — kernel cards (Detects / Goal / contrastive Questions /
+Artifacts), completion contract, clarification hints; **ProjectionPack(s)** — `project` +
+`validate` (required), `reconcile` (optional), output contract, annotated shapes, typed loss
+reports, lossiness policy; its declared payload/output _shape_ (never persistence itself, §9.6);
+domain vocabulary. One ElicitationPack + N ProjectionPacks per plugin sharing the plugin's payload
+structure — axes separated in contract, bundled in shipping; swappability proven by reprojection.
+
+### 11.2 Pack form and Principle v2
+
+Packs are kernel cards + annotated shapes + deterministic validators + small boundary-teaching
+wire schemas (shallow for model legibility, deep requiredness in validators) + a completion
+contract as checkable bounds. Authoring standard: `writing-for-agents`; guiding principle
+(**Principle v2**): _procedure for mechanism, anchors for judgment, shapes for output_ — short
+step sequences with checkable completion criteria where order matters, leading words wherever
+judgment is required, annotated shapes for everything produced, reference disclosed progressively.
+Design against sprawl, negation-steering, no-ops, and judgment-as-procedure — not against
+procedure itself.
+
+### 11.3 The smallest honest plugin
+
+A flat record list + one validator must suffice; every harness-contract addition is checked
+against the bar it raises. The envelope stratum gives such a plugin refusals and duplicate
+detection for free (§6.2); what it cannot delegate is exactly the payload stratum — the two live
+examples in §6.2 are its irreducible work.
+
+### 11.4 Pattern guidance (inherited from brunch, as patterns not mechanism)
+
+Comment-vs-message provenance discipline; boundary-teaching schemas; hash-pinned, ablatable prompt
+directives (a load-bearing prompt paragraph as a versioned, testable artifact); a private,
+non-authoritative scratchpad for "noticed, not yet asked" — **not** harness session state; on Flue
+its natural home is the `harness.prompt` private scratch conversation; "react to this" separate
+from "accept this"; agenda as derived state, never stored.
+
+### 11.5 Generic strategy cards (named, not designed)
+
+Some interviewing technique is target-independent. Socratic pressure on premises, contrastive
+cases that separate competing interpretations, stress-testing the weak points of an argument —
+these operate on vocabulary the **harness** owns (conflicts, alternatives, ambiguity, weak or
+missing evidence, absence clusters), not on any plugin's domain. By the same rule that governs
+schemas ("the shell that defines a capability owns its affordance schemas", §4), **guidance
+ownership follows vocabulary ownership**: cards that teach _what to notice in a domain_ are
+plugin pack content; cards that teach _how to work an interview situation the envelope can name_
+may ship with the harness as a **generic strategy quiver**, composed by plugins at authoring
+time exactly as packs compose (added on review 2026-08-11).
+
+Named, not designed: milestone one ships all guidance in plugin packs. Reference shapes for the
+quiver when it graduates: brunch's `ln-grill` (relentless Socratic interviewing — question
+premises, surface constraints, name anti-patterns) and `ln-disambiguate` (generate contrastive
+cases where plausible interpretations diverge and have the person classify them, instead of
+asking abstract questions), plus brunch's `elicitation_style: interrogate | disambiguate |
+propose` trichotomy, which the exchange-schema audit already classed generic. The assurance
+target is the worked example of the split: its technique decomposes into a generic
+stress-the-argument strategy card plus the plugin's domain cards (§13.2).
+
+## 12. Shipping shape
+
+### 12.1 Root
+
+The product is the **harness library** in a thin host-authored agent. Every host authors its own
+~10-line `'use agent'` module, `app.ts` mount, and `db.ts`, and calls `useElicitation(plugin)`.
+A runnable reference app ships alongside as the dev/demo vehicle, not the product. (Flue's
+build-time scan makes the alternative structurally unavailable: a library cannot ship a
+pre-registered agent.)
+
+### 12.2 Package topology (intended structure; nothing scaffolded during the map)
+
+Bun-workspace monorepo in this repo:
+
+```text
+packages/core              # the harness; plugin SDK is its public export surface
+packages/core/testing      # (subpath) fixtures, arbitraries, replay driver — prod bundles stay clean
+packages/binding-flue      # the Flue binding (implements §10; owns the storage port impl)
+packages/transport-aisdk   # validated UI ingress + harness replies → AI SDK wire; no binding/substrate imports
+packages/plugin-gherkin
+packages/plugin-assurance  # renamed 2026-08-10 from plugin-proof-obligations (§13.2)
+apps/dev                   # owns 'use agent' module, app.ts, db.ts, Vite build
+```
+
+**FE-1437 import amendment (2026-08-20):** the repository topology above is the standalone
+prototype record. In `hashintel/hash`, the same boundaries become private native workspaces:
+`@hashintel/brunch-agent`, `@hashintel/brunch-agent-binding-flue`,
+`@hashintel/brunch-agent-transport-aisdk`, and `@hashintel/brunch-agent-plugin-gherkin`, with
+`apps/dev` re-chartered as `apps/brunch-agent`. HASH's Yarn/Turbo workspace replaces the Bun root;
+it does not wrap or flatten these package boundaries.
+
+**FE-1437 context-root amendment (2026-08-21):** the four libraries are child workspaces under
+`libs/@hashintel/brunch-agent/packages/{core,binding-flue,transport-aisdk,plugin-gherkin}`.
+`libs/@hashintel/brunch-agent/` is their shared domain, documentation, and agent-session root, not
+a package-manager root: it carries no package manifest, lockfile, or competing toolchain.
+`apps/brunch-agent` remains at HASH's application root and points back to that context authority.
+
+**Dependency invariants (spec invariants):** plugins depend on `core` only — never on the binding,
+never on Flue; the harness imports no substrate; a binding imports both. A transport consumes
+harness-level reply parts plus its wire encoder and ingress validator only: `transport-aisdk`
+depends on `core`, `ai`, and `valibot`, never on a binding or Flue. **Role prefixes name what a
+package is architecturally**: plugin
+packages are `plugin-*` (never `elicit-*`), binding packages are `binding-*`, and ui reply-wire
+packages are `transport-*` — the glossary's own nouns, where `adapter-*`/`wrapper-*` are
+avoided terms (amended on review 2026-08-10 and FE-1436; ticket 06 had bare `packages/flue` and a
+`<substrate>-<name>` horizon scheme — the product name belongs in the npm scope, e.g.
+`@<name>/binding-flue`, not the package basename). Envisioned horizon, named not committed:
+per-substrate binding packages (`binding-flue`, `binding-pi`, `binding-codex`) — the payoff if
+the second-binding test keeps passing. **Publishing posture: workspace-internal**; the publishable
+shape is exactly the package boundaries above, but publishing waits on the real name and an
+external consumer.
+
+**FE-1437 naming amendment (2026-08-20):** HASH's organizational npm scope owns placement, so
+`brunch-agent` moves into the package basename as shown in §12.2. ADR-0001's `brunch_*` tool prefix,
+durable agent identity, and ban on function-shaped `elicit_*` names remain unchanged.
+
+### 12.3 Naming & tool namespacing
+
+Architectural strings name **identity, not function**: tool prefix derived from the product name —
+provisionally `bl_*`, never `elicit_*`. All model-facing tools are harness-owned (plugins expose
+operations, not tools); core names operations abstractly, the binding renders substrate tool
+names. The name-fog eventually resolves every provisional string; nothing bakes "elicit" or
+"brunch" into structure.
+
+### 12.4 Schemas and the SDK
+
+**Valibot throughout** — Flue locks it at every boundary; a Standard-Schema waist would buy
+comfort at the cost of a conversion seam that can silently drop constraints (the silent-coercion
+smell). SDK surface (core's exports): evidence anchoring, capture identity, issue construction,
+schema validation, retries, idempotency, state-delta application, tracing, test fixtures, the
+local simulation harness ("debugging should not require reading an entire agent transcript"), plus
+the testing machinery of §14.4 (schema-driven arbitraries, the command alphabet, mutation
+operators, fixture freeze/replay format).
+
+### 12.5 Dev app, deploy, remote parity
+
+- **Dev app chartered with three roles** (roles, not features): the local dev loop against both
+  plugins; the colleague-facing **target-gallery demo** (parallel tabbed sessions across targets);
+  the **diagnostic probe surface** (provisional affordance renderers now; the exploded-view
+  instrumented readout when that fog graduates). One agent per target (`ElicitGherkin`,
+  `ElicitAssurance`): static per-agent tool sets, and the shape Cloudflare forces anyway.
+- **UI affordance package deferred**, named as intended: React renderers over `@flue/react`;
+  non-React UIs build on `@flue/sdk`. The Petrinaut staging instead uses the committed
+  `transport-aisdk` server wire, without introducing a second renderer. Milestone one keeps
+  renderers in the dev app.
+- **Milestone one is local-only**, with **remote-parity constraints pinned now** so nothing
+  local-only creeps in: one-agent-many-conversations; pinned `agentName`; the storage port owned
+  outside the plugin (harness-defined, binding-implemented, §9.6); no dynamic agent creation.
+  Deploy-target choice waits on an infra conversation and blocks nothing here.
+- **CI smoke** = `vite build` + the simulation suite (no model key, no flake); an optional
+  secret-gated real-model `flue run` smoke once a provider key exists.
+
+**FE-1437 application amendment (2026-08-20):** the imported `apps/brunch-agent` adds the remote
+server role while carrying forward the local-loop, target-gallery, and diagnostic-surface charter.
+`apps/petrinaut-website` is the September user-facing application; there is no dedicated demo shell.
+The harness remains deploy-target-neutral, and deployment, authentication, and environment policy
+remain application concerns.
+
+**FE-1437 application-seam amendment (2026-08-21):** `apps/petrinaut-website` is the compile-time
+Brunch–Petrinaut meeting point. `apps/brunch-agent` remains Petrinaut-independent and communicates
+with the website only through the AI SDK/HTTP transport.
+
+### 12.6 Version axes (named, none implemented)
+
+API contract / plugin implementation / concept-schema / target-schema / persisted state. A change
+to a field's meaning is not a serializer change; the future migration story must be able to decide
+reuse / mechanical migration / reinterpretation-from-evidence / re-elicit.
+
+## 13. Dev targets and milestone one
+
+**Portfolio**: `plugin-gherkin` (tracer) + `plugin-assurance` (second target; forces the pack swap
+and the evidence-graded envelope); BPMN/process-mining named third; full elicit-lean deferred.
+**Hybrid order**: **both packs are authored before the pack interface freezes** (the two-targets-
+on-each-axis rule, applied at design time — the trivial target must not freeze the contract before
+the hard target has stressed it); **gherkin wires end-to-end first** as the cheap mechanism proof,
+assurance immediately after.
+
+### 13.1 Gherkin (milestone one)
+
+Validation = parse validity + optional **pack-declared step-lexicon** binding check (a step
+lexicon is pack policy, needing no external project). Live-codebase step binding is the target's
+named growth path, deferred.
+
+### 13.2 The assurance argument
+
+The second target elicits an **assurance argument** — GSN's own noun; "proof obligations" is a
+machine-generated-VC term of art and reads as a category error to verification readers (the
+2026-08-10 rename; package `plugin-assurance`). Canon alignment: **GSN skeleton, Dafny nouns,
+Lean sorry-taint semantics**.
+
+Milestone-one contract (one record type):
+
+- **`Statement`** with `kind` ∈ {`goal`, `strategy`, `assumption`, `lemma`, `theorem`,
+  `guarantee`, `constraint`, `evidence`, `justification`, `context`}; `statement` (one indicative
+  sentence); `owner`; `review_status` ∈ {`unreviewed`, `accepted`, `disputed`, `retired`}
+  (assumptions only, from `dafny audit`); `criticality` ∈ {`catastrophic`, `major`, `minor`} —
+  **sourced from safety engineering (DAL/SIL/ASIL), not Dafny or Lean, and the pack says so**;
+  `evidence_refs[]`; `developed: bool` (GSN Undeveloped). Transcript provenance lives in the
+  capture envelope, never duplicated inside the payload (the hidden-target-leakage smell).
+- **Four edge kinds**: `supports` (GSN SupportedBy, inferential), `evidenced_by` (SupportedBy,
+  evidential), `requires` (Dafny precondition), `in_context_of` (GSN InContextOf; scoping only —
+  the first three are load-bearing for status).
+
+### 13.3 Derived labels, the ledger, and the validator's honest stance
+
+- **Five-stratum status derivation** (plugin-computed, via `project` at read time): S0
+  `refuted`/`open` facts → S1 `BROKEN` (positive recursion) → S2 `WEAK` (undeveloped or
+  unevidenced) → S3 `CONDITIONAL` (reachable open assumption — Lean's sorry-taint) → S4 `PROVED`.
+  Negation only looks at lower strata; the validator enforces that stratification **and
+  acyclicity of the three load-bearing edge kinds**. Per-claim status is a **derived UI label**,
+  never headline.
+- **The headline artifact is the assumption ledger** — every `open` assumption with owner, review
+  status, and which guarantees it taints — shipped as a Markdown table, after `dafny audit`.
+- **Acyclicity is recorded as a deliberate restriction** (trivially decidable validation, legible
+  failures), with `decreases` — a well-foundedness witness — named as the future escape hatch.
+- **The Datalog closure is sold as well-formedness and taint propagation, never an assurance
+  verdict.** The ui never says "proved" unqualified — a GSN structure is a human argument; borrow
+  Alloy's stance: this finds defects, it does not certify. (Lineage note: cite coherent-logic
+  saturation — Datalog as its ∃-free, ⋁-free fragment — never "ARIA's Geolog", which does not
+  exist.)
+
+## 14. Acceptance material
+
+### 14.1 The ten harness invariants (restated in envelope vocabulary; enforced as test properties)
+
+1. **No value without provenance.** Every projected value traces to a capture (with evidence
+   spans), a declared default, or a documented transformation.
+2. **No silent conflict resolution.** Contradictory active captures resolve only via an explicit
+   resolution record or supersession event.
+3. **No silent projection loss.** Relevant active captures that cannot be represented appear in
+   the typed loss report.
+4. **Corrections don't erase history.** Superseded captures remain inspectable and never active.
+5. **Retries are semantically idempotent.** A retried operation or re-swept range never creates a
+   second user assertion (content-keyed capture identity).
+6. **Issues are namespaced to their producer.** A plugin/target-domain requirement never silently
+   becomes a harness-level requirement; harness envelope issues are namespaced to the harness.
+7. **Plugin failures are atomic.** A failed operation leaves no partially applied deltas; sweeps
+   apply whole or refuse whole.
+8. **Equivalent state produces equivalent projection.** Projection is a function of the
+   capture-store snapshot, never of discovery order.
+9. **Unknown remains distinct from false.** Absence states never collapse to null or negation.
+10. **Explicit remains distinct from inferred and defaulted.** Epistemic status never collapses.
+
+### 14.2 The five proof obligations (contract acceptance criteria)
+
+Independent variability · semantic conservation · explicit transformation · controlled elicitation
+· local implementation — judged as in the criteria doc, against the hourglass. Companion tests:
+**smallest-honest-plugin** (every contract addition checked against the bar it raises) and its
+sibling the **second-binding test** (every time mechanism wants to land in the binding: "genuinely
+substrate-specific, or mechanism leaking into Flue's dialect?").
+
+### 14.3 Gating tests and review vocabulary
+
+Gating: **reprojection / projector substitution** (capture once, project into materially different
+targets, verify agreement); **minimal pairs** ("the budget is / might be €20,000"); **black-box
+authoring** (public SDK + docs to a developer who hasn't read core; count concepts, boilerplate,
+escape hatches). Review vocabulary (named smells): opaque payload waist, giant context bag,
+schema-shaped questioning, null collapse, silent coercion/loss, correction-as-duplication, hidden
+target leakage.
+
+### 14.4 Testing strategy
+
+**Generation-first fixtures over a deterministic replay driver**; HASH routes the Brunch workspace
+tests through Turbo and Vitest — no model, no substrate. Hand-written fixtures are seeds; the corpus
+is generated:
+
+- Properties come from the **harness contract** — the ten invariants above are literally
+  properties; generators come from the **plugin's declarations**, never its implementation
+  (`arbitraryFromSchema`: Valibot → fast-check arbitraries), plus negative-space properties for
+  plugin code (validators total — never throw, always typed issues; `project` never emits an
+  undeclared loss category).
+- Where dynamics are the subject: **model-based command-sequence testing** (`fc.commands`) over
+  the envelope-derived alphabet — utter · settle-range · sweep · correct · contradict ·
+  reply-with-absence · redirect.
+- Language realism: a **model as offline generator, never CI oracle** — a model plays respondent
+  against the plugin's own kernel cards, varied by persona/curveball, plus a mutation library
+  generalizing minimal pairs (epistemic-status flips, absence injections, supersession
+  injections). Outputs freeze as replayable fixtures; **regenerate when declarations change**.
+- Shrunk counterexamples are minimal pathological conversations: pinned as regressions and read
+  first as type-design feedback on envelope/payload types.
+
+### 14.5 Open verification items (named, with homes)
+
+- **Interpretation-render plugin-renderer seam** — exercised once real packs exist (milestone-one
+  build, both plugins).
+- **Restart durability of the full stack** — the capture store survives restart (proven, ticket
+  13); conversation-store durability with a real `db.ts` is untested (milestone-one dev app).
+- **Wake-wart residue** — §7.4's no-interpolation ruling removes the cause observed in ticket 10;
+  confirm no other instruction-state write path re-triggers advisory wakes (milestone-one binding).
+- **History-projection paging** (>1000 entries) and binding base-URL discovery — binding
+  implementation details flagged by ticket 13.
+- **Compaction vs. durable history** (§9.7) — verify that Pi/Flue compaction leaves the durable
+  entry projection unmodified (or scope what the binding must preserve itself); no prototype has
+  driven a session across a compaction boundary (milestone-one binding).
+
+---
+
+## Appendix A — Adjudications
+
+The seven contradictions from the consistency pre-pass, and how this spec resolved each:
+
+- **C1 — storage port implementer.** Binding-implemented, harness-defined, plugin-blind (ticket 12
+  authoritative on ownership). Reconciliation: Flue's `db.ts` (substrate conversation storage)
+  stays host-authored because Flue requires it of the consuming app; the harness's capture store
+  is the storage port, implemented in the binding. §9.6, §12.5. Ticket 04's ownership-table "Host"
+  row reads: input surfaces/identity → ui; deploy target, model/provider, artifact delivery →
+  substrate; storage-port implementation → binding (pre-pass S5).
+- **C2 — operation purity vs. PluginContext storage methods.** The four operations stay pure
+  (snapshot-in/deltas-out); tickets 04+11 win — cadence-as-policy is load-bearing. Ticket 12's
+  clause is scoped to non-operation plugin code; milestone one defines no storage-addressable
+  PluginContext methods. §6.1.
+- **C3 — capture status.** Derived at read time, never stored (ticket 12 authoritative); the
+  envelope drops the `status` field. Retraction — previously unrecorded — is specified as an
+  explicit user-cited event with no successor. §5.
+- **C4 — explicit vs. inferred absence over string-only transport.** Ticket 10's transport finding
+  is the physical constraint: tap-ness must be a transport fact. The harness defines a reserved
+  reply encoding for structured taps; replies outside it yield inferred absences only. §5.1.
+- **C5 — provenance rule vs. invariant 1.** Both survive, reconciled: user-derived captures cite
+  true user entries only; `defaulted` / `external-lookup` captures cite a declared default or a
+  documented transformation. The enum keeps all five values. §5, §9.4, §14.1(1).
+- **C6 — one channel vs. one live affordance.** Ticket 10 authoritative on mechanism: the channel
+  is a per-message current-affordance surface; durable identity/payload ride tool output parts;
+  the reject-second rule covers interactive affordances per batch; non-interactive renders ride
+  tool parts and never contend for the slot. §7.3.
+- **C7 — wake wart and reply binding, picked together.** No instruction interpolation (removes the
+  wart's cause and the numbering corruption); the pending question rides the ask tool's result and
+  the pending-affordance slot; reply binding is harness-mechanical via the single-pending
+  invariant — stronger than either ticket-10 option, and consistent with ticket 13's
+  harness-resolved anchoring. No echo token. §7.4.
+
+Assembler adjudications beyond the seven (each flagged inline): retraction semantics (§5);
+`not-mentioned` as computed fact, absence-label mapping, and the `not-yet-decided` / `deferred`
+distinction (§5.1); advisories as computed-ephemeral vs. stored issues (§6.3); issue namespacing
+(§6.3); domain-label derivation inside `project` (§6.1, §13.3); transport-outcome vocabulary
+(§7.5); session→document binding via `initialData` (§9.1); milestone-one store format constraint
+(§9.6); kernel-card / harness-invariants naming (§3).
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/LICENSE.md b/libs/@hashintel/brunch-agent/packages/binding-flue/LICENSE.md
new file mode 100644
index 00000000000..c7d627721e2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/LICENSE.md
@@ -0,0 +1,607 @@
+GNU Affero General Public License
+=================================
+
+_Version 3, 19 November 2007_
+_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+## Preamble
+
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+Developers that use our General Public Licenses protect your rights
+with two steps: **(1)** assert copyright on the software, and **(2)** offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+The precise terms and conditions for copying, distribution and
+modification follow.
+
+## TERMS AND CONDITIONS
+
+### 0. Definitions
+
+“This License” refers to version 3 of the GNU Affero General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as “you”.  “Licensees” and
+“recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a “modified version” of the
+earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based
+on the Program.
+
+To “propagate” a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices”
+to the extent that it includes a convenient and prominently visible
+feature that **(1)** displays an appropriate copyright notice, and **(2)**
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+### 1. Source Code
+
+The “source code” for a work means the preferred form of the work
+for making modifications to it.  “Object code” means any non-source
+form of a work.
+
+A “Standard Interface” means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other
+than the work as a whole, that **(a)** is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and **(b)** serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+“Major Component”, in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+The Corresponding Source for a work in source code form is that
+same work.
+
+### 2. Basic Permissions
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+### 3. Protecting Users' Legal Rights From Anti-Circumvention Law
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+### 4. Conveying Verbatim Copies
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+### 5. Conveying Modified Source Versions
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+* **a)** The work must carry prominent notices stating that you modified
+it, and giving a relevant date.
+* **b)** The work must carry prominent notices stating that it is
+released under this License and any conditions added under section 7.
+This requirement modifies the requirement in section 4 to
+“keep intact all notices”.
+* **c)** You must license the entire work, as a whole, under this
+License to anyone who comes into possession of a copy.  This
+License will therefore apply, along with any applicable section 7
+additional terms, to the whole of the work, and all its parts,
+regardless of how they are packaged.  This License gives no
+permission to license the work in any other way, but it does not
+invalidate such permission if you have separately received it.
+* **d)** If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your
+work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+“aggregate” if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+### 6. Conveying Non-Source Forms
+
+You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+* **a)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium
+customarily used for software interchange.
+* **b)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a
+written offer, valid for at least three years and valid for as
+long as you offer spare parts or customer support for that product
+model, to give anyone who possesses the object code either **(1)** a
+copy of the Corresponding Source for all the software in the
+product that is covered by this License, on a durable physical
+medium customarily used for software interchange, for a price no
+more than your reasonable cost of physically performing this
+conveying of source, or **(2)** access to copy the
+Corresponding Source from a network server at no charge.
+* **c)** Convey individual copies of the object code with a copy of the
+written offer to provide the Corresponding Source.  This
+alternative is allowed only occasionally and noncommercially, and
+only if you received the object code with such an offer, in accord
+with subsection 6b.
+* **d)** Convey the object code by offering access from a designated
+place (gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to
+copy the object code is a network server, the Corresponding Source
+may be on a different server (operated by you or a third party)
+that supports equivalent copying facilities, provided you maintain
+clear directions next to the object code saying where to find the
+Corresponding Source.  Regardless of what server hosts the
+Corresponding Source, you remain obligated to ensure that it is
+available for as long as needed to satisfy these requirements.
+* **e)** Convey the object code using peer-to-peer transmission, provided
+you inform other peers where the object code and Corresponding
+Source of the work are being offered to the general public at no
+charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A “User Product” is either **(1)** a “consumer product”, which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or **(2)** anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, “normally used” refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+### 7. Additional Terms
+
+“Additional permissions” are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+* **a)** Disclaiming warranty or limiting liability differently from the
+terms of sections 15 and 16 of this License; or
+* **b)** Requiring preservation of specified reasonable legal notices or
+author attributions in that material or in the Appropriate Legal
+Notices displayed by works containing it; or
+* **c)** Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+* **d)** Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+* **e)** Declining to grant rights under trademark law for use of some
+trade names, trademarks, or service marks; or
+* **f)** Requiring indemnification of licensors and authors of that
+material by anyone who conveys the material (or modified versions of
+it) with contractual assumptions of liability to the recipient, for
+any liability that these contractual assumptions directly impose on
+those licensors and authors.
+
+All other non-permissive additional terms are considered “further
+restrictions” within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+### 8. Termination
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated **(a)**
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and **(b)** permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+### 9. Acceptance Not Required for Having Copies
+
+You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+### 10. Automatic Licensing of Downstream Recipients
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+### 11. Patents
+
+A “contributor” is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, “control” includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To “grant” such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either **(1)** cause the Corresponding Source to be so
+available, or **(2)** arrange to deprive yourself of the benefit of the
+patent license for this particular work, or **(3)** arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  “Knowingly relying” means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is “discriminatory” if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license **(a)** in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or **(b)** primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+### 12. No Surrender of Others' Freedom
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+### 13. Remote Network Interaction; Use with the GNU General Public License
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+### 14. Revised Versions of this License
+
+The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License “or any later version” applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+### 15. Disclaimer of Warranty
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+### 16. Limitation of Liability
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+### 17. Interpretation of Sections 15 and 16
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/package.json b/libs/@hashintel/brunch-agent/packages/binding-flue/package.json
new file mode 100644
index 00000000000..44cdc5a27c5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/package.json
@@ -0,0 +1,35 @@
+{
+  "name": "@hashintel/brunch-agent-binding-flue",
+  "version": "0.0.0-private",
+  "private": true,
+  "description": "The Flue binding: implements the substrate-capability list and owns the storage-port implementation.",
+  "license": "AGPL-3.0",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "import": "./dist/index.js"
+    }
+  },
+  "scripts": {
+    "build": "vite build",
+    "fix:eslint": "oxlint --fix --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:eslint": "oxlint --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:tsc": "tsgo --noEmit",
+    "test:unit": "vitest run"
+  },
+  "dependencies": {
+    "@flue/runtime": "2.0.3",
+    "@flue/sdk": "2.0.3",
+    "@hashintel/brunch-agent": "workspace:*",
+    "valibot": "1.4.2"
+  },
+  "devDependencies": {
+    "@types/node": "22.18.13",
+    "@typescript/native-preview": "7.0.0-dev.20260511.1",
+    "oxlint": "1.63.0",
+    "oxlint-tsgolint": "0.22.1",
+    "vite": "8.1.0",
+    "vitest": "4.1.10"
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/archive-capability.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/archive-capability.ts
new file mode 100644
index 00000000000..a0908512def
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/archive-capability.ts
@@ -0,0 +1,26 @@
+import type { CaptureStore } from "@hashintel/brunch-agent";
+import type { SessionLogRead } from "@hashintel/brunch-agent/storage";
+
+type ArchiveWriter = (read: SessionLogRead) => Promise<void>;
+
+const archiveWriters = new WeakMap<CaptureStore, ArchiveWriter>();
+
+export const registerArchiveWriter = (
+  store: CaptureStore,
+  writer: ArchiveWriter,
+): void => {
+  archiveWriters.set(store, writer);
+};
+
+export const archiveThroughBinding = async (
+  store: CaptureStore,
+  read: SessionLogRead,
+): Promise<void> => {
+  const writer = archiveWriters.get(store);
+  if (!writer) {
+    throw new TypeError(
+      "The supplied capture store has no binding-owned session-log writer.",
+    );
+  }
+  await writer(read);
+};
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/capabilities.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/capabilities.ts
new file mode 100644
index 00000000000..22f829593fa
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/capabilities.ts
@@ -0,0 +1,96 @@
+/**
+ * The substrate-capability list (spec §10), recorded as data.
+ *
+ * This is the core/binding seam, the portability pressure test, and the early
+ * smell detector all at once: porting means reimplementing this list, and
+ * exotic Flue-shaped entries appearing in it is the smell. Keeping it as a
+ * checkable record rather than prose is what lets the second-binding test
+ * (spec §14.2) be asked of every future addition — "genuinely
+ * substrate-specific, or mechanism leaking into Flue's dialect?"
+ *
+ * Binding-size asymmetry is expected, not failure: each binding absorbs what
+ * its substrate lacks or forbids.
+ */
+
+/** How a binding satisfies one capability. */
+export type Provision =
+  /** The substrate offers it directly. */
+  | "native"
+  /** The substrate lacks or forbids it; the binding supplies it itself. */
+  | "absorbed";
+
+export interface Capability {
+  readonly id: number;
+  readonly name: string;
+  readonly provision: Provision;
+  /** How this binding satisfies it, in Flue's dialect. */
+  readonly mechanism: string;
+}
+
+export const CAPABILITIES: readonly Capability[] = [
+  {
+    id: 1,
+    name: "Register a tool",
+    provision: "native",
+    mechanism: "defineTool / useTool",
+  },
+  {
+    id: 2,
+    name: "Contribute instructions",
+    provision: "native",
+    mechanism: "render return",
+  },
+  {
+    id: 3,
+    name: "Persist per-conversation state",
+    provision: "native",
+    mechanism: "usePersistentState, atomic with its unit of work",
+  },
+  {
+    id: 4,
+    name: "Emit an affordance payload",
+    provision: "native",
+    mechanism: "data channel + tool output parts",
+  },
+  {
+    id: 5,
+    name: "Suspend for reply",
+    provision: "absorbed",
+    mechanism:
+      "no ask primitive: terminate:true + pending-affordance slot + fresh dispatch",
+  },
+  {
+    id: 6,
+    name: "Private model call",
+    provision: "native",
+    mechanism: "harness.prompt scratch conversation",
+  },
+  {
+    id: 7,
+    name: "Subscribe to the would-stop lifecycle seam",
+    provision: "native",
+    mechanism:
+      "useAgentFinish + ctx.append; fires on suspensions, so the pending guard is load-bearing; loop-guarded",
+  },
+  {
+    id: 8,
+    name: "Read the durable entry projection with provenance-discriminating entry kinds",
+    provision: "absorbed",
+    mechanism:
+      "public materialized history snapshot over a host-injected conversation URL/transport; `role`/`purpose` discriminate provenance; no raw entry ranges",
+  },
+  {
+    id: 9,
+    name: "Inject typed non-user signal entries",
+    provision: "native",
+    mechanism:
+      "ctx.append / dispatch({kind:'signal'}); projects structurally non-user",
+  },
+  {
+    id: 10,
+    name: "Provide a transactional durable store outside conversation state",
+    provision: "absorbed",
+    mechanism:
+      "Flue neither provides nor forbids; the binding owns the storage-port implementation",
+  },
+];
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/capture-accounting.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/capture-accounting.ts
new file mode 100644
index 00000000000..a12e6400489
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/capture-accounting.ts
@@ -0,0 +1,29 @@
+import type {
+  CaptureStore,
+  CaptureStoreSnapshot,
+} from "@hashintel/brunch-agent";
+
+/**
+ * Recover only active-session Flue entry identities from already anchored
+ * captures. The archive pointer's host-session identity is part of the key;
+ * bare substrate ids are not globally unique across conversations.
+ */
+export const capturedUserEntryIdsForSession = async (
+  store: Pick<CaptureStore, "readArchivedEntries">,
+  snapshot: CaptureStoreSnapshot,
+  sessionId: string,
+): Promise<ReadonlySet<string>> => {
+  const entryIds = new Set<string>();
+  for (const capture of snapshot.captures) {
+    if (!("evidence" in capture)) continue;
+    for (const evidence of capture.evidence) {
+      if (evidence.pointer.sessionId !== sessionId) continue;
+      for (const entry of await store.readArchivedEntries(evidence.pointer)) {
+        if (entry.versions.at(-1)?.kind === "user-affordance-payload") {
+          entryIds.add(entry.substrateEntryId);
+        }
+      }
+    }
+  }
+  return entryIds;
+};
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/history-reader.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/history-reader.ts
new file mode 100644
index 00000000000..d6f55351792
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/history-reader.ts
@@ -0,0 +1,211 @@
+import {
+  createFlueClient,
+  type FlueConversationMessage,
+  type FlueConversationSnapshot,
+} from "@flue/sdk";
+
+import {
+  toolName,
+  type CaptureStore,
+  type JsonValue,
+  type SessionEntryKind,
+  type SweepAffordance,
+  type SweepResultFact,
+  type SweepSessionEntry,
+} from "@hashintel/brunch-agent";
+
+import { archiveThroughBinding } from "./archive-capability";
+
+import type { SessionLogRead } from "@hashintel/brunch-agent/storage";
+
+export interface FlueHistoryReaderOptions {
+  /** Host-owned full conversation URL; the binding never guesses the mount. */
+  readonly resolveConversationUrl: (sessionId: string) => string;
+  /** Host-owned transport, including in-process router.fetch adapters. */
+  readonly transport: typeof fetch;
+  readonly archive: CaptureStore;
+}
+
+export interface FlueHistoryReader {
+  /** Read the live public projection without mutating the target archive. */
+  peek(sessionId: string): Promise<FlueConversationSnapshot>;
+  /** Refresh the binding-private archive from the live public projection. */
+  read(sessionId: string): Promise<FlueConversationSnapshot>;
+}
+
+const materializedJson = (value: unknown): JsonValue =>
+  JSON.parse(JSON.stringify(value)) as JsonValue;
+
+const messageText = (message: FlueConversationMessage): string =>
+  message.parts
+    .filter(
+      (part): part is Extract<typeof part, { type: "text" }> =>
+        part.type === "text",
+    )
+    .map((part) => part.text)
+    .join("");
+
+const affordanceFrom = (value: unknown): SweepAffordance | undefined => {
+  if (
+    typeof value !== "object" ||
+    value === null ||
+    !("id" in value) ||
+    !("markdown" in value)
+  ) {
+    return undefined;
+  }
+  return typeof value.id === "string" &&
+    value.id.length > 0 &&
+    typeof value.markdown === "string" &&
+    value.markdown.length > 0
+    ? { id: value.id, markdown: value.markdown }
+    : undefined;
+};
+
+const sweepResultFrom = (value: unknown): SweepResultFact | undefined => {
+  if (typeof value !== "object" || value === null || !("status" in value))
+    return undefined;
+  if (value.status === "applied" || value.status === "no-settled-range") {
+    return { status: value.status };
+  }
+  if (
+    value.status !== "refused" ||
+    !("refusal" in value) ||
+    typeof value.refusal !== "object" ||
+    value.refusal === null ||
+    !("code" in value.refusal) ||
+    typeof value.refusal.code !== "string" ||
+    !("message" in value.refusal) ||
+    typeof value.refusal.message !== "string"
+  ) {
+    return undefined;
+  }
+  return {
+    status: "refused",
+    refusal: { code: value.refusal.code, message: value.refusal.message },
+  };
+};
+
+export const projectFlueHistoryForSweep = (
+  snapshot: Pick<FlueConversationSnapshot, "messages">,
+): readonly SweepSessionEntry[] => {
+  const { messages } = snapshot;
+  const emittedAffordanceIds = new Set<string>();
+  const affordancesByMessageId = new Map<string, SweepAffordance[]>();
+  for (const message of messages) {
+    const affordances: SweepAffordance[] = [];
+    for (const part of message.parts) {
+      const affordance =
+        part.type === "data-affordance"
+          ? affordanceFrom(part.data)
+          : part.type === "dynamic-tool" && part.state === "output-available"
+            ? affordanceFrom(part.output)
+            : undefined;
+      if (affordance && !emittedAffordanceIds.has(affordance.id)) {
+        emittedAffordanceIds.add(affordance.id);
+        affordances.push(affordance);
+      }
+    }
+    if (affordances.length > 0)
+      affordancesByMessageId.set(message.id, affordances);
+  }
+  const replyAffordanceByMessageId = new Map<string, string>();
+  for (let index = 1; index < messages.length; index += 1) {
+    const message = messages[index]!;
+    const previous = messages[index - 1]!;
+    const affordanceId = message.signal?.attributes?.affordanceId;
+    if (
+      message.role === "system" &&
+      message.purpose === "dispatch" &&
+      message.signal?.tagName === "affordance-reply-bound" &&
+      typeof affordanceId === "string" &&
+      emittedAffordanceIds.has(affordanceId) &&
+      previous.role === "user" &&
+      previous.purpose === "user"
+    ) {
+      replyAffordanceByMessageId.set(previous.id, affordanceId);
+    }
+  }
+
+  return messages.map((message) => {
+    let kind: SessionEntryKind;
+    if (message.role === "user" && message.purpose === "user") {
+      kind = replyAffordanceByMessageId.has(message.id)
+        ? "user-affordance-payload"
+        : "user";
+    } else if (
+      message.role === "assistant" &&
+      message.purpose === "assistant"
+    ) {
+      kind = "assistant";
+    } else {
+      kind = "non-user";
+    }
+    const affordances = affordancesByMessageId.get(message.id);
+    const replyToAffordanceId = replyAffordanceByMessageId.get(message.id);
+    const sweepResult = message.parts.reduce<SweepResultFact | undefined>(
+      (latest, part) => {
+        if (
+          part.type !== "dynamic-tool" ||
+          part.toolName !== toolName("sweep") ||
+          part.state !== "output-available"
+        ) {
+          return latest;
+        }
+        return sweepResultFrom(part.output) ?? latest;
+      },
+      undefined,
+    );
+    return {
+      id: message.id,
+      kind,
+      text: messageText(message),
+      ...(affordances === undefined ? {} : { affordances }),
+      ...(replyToAffordanceId === undefined ? {} : { replyToAffordanceId }),
+      ...(sweepResult === undefined ? {} : { sweepResult }),
+      ...(message.signal?.tagName === "sweep-repair"
+        ? { sweepRepairSignal: true as const }
+        : {}),
+    };
+  });
+};
+
+const classifyMessages = (
+  snapshot: FlueConversationSnapshot,
+): readonly SessionLogRead["entries"][number][] =>
+  projectFlueHistoryForSweep(snapshot).map((entry, index) => ({
+    substrateEntryId: entry.id,
+    kind: entry.kind,
+    text: entry.text,
+    materialized: materializedJson(snapshot.messages[index]!),
+  }));
+
+export const createFlueHistoryReader = (
+  options: FlueHistoryReaderOptions,
+): FlueHistoryReader => {
+  const peek = async (sessionId: string): Promise<FlueConversationSnapshot> => {
+    const client = createFlueClient({
+      url: options.resolveConversationUrl(sessionId),
+      fetch: options.transport,
+    });
+    return client.history();
+  };
+
+  return {
+    peek,
+    async read(sessionId) {
+      const snapshot = await peek(sessionId);
+      await archiveThroughBinding(options.archive, {
+        sessionId,
+        substrateConversationId: snapshot.conversationId,
+        offset: snapshot.offset,
+        ...(snapshot.incarnation === undefined
+          ? {}
+          : { incarnation: snapshot.incarnation }),
+        entries: classifyMessages(snapshot),
+        settlements: snapshot.settlements.map(materializedJson),
+      });
+      return snapshot;
+    },
+  };
+};
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/index.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/index.ts
new file mode 100644
index 00000000000..715684db65b
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/index.ts
@@ -0,0 +1,263 @@
+/**
+ * `@hashintel/brunch-agent-binding-flue` — the Flue binding.
+ *
+ * One binding per substrate. It implements the substrate-capability list
+ * (spec §10), owns the local capture-store/session-log storage-port
+ * implementation (spec §9.6), and is the
+ * only shell allowed to know Flue's dialect: **the harness imports no
+ * substrate; a binding imports both** (spec §4).
+ *
+ * Every time mechanism wants to land in here, the second-binding test applies
+ * (spec §14.2): genuinely substrate-specific, or mechanism leaking into Flue's
+ * dialect?
+ */
+
+import {
+  useAgentFinish,
+  useAgentStart,
+  useDataWriter,
+  useDelivery,
+  usePersistentState,
+  useTool,
+} from "@flue/runtime";
+import * as v from "valibot";
+
+import {
+  ASK_TOOL_DESCRIPTION,
+  AskInput,
+  FreeTextAffordance,
+  advanceSweepHighWater,
+  askProtocolInstructionFragments,
+  buildSettlementCheckSignal,
+  buildReplyBindingSignalPayload,
+  buildSweepExtractionPrompt,
+  buildSweepRepairSignal,
+  computeUnaccountedAskAdvisories,
+  createSweepExtractionResultSchema,
+  createInitialSweepState,
+  decidePendingAffordance,
+  decideSettlementTrigger,
+  mintAskAffordance,
+  parseSweepState,
+  pendingSweepRepair,
+  reopenSweepAfterRefusal,
+  settlementProtocolInstructionFragments,
+  sweepableRange,
+  toolName,
+  type CaptureStore,
+  type FreeTextAffordanceValue,
+  type Plugin,
+  type SweepState,
+} from "@hashintel/brunch-agent";
+
+import { capturedUserEntryIdsForSession } from "./capture-accounting";
+import {
+  projectFlueHistoryForSweep,
+  type FlueHistoryReader,
+} from "./history-reader";
+
+const SweepToolOutput = v.looseObject({
+  status: v.picklist(["no-settled-range", "refused", "applied"]),
+});
+
+export { CAPABILITIES, type Capability, type Provision } from "./capabilities";
+export {
+  createFlueHistoryReader,
+  projectFlueHistoryForSweep,
+  type FlueHistoryReaderOptions,
+} from "./history-reader";
+export {
+  createFlueReplyProjector,
+  type FlueReplyProjector,
+  type FlueReplyProjectorOptions,
+} from "./reply-projector";
+export { createLocalCaptureStore } from "./local-capture-store";
+
+export interface ElicitationSession {
+  readonly sessionId: string;
+  readonly captureStore: CaptureStore;
+  readonly historyReader: FlueHistoryReader;
+}
+
+/**
+ * Mount the elicitation harness in a Flue agent.
+ *
+ * Flue has no ask-the-user primitive, so the harness owns the turn-suspension
+ * protocol: a `terminate: true` ask tool, the pending affordance in
+ * per-session state, and the answer arriving as a fresh dispatch (spec §7.4).
+ */
+export function useElicitation(
+  plugin: Plugin,
+  session: ElicitationSession,
+): string {
+  const delivery = useDelivery();
+  const [pending, setPending] =
+    usePersistentState<FreeTextAffordanceValue | null>(
+      "pendingAffordance",
+      null,
+    );
+  const [storedSweepState, setSweepState] = usePersistentState<SweepState>(
+    "sweepHighWater",
+    createInitialSweepState(),
+  );
+  let pendingAtFinish = pending;
+  let sweepState = parseSweepState(storedSweepState);
+  const extractionResult = createSweepExtractionResultSchema(plugin);
+  const writeAffordance = useDataWriter("affordance", {
+    schema: FreeTextAffordance,
+  });
+
+  useAgentStart((ctx) => {
+    if (delivery.kind !== "user" || pending === null) return;
+
+    pendingAtFinish = null;
+    setPending(null);
+    ctx.append({ kind: "signal", ...buildReplyBindingSignalPayload(pending) });
+  });
+
+  useTool({
+    name: toolName("ask"),
+    description: ASK_TOOL_DESCRIPTION,
+    input: AskInput,
+    output: FreeTextAffordance,
+    run({ data, toolCallId }) {
+      const affordance = mintAskAffordance(data.question, toolCallId);
+
+      setPending((current) => {
+        const decision = decidePendingAffordance(current, affordance);
+        if (!decision.ok) throw new Error(decision.reason);
+        pendingAtFinish = decision.pending;
+        return decision.pending;
+      });
+      writeAffordance(affordance);
+
+      return { output: affordance, terminate: true };
+    },
+  });
+
+  useTool({
+    name: toolName("sweep"),
+    description:
+      "Apply or replay the settled conversation prefix. The harness privately extracts quote-anchored captures, refreshes durable history immediately before atomic application, and advances sweep state only on success.",
+    input: v.strictObject({}),
+    output: SweepToolOutput,
+    harness: true,
+    durable: true,
+    async run({ harness, signal, step }) {
+      const historyAtJudgment = await step.do("read-settled-range", async () =>
+        projectFlueHistoryForSweep(
+          await session.historyReader.peek(session.sessionId),
+        ),
+      );
+      const range = sweepableRange(historyAtJudgment);
+      const throughUserEntryId = range.at(-1)?.id;
+      if (!throughUserEntryId) {
+        return { output: { status: "no-settled-range" as const } };
+      }
+
+      const extraction = await step.do(
+        "extract-sweep-proposals",
+        async () =>
+          (
+            await harness.prompt(
+              buildSweepExtractionPrompt(
+                {
+                  targetDomain: plugin.targetDomain,
+                  proposalNames: plugin.proposalCatalog.map(
+                    (proposal) => proposal.name,
+                  ),
+                },
+                range,
+              ),
+              { result: extractionResult, signal },
+            )
+          ).data,
+      );
+
+      // This read is intentionally adjacent to application: its binding-owned
+      // archive write makes every quote resolvable before the store sees it.
+      await step.do("refresh-history-before-apply", async () =>
+        projectFlueHistoryForSweep(
+          await session.historyReader.read(session.sessionId),
+        ),
+      );
+      const applied = await step.do("apply-sweep", () =>
+        session.captureStore.execute(
+          {
+            type: "apply-sweep",
+            // The plugin schema narrows the existing envelope here; the store
+            // repeats envelope validation and owns anchoring at apply.
+            proposals: extraction.proposals,
+          },
+          { sessionId: session.sessionId },
+        ),
+      );
+      if (!applied.ok) {
+        sweepState = reopenSweepAfterRefusal(sweepState);
+        setSweepState(sweepState);
+        return {
+          output: { status: "refused" as const, refusal: applied.refusal },
+        };
+      }
+
+      sweepState = advanceSweepHighWater(sweepState, throughUserEntryId);
+      setSweepState(sweepState);
+      const accountedEntryIds = await capturedUserEntryIdsForSession(
+        session.captureStore,
+        applied.snapshot,
+        session.sessionId,
+      );
+      return {
+        output: {
+          status: "applied" as const,
+          appliedCaptureIds:
+            "appliedCaptureIds" in applied.value
+              ? applied.value.appliedCaptureIds
+              : [],
+          skippedDedupKeys:
+            "skippedDedupKeys" in applied.value
+              ? applied.value.skippedDedupKeys
+              : [],
+          advisories: [
+            ...("advisories" in applied.value ? applied.value.advisories : []),
+            ...computeUnaccountedAskAdvisories(range, accountedEntryIds),
+          ],
+        },
+      };
+    },
+  });
+
+  useAgentFinish(async (ctx) => {
+    // useAgentFinish also fires on terminate:true asks. The callback's local
+    // view is updated by ask/reply callbacks in this render, so it observes the
+    // live slot rather than the render-time persistent-state snapshot.
+    if (pendingAtFinish !== null) return;
+
+    const entries = projectFlueHistoryForSweep(
+      await session.historyReader.peek(session.sessionId),
+    );
+    const repair = pendingSweepRepair(entries);
+    if (repair) {
+      ctx.append({ kind: "signal", ...buildSweepRepairSignal(repair) });
+      return;
+    }
+    const decision = decideSettlementTrigger({
+      entries,
+      state: sweepState,
+      pendingAffordance: false,
+    });
+    if (decision.action !== "nudge") return;
+
+    sweepState = decision.nextState;
+    setSweepState(sweepState);
+    ctx.append({
+      kind: "signal",
+      ...buildSettlementCheckSignal(decision.tail),
+    });
+  });
+
+  return [
+    ...askProtocolInstructionFragments(plugin.targetDomain),
+    ...settlementProtocolInstructionFragments(),
+  ].join("\n\n");
+}
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/local-capture-store.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/local-capture-store.ts
new file mode 100644
index 00000000000..4e947830fc8
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/local-capture-store.ts
@@ -0,0 +1,197 @@
+import { randomUUID } from "node:crypto";
+import { mkdir, readFile, rename, rm, writeFile } from "node:fs/promises";
+import { dirname, resolve } from "node:path";
+
+import {
+  applyCaptureStoreCommand,
+  createEmptyCaptureStoreSnapshot,
+  parseCaptureStoreSnapshot,
+  type ArchivedSessionEntry,
+  type CaptureStore,
+  type CaptureStoreCommand,
+  type CaptureStoreEvidenceContext,
+  type CaptureStoreResult,
+  type CaptureStoreSnapshot,
+  type EvidenceSpan,
+} from "@hashintel/brunch-agent";
+import {
+  archiveSessionLogRead,
+  createEmptySessionLogArchive,
+  parseSessionLogArchive,
+  readArchivedEntryRange,
+  type SessionLogArchive,
+  type SessionLogRead,
+} from "@hashintel/brunch-agent/storage";
+
+import { registerArchiveWriter } from "./archive-capability";
+
+const FORMAT_VERSION = 1 as const;
+
+interface TargetDocumentRecord {
+  readonly formatVersion: typeof FORMAT_VERSION;
+  readonly captureStore: CaptureStoreSnapshot;
+  readonly sessionLogArchive: SessionLogArchive;
+}
+
+const writesByPath = new Map<string, Promise<void>>();
+
+const createEmptyTargetDocument = (): TargetDocumentRecord => ({
+  formatVersion: FORMAT_VERSION,
+  captureStore: createEmptyCaptureStoreSnapshot(),
+  sessionLogArchive: createEmptySessionLogArchive(),
+});
+
+const isRecord = (value: unknown): value is Record<string, unknown> =>
+  typeof value === "object" && value !== null && !Array.isArray(value);
+
+const parseTargetDocument = (input: unknown): TargetDocumentRecord => {
+  if (isRecord(input) && "formatVersion" in input) {
+    const fields = Object.keys(input).sort();
+    if (
+      input.formatVersion !== FORMAT_VERSION ||
+      JSON.stringify(fields) !==
+        JSON.stringify(["captureStore", "formatVersion", "sessionLogArchive"])
+    ) {
+      throw new TypeError(
+        `Unsupported target-document format version ${String(input.formatVersion)}.`,
+      );
+    }
+    return {
+      formatVersion: FORMAT_VERSION,
+      captureStore: parseCaptureStoreSnapshot(input.captureStore),
+      sessionLogArchive: parseSessionLogArchive(input.sessionLogArchive),
+    };
+  }
+
+  // FE-1390 files predate the archive slot. Reading that exact capture-store
+  // shape provisions the new record in memory; the next successful mutation
+  // rewrites it atomically in the current format.
+  return {
+    formatVersion: FORMAT_VERSION,
+    captureStore: parseCaptureStoreSnapshot(input),
+    sessionLogArchive: createEmptySessionLogArchive(),
+  };
+};
+
+class LocalCaptureStore implements CaptureStore {
+  readonly #path: string;
+
+  constructor(path: string) {
+    this.#path = resolve(path);
+    registerArchiveWriter(this, (read) => this.#archiveSessionLog(read));
+  }
+
+  async read(): Promise<CaptureStoreSnapshot> {
+    await writesByPath.get(this.#path);
+    return (await this.#readFile()).captureStore;
+  }
+
+  async execute(
+    command: CaptureStoreCommand,
+    context?: CaptureStoreEvidenceContext,
+  ): Promise<CaptureStoreResult> {
+    return this.#mutate<CaptureStoreResult>((document) => {
+      const evidenceContext = context
+        ? { ...context, archive: document.sessionLogArchive }
+        : undefined;
+      const result = applyCaptureStoreCommand(
+        document.captureStore,
+        command,
+        evidenceContext,
+      );
+      return result.ok
+        ? {
+            value: result,
+            document: { ...document, captureStore: result.snapshot },
+          }
+        : { value: result };
+    });
+  }
+
+  async #archiveSessionLog(read: SessionLogRead): Promise<void> {
+    await this.#mutate((document) => ({
+      value: undefined,
+      document: {
+        ...document,
+        sessionLogArchive: archiveSessionLogRead(
+          document.sessionLogArchive,
+          read,
+        ),
+      },
+    }));
+  }
+
+  async readArchivedEntries(
+    pointer: EvidenceSpan["pointer"],
+  ): Promise<readonly ArchivedSessionEntry[]> {
+    await writesByPath.get(this.#path);
+    return readArchivedEntryRange(
+      (await this.#readFile()).sessionLogArchive,
+      pointer,
+    );
+  }
+
+  async #mutate<T>(
+    mutation: (document: TargetDocumentRecord) => {
+      readonly value: T;
+      readonly document?: TargetDocumentRecord;
+    },
+  ): Promise<T> {
+    const previous = writesByPath.get(this.#path) ?? Promise.resolve();
+    const operation = previous.then(async () => {
+      const before = await this.#readFile();
+      const outcome = mutation(before);
+      if (
+        outcome.document &&
+        JSON.stringify(outcome.document) !== JSON.stringify(before)
+      ) {
+        await this.#writeFile(outcome.document);
+      }
+      return outcome.value;
+    });
+    const settled = operation.then(
+      () => undefined,
+      () => undefined,
+    );
+    writesByPath.set(this.#path, settled);
+    void settled.finally(() => {
+      if (writesByPath.get(this.#path) === settled)
+        writesByPath.delete(this.#path);
+    });
+    return operation;
+  }
+
+  async #readFile(): Promise<TargetDocumentRecord> {
+    try {
+      return parseTargetDocument(
+        JSON.parse(await readFile(this.#path, "utf8")),
+      );
+    } catch (error) {
+      if (
+        error instanceof Error &&
+        "code" in error &&
+        (error as NodeJS.ErrnoException).code === "ENOENT"
+      ) {
+        return createEmptyTargetDocument();
+      }
+      throw error;
+    }
+  }
+
+  async #writeFile(document: TargetDocumentRecord): Promise<void> {
+    await mkdir(dirname(this.#path), { recursive: true });
+    const temporaryPath = `${this.#path}.${randomUUID()}.tmp`;
+    try {
+      await writeFile(temporaryPath, `${JSON.stringify(document, null, 2)}\n`, {
+        encoding: "utf8",
+        flag: "wx",
+      });
+      await rename(temporaryPath, this.#path);
+    } finally {
+      await rm(temporaryPath, { force: true });
+    }
+  }
+}
+
+export const createLocalCaptureStore = (path: string): CaptureStore =>
+  new LocalCaptureStore(path);
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/src/reply-projector.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/src/reply-projector.ts
new file mode 100644
index 00000000000..ed0322ae76e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/src/reply-projector.ts
@@ -0,0 +1,139 @@
+/** Translate Flue's public live conversation chunks into the harness reply protocol. */
+
+import { type ConversationStreamChunk } from "@flue/sdk";
+
+import { type HarnessReplyEvent } from "@hashintel/brunch-agent";
+
+export interface FlueReplyProjectorOptions {
+  readonly submissionId: string;
+  readonly emit: (event: HarnessReplyEvent) => void;
+}
+
+export interface FlueReplyProjector {
+  accept(chunk: ConversationStreamChunk): void;
+}
+
+type StreamingPart = {
+  readonly kind: "text" | "reasoning";
+  readonly partId: string;
+};
+
+export const createFlueReplyProjector = (
+  options: FlueReplyProjectorOptions,
+): FlueReplyProjector => {
+  let accepting = false;
+  let messageId: string | undefined;
+  let turnId: string | undefined;
+  let partOrdinal = 0;
+  let streamingPart: StreamingPart | undefined;
+
+  const finishPart = (): void => {
+    if (!streamingPart) return;
+    options.emit({ type: "part-end", ...streamingPart });
+    streamingPart = undefined;
+  };
+
+  const finishTurn = (): void => {
+    finishPart();
+    if (!turnId) return;
+    options.emit({ type: "turn-finish", turnId });
+    turnId = undefined;
+  };
+
+  const startPart = (kind: "text" | "reasoning"): StreamingPart => {
+    finishPart();
+    partOrdinal += 1;
+    const part = {
+      kind,
+      partId: `${messageId}:${kind}:${partOrdinal}`,
+    } as const;
+    streamingPart = part;
+    options.emit({ type: "part-start", ...part });
+    return part;
+  };
+
+  return {
+    accept(chunk) {
+      if (chunk.type === "message-started") {
+        accepting = chunk.submissionId === options.submissionId;
+        if (!accepting) return;
+
+        if (messageId === undefined) {
+          messageId = chunk.messageId;
+          options.emit({ type: "response-start", messageId });
+        }
+        finishTurn();
+        turnId = chunk.turnId ?? `${messageId}:turn`;
+        options.emit({ type: "turn-start", turnId });
+        return;
+      }
+
+      if (chunk.type === "submission-settled") {
+        if (chunk.submissionId !== options.submissionId) return;
+        finishTurn();
+        options.emit({
+          type: "response-finish",
+          terminalState: chunk.outcome,
+          finishReason: chunk.outcome === "completed" ? "stop" : "error",
+        });
+        accepting = false;
+        return;
+      }
+
+      if (!accepting || messageId === undefined) return;
+
+      switch (chunk.type) {
+        case "message-delta": {
+          if (chunk.messageId !== messageId) return;
+          const part =
+            streamingPart?.kind === chunk.kind
+              ? streamingPart
+              : startPart(chunk.kind);
+          options.emit({
+            type: "part-delta",
+            kind: part.kind,
+            partId: part.partId,
+            delta: chunk.delta,
+          });
+          return;
+        }
+        case "tool-input":
+          if (chunk.messageId !== messageId) return;
+          finishPart();
+          options.emit({
+            type: "tool-input",
+            toolCallId: chunk.toolCallId,
+            toolName: chunk.toolName,
+            input: chunk.input,
+            execution: "server",
+          });
+          return;
+        case "tool-output":
+          options.emit({
+            type: "tool-output",
+            toolCallId: chunk.toolCallId,
+            output: chunk.output,
+            execution: "server",
+          });
+          return;
+        case "tool-output-error":
+          options.emit({
+            type: "tool-output-error",
+            toolCallId: chunk.toolCallId,
+            errorText: chunk.errorText,
+            execution: "server",
+          });
+          return;
+        case "message-completed":
+          if (chunk.messageId === messageId) finishTurn();
+          return;
+        case "conversation-reset":
+        case "message-appended":
+        case "message-metadata":
+        case "data-part":
+        case "stream-checkpoint":
+          return;
+      }
+    },
+  };
+};
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/test/capture-accounting.test.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/test/capture-accounting.test.ts
new file mode 100644
index 00000000000..a20d7526886
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/test/capture-accounting.test.ts
@@ -0,0 +1,148 @@
+import { describe, expect, test } from "vitest";
+
+import { capturedUserEntryIdsForSession } from "../src/capture-accounting";
+
+import type {
+  CaptureStoreSnapshot,
+  EvidenceSpan,
+} from "@hashintel/brunch-agent";
+
+const evidence = (sessionId: string): EvidenceSpan => ({
+  excerpt: "A colliding quote.",
+  pointer: { sessionId, entryStart: 1, entryEnd: 1 },
+  source: "user-affordance-payload",
+});
+
+describe("capture accounting", () => {
+  test("uses the current archived kind when persisted capture provenance is stale", async () => {
+    const snapshot = {
+      captures: [
+        {
+          id: "capture-reclassified-affordance-reply",
+          dedupKey: "reclassified",
+          evidence: [
+            {
+              excerpt: "An answer later recognized as an affordance reply.",
+              pointer: {
+                sessionId: "session-active",
+                entryStart: 1,
+                entryEnd: 1,
+              },
+              source: "user",
+            },
+          ],
+          epistemicStatus: "explicit",
+          confidence: "firm",
+          content: { value: "reclassified" },
+        },
+        {
+          id: "capture-ordinary-user-entry",
+          dedupKey: "ordinary",
+          evidence: [
+            {
+              excerpt: "An ordinary user answer.",
+              pointer: {
+                sessionId: "session-active",
+                entryStart: 2,
+                entryEnd: 2,
+              },
+              source: "user-affordance-payload",
+            },
+          ],
+          epistemicStatus: "explicit",
+          confidence: "firm",
+          content: { value: "ordinary" },
+        },
+      ],
+      issues: [],
+      events: [],
+    } satisfies CaptureStoreSnapshot;
+
+    const entryIds = await capturedUserEntryIdsForSession(
+      {
+        async readArchivedEntries(pointer) {
+          const kind =
+            pointer.entryStart === 1
+              ? "user-affordance-payload"
+              : ("user" as const);
+          return [
+            {
+              ordinal: pointer.entryStart,
+              substrateEntryId:
+                pointer.entryStart === 1
+                  ? "reclassified-affordance-reply"
+                  : "ordinary-user-entry",
+              versions: [
+                {
+                  version: 1,
+                  observedAtOffset: "offset-current",
+                  kind,
+                  text: "answer",
+                  materialized: { role: "user" },
+                },
+              ],
+            },
+          ];
+        },
+      },
+      snapshot,
+      "session-active",
+    );
+
+    expect(entryIds).toEqual(new Set(["reclassified-affordance-reply"]));
+  });
+
+  test("keeps host-session identity when Flue entry ids collide", async () => {
+    const pointersRead: string[] = [];
+    const snapshot = {
+      captures: [
+        {
+          id: "capture-other-session",
+          dedupKey: "other",
+          evidence: [evidence("session-other")],
+          epistemicStatus: "explicit",
+          confidence: "firm",
+          content: { value: "other" },
+        },
+        {
+          id: "capture-active-session",
+          dedupKey: "active",
+          evidence: [evidence("session-active")],
+          epistemicStatus: "explicit",
+          confidence: "firm",
+          content: { value: "active" },
+        },
+      ],
+      issues: [],
+      events: [],
+    } satisfies CaptureStoreSnapshot;
+
+    const entryIds = await capturedUserEntryIdsForSession(
+      {
+        async readArchivedEntries(pointer) {
+          pointersRead.push(pointer.sessionId);
+          return [
+            {
+              ordinal: 1,
+              substrateEntryId: "colliding-flue-entry-id",
+              versions: [
+                {
+                  version: 1,
+                  observedAtOffset: "offset-current",
+                  kind: "user-affordance-payload",
+                  text: "A colliding quote.",
+                  materialized: { role: "user" },
+                },
+              ],
+            },
+          ];
+        },
+      },
+      snapshot,
+      "session-active",
+    );
+
+    expect(entryIds).toEqual(new Set(["colliding-flue-entry-id"]));
+    expect(pointersRead).toEqual(["session-active"]);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/test/history-reader.test.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/test/history-reader.test.ts
new file mode 100644
index 00000000000..a46c48a5cba
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/test/history-reader.test.ts
@@ -0,0 +1,433 @@
+import { existsSync } from "node:fs";
+import { mkdtemp, readFile, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, describe, expect, test } from "vitest";
+
+import {
+  createFlueHistoryReader,
+  projectFlueHistoryForSweep,
+} from "../src/history-reader";
+import { createLocalCaptureStore } from "../src/local-capture-store";
+
+const directories: string[] = [];
+
+afterEach(async () => {
+  await Promise.all(
+    directories
+      .splice(0)
+      .map((directory) => rm(directory, { recursive: true })),
+  );
+});
+
+const storePath = async (): Promise<string> => {
+  const directory = await mkdtemp(join(tmpdir(), "brunch-history-"));
+  directories.push(directory);
+  return join(directory, "target-document.json");
+};
+
+const snapshot = {
+  v: 1 as const,
+  conversationId: "flue-conversation-internal",
+  offset: "4",
+  incarnation: "incarnation-1",
+  messages: [
+    {
+      id: "kickoff",
+      role: "user" as const,
+      purpose: "user" as const,
+      display: "visible" as const,
+      parts: [
+        {
+          type: "text" as const,
+          text: "Begin the interview.",
+          state: "done" as const,
+        },
+      ],
+    },
+    {
+      id: "ask",
+      role: "assistant" as const,
+      purpose: "assistant" as const,
+      display: "visible" as const,
+      parts: [
+        {
+          type: "dynamic-tool" as const,
+          toolName: "brunch_ask",
+          toolCallId: "tool-1",
+          state: "output-available" as const,
+          input: { question: "When?" },
+          output: { id: "affordance-1", form: "free-text", markdown: "When?" },
+        },
+      ],
+    },
+    {
+      id: "reply",
+      role: "user" as const,
+      purpose: "user" as const,
+      display: "visible" as const,
+      parts: [
+        { type: "text" as const, text: "June works.", state: "done" as const },
+      ],
+    },
+    {
+      id: "reply-binding",
+      role: "system" as const,
+      purpose: "dispatch" as const,
+      display: "hidden" as const,
+      signal: {
+        tagName: "affordance-reply-bound",
+        attributes: { affordanceId: "affordance-1" },
+      },
+      parts: [
+        {
+          type: "text" as const,
+          text: "Reply binding.",
+          state: "done" as const,
+        },
+      ],
+    },
+  ],
+  settlements: [
+    { submissionId: "submission-1", outcome: "completed" as const },
+  ],
+};
+
+describe("Flue materialized-history reader", () => {
+  test("projects Flue ask and reply-binding parts into substrate-neutral sweep facts", () => {
+    expect(projectFlueHistoryForSweep(snapshot)).toEqual([
+      {
+        id: "kickoff",
+        kind: "user",
+        text: "Begin the interview.",
+      },
+      {
+        id: "ask",
+        kind: "assistant",
+        text: "",
+        affordances: [{ id: "affordance-1", markdown: "When?" }],
+      },
+      {
+        id: "reply",
+        kind: "user-affordance-payload",
+        text: "June works.",
+        replyToAffordanceId: "affordance-1",
+      },
+      {
+        id: "reply-binding",
+        kind: "non-user",
+        text: "Reply binding.",
+      },
+    ]);
+  });
+
+  test("projects refused sweep results and repair signals as neutral lifecycle facts", () => {
+    const lifecycleSnapshot = {
+      ...snapshot,
+      messages: [
+        {
+          id: "sweep-refusal",
+          role: "assistant" as const,
+          purpose: "assistant" as const,
+          display: "visible" as const,
+          parts: [
+            {
+              type: "dynamic-tool" as const,
+              toolName: "brunch_sweep",
+              toolCallId: "sweep-1",
+              state: "output-available" as const,
+              input: {},
+              output: {
+                status: "refused",
+                refusal: {
+                  code: "evidence-quote-not-found",
+                  message: "Use an exact quote.",
+                },
+              },
+            },
+          ],
+        },
+        {
+          id: "repair-signal",
+          role: "system" as const,
+          purpose: "dispatch" as const,
+          display: "hidden" as const,
+          signal: { tagName: "sweep-repair", attributes: {} },
+          parts: [
+            {
+              type: "text" as const,
+              text: "Repair the sweep.",
+              state: "done" as const,
+            },
+          ],
+        },
+      ],
+    };
+
+    expect(projectFlueHistoryForSweep(lifecycleSnapshot)).toEqual([
+      {
+        id: "sweep-refusal",
+        kind: "assistant",
+        text: "",
+        sweepResult: {
+          status: "refused",
+          refusal: {
+            code: "evidence-quote-not-found",
+            message: "Use an exact quote.",
+          },
+        },
+      },
+      {
+        id: "repair-signal",
+        kind: "non-user",
+        text: "Repair the sweep.",
+        sweepRepairSignal: true,
+      },
+    ]);
+  });
+
+  test("uses only the host-resolved URL and transport, then archives the public snapshot", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+    const requested: string[] = [];
+    const transport = (async (input: Parameters<typeof fetch>[0]) => {
+      requested.push(input instanceof Request ? input.url : input.toString());
+      return Response.json(snapshot);
+    }) as typeof fetch;
+    const reader = createFlueHistoryReader({
+      resolveConversationUrl: (sessionId) =>
+        `http://host.test/custom-mount/${sessionId}`,
+      transport,
+      archive: store,
+    });
+
+    expect(await reader.peek("session-1")).toEqual(snapshot);
+    expect(existsSync(path)).toBe(false);
+
+    expect(await reader.read("session-1")).toEqual(snapshot);
+    expect(requested).toEqual([
+      "http://host.test/custom-mount/session-1?view=history",
+      "http://host.test/custom-mount/session-1?view=history",
+    ]);
+
+    const entries = await store.readArchivedEntries({
+      sessionId: "session-1",
+      entryStart: 1,
+      entryEnd: 4,
+    });
+    expect(entries.map((entry) => entry.versions.at(-1)!.kind)).toEqual([
+      "user",
+      "assistant",
+      "user-affordance-payload",
+      "non-user",
+    ]);
+    expect(entries[0]!.versions.at(-1)!.materialized).toEqual(
+      JSON.parse(JSON.stringify(snapshot.messages[0]!)),
+    );
+
+    const captured = await store.execute(
+      {
+        type: "apply-sweep",
+        proposals: [
+          {
+            evidence: [{ excerpt: "June works." }],
+            epistemicStatus: "explicit",
+            confidence: "high",
+            content: { value: "June" },
+          },
+        ],
+      },
+      { sessionId: "session-1" },
+    );
+    expect(captured.ok).toBe(true);
+    if (!captured.ok) throw new Error(captured.refusal.message);
+    const capture = captured.snapshot.captures[0]!;
+    if (!("evidence" in capture))
+      throw new Error("capture did not retain evidence");
+    const pointer = capture.evidence[0]!.pointer;
+    expect(
+      (await store.readArchivedEntries(pointer))[0]!.substrateEntryId,
+    ).toBe("reply");
+
+    const repairedOmission = await store.execute(
+      {
+        type: "apply-sweep",
+        proposals: [
+          {
+            evidence: [{ excerpt: "June works." }],
+            epistemicStatus: "explicit",
+            confidence: "high",
+            content: { value: "June" },
+          },
+          {
+            evidence: [{ excerpt: "June works." }],
+            epistemicStatus: "explicit",
+            confidence: "high",
+            content: { value: "schedule accepted" },
+          },
+        ],
+      },
+      { sessionId: "session-1" },
+    );
+    expect(repairedOmission).toMatchObject({
+      ok: true,
+      value: {
+        appliedCaptureIds: [expect.any(String)],
+        skippedDedupKeys: [expect.any(String)],
+      },
+      snapshot: { captures: [expect.any(Object), expect.any(Object)] },
+    });
+
+    expect(
+      await store.execute(
+        {
+          type: "apply-sweep",
+          proposals: [
+            {
+              evidence: [{ excerpt: "Reply binding." }],
+              epistemicStatus: "explicit",
+              confidence: "high",
+              content: { value: "injected" },
+            },
+          ],
+        },
+        { sessionId: "session-1" },
+      ),
+    ).toMatchObject({ ok: false, refusal: { code: "non-user-evidence" } });
+
+    const persisted = JSON.parse(await readFile(path, "utf8")) as {
+      formatVersion: number;
+      sessionLogArchive: {
+        sessions: { reads: { substrateConversationId?: string }[] }[];
+      };
+    };
+    expect(persisted.formatVersion).toBe(1);
+    expect(persisted.sessionLogArchive.sessions).toHaveLength(1);
+    expect(
+      persisted.sessionLogArchive.sessions[0]!.reads[0]!
+        .substrateConversationId,
+    ).toBe("flue-conversation-internal");
+  });
+
+  test("preserves capture identity when a full-prefix replay reclassifies a reply", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+    const snapshots = [
+      {
+        ...snapshot,
+        offset: "1",
+        // Before the reply-binding signal arrives, this is an ordinary user
+        // entry. The next full-prefix read classifies the same Flue message as
+        // an affordance payload.
+        messages: snapshot.messages.slice(0, 3),
+      },
+      { ...snapshot, offset: "2" },
+    ];
+    const reader = createFlueHistoryReader({
+      resolveConversationUrl: () => "http://host.test/agent/session-1",
+      transport: (async () =>
+        Response.json(snapshots.shift()!)) as unknown as typeof fetch,
+      archive: store,
+    });
+
+    await reader.read("session-1");
+    const first = await store.execute(
+      {
+        type: "apply-sweep",
+        proposals: [
+          {
+            evidence: [{ excerpt: "June works." }],
+            epistemicStatus: "explicit",
+            confidence: "high",
+            content: { value: "June" },
+          },
+        ],
+      },
+      { sessionId: "session-1" },
+    );
+    if (!first.ok) throw new Error(first.refusal.message);
+
+    await reader.read("session-1");
+    const retry = await store.execute(
+      {
+        type: "apply-sweep",
+        proposals: [
+          {
+            evidence: [{ excerpt: "June works." }],
+            epistemicStatus: "explicit",
+            confidence: "high",
+            content: { value: "June" },
+          },
+        ],
+      },
+      { sessionId: "session-1" },
+    );
+
+    expect(retry.ok).toBe(true);
+    if (!retry.ok || !("skippedDedupKeys" in retry.value))
+      throw new Error("retry sweep refused");
+    expect(retry.snapshot.captures).toHaveLength(1);
+    expect(retry.value.skippedDedupKeys).toHaveLength(1);
+  });
+
+  test("versions an evolving public message instead of duplicating its archive ordinal", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+    const snapshots = [
+      {
+        ...snapshot,
+        offset: "1",
+        messages: [
+          {
+            id: "assistant",
+            role: "assistant" as const,
+            purpose: "assistant" as const,
+            display: "visible" as const,
+            parts: [
+              {
+                type: "text" as const,
+                text: "Jun",
+                state: "streaming" as const,
+              },
+            ],
+          },
+        ],
+      },
+      {
+        ...snapshot,
+        offset: "2",
+        messages: [
+          {
+            id: "assistant",
+            role: "assistant" as const,
+            purpose: "assistant" as const,
+            display: "visible" as const,
+            parts: [
+              { type: "text" as const, text: "June.", state: "done" as const },
+            ],
+          },
+        ],
+      },
+    ];
+    const transport = (async () =>
+      Response.json(snapshots.shift()!)) as unknown as typeof fetch;
+    const reader = createFlueHistoryReader({
+      resolveConversationUrl: () => "http://host.test/agent/session-1",
+      transport,
+      archive: store,
+    });
+
+    await reader.read("session-1");
+    await reader.read("session-1");
+    const [entry] = await store.readArchivedEntries({
+      sessionId: "session-1",
+      entryStart: 1,
+      entryEnd: 1,
+    });
+    expect(entry!.versions.map((version) => version.text)).toEqual([
+      "Jun",
+      "June.",
+    ]);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/test/local-capture-store.test.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/test/local-capture-store.test.ts
new file mode 100644
index 00000000000..534eb6b1205
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/test/local-capture-store.test.ts
@@ -0,0 +1,286 @@
+import { mkdtemp, readFile, readdir, rm, writeFile } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, describe, expect, test } from "vitest";
+
+import { archiveThroughBinding } from "../src/archive-capability";
+import { createLocalCaptureStore as createLocalCaptureStoreAdapter } from "../src/local-capture-store";
+
+import type {
+  CaptureInputProposal,
+  CaptureStore,
+  CaptureStoreCommand,
+  EvidenceQuote,
+} from "@hashintel/brunch-agent";
+
+const directories: string[] = [];
+
+afterEach(async () => {
+  await Promise.all(
+    directories
+      .splice(0)
+      .map((directory) => rm(directory, { recursive: true })),
+  );
+  excerptsByEntry.clear();
+});
+
+const excerptsByEntry = new Map<number, Set<string>>();
+
+const userEvidence = (excerpt: string, entry: number): EvidenceQuote => {
+  const excerpts = excerptsByEntry.get(entry) ?? new Set<string>();
+  excerpts.add(excerpt);
+  excerptsByEntry.set(entry, excerpts);
+  return { excerpt };
+};
+
+const proposal = (value: string, entry: number): CaptureInputProposal => ({
+  evidence: [userEvidence(value, entry)],
+  epistemicStatus: "explicit",
+  confidence: "high",
+  content: { value },
+});
+
+const createLocalCaptureStore = (path: string): CaptureStore => {
+  const store = createLocalCaptureStoreAdapter(path);
+  return {
+    read: () => store.read(),
+    readArchivedEntries: (pointer) => store.readArchivedEntries(pointer),
+    async execute(command: CaptureStoreCommand) {
+      const maxEntry = Math.max(1, ...excerptsByEntry.keys());
+      await archiveThroughBinding(store, {
+        sessionId: "session-1",
+        offset: String(maxEntry),
+        entries: Array.from({ length: maxEntry }, (_, index) => {
+          const ordinal = index + 1;
+          const text = [
+            ...(excerptsByEntry.get(ordinal) ?? [`filler-${ordinal}`]),
+          ].join("\n");
+          return {
+            substrateEntryId: `message-${ordinal}`,
+            kind: "user" as const,
+            text,
+            materialized: { id: `message-${ordinal}`, text },
+          };
+        }),
+        settlements: [],
+      });
+      return store.execute(command, { sessionId: "session-1" });
+    },
+  };
+};
+
+const storePath = async (): Promise<string> => {
+  const directory = await mkdtemp(join(tmpdir(), "brunch-captures-"));
+  directories.push(directory);
+  return join(directory, "captures.json");
+};
+
+describe("local capture store", () => {
+  test("persists captures through JSON tmp-and-rename without stored statuses", async () => {
+    const path = await storePath();
+    const first = createLocalCaptureStore(path);
+    const written = await first.execute({
+      type: "apply-sweep",
+      proposals: [proposal("alpha", 1)],
+    });
+    expect(written.ok).toBe(true);
+
+    const reopened = createLocalCaptureStore(path);
+    const snapshot = await reopened.read();
+    expect(snapshot.captures).toHaveLength(1);
+    expect(snapshot.captures[0]!.content).toEqual({ value: "alpha" });
+
+    const persisted = JSON.parse(await readFile(path, "utf8")) as unknown;
+    expect(JSON.stringify(persisted)).not.toContain('"status"');
+    expect(
+      (await readdir(join(path, ".."))).filter((name) => name.endsWith(".tmp")),
+    ).toEqual([]);
+  });
+
+  test("serializes concurrent writes and never persists a refused partial sweep", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+
+    const [first, second] = await Promise.all([
+      store.execute({ type: "apply-sweep", proposals: [proposal("alpha", 1)] }),
+      store.execute({ type: "apply-sweep", proposals: [proposal("beta", 2)] }),
+    ]);
+    expect(first.ok).toBe(true);
+    expect(second.ok).toBe(true);
+
+    const refused = await store.execute({
+      type: "apply-sweep",
+      proposals: [
+        proposal("gamma", 3),
+        {
+          ...proposal("invalid", 4),
+          content: { value: "invalid", absence: "deferred" },
+        } as unknown as CaptureInputProposal,
+      ],
+    });
+    expect(refused).toMatchObject({
+      ok: false,
+      refusal: { code: "invalid-envelope" },
+    });
+
+    const snapshot = await createLocalCaptureStore(path).read();
+    expect(snapshot.captures.map((capture) => capture.content)).toEqual([
+      { value: "alpha" },
+      { value: "beta" },
+    ]);
+  });
+
+  test("a command refused by the conflict guard leaves capture state unchanged and readable", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+    const created = await store.execute({
+      type: "apply-sweep",
+      proposals: [proposal("March", 1), proposal("June", 2)],
+    });
+    expect(created.ok).toBe(true);
+    if (!created.ok)
+      throw new Error(
+        `The setup sweep was refused: ${created.refusal.message}`,
+      );
+    const captures = await store.read();
+    const [marchId, juneId] = captures.captures.map((capture) => capture.id);
+    if (marchId === undefined || juneId === undefined) {
+      throw new Error(
+        "The setup sweep did not persist both conflicting captures.",
+      );
+    }
+    const opened = await store.execute({
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId, juneId],
+      canDefault: false,
+    });
+    expect(opened.ok).toBe(true);
+
+    const before = JSON.parse(await readFile(path, "utf8")) as {
+      captureStore: unknown;
+    };
+    for (const command of [
+      {
+        type: "apply-sweep",
+        proposals: [{ ...proposal("April", 3), supersedes: marchId }],
+      },
+      {
+        type: "retract-capture",
+        captureId: marchId,
+        evidence: [userEvidence("Forget it", 4)],
+      },
+    ] as const) {
+      const refused = await store.execute(command);
+      expect(refused).toMatchObject({
+        ok: false,
+        refusal: { code: "blocked-by-open-conflict", captureId: marchId },
+      });
+    }
+
+    // Reading the later cited quotes legitimately grows the co-located archive,
+    // but neither refused command may change the capture-store half.
+    const after = JSON.parse(await readFile(path, "utf8")) as {
+      captureStore: unknown;
+    };
+    expect(after.captureStore).toEqual(before.captureStore);
+    // And still readable through the parser, which is what makes it a snapshot
+    // rather than surviving bytes.
+    expect(
+      (await createLocalCaptureStore(path).read()).captures.map(
+        (c) => c.content,
+      ),
+    ).toEqual([{ value: "March" }, { value: "June" }]);
+    expect(
+      (await readdir(join(path, ".."))).filter((name) => name.endsWith(".tmp")),
+    ).toEqual([]);
+  });
+
+  test("what a command returns is what the file gives back, even after the caller edits its arrays", async () => {
+    const path = await storePath();
+    const store = createLocalCaptureStore(path);
+    const created = await store.execute({
+      type: "apply-sweep",
+      proposals: [proposal("June", 1)],
+    });
+    if (!created.ok) throw new Error("the sweep was refused");
+    const captureId = created.snapshot.captures[0]!.id;
+
+    const evidence = [userEvidence("Forget the June date", 2)];
+    const retracted = await store.execute({
+      type: "retract-capture",
+      captureId,
+      evidence,
+    });
+    if (!retracted.ok) throw new Error("the retraction was refused");
+
+    // The caller edits everything it still holds, after the store accepted and
+    // wrote it. If the snapshot aliased any of it, the result the caller was
+    // handed and the bytes on disk would now disagree.
+    (evidence[0] as { excerpt: string }).excerpt = "Mutated after the write";
+    evidence.push(userEvidence("Injected after the write", 3));
+
+    expect(await createLocalCaptureStore(path).read()).toEqual(
+      retracted.snapshot,
+    );
+  });
+
+  test("migrates the legacy capture-only shape on the next successful archive write", async () => {
+    const path = await storePath();
+    const legacy = { captures: [], issues: [], events: [] };
+    await writeFile(path, `${JSON.stringify(legacy)}\n`);
+
+    const store = createLocalCaptureStoreAdapter(path);
+    expect(await store.read()).toEqual(legacy);
+    await archiveThroughBinding(store, {
+      sessionId: "session-1",
+      offset: "0",
+      entries: [],
+      settlements: [],
+    });
+
+    expect(JSON.parse(await readFile(path, "utf8"))).toEqual({
+      formatVersion: 1,
+      captureStore: legacy,
+      sessionLogArchive: {
+        sessions: [
+          {
+            sessionId: "session-1",
+            entries: [],
+            reads: [{ offset: "0", entries: [], settlements: [] }],
+          },
+        ],
+      },
+    });
+  });
+
+  test("fails loudly when the versioned archive cannot be parsed", async () => {
+    const path = await storePath();
+    await writeFile(
+      path,
+      JSON.stringify({
+        formatVersion: 1,
+        captureStore: { captures: [], issues: [], events: [] },
+        sessionLogArchive: {
+          sessions: [
+            {
+              sessionId: "session-1",
+              entries: [
+                {
+                  ordinal: 2,
+                  substrateEntryId: "message-2",
+                  versions: [],
+                },
+              ],
+              reads: [],
+            },
+          ],
+        },
+      }),
+    );
+
+    await expect(createLocalCaptureStoreAdapter(path).read()).rejects.toThrow();
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/test/reply-projector.test.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/test/reply-projector.test.ts
new file mode 100644
index 00000000000..86ec06846ed
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/test/reply-projector.test.ts
@@ -0,0 +1,214 @@
+import { expect, test } from "vitest";
+
+import { createFlueReplyProjector } from "../src/index";
+
+import type { HarnessReplyEvent } from "@hashintel/brunch-agent";
+
+const position = (batch: number, index: number) => ({ batch, index });
+
+test("projects one Flue submission into stable substrate-neutral reply events", () => {
+  const emitted: HarnessReplyEvent[] = [];
+  const projector = createFlueReplyProjector({
+    submissionId: "submission-1436",
+    emit: (event) => emitted.push(event),
+  });
+  const chunks = [
+    {
+      type: "message-started",
+      conversationId: "conversation-1436",
+      messageId: "message-1436",
+      submissionId: "submission-1436",
+      turnId: "turn-1436",
+      position: position(1, 0),
+    },
+    {
+      type: "message-delta",
+      conversationId: "conversation-1436",
+      messageId: "message-1436",
+      kind: "reasoning",
+      delta: "Checking the process boundary.",
+      position: position(1, 1),
+    },
+    {
+      type: "message-delta",
+      conversationId: "conversation-1436",
+      messageId: "message-1436",
+      kind: "text",
+      delta: "What outcome should the process achieve?",
+      position: position(1, 2),
+    },
+    {
+      type: "tool-input",
+      conversationId: "conversation-1436",
+      messageId: "message-1436",
+      toolCallId: "tool-1436",
+      toolName: "bl_sweep",
+      input: {},
+      position: position(1, 3),
+    },
+    {
+      type: "tool-output",
+      conversationId: "conversation-1436",
+      toolCallId: "tool-1436",
+      output: { status: "no-settled-range" },
+      position: position(1, 4),
+    },
+    {
+      type: "message-completed",
+      conversationId: "conversation-1436",
+      messageId: "message-1436",
+      position: position(1, 5),
+    },
+    {
+      type: "submission-settled",
+      conversationId: "conversation-1436",
+      submissionId: "submission-1436",
+      outcome: "completed",
+      position: position(1, 6),
+    },
+  ] as const;
+
+  for (const chunk of chunks) projector.accept(chunk);
+
+  expect(emitted).toEqual([
+    { type: "response-start", messageId: "message-1436" },
+    { type: "turn-start", turnId: "turn-1436" },
+    {
+      type: "part-start",
+      kind: "reasoning",
+      partId: "message-1436:reasoning:1",
+    },
+    {
+      type: "part-delta",
+      kind: "reasoning",
+      partId: "message-1436:reasoning:1",
+      delta: "Checking the process boundary.",
+    },
+    { type: "part-end", kind: "reasoning", partId: "message-1436:reasoning:1" },
+    { type: "part-start", kind: "text", partId: "message-1436:text:2" },
+    {
+      type: "part-delta",
+      kind: "text",
+      partId: "message-1436:text:2",
+      delta: "What outcome should the process achieve?",
+    },
+    { type: "part-end", kind: "text", partId: "message-1436:text:2" },
+    {
+      type: "tool-input",
+      toolCallId: "tool-1436",
+      toolName: "bl_sweep",
+      input: {},
+      execution: "server",
+    },
+    {
+      type: "tool-output",
+      toolCallId: "tool-1436",
+      output: { status: "no-settled-range" },
+      execution: "server",
+    },
+    { type: "turn-finish", turnId: "turn-1436" },
+    {
+      type: "response-finish",
+      terminalState: "completed",
+      finishReason: "stop",
+    },
+  ]);
+});
+
+test("ignores replayed chunks belonging to a different submission", () => {
+  const emitted: HarnessReplyEvent[] = [];
+  const projector = createFlueReplyProjector({
+    submissionId: "submission-current",
+    emit: (event) => emitted.push(event),
+  });
+
+  projector.accept({
+    type: "message-started",
+    conversationId: "conversation-1436",
+    messageId: "message-old",
+    submissionId: "submission-old",
+    turnId: "turn-old",
+    position: position(1, 0),
+  });
+  projector.accept({
+    type: "message-delta",
+    conversationId: "conversation-1436",
+    messageId: "message-old",
+    kind: "text",
+    delta: "Old response.",
+    position: position(1, 1),
+  });
+  projector.accept({
+    type: "submission-settled",
+    conversationId: "conversation-1436",
+    submissionId: "submission-old",
+    outcome: "completed",
+    position: position(1, 2),
+  });
+
+  expect(emitted).toEqual([]);
+});
+
+test("projects a failed server tool through the substrate-neutral terminal outcome", () => {
+  const emitted: HarnessReplyEvent[] = [];
+  const projector = createFlueReplyProjector({
+    submissionId: "submission-tool-failed",
+    emit: (event) => emitted.push(event),
+  });
+
+  projector.accept({
+    type: "message-started",
+    conversationId: "conversation-tool-failed",
+    messageId: "message-tool-failed",
+    submissionId: "submission-tool-failed",
+    turnId: "turn-tool-failed",
+    position: position(1, 0),
+  });
+  projector.accept({
+    type: "tool-input",
+    conversationId: "conversation-tool-failed",
+    messageId: "message-tool-failed",
+    toolCallId: "tool-failed",
+    toolName: "bl_sweep",
+    input: {},
+    position: position(1, 1),
+  });
+  projector.accept({
+    type: "tool-output-error",
+    conversationId: "conversation-tool-failed",
+    toolCallId: "tool-failed",
+    errorText: "Sweep persistence failed.",
+    position: position(1, 2),
+  });
+  projector.accept({
+    type: "submission-settled",
+    conversationId: "conversation-tool-failed",
+    submissionId: "submission-tool-failed",
+    outcome: "failed",
+    position: position(1, 3),
+  });
+
+  expect(emitted).toEqual([
+    { type: "response-start", messageId: "message-tool-failed" },
+    { type: "turn-start", turnId: "turn-tool-failed" },
+    {
+      type: "tool-input",
+      toolCallId: "tool-failed",
+      toolName: "bl_sweep",
+      input: {},
+      execution: "server",
+    },
+    {
+      type: "tool-output-error",
+      toolCallId: "tool-failed",
+      errorText: "Sweep persistence failed.",
+      execution: "server",
+    },
+    { type: "turn-finish", turnId: "turn-tool-failed" },
+    {
+      type: "response-finish",
+      terminalState: "failed",
+      finishReason: "error",
+    },
+  ]);
+});
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/tsconfig.json b/libs/@hashintel/brunch-agent/packages/binding-flue/tsconfig.json
new file mode 100644
index 00000000000..844edbd8e66
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/tsconfig.json
@@ -0,0 +1,19 @@
+{
+  "compilerOptions": {
+    "target": "es2024",
+    "lib": ["ESNext"],
+    "types": ["node"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedIndexedAccess": true,
+    "resolveJsonModule": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "isolatedModules": true
+  },
+  "include": ["src", "test"]
+}
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/turbo.json b/libs/@hashintel/brunch-agent/packages/binding-flue/turbo.json
new file mode 100644
index 00000000000..6d9a1d1f9e5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/turbo.json
@@ -0,0 +1,10 @@
+{
+  "extends": ["//"],
+  "tasks": {
+    "build": {
+      "dependsOn": ["^build"],
+      "outputs": ["dist/**"],
+      "cache": false
+    }
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/binding-flue/vite.config.ts b/libs/@hashintel/brunch-agent/packages/binding-flue/vite.config.ts
new file mode 100644
index 00000000000..f98b78c0397
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/binding-flue/vite.config.ts
@@ -0,0 +1,28 @@
+import { fileURLToPath } from "node:url";
+
+import { defineConfig } from "vitest/config";
+
+const packageRoot = fileURLToPath(new URL(".", import.meta.url));
+
+export default defineConfig({
+  build: {
+    lib: {
+      entry: fileURLToPath(new URL("src/index.ts", import.meta.url)),
+      fileName: "index",
+      formats: ["es"],
+    },
+    rolldownOptions: {
+      external: [
+        /^node:/u,
+        /^@flue\//u,
+        /^@hashintel\/brunch-agent(?:\/.*)?$/u,
+        "valibot",
+      ],
+    },
+    sourcemap: true,
+  },
+  root: packageRoot,
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/LICENSE.md b/libs/@hashintel/brunch-agent/packages/core/LICENSE.md
new file mode 100644
index 00000000000..c7d627721e2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/LICENSE.md
@@ -0,0 +1,607 @@
+GNU Affero General Public License
+=================================
+
+_Version 3, 19 November 2007_
+_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+## Preamble
+
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+Developers that use our General Public Licenses protect your rights
+with two steps: **(1)** assert copyright on the software, and **(2)** offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+The precise terms and conditions for copying, distribution and
+modification follow.
+
+## TERMS AND CONDITIONS
+
+### 0. Definitions
+
+“This License” refers to version 3 of the GNU Affero General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as “you”.  “Licensees” and
+“recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a “modified version” of the
+earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based
+on the Program.
+
+To “propagate” a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices”
+to the extent that it includes a convenient and prominently visible
+feature that **(1)** displays an appropriate copyright notice, and **(2)**
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+### 1. Source Code
+
+The “source code” for a work means the preferred form of the work
+for making modifications to it.  “Object code” means any non-source
+form of a work.
+
+A “Standard Interface” means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other
+than the work as a whole, that **(a)** is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and **(b)** serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+“Major Component”, in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+The Corresponding Source for a work in source code form is that
+same work.
+
+### 2. Basic Permissions
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+### 3. Protecting Users' Legal Rights From Anti-Circumvention Law
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+### 4. Conveying Verbatim Copies
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+### 5. Conveying Modified Source Versions
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+* **a)** The work must carry prominent notices stating that you modified
+it, and giving a relevant date.
+* **b)** The work must carry prominent notices stating that it is
+released under this License and any conditions added under section 7.
+This requirement modifies the requirement in section 4 to
+“keep intact all notices”.
+* **c)** You must license the entire work, as a whole, under this
+License to anyone who comes into possession of a copy.  This
+License will therefore apply, along with any applicable section 7
+additional terms, to the whole of the work, and all its parts,
+regardless of how they are packaged.  This License gives no
+permission to license the work in any other way, but it does not
+invalidate such permission if you have separately received it.
+* **d)** If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your
+work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+“aggregate” if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+### 6. Conveying Non-Source Forms
+
+You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+* **a)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium
+customarily used for software interchange.
+* **b)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a
+written offer, valid for at least three years and valid for as
+long as you offer spare parts or customer support for that product
+model, to give anyone who possesses the object code either **(1)** a
+copy of the Corresponding Source for all the software in the
+product that is covered by this License, on a durable physical
+medium customarily used for software interchange, for a price no
+more than your reasonable cost of physically performing this
+conveying of source, or **(2)** access to copy the
+Corresponding Source from a network server at no charge.
+* **c)** Convey individual copies of the object code with a copy of the
+written offer to provide the Corresponding Source.  This
+alternative is allowed only occasionally and noncommercially, and
+only if you received the object code with such an offer, in accord
+with subsection 6b.
+* **d)** Convey the object code by offering access from a designated
+place (gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to
+copy the object code is a network server, the Corresponding Source
+may be on a different server (operated by you or a third party)
+that supports equivalent copying facilities, provided you maintain
+clear directions next to the object code saying where to find the
+Corresponding Source.  Regardless of what server hosts the
+Corresponding Source, you remain obligated to ensure that it is
+available for as long as needed to satisfy these requirements.
+* **e)** Convey the object code using peer-to-peer transmission, provided
+you inform other peers where the object code and Corresponding
+Source of the work are being offered to the general public at no
+charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A “User Product” is either **(1)** a “consumer product”, which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or **(2)** anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, “normally used” refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+### 7. Additional Terms
+
+“Additional permissions” are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+* **a)** Disclaiming warranty or limiting liability differently from the
+terms of sections 15 and 16 of this License; or
+* **b)** Requiring preservation of specified reasonable legal notices or
+author attributions in that material or in the Appropriate Legal
+Notices displayed by works containing it; or
+* **c)** Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+* **d)** Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+* **e)** Declining to grant rights under trademark law for use of some
+trade names, trademarks, or service marks; or
+* **f)** Requiring indemnification of licensors and authors of that
+material by anyone who conveys the material (or modified versions of
+it) with contractual assumptions of liability to the recipient, for
+any liability that these contractual assumptions directly impose on
+those licensors and authors.
+
+All other non-permissive additional terms are considered “further
+restrictions” within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+### 8. Termination
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated **(a)**
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and **(b)** permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+### 9. Acceptance Not Required for Having Copies
+
+You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+### 10. Automatic Licensing of Downstream Recipients
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+### 11. Patents
+
+A “contributor” is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, “control” includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To “grant” such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either **(1)** cause the Corresponding Source to be so
+available, or **(2)** arrange to deprive yourself of the benefit of the
+patent license for this particular work, or **(3)** arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  “Knowingly relying” means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is “discriminatory” if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license **(a)** in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or **(b)** primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+### 12. No Surrender of Others' Freedom
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+### 13. Remote Network Interaction; Use with the GNU General Public License
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+### 14. Revised Versions of this License
+
+The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License “or any later version” applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+### 15. Disclaimer of Warranty
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+### 16. Limitation of Liability
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+### 17. Interpretation of Sections 15 and 16
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
diff --git a/libs/@hashintel/brunch-agent/packages/core/package.json b/libs/@hashintel/brunch-agent/packages/core/package.json
new file mode 100644
index 00000000000..f9001fcbe9c
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/package.json
@@ -0,0 +1,48 @@
+{
+  "name": "@hashintel/brunch-agent",
+  "version": "0.0.0-private",
+  "private": true,
+  "description": "The harness: mechanism and orchestration. Its public export surface is the plugin SDK.",
+  "license": "AGPL-3.0",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "import": "./dist/index.js"
+    },
+    "./client-tools": {
+      "types": "./src/client-tools.ts",
+      "import": "./dist/client-tools.js"
+    },
+    "./storage": {
+      "types": "./src/storage.ts",
+      "import": "./dist/storage.js"
+    },
+    "./testing": {
+      "types": "./src/testing/index.ts",
+      "import": "./dist/testing/index.js"
+    }
+  },
+  "scripts": {
+    "baseline:run": "node --experimental-strip-types ../../docs/planning/process-model-elicitation/baseline/run.ts",
+    "build": "vite build",
+    "fix:eslint": "oxlint --fix --type-aware --report-unused-disable-directives-severity=error .",
+    "linear:graph": "node --experimental-strip-types ../../scripts/linear-project-graph.ts",
+    "lint:eslint": "oxlint --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:tsc": "tsgo --noEmit",
+    "test:unit": "vitest run"
+  },
+  "dependencies": {
+    "valibot": "1.4.2"
+  },
+  "devDependencies": {
+    "@anthropic-ai/sdk": "0.74.0",
+    "@types/node": "22.18.13",
+    "@typescript/native-preview": "7.0.0-dev.20260511.1",
+    "fast-check": "4.9.0",
+    "oxlint": "1.63.0",
+    "oxlint-tsgolint": "0.22.1",
+    "vite": "8.1.0",
+    "vitest": "4.1.10"
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/affordance.ts b/libs/@hashintel/brunch-agent/packages/core/src/affordance.ts
new file mode 100644
index 00000000000..60dc46510a3
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/affordance.ts
@@ -0,0 +1,15 @@
+import * as v from "valibot";
+
+export { AskInput } from "./ask-tool-contract";
+
+/** The first baseline affordance carried by the walking skeleton (spec §7.2). */
+export const FreeTextAffordance = v.object({
+  id: v.pipe(v.string(), v.nonEmpty()),
+  form: v.literal("free-text"),
+  markdown: v.pipe(v.string(), v.nonEmpty()),
+  payload: v.object({
+    question: v.pipe(v.string(), v.nonEmpty()),
+  }),
+});
+
+export type FreeTextAffordance = v.InferOutput<typeof FreeTextAffordance>;
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/ask-protocol.ts b/libs/@hashintel/brunch-agent/packages/core/src/ask-protocol.ts
new file mode 100644
index 00000000000..ffe7d5ddd29
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/ask-protocol.ts
@@ -0,0 +1,120 @@
+import { toolName } from "./naming";
+
+import type { FreeTextAffordance } from "./affordance";
+import type { SweepSessionEntry } from "./sweep-protocol";
+
+export { AskSubmission } from "./ask-tool-contract";
+
+export const ASK_TOOL_DESCRIPTION =
+  "Ask one free-text question and suspend this turn for the person’s reply. A second ask in the same tool batch is rejected.";
+
+export type PendingAffordanceDecision =
+  | { readonly ok: true; readonly pending: FreeTextAffordance }
+  | { readonly ok: false; readonly reason: string };
+
+export interface ReplyBindingSignalPayload {
+  readonly type: "affordance-reply-bound";
+  readonly tagName: "affordance-reply-bound";
+  readonly body: string;
+  readonly attributes: { readonly affordanceId: string };
+}
+
+/** The affordance id an ask tool call mints — the wire-level correlation key. */
+export function askAffordanceId(callId: string): string {
+  return `affordance_${callId}`;
+}
+
+/** Mint the durable free-text affordance carried by an ask tool result. */
+export function mintAskAffordance(
+  question: string,
+  callId: string,
+): FreeTextAffordance {
+  return {
+    id: askAffordanceId(callId),
+    form: "free-text",
+    markdown: question,
+    payload: { question },
+  };
+}
+
+/** Decide whether a candidate may occupy the one-live-affordance slot. */
+export function decidePendingAffordance(
+  current: FreeTextAffordance | null,
+  candidate: FreeTextAffordance,
+): PendingAffordanceDecision {
+  if (current !== null) {
+    return {
+      ok: false,
+      reason: `An interactive affordance is already pending (${current.id}); wait for its reply before asking another question.`,
+    };
+  }
+  return { ok: true, pending: candidate };
+}
+
+/** Describe the mechanical binding between a user dispatch and its pending affordance. */
+export function buildReplyBindingSignalPayload(
+  pending: FreeTextAffordance,
+): ReplyBindingSignalPayload {
+  return {
+    type: "affordance-reply-bound",
+    tagName: "affordance-reply-bound",
+    body: `The immediately preceding user message is mechanically bound as the reply to this pending affordance:\n\n${pending.markdown}`,
+    attributes: { affordanceId: pending.id },
+  };
+}
+
+export type AskReplyAdmission =
+  | { readonly ok: true }
+  | {
+      readonly ok: false;
+      readonly reason: "no-pending-ask" | "different-ask-pending";
+    };
+
+/**
+ * The affordance id of the one ask still awaiting its reply, from projected
+ * durable history. An affordance is pending once emitted and stops being
+ * pending when a later entry is bound as its reply.
+ */
+export function pendingAskAffordanceId(
+  entries: readonly SweepSessionEntry[],
+): string | undefined {
+  const answered = new Set<string>();
+  for (const entry of entries) {
+    if (entry.replyToAffordanceId !== undefined)
+      answered.add(entry.replyToAffordanceId);
+  }
+  for (let index = entries.length - 1; index >= 0; index -= 1) {
+    for (const affordance of entries[index]!.affordances ?? []) {
+      if (!answered.has(affordance.id)) return affordance.id;
+    }
+  }
+  return undefined;
+}
+
+/**
+ * Decide whether one submitted ask answer may become the user-affordance
+ * reply. Only the currently pending ask's correlated submission is admitted;
+ * stale, duplicate, and forged tool-call ids are refused before any dispatch.
+ */
+export function decideAskReplyAdmission(
+  pendingAffordanceId: string | undefined,
+  submittedToolCallId: string,
+): AskReplyAdmission {
+  if (pendingAffordanceId === undefined)
+    return { ok: false, reason: "no-pending-ask" };
+  if (pendingAffordanceId !== askAffordanceId(submittedToolCallId)) {
+    return { ok: false, reason: "different-ask-pending" };
+  }
+  return { ok: true };
+}
+
+/** Render-invariant instruction fragments for the ask/suspension protocol. */
+export function askProtocolInstructionFragments(
+  targetDomain: string,
+): readonly string[] {
+  return [
+    `You are interviewing someone to elicit ${targetDomain}.`,
+    `Ask one question at a time with ${toolName("ask")}.`,
+    "Continue the conversation after each reply, using the harness-provided reply binding as a mechanical fact.",
+  ];
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/ask-tool-contract.ts b/libs/@hashintel/brunch-agent/packages/core/src/ask-tool-contract.ts
new file mode 100644
index 00000000000..b64a7590838
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/ask-tool-contract.ts
@@ -0,0 +1,11 @@
+import * as v from "valibot";
+
+/** The model-facing input contract for the harness-owned ask operation. */
+export const AskInput = v.object({
+  question: v.pipe(v.string(), v.nonEmpty()),
+});
+
+/** The host-authored output contract for one answered ask operation. */
+export const AskSubmission = v.object({
+  answer: v.pipe(v.string(), v.nonEmpty()),
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/capture-store.ts b/libs/@hashintel/brunch-agent/packages/core/src/capture-store.ts
new file mode 100644
index 00000000000..54356282519
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/capture-store.ts
@@ -0,0 +1,1354 @@
+import { randomUUID } from "node:crypto";
+
+import * as v from "valibot";
+
+import {
+  resolveEvidenceQuotes,
+  type EvidenceQuote,
+  type EvidenceResolutionRefusal,
+  type MultipleEvidenceMatchesAdvisory,
+  type ArchivedSessionEntry,
+  type SessionLogArchive,
+} from "./session-log";
+
+export const ABSENCE_STATES = [
+  "unknown-to-user",
+  "not-yet-decided",
+  "not-applicable",
+  "explicitly-absent",
+  "declined",
+  "deferred",
+] as const;
+
+export const EPISTEMIC_STATUSES = [
+  "explicit",
+  "inferred",
+  "tentative",
+  "defaulted",
+  "external-lookup",
+] as const;
+
+export const ISSUE_TYPES = [
+  "missing",
+  "ambiguous",
+  "conflicting",
+  "invalid",
+  "unsupported",
+  "unmapped",
+  "low-confidence",
+] as const;
+
+export type AbsenceState = (typeof ABSENCE_STATES)[number];
+export type EpistemicStatus = (typeof EPISTEMIC_STATUSES)[number];
+export type IssueType = (typeof ISSUE_TYPES)[number];
+export type CaptureStatus = "active" | "superseded" | "retracted";
+export type IssueStatus = "open" | "closed";
+export type JsonValue =
+  | null
+  | boolean
+  | number
+  | string
+  | JsonValue[]
+  | { readonly [key: string]: JsonValue };
+
+export interface EvidenceSpan {
+  readonly excerpt: string;
+  readonly pointer: {
+    readonly sessionId: string;
+    readonly entryStart: number;
+    readonly entryEnd: number;
+  };
+  readonly source: "user" | "user-affordance-payload";
+}
+
+export type CaptureContent =
+  | { readonly value: JsonValue }
+  | { readonly absence: AbsenceState };
+
+interface CaptureProposalCommon {
+  readonly confidence: string;
+  readonly content: CaptureContent;
+  readonly alternativeGroup?: string;
+  readonly supersedes?: string;
+}
+
+export type CaptureInputProposal = CaptureProposalCommon &
+  (
+    | {
+        readonly evidence: readonly EvidenceQuote[];
+        readonly epistemicStatus: "explicit" | "inferred" | "tentative";
+      }
+    | {
+        readonly basis: {
+          readonly type: "declared-default";
+          readonly description: string;
+        };
+        readonly epistemicStatus: "defaulted";
+      }
+    | {
+        readonly basis: {
+          readonly type: "documented-transformation";
+          readonly description: string;
+        };
+        readonly epistemicStatus: "external-lookup";
+      }
+  );
+
+export type CaptureProposal = CaptureProposalCommon &
+  (
+    | {
+        readonly evidence: readonly EvidenceSpan[];
+        readonly epistemicStatus: "explicit" | "inferred" | "tentative";
+      }
+    | {
+        readonly basis: {
+          readonly type: "declared-default";
+          readonly description: string;
+        };
+        readonly epistemicStatus: "defaulted";
+      }
+    | {
+        readonly basis: {
+          readonly type: "documented-transformation";
+          readonly description: string;
+        };
+        readonly epistemicStatus: "external-lookup";
+      }
+  );
+
+export type CaptureEnvelope = CaptureProposal & {
+  readonly id: string;
+  readonly dedupKey: string;
+};
+
+export type IssueOrigin =
+  | { readonly type: "harness" }
+  | { readonly type: "plugin"; readonly namespace: string };
+
+export interface CaptureIssue {
+  readonly id: string;
+  readonly type: IssueType;
+  readonly origin: IssueOrigin;
+  readonly references: readonly string[];
+  readonly canDefault: boolean;
+}
+
+export type CaptureAdvisory =
+  | {
+      readonly type: "possibly-equivalent";
+      readonly reason: "same-evidence" | "near-identical-payload";
+      readonly captureIds: readonly [string, string];
+    }
+  | MultipleEvidenceMatchesAdvisory;
+
+export interface ResolutionRecord {
+  readonly type: "resolution";
+  readonly id: string;
+  readonly issueId: string;
+  readonly decision: string;
+  readonly evidence: readonly EvidenceSpan[];
+  readonly winnerCaptureId: string;
+  readonly loserCaptureIds: readonly string[];
+}
+
+export interface RetractionEvent {
+  readonly type: "retraction";
+  readonly id: string;
+  readonly captureId: string;
+  readonly evidence: readonly EvidenceSpan[];
+}
+
+export interface IssueClosedEvent {
+  readonly type: "issue-closed";
+  readonly id: string;
+  readonly issueId: string;
+}
+
+export type CaptureStoreEvent =
+  | ResolutionRecord
+  | RetractionEvent
+  | IssueClosedEvent;
+
+export interface CaptureStoreSnapshot {
+  readonly captures: readonly CaptureEnvelope[];
+  readonly issues: readonly CaptureIssue[];
+  readonly events: readonly CaptureStoreEvent[];
+}
+
+export interface CaptureStore {
+  read(): Promise<CaptureStoreSnapshot>;
+  execute(
+    command: CaptureStoreCommand,
+    context?: CaptureStoreEvidenceContext,
+  ): Promise<CaptureStoreResult>;
+  readArchivedEntries(
+    pointer: EvidenceSpan["pointer"],
+  ): Promise<readonly ArchivedSessionEntry[]>;
+}
+
+export interface CaptureStoreEvidenceContext {
+  readonly sessionId: string;
+}
+
+export interface CaptureStoreCommandEvidenceContext extends CaptureStoreEvidenceContext {
+  readonly archive: SessionLogArchive;
+}
+
+export type CaptureStoreCommand =
+  | {
+      readonly type: "apply-sweep";
+      readonly proposals: readonly CaptureInputProposal[];
+    }
+  | {
+      readonly type: "open-issue";
+      readonly issueType: IssueType;
+      readonly origin: IssueOrigin;
+      readonly references: readonly string[];
+      readonly canDefault: boolean;
+    }
+  | { readonly type: "close-issue"; readonly issueId: string }
+  | {
+      readonly type: "resolve-conflict";
+      readonly issueId: string;
+      readonly decision: string;
+      readonly evidence: readonly EvidenceQuote[];
+      readonly winnerCaptureId: string;
+      readonly loserCaptureIds: readonly string[];
+    }
+  | {
+      readonly type: "retract-capture";
+      readonly captureId: string;
+      readonly evidence: readonly EvidenceQuote[];
+    };
+
+export type CaptureStoreRefusal =
+  | EvidenceResolutionRefusal
+  | {
+      readonly code: "evidence-session-required";
+      readonly message: string;
+    }
+  | { readonly code: "invalid-envelope"; readonly message: string }
+  | {
+      readonly code: "unknown-capture";
+      readonly message: string;
+      readonly captureId: string;
+    }
+  | {
+      readonly code: "unknown-issue";
+      readonly message: string;
+      readonly issueId: string;
+    }
+  | {
+      readonly code: "issue-already-closed";
+      readonly message: string;
+      readonly issueId: string;
+    }
+  | {
+      readonly code: "resolution-required";
+      readonly message: string;
+      readonly issueId: string;
+    }
+  | {
+      readonly code: "invalid-resolution";
+      readonly message: string;
+      readonly issueId: string;
+    }
+  | {
+      readonly code: "invalid-retraction";
+      readonly message: string;
+      readonly captureId: string;
+    }
+  | {
+      readonly code: "blocked-by-open-conflict";
+      readonly message: string;
+      readonly captureId: string;
+      readonly blockingIssueIds: readonly string[];
+    }
+  | {
+      readonly code: "superseded-target-not-active";
+      readonly message: string;
+      readonly targetCaptureId: string;
+      readonly currentHeadIds: readonly string[];
+    };
+
+export type CaptureStoreResult =
+  | {
+      readonly ok: true;
+      readonly snapshot: CaptureStoreSnapshot;
+      readonly value:
+        | {
+            readonly appliedCaptureIds: readonly string[];
+            readonly skippedDedupKeys: readonly string[];
+            readonly advisories: readonly CaptureAdvisory[];
+          }
+        | { readonly issueId: string }
+        | {
+            readonly eventId: string;
+            readonly advisories: readonly CaptureAdvisory[];
+          };
+    }
+  | { readonly ok: false; readonly refusal: CaptureStoreRefusal };
+
+const nonEmptyString = v.pipe(v.string(), v.nonEmpty());
+const positiveInteger = v.pipe(v.number(), v.integer(), v.minValue(1));
+// Range ordering belongs to this schema rather than to any one caller: every
+// surface that accepts evidence — proposals, resolution and retraction
+// commands, persisted snapshots — reaches it through here, so all of them
+// refuse the same spans.
+const evidenceSpanSchema = v.strictObject({
+  excerpt: nonEmptyString,
+  pointer: v.pipe(
+    v.strictObject({
+      sessionId: nonEmptyString,
+      entryStart: positiveInteger,
+      entryEnd: positiveInteger,
+    }),
+    v.check(
+      (pointer) => pointer.entryEnd >= pointer.entryStart,
+      "An evidence range cannot end before it starts.",
+    ),
+  ),
+  source: v.picklist(["user", "user-affordance-payload"]),
+});
+const evidenceQuoteSchema = v.strictObject({ excerpt: nonEmptyString });
+const contentSchema = v.union([
+  v.strictObject({ value: v.unknown() }),
+  v.strictObject({ absence: v.picklist(ABSENCE_STATES) }),
+]);
+const captureCommonFields = {
+  confidence: nonEmptyString,
+  content: contentSchema,
+  alternativeGroup: v.optional(nonEmptyString),
+  supersedes: v.optional(nonEmptyString),
+};
+const userCaptureFields = {
+  ...captureCommonFields,
+  evidence: v.pipe(v.array(evidenceSpanSchema), v.minLength(1)),
+  epistemicStatus: v.picklist(["explicit", "inferred", "tentative"]),
+};
+const defaultedCaptureFields = {
+  ...captureCommonFields,
+  basis: v.strictObject({
+    type: v.literal("declared-default"),
+    description: nonEmptyString,
+  }),
+  epistemicStatus: v.literal("defaulted"),
+};
+const externalCaptureFields = {
+  ...captureCommonFields,
+  basis: v.strictObject({
+    type: v.literal("documented-transformation"),
+    description: nonEmptyString,
+  }),
+  epistemicStatus: v.literal("external-lookup"),
+};
+const captureProposalSchema = v.union([
+  v.strictObject(userCaptureFields),
+  v.strictObject(defaultedCaptureFields),
+  v.strictObject(externalCaptureFields),
+]);
+export const CaptureInputProposalSchema = v.union([
+  v.strictObject({
+    ...captureCommonFields,
+    evidence: v.pipe(v.array(evidenceQuoteSchema), v.minLength(1)),
+    epistemicStatus: v.picklist(["explicit", "inferred", "tentative"]),
+  }),
+  v.strictObject(defaultedCaptureFields),
+  v.strictObject(externalCaptureFields),
+]);
+const envelopeIdentityFields = {
+  id: nonEmptyString,
+  dedupKey: nonEmptyString,
+};
+const captureEnvelopeSchema = v.union([
+  v.strictObject({ ...userCaptureFields, ...envelopeIdentityFields }),
+  v.strictObject({ ...defaultedCaptureFields, ...envelopeIdentityFields }),
+  v.strictObject({ ...externalCaptureFields, ...envelopeIdentityFields }),
+]);
+const issueSchema = v.pipe(
+  v.strictObject({
+    id: nonEmptyString,
+    type: v.picklist(ISSUE_TYPES),
+    origin: v.variant("type", [
+      v.strictObject({ type: v.literal("harness") }),
+      v.strictObject({ type: v.literal("plugin"), namespace: nonEmptyString }),
+    ]),
+    // A set, not a list: the resolution rule below compares reference sets, and
+    // a repeated reference makes an issue's population ambiguous — two captures
+    // in conflict or one, cited twice.
+    references: v.pipe(
+      v.array(nonEmptyString),
+      v.minLength(1),
+      v.check(
+        (references) => new Set(references).size === references.length,
+        "Issue references must be distinct capture ids.",
+      ),
+    ),
+    canDefault: v.boolean(),
+  }),
+  // A conflict between one capture is not a conflict, and it can never close:
+  // closing one takes a resolution, a resolution cites a winner and at least
+  // one loser, and that cited set can never equal a single reference.
+  v.check(
+    (issue) => issue.type !== "conflicting" || issue.references.length >= 2,
+    "A conflicting issue must reference at least two captures.",
+  ),
+);
+const resolutionSchema = v.strictObject({
+  type: v.literal("resolution"),
+  id: nonEmptyString,
+  issueId: nonEmptyString,
+  decision: nonEmptyString,
+  evidence: v.pipe(v.array(evidenceSpanSchema), v.minLength(1)),
+  winnerCaptureId: nonEmptyString,
+  loserCaptureIds: v.pipe(v.array(nonEmptyString), v.minLength(1)),
+});
+const retractionSchema = v.strictObject({
+  type: v.literal("retraction"),
+  id: nonEmptyString,
+  captureId: nonEmptyString,
+  evidence: v.pipe(v.array(evidenceSpanSchema), v.minLength(1)),
+});
+const issueClosedSchema = v.strictObject({
+  type: v.literal("issue-closed"),
+  id: nonEmptyString,
+  issueId: nonEmptyString,
+});
+const snapshotSchema = v.strictObject({
+  captures: v.array(captureEnvelopeSchema),
+  issues: v.array(issueSchema),
+  events: v.array(
+    v.variant("type", [resolutionSchema, retractionSchema, issueClosedSchema]),
+  ),
+});
+
+/**
+ * Whether two id lists denote the same set, neither repeating. The rule a
+ * resolution has to satisfy is set equality; the length-plus-membership pair
+ * this replaces agreed with it only while references happened to be distinct.
+ */
+const denotesSameCaptureSet = (
+  left: readonly string[],
+  right: readonly string[],
+): boolean => {
+  const leftIds = new Set(left);
+  const rightIds = new Set(right);
+  return (
+    leftIds.size === left.length &&
+    rightIds.size === right.length &&
+    leftIds.size === rightIds.size &&
+    [...leftIds].every((captureId) => rightIds.has(captureId))
+  );
+};
+
+export const createEmptyCaptureStoreSnapshot = (): CaptureStoreSnapshot => ({
+  captures: [],
+  issues: [],
+  events: [],
+});
+
+export const parseCaptureStoreSnapshot = (
+  input: unknown,
+): CaptureStoreSnapshot => {
+  const snapshot = v.parse(snapshotSchema, input) as CaptureStoreSnapshot;
+  for (const records of [snapshot.captures, snapshot.issues, snapshot.events]) {
+    if (new Set(records.map((record) => record.id)).size !== records.length) {
+      throw new TypeError(
+        "Capture-store record ids must be unique within their record family.",
+      );
+    }
+  }
+  for (const capture of snapshot.captures) {
+    if ("value" in capture.content && !isJsonValue(capture.content.value)) {
+      throw new TypeError(
+        `Capture ${capture.id} contains a value that cannot be stored as JSON`,
+      );
+    }
+    if (capture.dedupKey !== captureDedupKey(capture)) {
+      throw new TypeError(
+        `Capture ${capture.id} has a stale content dedup key.`,
+      );
+    }
+    if (
+      capture.supersedes &&
+      !snapshot.captures.some(
+        (candidate) => candidate.id === capture.supersedes,
+      )
+    ) {
+      throw new TypeError(
+        `Capture ${capture.id} supersedes an unknown capture.`,
+      );
+    }
+  }
+  const closingEventByIssue = new Map<string, string>();
+  for (const event of snapshot.events) {
+    if (
+      (event.type === "resolution" || event.type === "retraction") &&
+      !event.evidence.every((span) => span.source === "user")
+    ) {
+      throw new TypeError(
+        `${event.type} events must cite evidence whose declared source is the user.`,
+      );
+    }
+    if (event.type === "retraction") {
+      if (
+        !snapshot.captures.some((capture) => capture.id === event.captureId)
+      ) {
+        throw new TypeError(
+          `Retraction ${event.id} references an unknown capture.`,
+        );
+      }
+      continue;
+    }
+    const issue = snapshot.issues.find(
+      (candidate) => candidate.id === event.issueId,
+    );
+    if (!issue)
+      throw new TypeError(`Event ${event.id} references an unknown issue.`);
+    const previousClosingEventId = closingEventByIssue.get(issue.id);
+    if (previousClosingEventId !== undefined) {
+      throw new TypeError(
+        `Issue ${issue.id} has more than one closing event: ${previousClosingEventId} and ${event.id}.`,
+      );
+    }
+    closingEventByIssue.set(issue.id, event.id);
+    if (event.type === "issue-closed") {
+      if (issue.type === "conflicting") {
+        throw new TypeError(
+          "A conflicting issue cannot be closed without a resolution record.",
+        );
+      }
+      continue;
+    }
+    const citedCaptureIds = [event.winnerCaptureId, ...event.loserCaptureIds];
+    if (
+      issue.type !== "conflicting" ||
+      !denotesSameCaptureSet(issue.references, citedCaptureIds)
+    ) {
+      throw new TypeError(
+        `Resolution ${event.id} does not account for its conflict's captures.`,
+      );
+    }
+  }
+  for (const issue of snapshot.issues) {
+    if (
+      issue.references.some(
+        (captureId) =>
+          !snapshot.captures.some((capture) => capture.id === captureId),
+      )
+    ) {
+      throw new TypeError(`Issue ${issue.id} references an unknown capture.`);
+    }
+  }
+  const successorByCapture = new Map<string, string>();
+  const addSuccessor = (captureId: string, successorId: string): void => {
+    if (successorByCapture.has(captureId)) {
+      throw new TypeError(
+        `Capture ${captureId} has a forking supersession history.`,
+      );
+    }
+    successorByCapture.set(captureId, successorId);
+  };
+  for (const capture of snapshot.captures) {
+    if (capture.supersedes) addSuccessor(capture.supersedes, capture.id);
+  }
+  for (const event of snapshot.events) {
+    if (event.type === "resolution") {
+      for (const loserCaptureId of event.loserCaptureIds) {
+        addSuccessor(loserCaptureId, event.winnerCaptureId);
+      }
+    } else if (event.type === "retraction") {
+      addSuccessor(event.captureId, event.id);
+    }
+  }
+  for (const capture of snapshot.captures) {
+    const visited = new Set<string>();
+    let current: string | undefined = capture.id;
+    while (
+      current &&
+      snapshot.captures.some((candidate) => candidate.id === current)
+    ) {
+      if (visited.has(current)) {
+        throw new TypeError(
+          `Capture ${capture.id} participates in a supersession cycle.`,
+        );
+      }
+      visited.add(current);
+      current = successorByCapture.get(current);
+    }
+  }
+  const openConflicts = snapshot.issues.filter(
+    (issue) =>
+      issue.type === "conflicting" && !closingEventByIssue.has(issue.id),
+  );
+  for (const [index, issue] of openConflicts.entries()) {
+    const inactiveReference = issue.references.find(
+      (captureId) => deriveCaptureStatus(snapshot, captureId) !== "active",
+    );
+    if (inactiveReference !== undefined) {
+      throw new TypeError(
+        `Open conflict ${issue.id} references inactive capture ${inactiveReference}.`,
+      );
+    }
+    const overlappingIssue = openConflicts
+      .slice(index + 1)
+      .find((candidate) =>
+        candidate.references.some((captureId) =>
+          issue.references.includes(captureId),
+        ),
+      );
+    if (overlappingIssue !== undefined) {
+      throw new TypeError(
+        `Open conflicts ${issue.id} and ${overlappingIssue.id} share a capture reference.`,
+      );
+    }
+  }
+  return snapshot;
+};
+
+const isJsonValue = (value: unknown): value is JsonValue => {
+  if (value === null || typeof value === "string" || typeof value === "boolean")
+    return true;
+  // Negative zero is refused alongside the non-finite numbers: JSON.stringify
+  // writes it as "0", so the read path could never reproduce what was accepted.
+  if (typeof value === "number")
+    return Number.isFinite(value) && !Object.is(value, -0);
+  if (Array.isArray(value)) return value.every(isJsonValue);
+  if (typeof value !== "object") return false;
+  const prototype = Object.getPrototypeOf(value);
+  return (
+    (prototype === Object.prototype || prototype === null) &&
+    Object.values(value as Record<string, unknown>).every(isJsonValue)
+  );
+};
+
+const canonicalize = (value: JsonValue): JsonValue => {
+  if (Array.isArray(value)) return value.map(canonicalize);
+  if (value !== null && typeof value === "object") {
+    return Object.fromEntries(
+      Object.entries(value)
+        .sort(([left], [right]) => left.localeCompare(right))
+        .map(([key, child]) => [key, canonicalize(child)]),
+    );
+  }
+  return value;
+};
+
+const canonicalString = (value: JsonValue): string =>
+  JSON.stringify(canonicalize(value));
+
+export const captureDedupKey = (proposal: CaptureProposal): string => {
+  const provenance: JsonValue =
+    "evidence" in proposal
+      ? {
+          evidence: [...proposal.evidence]
+            .map((span) => canonicalString(span as unknown as JsonValue))
+            .sort(),
+        }
+      : { basis: proposal.basis as unknown as JsonValue };
+  const content: JsonValue =
+    "absence" in proposal.content
+      ? { absence: proposal.content.absence }
+      : { value: proposal.content.value };
+  return canonicalString({
+    ...provenance,
+    content,
+  });
+};
+
+/**
+ * The model's quote-only proposal identity before the harness anchors it. It
+ * deliberately has no pointer or source: those are assigned by the harness
+ * after the proposal crosses this boundary.
+ */
+const captureOccurrenceKey = (
+  proposal: CaptureInputProposal | CaptureEnvelope,
+): string | undefined => {
+  if (!("evidence" in proposal)) return undefined;
+  const content: JsonValue =
+    "absence" in proposal.content
+      ? { absence: proposal.content.absence }
+      : { value: proposal.content.value };
+  return canonicalString({
+    evidence: proposal.evidence.map((evidence) => evidence.excerpt).sort(),
+    content,
+  });
+};
+
+/**
+ * Sweep retries identify evidence by its harness-owned pointer and cited text,
+ * not its current source classification. A binding may later recognize that the
+ * same archived entry is an affordance payload; that is a provenance update,
+ * not another user occurrence. `dedupKey` remains the persisted content key so
+ * existing target documents retain their validated shape.
+ */
+const captureRetryKey = (proposal: CaptureProposal): string => {
+  const provenance: JsonValue =
+    "evidence" in proposal
+      ? {
+          evidence: [...proposal.evidence]
+            .map((span) =>
+              canonicalString({
+                excerpt: span.excerpt,
+                pointer: span.pointer,
+              } as unknown as JsonValue),
+            )
+            .sort(),
+        }
+      : { basis: proposal.basis as unknown as JsonValue };
+  const content: JsonValue =
+    "absence" in proposal.content
+      ? { absence: proposal.content.absence }
+      : { value: proposal.content.value };
+  return canonicalString({
+    ...provenance,
+    content,
+  });
+};
+
+const priorEvidenceForOccurrence = (
+  snapshot: CaptureStoreSnapshot,
+  sessionId: string,
+  proposal: CaptureInputProposal,
+  occurrence: number,
+): readonly EvidenceSpan[] | undefined => {
+  const occurrenceKey = captureOccurrenceKey(proposal);
+  if (occurrenceKey === undefined) return undefined;
+  return snapshot.captures
+    .filter(
+      (
+        capture,
+      ): capture is Extract<
+        CaptureEnvelope,
+        { readonly evidence: readonly EvidenceSpan[] }
+      > =>
+        "evidence" in capture &&
+        capture.evidence.every(
+          (evidence) => evidence.pointer.sessionId === sessionId,
+        ) &&
+        captureOccurrenceKey(capture) === occurrenceKey,
+    )
+    .at(occurrence)?.evidence;
+};
+
+const refusal = (value: CaptureStoreRefusal): CaptureStoreResult => ({
+  ok: false,
+  refusal: value,
+});
+
+const validateProposal = (
+  input: CaptureProposal,
+): CaptureStoreRefusal | undefined => {
+  const parsed = v.safeParse(captureProposalSchema, input);
+  if (!parsed.success) {
+    return {
+      code: "invalid-envelope",
+      // States what the schema checked, and no more: the spans are structurally
+      // well formed and declare a source, which is not the same as provenance
+      // having been resolved against an entry projection.
+      message:
+        "A capture must carry the provenance shape its epistemic status names, exactly one of value or absence, and evidence ranges that do not end before they start.",
+    };
+  }
+  if (
+    "value" in parsed.output.content &&
+    !isJsonValue(parsed.output.content.value)
+  ) {
+    return {
+      code: "invalid-envelope",
+      message: "A capture value must be JSON-compatible.",
+    };
+  }
+  return undefined;
+};
+
+const validateInputProposal = (
+  input: CaptureInputProposal,
+): CaptureStoreRefusal | undefined => {
+  const parsed = v.safeParse(CaptureInputProposalSchema, input);
+  if (!parsed.success) {
+    return {
+      code: "invalid-envelope",
+      message:
+        "A capture must carry the provenance shape its epistemic status names, exactly one of value or absence, and non-empty verbatim evidence quotes.",
+    };
+  }
+  if (
+    "value" in parsed.output.content &&
+    !isJsonValue(parsed.output.content.value)
+  ) {
+    return {
+      code: "invalid-envelope",
+      message: "A capture value must be JSON-compatible.",
+    };
+  }
+  return undefined;
+};
+
+const requireEvidenceContext = (
+  context: CaptureStoreCommandEvidenceContext | undefined,
+): CaptureStoreCommandEvidenceContext | CaptureStoreRefusal =>
+  context ?? {
+    code: "evidence-session-required",
+    message:
+      "Evidence-bearing commands require the harness-owned session context.",
+  };
+
+export const deriveCaptureStatus = (
+  snapshot: CaptureStoreSnapshot,
+  captureId: string,
+): CaptureStatus => {
+  if (
+    snapshot.events.some(
+      (event) => event.type === "retraction" && event.captureId === captureId,
+    )
+  ) {
+    return "retracted";
+  }
+  if (
+    snapshot.captures.some((capture) => capture.supersedes === captureId) ||
+    snapshot.events.some(
+      (event) =>
+        event.type === "resolution" &&
+        event.loserCaptureIds.includes(captureId),
+    )
+  ) {
+    return "superseded";
+  }
+  return "active";
+};
+
+export const deriveIssueStatus = (
+  snapshot: CaptureStoreSnapshot,
+  issueId: string,
+): IssueStatus =>
+  snapshot.events.some(
+    (event) =>
+      (event.type === "resolution" || event.type === "issue-closed") &&
+      event.issueId === issueId,
+  )
+    ? "closed"
+    : "open";
+
+/**
+ * The unresolved conflicts a capture is named by, which pin it: while one is
+ * open, superseding or retracting the capture would settle the contradiction by
+ * correction and leave the issue as litter — invariant 2's letter kept (no
+ * conflict closed without a user-cited record) and its point lost. Together with
+ * a conflict's two-active-reference minimum, this is what keeps every open
+ * conflict resolvable: its captures cannot leave the active set behind its back.
+ */
+const openConflictsNaming = (
+  snapshot: CaptureStoreSnapshot,
+  captureId: string,
+): string[] =>
+  snapshot.issues
+    .filter(
+      (issue) =>
+        issue.type === "conflicting" &&
+        issue.references.includes(captureId) &&
+        deriveIssueStatus(snapshot, issue.id) === "open",
+    )
+    .map((issue) => issue.id);
+
+const currentHeads = (
+  snapshot: CaptureStoreSnapshot,
+  captureId: string,
+): string[] => {
+  const reachable = new Set([captureId]);
+  let changed = true;
+  while (changed) {
+    changed = false;
+    for (const capture of snapshot.captures) {
+      if (
+        capture.supersedes &&
+        reachable.has(capture.supersedes) &&
+        !reachable.has(capture.id)
+      ) {
+        reachable.add(capture.id);
+        changed = true;
+      }
+    }
+    for (const event of snapshot.events) {
+      if (
+        event.type === "resolution" &&
+        event.loserCaptureIds.some((loserId) => reachable.has(loserId)) &&
+        !reachable.has(event.winnerCaptureId)
+      ) {
+        reachable.add(event.winnerCaptureId);
+        changed = true;
+      }
+    }
+  }
+  return snapshot.captures
+    .filter(
+      (capture) =>
+        capture.id !== captureId &&
+        reachable.has(capture.id) &&
+        deriveCaptureStatus(snapshot, capture.id) === "active",
+    )
+    .map((capture) => capture.id);
+};
+
+const evidenceIdentity = (
+  capture: CaptureProposal | CaptureEnvelope,
+): string | undefined =>
+  "evidence" in capture
+    ? canonicalString(
+        [...capture.evidence]
+          .map((span) => canonicalString(span as unknown as JsonValue))
+          .sort(),
+      )
+    : undefined;
+
+const normalizedPayloadText = (
+  capture: CaptureProposal | CaptureEnvelope,
+): string | undefined =>
+  "value" in capture.content && typeof capture.content.value === "string"
+    ? capture.content.value.trim().replaceAll(/\s+/g, " ").toLocaleLowerCase()
+    : undefined;
+
+const applySweep = (
+  snapshot: CaptureStoreSnapshot,
+  proposals: readonly CaptureProposal[],
+): CaptureStoreResult => {
+  const accepted: CaptureProposal[] = [];
+  const skippedDedupKeys: string[] = [];
+  const targetedCaptures = new Set<string>();
+
+  for (const proposal of proposals) {
+    const invalid = validateProposal(proposal);
+    if (invalid) return refusal(invalid);
+
+    const dedupKey = captureDedupKey(proposal);
+    const retryKey = captureRetryKey(proposal);
+    const exactRetry = snapshot.captures.some(
+      (capture) =>
+        captureRetryKey(capture) === retryKey &&
+        capture.supersedes === proposal.supersedes &&
+        capture.epistemicStatus === proposal.epistemicStatus &&
+        capture.confidence === proposal.confidence &&
+        capture.alternativeGroup === proposal.alternativeGroup,
+    );
+    const duplicateWithoutSupersession =
+      !proposal.supersedes &&
+      snapshot.captures.some(
+        (capture) => captureRetryKey(capture) === retryKey,
+      );
+    const duplicateInBatch = accepted.some(
+      (candidate) =>
+        captureRetryKey(candidate) === retryKey &&
+        candidate.supersedes === proposal.supersedes,
+    );
+    if (exactRetry || duplicateWithoutSupersession || duplicateInBatch) {
+      skippedDedupKeys.push(dedupKey);
+      continue;
+    }
+
+    if (proposal.supersedes) {
+      const target = snapshot.captures.find(
+        (capture) => capture.id === proposal.supersedes,
+      );
+      if (!target) {
+        return refusal({
+          code: "unknown-capture",
+          message: `No capture exists with id ${proposal.supersedes}.`,
+          captureId: proposal.supersedes,
+        });
+      }
+      // Before the head check, because a pinned capture's blocker is the
+      // conflict rather than its position in the supersession chain: the caller
+      // has to resolve the issue, not retarget the head.
+      const blockingIssueIds = openConflictsNaming(snapshot, target.id);
+      if (blockingIssueIds.length > 0) {
+        return refusal({
+          code: "blocked-by-open-conflict",
+          message: `Capture ${target.id} cannot be superseded while an unresolved conflict names it; resolve the conflict first.`,
+          captureId: target.id,
+          blockingIssueIds,
+        });
+      }
+      if (
+        deriveCaptureStatus(snapshot, target.id) !== "active" ||
+        targetedCaptures.has(target.id)
+      ) {
+        return refusal({
+          code: "superseded-target-not-active",
+          message: `Capture ${target.id} is no longer an active head.`,
+          targetCaptureId: target.id,
+          currentHeadIds: currentHeads(snapshot, target.id),
+        });
+      }
+      targetedCaptures.add(target.id);
+    }
+    accepted.push(proposal);
+  }
+
+  const captures = [...snapshot.captures];
+  const appliedCaptureIds: string[] = [];
+  for (const proposal of accepted) {
+    const id = `capture-${randomUUID()}`;
+    captures.push({
+      ...structuredClone(proposal),
+      id,
+      dedupKey: captureDedupKey(proposal),
+    });
+    appliedCaptureIds.push(id);
+  }
+  const nextSnapshot = { ...snapshot, captures };
+  const advisories: CaptureAdvisory[] = [];
+  for (let leftIndex = 0; leftIndex < captures.length; leftIndex += 1) {
+    const left = captures[leftIndex]!;
+    for (
+      let rightIndex = leftIndex + 1;
+      rightIndex < captures.length;
+      rightIndex += 1
+    ) {
+      const right = captures[rightIndex]!;
+      if (
+        (!appliedCaptureIds.includes(left.id) &&
+          !appliedCaptureIds.includes(right.id)) ||
+        deriveCaptureStatus(nextSnapshot, left.id) !== "active" ||
+        deriveCaptureStatus(nextSnapshot, right.id) !== "active" ||
+        left.dedupKey === right.dedupKey
+      ) {
+        continue;
+      }
+      const sameEvidence =
+        evidenceIdentity(left) !== undefined &&
+        evidenceIdentity(left) === evidenceIdentity(right);
+      const leftPayload = normalizedPayloadText(left);
+      const nearIdenticalPayload =
+        leftPayload !== undefined &&
+        leftPayload === normalizedPayloadText(right);
+      if (sameEvidence || nearIdenticalPayload) {
+        advisories.push({
+          type: "possibly-equivalent",
+          reason: sameEvidence ? "same-evidence" : "near-identical-payload",
+          captureIds: [left.id, right.id],
+        });
+      }
+    }
+  }
+  return {
+    ok: true,
+    snapshot: nextSnapshot,
+    value: { appliedCaptureIds, skippedDedupKeys, advisories },
+  };
+};
+
+export const applyCaptureStoreCommand = (
+  snapshot: CaptureStoreSnapshot,
+  command: CaptureStoreCommand,
+  evidenceContext?: CaptureStoreCommandEvidenceContext,
+): CaptureStoreResult => {
+  switch (command.type) {
+    case "apply-sweep": {
+      const invalidProposal = command.proposals
+        .map(validateInputProposal)
+        .find((candidate) => candidate !== undefined);
+      if (invalidProposal) return refusal(invalidProposal);
+
+      const proposals: CaptureProposal[] = [];
+      const anchoringAdvisories: MultipleEvidenceMatchesAdvisory[] = [];
+      const occurrencesByKey = new Map<string, number>();
+      for (const proposal of command.proposals) {
+        if (!("evidence" in proposal)) {
+          proposals.push(structuredClone(proposal));
+          continue;
+        }
+        const context = requireEvidenceContext(evidenceContext);
+        if ("code" in context) return refusal(context);
+        const occurrenceKey = captureOccurrenceKey(proposal);
+        if (occurrenceKey !== undefined) {
+          const occurrence = occurrencesByKey.get(occurrenceKey) ?? 0;
+          occurrencesByKey.set(occurrenceKey, occurrence + 1);
+          const priorEvidence = priorEvidenceForOccurrence(
+            snapshot,
+            context.sessionId,
+            proposal,
+            occurrence,
+          );
+          if (priorEvidence !== undefined) {
+            proposals.push({
+              ...structuredClone(proposal),
+              evidence: structuredClone(priorEvidence),
+            });
+            continue;
+          }
+        }
+        const resolved = resolveEvidenceQuotes(
+          context.archive,
+          context.sessionId,
+          proposal.evidence,
+        );
+        if (!resolved.ok) return refusal(resolved.refusal);
+        proposals.push({
+          ...structuredClone(proposal),
+          evidence: resolved.evidence,
+        });
+        anchoringAdvisories.push(...resolved.advisories);
+      }
+      const result = applySweep(snapshot, proposals);
+      if (!result.ok || !("appliedCaptureIds" in result.value)) return result;
+      return {
+        ...result,
+        value: {
+          ...result.value,
+          advisories: [...anchoringAdvisories, ...result.value.advisories],
+        },
+      };
+    }
+
+    case "open-issue": {
+      const candidateIssue: CaptureIssue = {
+        id: `issue-${randomUUID()}`,
+        type: command.issueType,
+        origin: command.origin,
+        references: structuredClone(command.references),
+        canDefault: command.canDefault,
+      };
+      // Through the same schema a persisted issue is read with, so a command
+      // cannot mint an issue the next read rejects.
+      if (!v.safeParse(issueSchema, candidateIssue).success) {
+        return refusal({
+          code: "invalid-envelope",
+          message:
+            "An issue must carry a known type, an origin naming its producer, and distinct references to at least one capture; a conflicting issue needs at least two.",
+        });
+      }
+      const unknownReference = candidateIssue.references.find(
+        (captureId) =>
+          !snapshot.captures.some((capture) => capture.id === captureId),
+      );
+      if (unknownReference !== undefined) {
+        return refusal({
+          code: "invalid-envelope",
+          message: `An issue must reference existing captures; no capture exists with id ${unknownReference}.`,
+        });
+      }
+      // Activity is a fact about this snapshot, so it is checked here rather
+      // than in the schema: a closed conflict's captures are legitimately
+      // superseded afterwards, and a persisted issue must still parse.
+      const inactiveReference =
+        candidateIssue.type === "conflicting"
+          ? candidateIssue.references.find(
+              (captureId) =>
+                deriveCaptureStatus(snapshot, captureId) !== "active",
+            )
+          : undefined;
+      if (inactiveReference !== undefined) {
+        return refusal({
+          code: "invalid-envelope",
+          message: `A new conflicting issue must reference active captures; capture ${inactiveReference} is ${deriveCaptureStatus(snapshot, inactiveReference)}.`,
+        });
+      }
+      const overlappingOpenConflict =
+        candidateIssue.type === "conflicting"
+          ? snapshot.issues.find(
+              (issue) =>
+                issue.type === "conflicting" &&
+                deriveIssueStatus(snapshot, issue.id) === "open" &&
+                issue.references.some((captureId) =>
+                  candidateIssue.references.includes(captureId),
+                ),
+            )
+          : undefined;
+      if (overlappingOpenConflict !== undefined) {
+        return refusal({
+          code: "invalid-envelope",
+          message: `Open conflicts cannot share capture references; issue ${overlappingOpenConflict.id} already names one of them.`,
+        });
+      }
+      return {
+        ok: true,
+        snapshot: { ...snapshot, issues: [...snapshot.issues, candidateIssue] },
+        value: { issueId: candidateIssue.id },
+      };
+    }
+
+    case "close-issue": {
+      const issue = snapshot.issues.find(
+        (candidate) => candidate.id === command.issueId,
+      );
+      if (!issue) {
+        return refusal({
+          code: "unknown-issue",
+          message: `No issue exists with id ${command.issueId}.`,
+          issueId: command.issueId,
+        });
+      }
+      if (deriveIssueStatus(snapshot, issue.id) === "closed") {
+        return refusal({
+          code: "issue-already-closed",
+          message: `Issue ${issue.id} is already closed.`,
+          issueId: issue.id,
+        });
+      }
+      if (issue.type === "conflicting") {
+        return refusal({
+          code: "resolution-required",
+          message:
+            "A conflicting issue closes only through a user-cited resolution record.",
+          issueId: issue.id,
+        });
+      }
+      const event: IssueClosedEvent = {
+        type: "issue-closed",
+        id: `event-${randomUUID()}`,
+        issueId: issue.id,
+      };
+      return {
+        ok: true,
+        snapshot: { ...snapshot, events: [...snapshot.events, event] },
+        value: { eventId: event.id, advisories: [] },
+      };
+    }
+
+    case "resolve-conflict": {
+      const issue = snapshot.issues.find(
+        (candidate) => candidate.id === command.issueId,
+      );
+      if (!issue) {
+        return refusal({
+          code: "unknown-issue",
+          message: `No issue exists with id ${command.issueId}.`,
+          issueId: command.issueId,
+        });
+      }
+      if (
+        !v.safeParse(
+          v.pipe(v.array(evidenceQuoteSchema), v.minLength(1)),
+          command.evidence,
+        ).success
+      ) {
+        return refusal({
+          code: "invalid-resolution",
+          message:
+            "A conflict resolution must cite non-empty verbatim user quotes.",
+          issueId: issue.id,
+        });
+      }
+      const context = requireEvidenceContext(evidenceContext);
+      if ("code" in context) return refusal(context);
+      const resolved = resolveEvidenceQuotes(
+        context.archive,
+        context.sessionId,
+        command.evidence,
+      );
+      if (!resolved.ok) return refusal(resolved.refusal);
+      const candidateRecord: ResolutionRecord = {
+        type: "resolution" as const,
+        id: `event-${randomUUID()}`,
+        issueId: command.issueId,
+        decision: command.decision,
+        // Cloned, not aliased: the snapshot is the store's record, and a caller
+        // that keeps its evidence array must not be able to edit it afterwards.
+        evidence: structuredClone(resolved.evidence),
+        winnerCaptureId: command.winnerCaptureId,
+        loserCaptureIds: structuredClone(command.loserCaptureIds),
+      };
+      const citedCaptureIds = [
+        command.winnerCaptureId,
+        ...command.loserCaptureIds,
+      ];
+      const invalid =
+        issue.type !== "conflicting" ||
+        deriveIssueStatus(snapshot, issue.id) === "closed" ||
+        !v.safeParse(resolutionSchema, candidateRecord).success ||
+        !resolved.evidence.every((span) => span.source === "user") ||
+        !denotesSameCaptureSet(issue.references, citedCaptureIds) ||
+        citedCaptureIds.some(
+          (captureId) => deriveCaptureStatus(snapshot, captureId) !== "active",
+        );
+      if (invalid) {
+        return refusal({
+          code: "invalid-resolution",
+          message:
+            "A conflict resolution must name an open conflicting issue, declare the user as its evidence source, and account for exactly that issue’s captures, each still active.",
+          issueId: issue.id,
+        });
+      }
+      return {
+        ok: true,
+        snapshot: {
+          ...snapshot,
+          events: [...snapshot.events, candidateRecord],
+        },
+        value: { eventId: candidateRecord.id, advisories: resolved.advisories },
+      };
+    }
+
+    case "retract-capture": {
+      const capture = snapshot.captures.find(
+        (candidate) => candidate.id === command.captureId,
+      );
+      if (!capture) {
+        return refusal({
+          code: "unknown-capture",
+          message: `No capture exists with id ${command.captureId}.`,
+          captureId: command.captureId,
+        });
+      }
+      const blockingIssueIds = openConflictsNaming(snapshot, capture.id);
+      if (blockingIssueIds.length > 0) {
+        return refusal({
+          code: "blocked-by-open-conflict",
+          message: `Capture ${capture.id} cannot be retracted while an unresolved conflict names it; resolve the conflict first.`,
+          captureId: capture.id,
+          blockingIssueIds,
+        });
+      }
+      if (
+        !v.safeParse(
+          v.pipe(v.array(evidenceQuoteSchema), v.minLength(1)),
+          command.evidence,
+        ).success
+      ) {
+        return refusal({
+          code: "invalid-retraction",
+          message: "A retraction must cite non-empty verbatim user quotes.",
+          captureId: capture.id,
+        });
+      }
+      const context = requireEvidenceContext(evidenceContext);
+      if ("code" in context) return refusal(context);
+      const resolved = resolveEvidenceQuotes(
+        context.archive,
+        context.sessionId,
+        command.evidence,
+      );
+      if (!resolved.ok) return refusal(resolved.refusal);
+      const event: RetractionEvent = {
+        type: "retraction",
+        id: `event-${randomUUID()}`,
+        captureId: command.captureId,
+        // Cloned for the same reason as a resolution's: a shallow array copy
+        // still shares every span object with the caller.
+        evidence: structuredClone(resolved.evidence),
+      };
+      if (
+        deriveCaptureStatus(snapshot, capture.id) !== "active" ||
+        !v.safeParse(retractionSchema, event).success ||
+        !resolved.evidence.every((span) => span.source === "user")
+      ) {
+        return refusal({
+          code: "invalid-retraction",
+          message:
+            "Only an active capture can be retracted, and its evidence must declare the user as its source.",
+          captureId: capture.id,
+        });
+      }
+      return {
+        ok: true,
+        snapshot: { ...snapshot, events: [...snapshot.events, event] },
+        value: { eventId: event.id, advisories: resolved.advisories },
+      };
+    }
+
+    default: {
+      const exhaustive: never = command;
+      return exhaustive;
+    }
+  }
+};
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/client-tools.ts b/libs/@hashintel/brunch-agent/packages/core/src/client-tools.ts
new file mode 100644
index 00000000000..3cea4ff89a6
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/client-tools.ts
@@ -0,0 +1,6 @@
+/**
+ * Browser-safe source contracts for Brunch tools rendered by a host UI.
+ */
+
+export { AskInput, AskSubmission } from "./ask-tool-contract";
+export { toolName, type ToolName } from "./naming";
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/index.ts b/libs/@hashintel/brunch-agent/packages/core/src/index.ts
new file mode 100644
index 00000000000..40a29668ac5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/index.ts
@@ -0,0 +1,114 @@
+/**
+ * `@hashintel/brunch-agent` — the harness.
+ *
+ * Mechanism and orchestration: the conversation loop, the ask API, the capture
+ * envelope, the issue queue, sweep bookkeeping. Its public export surface *is*
+ * the plugin SDK (spec §12.2).
+ *
+ * **The harness imports no substrate.** A binding imports both this package and
+ * its substrate; plugins resolve this package only. That direction is enforced
+ * mechanically — see `test/boundaries.test.ts` at the repo root.
+ */
+
+export {
+  AskInput,
+  FreeTextAffordance,
+  type FreeTextAffordance as FreeTextAffordanceValue,
+} from "./affordance";
+export {
+  ASK_TOOL_DESCRIPTION,
+  askAffordanceId,
+  askProtocolInstructionFragments,
+  AskSubmission,
+  buildReplyBindingSignalPayload,
+  decideAskReplyAdmission,
+  decidePendingAffordance,
+  mintAskAffordance,
+  pendingAskAffordanceId,
+  type AskReplyAdmission,
+  type PendingAffordanceDecision,
+  type ReplyBindingSignalPayload,
+} from "./ask-protocol";
+export {
+  OPERATIONS,
+  PRODUCT_NAME,
+  toolName,
+  toolPrefix,
+  type Operation,
+} from "./naming";
+export { type HarnessReplyEvent } from "./reply-protocol";
+export {
+  definePlugin,
+  PluginDescriptor,
+  type Plugin,
+  type PluginProposalType,
+} from "./plugin";
+export {
+  ABSENCE_STATES,
+  CaptureInputProposalSchema,
+  applyCaptureStoreCommand,
+  captureDedupKey,
+  createEmptyCaptureStoreSnapshot,
+  deriveCaptureStatus,
+  deriveIssueStatus,
+  EPISTEMIC_STATUSES,
+  ISSUE_TYPES,
+  parseCaptureStoreSnapshot,
+  type AbsenceState,
+  type CaptureContent,
+  type CaptureAdvisory,
+  type CaptureEnvelope,
+  type CaptureInputProposal,
+  type CaptureIssue,
+  type CaptureProposal,
+  type CaptureStatus,
+  type CaptureStore,
+  type CaptureStoreCommand,
+  type CaptureStoreCommandEvidenceContext,
+  type CaptureStoreEvidenceContext,
+  type CaptureStoreEvent,
+  type CaptureStoreRefusal,
+  type CaptureStoreResult,
+  type CaptureStoreSnapshot,
+  type EpistemicStatus,
+  type EvidenceSpan,
+  type IssueStatus,
+  type IssueOrigin,
+  type IssueType,
+  type JsonValue,
+} from "./capture-store";
+export {
+  type ArchivedSessionEntry,
+  type ArchivedSessionEntryVersion,
+  type EvidenceQuote,
+  type EvidenceResolutionRefusal,
+  type EvidenceResolutionResult,
+  type MultipleEvidenceMatchesAdvisory,
+  type SessionEntryKind,
+} from "./session-log";
+export {
+  advanceSweepHighWater,
+  buildSettlementCheckSignal,
+  buildSweepExtractionPrompt,
+  buildSweepRepairSignal,
+  computeUnaccountedAskAdvisories,
+  createSweepExtractionResultSchema,
+  createInitialSweepState,
+  decideSettlementTrigger,
+  parseSweepState,
+  pendingSweepRepair,
+  reopenSweepAfterRefusal,
+  settlementProtocolInstructionFragments,
+  sweepableRange,
+  unsweptTail,
+  type SettlementCheckSignal,
+  type SettlementTriggerDecision,
+  type SweepAffordance,
+  type SweepExtraction,
+  type SweepRepairSignal,
+  type SweepRefusalFact,
+  type SweepResultFact,
+  type SweepSessionEntry,
+  type SweepState,
+  type UnaccountedAskAdvisory,
+} from "./sweep-protocol";
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/naming.ts b/libs/@hashintel/brunch-agent/packages/core/src/naming.ts
new file mode 100644
index 00000000000..1de764ed553
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/naming.ts
@@ -0,0 +1,81 @@
+/**
+ * Tool namespacing (spec §12.3).
+ *
+ * Architectural strings name **identity, not function**. Every model-facing
+ * tool is harness-owned, and its name is the product name applied to an
+ * abstract operation — so the unresolved product name costs exactly one edit
+ * here rather than a repo-wide rename. `elicit_*` is the anti-pattern: it
+ * names what the tool does, which is the one thing the name must not fix.
+ *
+ * Core names operations abstractly; the binding renders substrate tool names
+ * from them (spec §10, §4).
+ */
+
+/**
+ * The product name.
+ *
+ * Settled as `brunch` (ADR-0001), which is a deliberate exception to the
+ * spec's "nothing bakes 'brunch' into structure": the name-fog resolved in
+ * favour of the working label rather than away from it. The rule that still
+ * binds is the one about *function* — the prefix names who the tool belongs
+ * to, never what it does, so `elicit_*` stays forbidden.
+ *
+ * Should the name ever move again, this constant is the only line that
+ * changes; everything model-facing derives from it.
+ */
+export const PRODUCT_NAME = "brunch";
+
+/**
+ * The abstract operations core names. The binding renders each into its
+ * substrate's tool namespace; nothing here knows Flue's dialect.
+ *
+ * Milestone one grows this list one slice at a time. `ask` proves suspension;
+ * `sweep` proves the first durable session-to-document transition.
+ */
+export const OPERATIONS = ["ask", "sweep"] as const;
+
+export type Operation = (typeof OPERATIONS)[number];
+export type ToolName<OperationName extends Operation = Operation> =
+  `${typeof PRODUCT_NAME}_${OperationName}`;
+
+const IDENTIFIER = /^[a-z][a-z0-9_]*$/;
+
+/**
+ * Derive the tool-name prefix from a product name: lowercased, stripped to
+ * alphanumerics, terminated with `_`.
+ *
+ * Refuses rather than silently emptying — a nameless prefix would collide with
+ * the substrate's reserved tool names (spec §10, recorded Flue facts).
+ */
+export function toolPrefix(productName: string = PRODUCT_NAME): string {
+  const normalized = productName.toLowerCase().replace(/[^a-z0-9]/g, "");
+  if (!/^[a-z][a-z0-9]*$/.test(normalized)) {
+    throw new Error(
+      `Unusable product name ${JSON.stringify(productName)}: a tool prefix must normalize to alphanumerics starting with a letter.`,
+    );
+  }
+  return `${normalized}_`;
+}
+
+/**
+ * Render an abstract operation into its model-facing tool name.
+ *
+ * The parameter is the `Operation` union, not `string`, so a misspelled
+ * operation is a compile error rather than a misnamed tool the model quietly
+ * fails to find. The runtime guard stays for untyped callers.
+ */
+export function toolName<OperationName extends Operation>(
+  operation: OperationName,
+): ToolName<OperationName>;
+export function toolName(operation: Operation, productName: string): string;
+export function toolName(
+  operation: Operation,
+  productName: string = PRODUCT_NAME,
+): string {
+  if (!IDENTIFIER.test(operation)) {
+    throw new Error(
+      `Unusable operation name ${JSON.stringify(operation)}: expected a lowercase identifier.`,
+    );
+  }
+  return `${toolPrefix(productName)}${operation}`;
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/plugin.ts b/libs/@hashintel/brunch-agent/packages/core/src/plugin.ts
new file mode 100644
index 00000000000..34c8403d420
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/plugin.ts
@@ -0,0 +1,60 @@
+import * as v from "valibot";
+
+import type { CaptureInputProposal } from "./capture-store";
+
+/**
+ * The plugin descriptor — identity only, at this stage.
+ *
+ * The plugin's real surface is its packs and the four operations (spec §6.1,
+ * §11.1). Those are **deliberately absent here**: spec §13's two-targets rule
+ * says the trivial target must not freeze the plugin contract before the hard
+ * target has stressed it, so nothing in this scaffold ratifies the SDK export
+ * surface. What the descriptor fixes now is only what the topology needs —
+ * that a plugin declares which target-domain it defines, and does so through
+ * Valibot like every other boundary in the system (spec §12.4).
+ */
+export const PluginDescriptor = v.object({
+  /** Package-level identity, matching the `plugin-*` role prefix (spec §12.2). */
+  name: v.pipe(
+    v.string(),
+    v.regex(/^plugin-[a-z][a-z0-9-]*$/, "expected a `plugin-<name>` name"),
+  ),
+  /** The artifact family this plugin elicits — gherkin scenarios, assurance arguments. */
+  targetDomain: v.pipe(v.string(), v.nonEmpty()),
+});
+
+export interface PluginProposalType {
+  readonly name: string;
+  readonly description: string;
+  readonly schema: v.GenericSchema<unknown, CaptureInputProposal>;
+}
+
+export type Plugin = v.InferOutput<typeof PluginDescriptor> & {
+  /** FE-1392's declared floor; FE-1393 grows the catalog and SDK around it. */
+  readonly proposalCatalog: readonly [PluginProposalType];
+};
+
+/**
+ * Declare a plugin. Inversion of control (spec §4): the plugin declares and
+ * registers; the harness discovers, orders, and invokes. Nothing a plugin
+ * declares can reach persistence — the storage port is harness-defined and
+ * binding-implemented, and plugins are storage-blind (spec §9.6).
+ */
+export function definePlugin(descriptor: Plugin): Plugin {
+  const identity = v.parse(PluginDescriptor, descriptor);
+  const [proposal, ...extraProposals] = descriptor.proposalCatalog;
+  if (!proposal || extraProposals.length > 0) {
+    throw new TypeError(
+      "This slice requires exactly one declared proposal type.",
+    );
+  }
+  const name = v.parse(v.pipe(v.string(), v.nonEmpty()), proposal.name);
+  const description = v.parse(
+    v.pipe(v.string(), v.nonEmpty()),
+    proposal.description,
+  );
+  return {
+    ...identity,
+    proposalCatalog: [{ ...proposal, name, description }],
+  };
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/reply-protocol.ts b/libs/@hashintel/brunch-agent/packages/core/src/reply-protocol.ts
new file mode 100644
index 00000000000..8e5334564c0
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/reply-protocol.ts
@@ -0,0 +1,51 @@
+/**
+ * Substrate-neutral live reply events emitted by a harness binding.
+ *
+ * Transports consume this protocol; no UI wire format and no substrate type
+ * crosses the boundary. Message, part, turn, and tool-call identities are
+ * supplied by the binding and preserved by transports.
+ */
+export type HarnessReplyEvent =
+  | { readonly type: "response-start"; readonly messageId: string }
+  | { readonly type: "turn-start"; readonly turnId: string }
+  | {
+      readonly type: "part-start";
+      readonly kind: "text" | "reasoning";
+      readonly partId: string;
+    }
+  | {
+      readonly type: "part-delta";
+      readonly kind: "text" | "reasoning";
+      readonly partId: string;
+      readonly delta: string;
+    }
+  | {
+      readonly type: "part-end";
+      readonly kind: "text" | "reasoning";
+      readonly partId: string;
+    }
+  | {
+      readonly type: "tool-input";
+      readonly toolCallId: string;
+      readonly toolName: string;
+      readonly input: unknown;
+      readonly execution: "client" | "server";
+    }
+  | {
+      readonly type: "tool-output";
+      readonly toolCallId: string;
+      readonly output: unknown;
+      readonly execution: "client" | "server";
+    }
+  | {
+      readonly type: "tool-output-error";
+      readonly toolCallId: string;
+      readonly errorText: string;
+      readonly execution: "client" | "server";
+    }
+  | { readonly type: "turn-finish"; readonly turnId: string }
+  | {
+      readonly type: "response-finish";
+      readonly terminalState: "completed" | "failed" | "aborted";
+      readonly finishReason: "stop" | "tool-calls" | "error";
+    };
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/session-log.ts b/libs/@hashintel/brunch-agent/packages/core/src/session-log.ts
new file mode 100644
index 00000000000..328c1fa6db6
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/session-log.ts
@@ -0,0 +1,450 @@
+import * as v from "valibot";
+
+import type { EvidenceSpan, JsonValue } from "./capture-store";
+
+export type SessionEntryKind =
+  | "user"
+  | "user-affordance-payload"
+  | "assistant"
+  | "non-user";
+
+export interface SessionLogEntrySnapshot {
+  /** Stable identity supplied by the substrate's public projection. */
+  readonly substrateEntryId: string;
+  /** Harness-owned provenance classification at this read. */
+  readonly kind: SessionEntryKind;
+  /** Materialized text searched for verbatim evidence quotes. */
+  readonly text: string;
+  /** Complete public entry, retained independently of the substrate. */
+  readonly materialized: JsonValue;
+}
+
+export interface SessionLogRead {
+  readonly sessionId: string;
+  /** Substrate projection identity, distinct from the harness session id. */
+  readonly substrateConversationId?: string;
+  /** Opaque substrate checkpoint, retained as provenance and never interpreted. */
+  readonly offset: string;
+  readonly incarnation?: string;
+  readonly entries: readonly SessionLogEntrySnapshot[];
+  readonly settlements: readonly JsonValue[];
+}
+
+export interface ArchivedSessionEntryVersion {
+  readonly version: number;
+  readonly observedAtOffset: string;
+  readonly kind: SessionEntryKind;
+  readonly text: string;
+  readonly materialized: JsonValue;
+}
+
+export interface ArchivedSessionEntry {
+  /** Harness-owned, one-based entry identity used by evidence pointers. */
+  readonly ordinal: number;
+  readonly substrateEntryId: string;
+  readonly substrateIncarnation?: string;
+  readonly versions: readonly ArchivedSessionEntryVersion[];
+}
+
+export interface ArchivedSessionRead {
+  readonly offset: string;
+  readonly substrateConversationId?: string;
+  readonly incarnation?: string;
+  readonly entries: readonly {
+    readonly ordinal: number;
+    readonly version: number;
+  }[];
+  readonly settlements: readonly JsonValue[];
+}
+
+export interface ArchivedSessionLog {
+  readonly sessionId: string;
+  readonly entries: readonly ArchivedSessionEntry[];
+  readonly reads: readonly ArchivedSessionRead[];
+}
+
+export interface SessionLogArchive {
+  readonly sessions: readonly ArchivedSessionLog[];
+}
+
+export interface EvidenceQuote {
+  readonly excerpt: string;
+  /** Persisted pointer fields are deliberately unassignable to caller input. */
+  readonly pointer?: never;
+  /** Provenance is derived from the archive, never asserted by the caller. */
+  readonly source?: never;
+}
+
+export interface MultipleEvidenceMatchesAdvisory {
+  readonly type: "multiple-evidence-matches";
+  readonly excerpt: string;
+  readonly matchCount: number;
+  readonly message: string;
+}
+
+export type EvidenceResolutionRefusal =
+  | {
+      readonly code: "evidence-quote-not-found";
+      readonly excerpt: string;
+      readonly message: string;
+    }
+  | {
+      readonly code: "non-user-evidence";
+      readonly excerpt: string;
+      readonly message: string;
+    };
+
+export type EvidenceResolutionResult =
+  | {
+      readonly ok: true;
+      readonly evidence: readonly EvidenceSpan[];
+      readonly advisories: readonly MultipleEvidenceMatchesAdvisory[];
+    }
+  | { readonly ok: false; readonly refusal: EvidenceResolutionRefusal };
+
+const nonEmptyString = v.pipe(v.string(), v.nonEmpty());
+const positiveInteger = v.pipe(v.number(), v.integer(), v.minValue(1));
+const kindSchema = v.picklist([
+  "user",
+  "user-affordance-payload",
+  "assistant",
+  "non-user",
+]);
+const versionSchema = v.strictObject({
+  version: positiveInteger,
+  observedAtOffset: nonEmptyString,
+  kind: kindSchema,
+  text: v.string(),
+  materialized: v.unknown(),
+});
+const entrySchema = v.strictObject({
+  ordinal: positiveInteger,
+  substrateEntryId: nonEmptyString,
+  substrateIncarnation: v.optional(nonEmptyString),
+  versions: v.pipe(v.array(versionSchema), v.minLength(1)),
+});
+const readSchema = v.strictObject({
+  offset: nonEmptyString,
+  substrateConversationId: v.optional(nonEmptyString),
+  incarnation: v.optional(nonEmptyString),
+  entries: v.array(
+    v.strictObject({
+      ordinal: positiveInteger,
+      version: positiveInteger,
+    }),
+  ),
+  settlements: v.array(v.unknown()),
+});
+const sessionSchema = v.strictObject({
+  sessionId: nonEmptyString,
+  entries: v.array(entrySchema),
+  reads: v.array(readSchema),
+});
+const archiveSchema = v.strictObject({ sessions: v.array(sessionSchema) });
+
+const isJsonValue = (value: unknown): value is JsonValue => {
+  if (value === null || typeof value === "string" || typeof value === "boolean")
+    return true;
+  if (typeof value === "number")
+    return Number.isFinite(value) && !Object.is(value, -0);
+  if (Array.isArray(value)) return value.every(isJsonValue);
+  if (typeof value !== "object") return false;
+  const prototype = Object.getPrototypeOf(value);
+  return (
+    (prototype === Object.prototype || prototype === null) &&
+    Object.values(value as Record<string, unknown>).every(isJsonValue)
+  );
+};
+
+const canonicalize = (value: JsonValue): JsonValue => {
+  if (Array.isArray(value)) return value.map(canonicalize);
+  if (value !== null && typeof value === "object") {
+    return Object.fromEntries(
+      Object.entries(value)
+        .sort(([left], [right]) => left.localeCompare(right))
+        .map(([key, child]) => [key, canonicalize(child)]),
+    );
+  }
+  return value;
+};
+
+const canonicalString = (value: JsonValue): string =>
+  JSON.stringify(canonicalize(value));
+
+export const createEmptySessionLogArchive = (): SessionLogArchive => ({
+  sessions: [],
+});
+
+export const parseSessionLogArchive = (input: unknown): SessionLogArchive => {
+  const archive = v.parse(archiveSchema, input) as SessionLogArchive;
+  const sessionIds = new Set<string>();
+  for (const session of archive.sessions) {
+    if (sessionIds.has(session.sessionId)) {
+      throw new TypeError(`Session log ${session.sessionId} is duplicated.`);
+    }
+    sessionIds.add(session.sessionId);
+    const ordinals = session.entries.map((entry) => entry.ordinal);
+    if (ordinals.some((ordinal, index) => ordinal !== index + 1)) {
+      throw new TypeError(
+        `Session log ${session.sessionId} entry ordinals must be contiguous.`,
+      );
+    }
+    const substrateIdentities = session.entries.map(
+      (entry) =>
+        `${entry.substrateIncarnation ?? ""}\u0000${entry.substrateEntryId}`,
+    );
+    if (new Set(substrateIdentities).size !== substrateIdentities.length) {
+      throw new TypeError(
+        `Session log ${session.sessionId} repeats a substrate entry identity.`,
+      );
+    }
+    for (const entry of session.entries) {
+      if (
+        entry.versions.some((version, index) => version.version !== index + 1)
+      ) {
+        throw new TypeError(
+          `Archived entry ${entry.ordinal} has non-contiguous versions.`,
+        );
+      }
+      for (const version of entry.versions) {
+        if (!isJsonValue(version.materialized)) {
+          throw new TypeError(
+            `Archived entry ${entry.ordinal} is not JSON-compatible.`,
+          );
+        }
+      }
+    }
+    for (const read of session.reads) {
+      if (!read.settlements.every(isJsonValue)) {
+        throw new TypeError(
+          `Session log ${session.sessionId} has a non-JSON settlement.`,
+        );
+      }
+      for (const reference of read.entries) {
+        const archived = session.entries[reference.ordinal - 1];
+        if (!archived || !archived.versions[reference.version - 1]) {
+          throw new TypeError(
+            `Session log ${session.sessionId} read references an unknown entry version.`,
+          );
+        }
+      }
+      const readOrdinals = read.entries.map((reference) => reference.ordinal);
+      if (
+        readOrdinals.some(
+          (ordinal, index) => index > 0 && ordinal <= readOrdinals[index - 1]!,
+        )
+      ) {
+        throw new TypeError(
+          `Session log ${session.sessionId} read entries must be ordered and distinct.`,
+        );
+      }
+    }
+    const readIdentities = session.reads.map((read) =>
+      canonicalString(read as unknown as JsonValue),
+    );
+    if (new Set(readIdentities).size !== readIdentities.length) {
+      throw new TypeError(
+        `Session log ${session.sessionId} repeats a materialized read.`,
+      );
+    }
+  }
+  return archive;
+};
+
+const sameVersion = (
+  archived: ArchivedSessionEntryVersion,
+  incoming: SessionLogEntrySnapshot,
+): boolean =>
+  archived.kind === incoming.kind &&
+  archived.text === incoming.text &&
+  canonicalString(archived.materialized) ===
+    canonicalString(incoming.materialized);
+
+export const archiveSessionLogRead = (
+  archive: SessionLogArchive,
+  read: SessionLogRead,
+): SessionLogArchive => {
+  if (
+    read.sessionId.length === 0 ||
+    read.offset.length === 0 ||
+    read.entries.some(
+      (entry) =>
+        entry.substrateEntryId.length === 0 || !isJsonValue(entry.materialized),
+    ) ||
+    !read.settlements.every(isJsonValue)
+  ) {
+    throw new TypeError(
+      "A session-log read must be non-empty and JSON-compatible.",
+    );
+  }
+  if (
+    new Set(read.entries.map((entry) => entry.substrateEntryId)).size !==
+    read.entries.length
+  ) {
+    throw new TypeError(
+      "A materialized session-log read cannot repeat a substrate entry id.",
+    );
+  }
+
+  const cloned = structuredClone(archive);
+  let session = cloned.sessions.find(
+    (candidate) => candidate.sessionId === read.sessionId,
+  );
+  if (!session) {
+    session = { sessionId: read.sessionId, entries: [], reads: [] };
+    (cloned.sessions as ArchivedSessionLog[]).push(session);
+  }
+  const entries = session.entries as ArchivedSessionEntry[];
+  const readEntries: { ordinal: number; version: number }[] = [];
+
+  for (const incoming of read.entries) {
+    let archived = entries.find(
+      (candidate) =>
+        candidate.substrateEntryId === incoming.substrateEntryId &&
+        candidate.substrateIncarnation === read.incarnation,
+    );
+    if (!archived) {
+      archived = {
+        ordinal: entries.length + 1,
+        substrateEntryId: incoming.substrateEntryId,
+        ...(read.incarnation === undefined
+          ? {}
+          : { substrateIncarnation: read.incarnation }),
+        versions: [],
+      };
+      entries.push(archived);
+    }
+    const versions = archived.versions as ArchivedSessionEntryVersion[];
+    let version = versions.find((candidate) =>
+      sameVersion(candidate, incoming),
+    );
+    if (!version) {
+      version = {
+        version: versions.length + 1,
+        observedAtOffset: read.offset,
+        kind: incoming.kind,
+        text: incoming.text,
+        materialized: structuredClone(incoming.materialized),
+      };
+      versions.push(version);
+    }
+    readEntries.push({ ordinal: archived.ordinal, version: version.version });
+  }
+
+  const archivedRead: ArchivedSessionRead = {
+    offset: read.offset,
+    ...(read.substrateConversationId === undefined
+      ? {}
+      : { substrateConversationId: read.substrateConversationId }),
+    ...(read.incarnation === undefined
+      ? {}
+      : { incarnation: read.incarnation }),
+    entries: readEntries,
+    settlements: structuredClone(read.settlements),
+  };
+  const archivedReadIdentity = canonicalString(
+    archivedRead as unknown as JsonValue,
+  );
+  if (
+    !session.reads.some(
+      (candidate) =>
+        canonicalString(candidate as unknown as JsonValue) ===
+        archivedReadIdentity,
+    )
+  ) {
+    (session.reads as ArchivedSessionRead[]).push(archivedRead);
+  }
+  return parseSessionLogArchive(cloned);
+};
+
+const currentVersion = (
+  entry: ArchivedSessionEntry,
+): ArchivedSessionEntryVersion => entry.versions.at(-1)!;
+
+export const resolveEvidenceQuotes = (
+  archive: SessionLogArchive,
+  sessionId: string,
+  quotes: readonly EvidenceQuote[],
+): EvidenceResolutionResult => {
+  const session = archive.sessions.find(
+    (candidate) => candidate.sessionId === sessionId,
+  );
+  const evidence: EvidenceSpan[] = [];
+  const advisories: MultipleEvidenceMatchesAdvisory[] = [];
+
+  for (const quote of quotes) {
+    const entries = session?.entries ?? [];
+    const allMatches = entries.filter((entry) =>
+      currentVersion(entry).text.includes(quote.excerpt),
+    );
+    const userMatches = allMatches.filter((entry) => {
+      const kind = currentVersion(entry).kind;
+      return kind === "user" || kind === "user-affordance-payload";
+    });
+    if (userMatches.length === 0) {
+      if (allMatches.length > 0) {
+        return {
+          ok: false,
+          refusal: {
+            code: "non-user-evidence",
+            excerpt: quote.excerpt,
+            message: `The quote "${quote.excerpt}" occurs only in injected non-user entries and cannot be cited as user evidence.`,
+          },
+        };
+      }
+      return {
+        ok: false,
+        refusal: {
+          code: "evidence-quote-not-found",
+          excerpt: quote.excerpt,
+          message: `No user entry contains the verbatim quote "${quote.excerpt}". Repair the quote to match the user's words exactly.`,
+        },
+      };
+    }
+    const selected = userMatches.at(-1)!;
+    const selectedKind = currentVersion(selected).kind;
+    const source =
+      selectedKind === "user-affordance-payload"
+        ? "user-affordance-payload"
+        : "user";
+    evidence.push({
+      excerpt: quote.excerpt,
+      pointer: {
+        sessionId,
+        entryStart: selected.ordinal,
+        entryEnd: selected.ordinal,
+      },
+      source,
+    });
+    if (userMatches.length > 1) {
+      advisories.push({
+        type: "multiple-evidence-matches",
+        excerpt: quote.excerpt,
+        matchCount: userMatches.length,
+        message: `The quote matched ${userMatches.length} user entries; the latest match was selected.`,
+      });
+    }
+  }
+
+  return { ok: true, evidence, advisories };
+};
+
+export const readArchivedEntryRange = (
+  archive: SessionLogArchive,
+  pointer: EvidenceSpan["pointer"],
+): readonly ArchivedSessionEntry[] => {
+  const session = archive.sessions.find(
+    (candidate) => candidate.sessionId === pointer.sessionId,
+  );
+  const entries = session?.entries.filter(
+    (entry) =>
+      entry.ordinal >= pointer.entryStart && entry.ordinal <= pointer.entryEnd,
+  );
+  const expectedLength = pointer.entryEnd - pointer.entryStart + 1;
+  if (!entries || entries.length !== expectedLength) {
+    throw new TypeError(
+      `Evidence range ${pointer.sessionId}:${pointer.entryStart}-${pointer.entryEnd} is not archived.`,
+    );
+  }
+  return structuredClone(entries);
+};
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/storage.ts b/libs/@hashintel/brunch-agent/packages/core/src/storage.ts
new file mode 100644
index 00000000000..34e7db9cd12
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/storage.ts
@@ -0,0 +1,18 @@
+/**
+ * Binding-side storage implementation support.
+ *
+ * This subpath is not part of the plugin SDK. It exposes the substrate-neutral
+ * archive reducer/parser used by binding implementations; the actual write
+ * capability remains private to each binding.
+ */
+export {
+  archiveSessionLogRead,
+  createEmptySessionLogArchive,
+  parseSessionLogArchive,
+  readArchivedEntryRange,
+  type ArchivedSessionLog,
+  type ArchivedSessionRead,
+  type SessionLogArchive,
+  type SessionLogEntrySnapshot,
+  type SessionLogRead,
+} from "./session-log";
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/sweep-protocol.ts b/libs/@hashintel/brunch-agent/packages/core/src/sweep-protocol.ts
new file mode 100644
index 00000000000..4672fa7361f
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/sweep-protocol.ts
@@ -0,0 +1,298 @@
+import * as v from "valibot";
+
+import { toolName } from "./naming";
+
+import type {
+  CaptureInputProposal,
+  CaptureStoreRefusal,
+} from "./capture-store";
+import type { Plugin } from "./plugin";
+import type { SessionEntryKind } from "./session-log";
+
+const nonEmptyString = v.pipe(v.string(), v.nonEmpty());
+
+export interface SweepExtraction {
+  readonly proposals: readonly CaptureInputProposal[];
+}
+
+export const createSweepExtractionResultSchema = (
+  plugin: Plugin,
+): v.GenericSchema<unknown, SweepExtraction> =>
+  v.strictObject({
+    proposals: v.array(plugin.proposalCatalog[0].schema),
+  });
+
+export interface SweepAffordance {
+  readonly id: string;
+  readonly markdown: string;
+}
+
+export interface SweepRefusalFact {
+  readonly code: string;
+  readonly message: string;
+}
+
+export interface SweepResultFact {
+  readonly status: "no-settled-range" | "refused" | "applied";
+  readonly refusal?: SweepRefusalFact;
+}
+
+/** Binding-classified history; no substrate message shape crosses this seam. */
+export interface SweepSessionEntry {
+  readonly id: string;
+  readonly kind: SessionEntryKind;
+  readonly text: string;
+  readonly affordances?: readonly SweepAffordance[];
+  readonly replyToAffordanceId?: string;
+  readonly sweepResult?: SweepResultFact;
+  readonly sweepRepairSignal?: true;
+}
+
+export interface SweepState {
+  /** Latest true-user entry included in a successfully applied sweep. */
+  readonly sweptThroughUserEntryId: string | null;
+  /** Loop guard: latest true-user entry offered for settlement judgment. */
+  readonly lastCheckedUserEntryId: string | null;
+}
+
+const sweepStateSchema = v.strictObject({
+  sweptThroughUserEntryId: v.nullable(nonEmptyString),
+  lastCheckedUserEntryId: v.nullable(nonEmptyString),
+});
+
+export const createInitialSweepState = (): SweepState => ({
+  sweptThroughUserEntryId: null,
+  lastCheckedUserEntryId: null,
+});
+
+export const parseSweepState = (input: unknown): SweepState =>
+  v.parse(sweepStateSchema, input);
+
+const isTrueUserEntry = (entry: SweepSessionEntry): boolean =>
+  entry.kind === "user" || entry.kind === "user-affordance-payload";
+
+/**
+ * End at the latest true-user entry. Trailing assistant/tool material remains
+ * eligible for a later range instead of being swept while it is still evolving.
+ */
+export const unsweptTail = (
+  entries: readonly SweepSessionEntry[],
+  state: SweepState,
+): readonly SweepSessionEntry[] => {
+  const parsedState = parseSweepState(state);
+  let startIndex = 0;
+  if (parsedState.sweptThroughUserEntryId !== null) {
+    const highWaterIndex = entries.findIndex(
+      (entry) => entry.id === parsedState.sweptThroughUserEntryId,
+    );
+    if (highWaterIndex < 0 || !isTrueUserEntry(entries[highWaterIndex]!)) {
+      throw new TypeError(
+        `The swept high-water entry ${parsedState.sweptThroughUserEntryId} is absent from durable history or is not a true-user entry.`,
+      );
+    }
+    startIndex = highWaterIndex + 1;
+  }
+
+  const candidate = entries.slice(startIndex);
+  let latestUserIndex = -1;
+  for (let index = candidate.length - 1; index >= 0; index -= 1) {
+    if (isTrueUserEntry(candidate[index]!)) {
+      latestUserIndex = index;
+      break;
+    }
+  }
+  return latestUserIndex < 0 ? [] : candidate.slice(0, latestUserIndex + 1);
+};
+
+/**
+ * A sweep may replay the whole settled prefix. Content identity makes this
+ * safe and lets a later pass repair anything an earlier extraction omitted.
+ */
+export const sweepableRange = (
+  entries: readonly SweepSessionEntry[],
+): readonly SweepSessionEntry[] => {
+  for (let index = entries.length - 1; index >= 0; index -= 1) {
+    if (isTrueUserEntry(entries[index]!)) return entries.slice(0, index + 1);
+  }
+  return [];
+};
+
+export type SettlementTriggerDecision =
+  | {
+      readonly action: "skip";
+      readonly reason:
+        | "pending-affordance"
+        | "no-unswept-user"
+        | "already-checked";
+    }
+  | {
+      readonly action: "nudge";
+      readonly tail: readonly SweepSessionEntry[];
+      readonly throughUserEntryId: string;
+      readonly nextState: SweepState;
+    };
+
+export const decideSettlementTrigger = (input: {
+  readonly entries: readonly SweepSessionEntry[];
+  readonly state: SweepState;
+  readonly pendingAffordance: boolean;
+}): SettlementTriggerDecision => {
+  if (input.pendingAffordance)
+    return { action: "skip", reason: "pending-affordance" };
+
+  const tail = unsweptTail(input.entries, input.state);
+  const latestUser = tail.at(-1);
+  if (!latestUser) return { action: "skip", reason: "no-unswept-user" };
+  if (input.state.lastCheckedUserEntryId === latestUser.id) {
+    return { action: "skip", reason: "already-checked" };
+  }
+  return {
+    action: "nudge",
+    tail,
+    throughUserEntryId: latestUser.id,
+    nextState: parseSweepState({
+      ...input.state,
+      lastCheckedUserEntryId: latestUser.id,
+    }),
+  };
+};
+
+export const advanceSweepHighWater = (
+  state: SweepState,
+  throughUserEntryId: string,
+): SweepState =>
+  parseSweepState({
+    ...state,
+    sweptThroughUserEntryId: throughUserEntryId,
+    lastCheckedUserEntryId: throughUserEntryId,
+  });
+
+/**
+ * Application refusal reopens judgment for the still-unswept range. The
+ * successful high-water remains authoritative; only the once-per-frontier
+ * loop guard rolls back. A model that stops on the repair continuation will
+ * therefore receive one ordinary settlement check instead of stranding the
+ * range behind `already-checked`.
+ */
+export const reopenSweepAfterRefusal = (state: SweepState): SweepState => {
+  const parsedState = parseSweepState(state);
+  return parseSweepState({
+    ...parsedState,
+    lastCheckedUserEntryId: parsedState.sweptThroughUserEntryId,
+  });
+};
+
+const renderEntry = (entry: SweepSessionEntry): readonly string[] => {
+  const rendered: string[] = [];
+  for (const affordance of entry.affordances ?? []) {
+    rendered.push(`[assistant ask] ${affordance.markdown}`);
+  }
+  if (entry.text.length > 0) {
+    const label = isTrueUserEntry(entry) ? "user" : entry.kind;
+    rendered.push(`[${label}] ${entry.text}`);
+  }
+  return rendered;
+};
+
+const renderTail = (tail: readonly SweepSessionEntry[]): string =>
+  tail.flatMap(renderEntry).join("\n");
+
+export interface SettlementCheckSignal {
+  readonly type: "settlement-check";
+  readonly tagName: "settlement-check";
+  readonly body: string;
+}
+
+export const buildSettlementCheckSignal = (
+  tail: readonly SweepSessionEntry[],
+): SettlementCheckSignal => ({
+  type: "settlement-check",
+  tagName: "settlement-check",
+  body: [
+    "The harness computed this unswept conversation tail:",
+    renderTail(tail),
+    `Judge whether this range has settled. If it has, call ${toolName("sweep")}. Declining is legal; continue the interview when the topic is still open.`,
+  ].join("\n\n"),
+});
+
+export const buildSweepExtractionPrompt = (
+  plugin: {
+    readonly targetDomain: string;
+    readonly proposalNames: readonly string[];
+  },
+  tail: readonly SweepSessionEntry[],
+): string =>
+  [
+    `Extract capture proposals for the ${plugin.targetDomain} target from this settled conversation range.`,
+    `Use only the declared proposal schema: ${plugin.proposalNames.join(", ")}. Do not add parsed structure or undeclared proposal types.`,
+    "Every user-grounded proposal must cite one or more exact verbatim quotes from the user lines below. Never supply entry ids, ranges, pointers, or evidence sources; the harness resolves those.",
+    "The declared verbatim interior must preserve what was said without paraphrase or normalization. Return an empty proposal list when no honest capture is available.",
+    renderTail(tail),
+  ].join("\n\n");
+
+export interface SweepRepairSignal {
+  readonly type: "sweep-repair";
+  readonly tagName: "sweep-repair";
+  readonly body: string;
+}
+
+export const buildSweepRepairSignal = (
+  refusal: Pick<CaptureStoreRefusal, "code" | "message"> | SweepRefusalFact,
+): SweepRepairSignal => ({
+  type: "sweep-repair",
+  tagName: "sweep-repair",
+  body: `The sweep was refused: ${refusal.message} Repair the proposal and call ${toolName("sweep")} again. Declining is legal.`,
+});
+
+export const pendingSweepRepair = (
+  entries: readonly SweepSessionEntry[],
+): SweepRefusalFact | null => {
+  let pending: SweepRefusalFact | null = null;
+  for (const entry of entries) {
+    if (entry.sweepRepairSignal) pending = null;
+    if (entry.sweepResult?.status === "refused" && entry.sweepResult.refusal) {
+      pending = entry.sweepResult.refusal;
+    } else if (entry.sweepResult && entry.sweepResult.status !== "refused") {
+      pending = null;
+    }
+  }
+  return pending;
+};
+
+export interface UnaccountedAskAdvisory {
+  readonly type: "unaccounted-ask";
+  readonly affordanceId: string;
+  readonly question: string;
+  readonly message: string;
+}
+
+export const computeUnaccountedAskAdvisories = (
+  tail: readonly SweepSessionEntry[],
+  capturedUserEntryIds: ReadonlySet<string>,
+): readonly UnaccountedAskAdvisory[] => {
+  const accountedAffordanceIds = new Set(
+    tail.flatMap((entry) =>
+      entry.replyToAffordanceId === undefined ||
+      !capturedUserEntryIds.has(entry.id)
+        ? []
+        : [entry.replyToAffordanceId],
+    ),
+  );
+  return tail.flatMap((entry) =>
+    (entry.affordances ?? [])
+      .filter((affordance) => !accountedAffordanceIds.has(affordance.id))
+      .map((affordance) => ({
+        type: "unaccounted-ask" as const,
+        affordanceId: affordance.id,
+        question: affordance.markdown,
+        message:
+          "The swept range contains an ask with no affordance-bound capture.",
+      })),
+  );
+};
+
+export const settlementProtocolInstructionFragments = (): readonly string[] => [
+  "When the harness reports an unswept tail, judge whether that range has settled. Declining is legal.",
+  `When it has settled, call ${toolName("sweep")}. The harness privately extracts quote-anchored proposals, refreshes durable history, applies them atomically, and advances the swept high-water mark only on success.`,
+  "Projection and validation are read-time operations; do not treat sweep completion as a stored derived result.",
+];
diff --git a/libs/@hashintel/brunch-agent/packages/core/src/testing/index.ts b/libs/@hashintel/brunch-agent/packages/core/src/testing/index.ts
new file mode 100644
index 00000000000..b4b297966cd
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/src/testing/index.ts
@@ -0,0 +1,46 @@
+/**
+ * `@hashintel/brunch-agent/testing` — fixtures, arbitraries, and the replay driver.
+ *
+ * A subpath rather than a package so production bundles stay clean (spec
+ * §12.2): nothing on a deploy path may import it. That, too, is checked
+ * mechanically rather than merely documented.
+ *
+ * The generation-first corpus and the deterministic replay driver (spec §14.4)
+ * land with their own slices; this module holds the seed fixtures they grow
+ * from.
+ */
+
+import * as v from "valibot";
+
+import { definePlugin, type Plugin } from "../plugin";
+
+const fixtureProposalSchema = v.strictObject({
+  evidence: v.pipe(
+    v.array(v.strictObject({ excerpt: v.pipe(v.string(), v.nonEmpty()) })),
+    v.minLength(1),
+  ),
+  epistemicStatus: v.literal("explicit"),
+  confidence: v.pipe(v.string(), v.nonEmpty()),
+  content: v.strictObject({ value: v.literal("fixture") }),
+});
+
+/**
+ * The smallest honest plugin (spec §11.3), as a fixture: a flat record list and
+ * one validator must suffice, and every harness-contract addition is checked
+ * against the bar it raises. Tests that need *a* plugin without caring which
+ * one take this.
+ */
+export function pluginFixture(overrides: Partial<Plugin> = {}): Plugin {
+  return definePlugin({
+    name: "plugin-fixture",
+    targetDomain: "fixture",
+    proposalCatalog: [
+      {
+        name: "fixture-proposal",
+        description: "A fixture-only capture proposal.",
+        schema: fixtureProposalSchema,
+      },
+    ],
+    ...overrides,
+  });
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/anchoring.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/anchoring.test.ts
new file mode 100644
index 00000000000..224c7aca753
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/anchoring.test.ts
@@ -0,0 +1,301 @@
+import { describe, expect, test } from "vitest";
+
+import {
+  applyCaptureStoreCommand,
+  createEmptyCaptureStoreSnapshot,
+  type CaptureInputProposal,
+  type EvidenceSpan,
+} from "../src/capture-store";
+import {
+  archiveSessionLogRead,
+  createEmptySessionLogArchive,
+} from "../src/session-log";
+
+type UserCaptureInput = Extract<
+  CaptureInputProposal,
+  { readonly evidence: readonly { readonly excerpt: string }[] }
+>;
+
+const archive = archiveSessionLogRead(createEmptySessionLogArchive(), {
+  sessionId: "session-1",
+  offset: "3",
+  entries: [
+    {
+      substrateEntryId: "injected",
+      kind: "non-user",
+      text: "Begin the interview.",
+      materialized: { id: "injected", text: "Begin the interview." },
+    },
+    {
+      substrateEntryId: "first",
+      kind: "user",
+      text: "June works.",
+      materialized: { id: "first", text: "June works." },
+    },
+    {
+      substrateEntryId: "latest",
+      kind: "user",
+      text: "June works.",
+      materialized: { id: "latest", text: "June works." },
+    },
+  ],
+  settlements: [],
+});
+
+const proposal = (excerpt: string): CaptureInputProposal => ({
+  evidence: [{ excerpt }],
+  epistemicStatus: "explicit",
+  confidence: "high",
+  content: { value: "June" },
+});
+
+describe("capture anchoring", () => {
+  test("resolves quotes once at application time and carries latest-match advice", () => {
+    const result = applyCaptureStoreCommand(
+      createEmptyCaptureStoreSnapshot(),
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive },
+    );
+
+    expect(result.ok).toBe(true);
+    if (!result.ok || !("appliedCaptureIds" in result.value))
+      throw new Error("sweep refused");
+    const capture = result.snapshot.captures[0]!;
+    if (!("evidence" in capture))
+      throw new Error("capture did not retain evidence");
+    expect(capture.evidence).toEqual([
+      {
+        excerpt: "June works.",
+        pointer: { sessionId: "session-1", entryStart: 3, entryEnd: 3 },
+        source: "user",
+      },
+    ]);
+    expect(result.value.advisories).toContainEqual({
+      type: "multiple-evidence-matches",
+      excerpt: "June works.",
+      matchCount: 2,
+      message:
+        "The quote matched 2 user entries; the latest match was selected.",
+    });
+  });
+
+  test("keeps a quote-only replay anchored to one archived entry", () => {
+    const firstRead = archiveSessionLogRead(createEmptySessionLogArchive(), {
+      sessionId: "session-1",
+      offset: "1",
+      entries: [
+        {
+          substrateEntryId: "reply",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "reply", text: "June works." },
+        },
+      ],
+      settlements: [],
+    });
+    const first = applyCaptureStoreCommand(
+      createEmptyCaptureStoreSnapshot(),
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: firstRead },
+    );
+    if (!first.ok || !("appliedCaptureIds" in first.value))
+      throw new Error("first sweep refused");
+
+    const replayedRead = archiveSessionLogRead(firstRead, {
+      sessionId: "session-1",
+      offset: "2",
+      entries: [
+        {
+          substrateEntryId: "reply",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "reply", text: "June works." },
+        },
+      ],
+      settlements: [],
+    });
+    const replay = applyCaptureStoreCommand(
+      first.snapshot,
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: replayedRead },
+    );
+
+    expect(replay.ok).toBe(true);
+    if (!replay.ok || !("skippedDedupKeys" in replay.value))
+      throw new Error("replay refused");
+    expect(replay.snapshot.captures).toHaveLength(1);
+    expect(replay.value.skippedDedupKeys).toEqual([
+      first.snapshot.captures[0]!.dedupKey,
+    ]);
+  });
+
+  test("keeps a full-prefix replay bound to its first matching occurrence", () => {
+    const firstRead = archiveSessionLogRead(createEmptySessionLogArchive(), {
+      sessionId: "session-1",
+      offset: "1",
+      entries: [
+        {
+          substrateEntryId: "first",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "first", text: "June works." },
+        },
+      ],
+      settlements: [],
+    });
+    const first = applyCaptureStoreCommand(
+      createEmptyCaptureStoreSnapshot(),
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: firstRead },
+    );
+    if (!first.ok) throw new Error("first sweep refused");
+
+    const secondRead = archiveSessionLogRead(firstRead, {
+      sessionId: "session-1",
+      offset: "2",
+      entries: [
+        {
+          substrateEntryId: "first",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "first", text: "June works." },
+        },
+        {
+          substrateEntryId: "second",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "second", text: "June works." },
+        },
+      ],
+      settlements: [],
+    });
+    const replay = applyCaptureStoreCommand(
+      first.snapshot,
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: secondRead },
+    );
+
+    expect(replay.ok).toBe(true);
+    if (!replay.ok || !("skippedDedupKeys" in replay.value))
+      throw new Error("replay refused");
+    expect(replay.snapshot.captures).toHaveLength(1);
+    expect(
+      replay.snapshot.captures.flatMap((capture) =>
+        "evidence" in capture
+          ? capture.evidence.map((span) => span.pointer.entryStart)
+          : [],
+      ),
+    ).toEqual([1]);
+
+    // A full-prefix extraction has one proposal for A and a genuinely new
+    // proposal for B. Their quotes and contents are intentionally identical;
+    // their ordered occurrence slots are assigned by the harness.
+    const bothOccurrences = applyCaptureStoreCommand(
+      replay.snapshot,
+      {
+        type: "apply-sweep",
+        proposals: [proposal("June works."), proposal("June works.")],
+      },
+      { sessionId: "session-1", archive: secondRead },
+    );
+    expect(bothOccurrences.ok).toBe(true);
+    if (!bothOccurrences.ok) throw new Error("full-prefix sweep refused");
+    expect(bothOccurrences.snapshot.captures).toHaveLength(2);
+    expect(
+      bothOccurrences.snapshot.captures.flatMap((capture) =>
+        "evidence" in capture
+          ? capture.evidence.map((span) => span.pointer.entryStart)
+          : [],
+      ),
+    ).toEqual([1, 2]);
+  });
+
+  test("does not duplicate a retry when its archived source is reclassified", () => {
+    const firstRead = archiveSessionLogRead(createEmptySessionLogArchive(), {
+      sessionId: "session-1",
+      offset: "1",
+      entries: [
+        {
+          substrateEntryId: "reply",
+          kind: "user",
+          text: "June works.",
+          materialized: { id: "reply", text: "June works." },
+        },
+      ],
+      settlements: [],
+    });
+    const first = applyCaptureStoreCommand(
+      createEmptyCaptureStoreSnapshot(),
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: firstRead },
+    );
+    if (!first.ok) throw new Error("first sweep refused");
+
+    const reclassifiedRead = archiveSessionLogRead(firstRead, {
+      sessionId: "session-1",
+      offset: "2",
+      entries: [
+        {
+          substrateEntryId: "reply",
+          kind: "user-affordance-payload",
+          text: "June works.",
+          materialized: {
+            id: "reply",
+            text: "June works.",
+            affordanceId: "when",
+          },
+        },
+      ],
+      settlements: [],
+    });
+    const retry = applyCaptureStoreCommand(
+      first.snapshot,
+      { type: "apply-sweep", proposals: [proposal("June works.")] },
+      { sessionId: "session-1", archive: reclassifiedRead },
+    );
+
+    expect(retry.ok).toBe(true);
+    if (!retry.ok) throw new Error("retry sweep refused");
+    expect(retry.snapshot.captures).toHaveLength(1);
+  });
+
+  test("refuses an injected entry and a missing quote before writing a capture", () => {
+    for (const [excerpt, code] of [
+      ["Begin the interview.", "non-user-evidence"],
+      ["July works.", "evidence-quote-not-found"],
+    ] as const) {
+      expect(
+        applyCaptureStoreCommand(
+          createEmptyCaptureStoreSnapshot(),
+          { type: "apply-sweep", proposals: [proposal(excerpt)] },
+          { sessionId: "session-1", archive },
+        ),
+      ).toMatchObject({ ok: false, refusal: { code } });
+    }
+  });
+
+  test("caller-facing evidence accepts quotes, not ranges or source assertions", () => {
+    const evidence: UserCaptureInput["evidence"] = [
+      {
+        excerpt: "June works.",
+        // @ts-expect-error Entry ranges are harness-owned and absent from caller input.
+        pointer: { sessionId: "session-1", entryStart: 1, entryEnd: 1 },
+      },
+    ];
+    expect(evidence[0] as unknown).toEqual({
+      excerpt: "June works.",
+      pointer: { sessionId: "session-1", entryStart: 1, entryEnd: 1 },
+    });
+
+    const storedSpan: EvidenceSpan = {
+      excerpt: "June works.",
+      pointer: { sessionId: "session-1", entryStart: 1, entryEnd: 1 },
+      source: "user",
+    };
+    const callerQuotes: readonly UserCaptureInput["evidence"][number][] = [
+      // @ts-expect-error A stored span is not assignable to caller quote input.
+      storedSpan,
+    ];
+    expect(callerQuotes).toHaveLength(1);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/baseline-runner.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/baseline-runner.test.ts
new file mode 100644
index 00000000000..93f38d9a23e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/baseline-runner.test.ts
@@ -0,0 +1,210 @@
+import { spawn } from "node:child_process";
+import { cp, mkdtemp, readFile, rm } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+import { pathToFileURL } from "node:url";
+
+import { afterEach, describe, expect, test } from "vitest";
+
+import { CONTEXT_ROOT, contextRootPresent } from "./workspace";
+
+const BASELINE_DIR = join(
+  CONTEXT_ROOT,
+  "docs/planning/process-model-elicitation/baseline",
+);
+const STUB_MODULE = pathToFileURL(
+  join(import.meta.dirname, "fixtures/baseline-anthropic-stub.ts"),
+).href;
+const temporaryDirectories: string[] = [];
+
+interface StubReply {
+  text: string;
+  truncated?: boolean;
+}
+
+async function createBaselineCopy(): Promise<string> {
+  const testDirectory = await mkdtemp(join(tmpdir(), "baseline-runner-test-"));
+  temporaryDirectories.push(testDirectory);
+  await cp(BASELINE_DIR, testDirectory, { recursive: true });
+  await rm(join(testDirectory, "transcripts"), {
+    recursive: true,
+    force: true,
+  });
+  return testDirectory;
+}
+
+async function runBaseline(
+  testDirectory: string,
+  replies: StubReply[],
+  mode?: "--resume" | "--continue-final",
+): Promise<{
+  checkpoint: {
+    stopReason: string;
+    calls: unknown[];
+    interviewerMessages: Array<{
+      role: "user" | "assistant";
+      content: string;
+      truncated?: boolean;
+    }>;
+  };
+  stderr: string;
+  requests: Array<{ messages: Array<Record<string, unknown>> }>;
+}> {
+  const requestsPath = join(testDirectory, "requests.jsonl");
+  const subprocess = spawn(
+    process.execPath,
+    ["--experimental-strip-types", "run.ts", "1", ...(mode ? [mode] : [])],
+    {
+      cwd: testDirectory,
+      env: {
+        ...process.env,
+        BRUNCH_BASELINE_ANTHROPIC_MODULE: STUB_MODULE,
+        BASELINE_STUB_REPLIES: JSON.stringify(replies),
+        BASELINE_STUB_REQUESTS_PATH: requestsPath,
+      },
+      stdio: ["ignore", "ignore", "pipe"],
+    },
+  );
+  subprocess.stderr.setEncoding("utf8");
+  let stderr = "";
+  subprocess.stderr.on("data", (chunk: string) => {
+    stderr += chunk;
+  });
+  const exitCode = await new Promise<number | null>((resolve, reject) => {
+    subprocess.once("error", reject);
+    subprocess.once("close", resolve);
+  });
+  expect(exitCode).toBe(0);
+
+  const checkpoint = JSON.parse(
+    await readFile(
+      join(testDirectory, "transcripts/condition-1.raw.json"),
+      "utf8",
+    ),
+  );
+  const requests = (await readFile(requestsPath, "utf8"))
+    .trim()
+    .split("\n")
+    .map((line) => JSON.parse(line));
+  return { checkpoint, stderr, requests };
+}
+
+afterEach(async () => {
+  await Promise.all(
+    temporaryDirectories
+      .splice(0)
+      .map((directory) => rm(directory, { recursive: true, force: true })),
+  );
+});
+
+describe.skipIf(!contextRootPresent)(
+  "baseline runner completion metadata",
+  () => {
+    test("checkpoints a truncated expert reply and stops before another interviewer call", async () => {
+      const testDirectory = await createBaselineCopy();
+      const result = await runBaseline(testDirectory, [
+        { text: "What happens next?" },
+        { text: "NO" },
+        { text: "The operator begins to explain", truncated: true },
+      ]);
+
+      expect(result.checkpoint.calls).toHaveLength(3);
+      expect(result.checkpoint.stopReason).toBe("expert-truncated");
+      expect(result.checkpoint.interviewerMessages.at(-1)).toEqual({
+        role: "user",
+        content: "The operator begins to explain",
+        truncated: true,
+      });
+      expect(result.stderr).toContain("expert reply is truncated");
+    });
+
+    test("resume regenerates a trailing truncated expert reply before continuing", async () => {
+      const testDirectory = await createBaselineCopy();
+      await runBaseline(testDirectory, [
+        { text: "What happens next?" },
+        { text: "NO" },
+        { text: "Partial expert reply", truncated: true },
+      ]);
+
+      const resumed = await runBaseline(
+        testDirectory,
+        [
+          { text: "Complete expert reply" },
+          { text: "Final model" },
+          { text: "YES" },
+        ],
+        "--resume",
+      );
+
+      expect(resumed.checkpoint.stopReason).toBe("delivered");
+      expect(resumed.checkpoint.interviewerMessages).toEqual([
+        expect.objectContaining({ role: "user" }),
+        { role: "assistant", content: "What happens next?" },
+        { role: "user", content: "Complete expert reply" },
+        { role: "assistant", content: "Final model" },
+      ]);
+      expect(resumed.stderr).toContain("regenerating truncated expert reply");
+    });
+
+    test("checkpoints a capped non-final interviewer reply and stops before calling the expert", async () => {
+      const testDirectory = await createBaselineCopy();
+      const result = await runBaseline(testDirectory, [
+        { text: "part-1", truncated: true },
+        { text: "part-2", truncated: true },
+        { text: "part-3", truncated: true },
+        { text: "part-4", truncated: true },
+        { text: "part-5", truncated: true },
+        { text: "NO" },
+      ]);
+
+      expect(result.checkpoint.calls).toHaveLength(6);
+      expect(result.checkpoint.stopReason).toBe("interviewer-truncated");
+      expect(result.checkpoint.interviewerMessages.at(-1)).toEqual({
+        role: "assistant",
+        content: "part-1part-2part-3part-4part-5",
+        truncated: true,
+      });
+      expect(result.stderr).toContain(
+        "non-final interviewer reply is truncated",
+      );
+    });
+
+    test("continues a truncated final delivery without sending checkpoint metadata", async () => {
+      const testDirectory = await createBaselineCopy();
+      await runBaseline(testDirectory, [
+        { text: "part-1", truncated: true },
+        { text: "part-2", truncated: true },
+        { text: "part-3", truncated: true },
+        { text: "part-4", truncated: true },
+        { text: "part-5", truncated: true },
+        { text: "YES" },
+      ]);
+      await rm(join(testDirectory, "requests.jsonl"));
+
+      const continued = await runBaseline(
+        testDirectory,
+        [{ text: " continued" }],
+        "--continue-final",
+      );
+
+      expect(continued.requests).toHaveLength(1);
+      expect(continued.requests[0]?.messages).toEqual([
+        expect.objectContaining({ role: "user" }),
+        { role: "assistant", content: "part-1part-2part-3part-4part-5" },
+        {
+          role: "user",
+          content:
+            "You were cut off mid-document. Continue exactly from where you stopped — no preamble, no repetition.",
+        },
+      ]);
+      for (const message of continued.requests[0]?.messages ?? []) {
+        expect(Object.keys(message).sort()).toEqual(["content", "role"]);
+      }
+      expect(continued.checkpoint.stopReason).toBe("delivered");
+      expect(continued.checkpoint.interviewerMessages.at(-1)).toEqual({
+        role: "assistant",
+        content: "part-1part-2part-3part-4part-5 continued",
+      });
+    });
+  },
+);
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/boundaries.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/boundaries.test.ts
new file mode 100644
index 00000000000..9f447276438
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/boundaries.test.ts
@@ -0,0 +1,501 @@
+/**
+ * The architectural boundaries, as tests rather than as documentation.
+ *
+ * Spec §4 and §12.2 state the dependency direction as invariants; an invariant
+ * nobody can run is a wish. These are the mechanical checks — they read the
+ * real tree, so a package added later is governed without opting in.
+ *
+ * Two of them are load-bearing beyond tidiness, because the Flue build is
+ * silent about the failure: a `'use agent'` directive that is not the file's
+ * first statement builds green and simply never registers the agent.
+ */
+
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, test } from "vitest";
+
+import {
+  AGENT_DIRECTIVE_STATEMENT,
+  agentModules,
+  allDependencies,
+  CONTEXT_ROOT,
+  importedPackages,
+  MODEL_KEY_NAME,
+  packageOf,
+  pinnedIdentities,
+  runtimeDependencies,
+  sourceFiles,
+  testFiles,
+  workspacePackages,
+  type WorkspacePackage,
+} from "./workspace";
+
+const PACKAGES = workspacePackages();
+
+const CORE = "@hashintel/brunch-agent";
+/** Any substrate package. The harness may never name one; a binding must. */
+const SUBSTRATE_SCOPES = ["@flue/", "@earendil-works/"];
+
+const isSubstrate = (name: string): boolean =>
+  SUBSTRATE_SCOPES.some((scope) => name.startsWith(scope));
+const byRole = (role: string): WorkspacePackage[] =>
+  PACKAGES.filter((pkg) => pkg.dir.startsWith(`${role}-`));
+
+test("every workspace package is one the spec topology names", () => {
+  // Derived from the spec's own §12.2 topology block instead of a second
+  // hand-written list here. The spec names *intended* structure — some
+  // entries are not scaffolded yet — so the direction checked is disk ⊆
+  // spec: a package the spec does not name is loud, while an
+  // intended-but-unbuilt one is not a failure. (The old hardcoded equality
+  // would have failed the next legitimate package instead of governing it.)
+  const spec = readFileSync(join(CONTEXT_ROOT, "docs/spec.md"), "utf8");
+  const topology = /### 12\.2[^\n]*\n[\s\S]*?```text\n([\s\S]*?)```/.exec(
+    spec,
+  )?.[1];
+  expect(topology).toBeDefined();
+  const named = new Set(
+    [...topology!.matchAll(/^((?:packages|apps)\/[\w-]+)(?=\s|$)/gm)].map(
+      (match) => match[1]!,
+    ),
+  );
+  expect(named.size).toBeGreaterThan(0);
+  for (const pkg of PACKAGES) {
+    const standalonePath =
+      pkg.kind === "app" ? "apps/dev" : `packages/${pkg.dir}`;
+    expect({ pkg: pkg.relPath, inSpec: named.has(standalonePath) }).toEqual({
+      pkg: pkg.relPath,
+      inSpec: true,
+    });
+  }
+});
+
+test("every package is actually scanned", () => {
+  // Without this, a package the file walker misses passes every file-level
+  // invariant vacuously — the substrate-import ban, the plugin-resolves-core
+  // rule, and the schema-library ban would all iterate an empty list and go
+  // green. A silent exemption is worse than no check at all.
+  for (const pkg of PACKAGES) {
+    expect({ pkg: pkg.relPath, scanned: sourceFiles(pkg).length > 0 }).toEqual({
+      pkg: pkg.relPath,
+      scanned: true,
+    });
+  }
+});
+
+describe("role prefixes name what a package is architecturally (spec §12.2)", () => {
+  test("every package under packages/ is core or carries a role prefix", () => {
+    for (const pkg of PACKAGES.filter((p) => p.kind === "package")) {
+      expect(pkg.dir).toMatch(
+        /^(core|plugin-[a-z0-9-]+|binding-[a-z0-9-]+|transport-[a-z0-9-]+)$/,
+      );
+    }
+  });
+
+  test("no package uses an avoided role noun", () => {
+    // The glossary's own noun is `binding`; `adapter-*` and `wrapper-*` are
+    // avoided terms, and `elicit-*` names function rather than identity.
+    for (const pkg of PACKAGES) {
+      expect(pkg.dir).not.toMatch(/^(adapter|wrapper|elicit)-/);
+    }
+  });
+
+  test("the manifest name matches the role-prefixed directory", () => {
+    for (const pkg of PACKAGES) {
+      const expectedName =
+        pkg.kind === "app"
+          ? "@apps/brunch-agent"
+          : pkg.dir === "core"
+            ? CORE
+            : `@hashintel/brunch-agent-${pkg.dir}`;
+      expect(pkg.name).toBe(expectedName);
+    }
+  });
+});
+
+describe("dependency direction (spec §4, §12.2)", () => {
+  test("the harness imports no substrate", () => {
+    const core = PACKAGES.find((pkg) => pkg.name === CORE);
+    expect(core).toBeDefined();
+    expect(allDependencies(core!).filter(isSubstrate)).toEqual([]);
+    for (const file of sourceFiles(core!)) {
+      const substrateImports = importedPackages(file).filter((s) =>
+        isSubstrate(packageOf(s)),
+      );
+      expect({ file: file.relPath, substrateImports }).toEqual({
+        file: file.relPath,
+        substrateImports: [],
+      });
+    }
+  });
+
+  test("the harness depends on no binding and no plugin", () => {
+    const core = PACKAGES.find((pkg) => pkg.name === CORE)!;
+    for (const dependency of runtimeDependencies(core)) {
+      expect(dependency).not.toMatch(
+        /^@hashintel\/brunch-agent-(binding|plugin)-/u,
+      );
+    }
+  });
+
+  test("plugins resolve core only — never the binding, never Flue", () => {
+    const plugins = byRole("plugin");
+    expect(plugins.length).toBeGreaterThan(0);
+    for (const plugin of plugins) {
+      const workspaceDeps = runtimeDependencies(plugin).filter((dependency) =>
+        dependency.startsWith("@hashintel/brunch-agent"),
+      );
+      expect(workspaceDeps).toEqual([CORE]);
+      expect(allDependencies(plugin).filter(isSubstrate)).toEqual([]);
+
+      for (const file of sourceFiles(plugin)) {
+        for (const specifier of importedPackages(file)) {
+          const pkg = packageOf(specifier);
+          expect(isSubstrate(pkg)).toBe(false);
+          if (pkg.startsWith("@hashintel/brunch-agent")) expect(pkg).toBe(CORE);
+          expect(specifier).not.toBe(`${CORE}/storage`);
+        }
+      }
+    }
+  });
+
+  test("a binding imports both", () => {
+    const bindings = byRole("binding");
+    expect(bindings.length).toBeGreaterThan(0);
+    for (const binding of bindings) {
+      const deps = runtimeDependencies(binding);
+      expect(deps).toContain(CORE);
+      expect(deps.some(isSubstrate)).toBe(true);
+    }
+  });
+
+  test("bindings depend on no plugin — the harness discovers plugins, not the substrate", () => {
+    for (const binding of byRole("binding")) {
+      for (const dependency of runtimeDependencies(binding)) {
+        expect(dependency).not.toMatch(/^@hashintel\/brunch-agent-plugin-/u);
+      }
+    }
+  });
+
+  test("transports consume harness parts and their wire encoder only", () => {
+    const transports = byRole("transport");
+    expect(transports.length).toBeGreaterThan(0);
+    for (const transport of transports) {
+      expect(runtimeDependencies(transport).sort()).toEqual(
+        [CORE, "ai", "valibot"].sort(),
+      );
+      for (const file of sourceFiles(transport).filter((file) =>
+        file.path.startsWith(join(transport.path, "src")),
+      )) {
+        for (const specifier of importedPackages(file)) {
+          if (specifier.startsWith("node:")) continue;
+          expect([CORE, "ai", "valibot"]).toContain(packageOf(specifier));
+        }
+      }
+    }
+  });
+});
+
+describe("the direction is enforced under HASH's linker", () => {
+  // HASH may hoist dependencies, so physical resolution is not an authority:
+  // an undeclared package can be resolvable by accident. Runtime manifests and
+  // authored imports are the stable boundary surfaces.
+  test("every imported Brunch workspace is a declared runtime dependency", () => {
+    for (const pkg of PACKAGES) {
+      const declared = runtimeDependencies(pkg);
+      for (const file of sourceFiles(pkg)) {
+        for (const imported of importedPackages(file).map(packageOf)) {
+          if (
+            imported === CORE ||
+            imported.startsWith("@hashintel/brunch-agent-")
+          ) {
+            expect({ file: file.relPath, imported, declared }).toEqual({
+              file: file.relPath,
+              imported,
+              declared: expect.arrayContaining([imported]),
+            });
+          }
+        }
+      }
+    }
+  });
+});
+
+describe("Valibot is the schema library at every boundary (spec §12.4)", () => {
+  // Flue locks Valibot at every boundary. A Standard-Schema waist would buy
+  // comfort at the cost of a conversion seam that can silently drop
+  // constraints — the silent-coercion smell.
+  const OTHER_SCHEMA_LIBRARIES = [
+    "zod",
+    "yup",
+    "joi",
+    "ajv",
+    "superstruct",
+    "arktype",
+    "io-ts",
+    "runtypes",
+    "@sinclair/typebox",
+    "@standard-schema/spec",
+    "@standard-schema/utils",
+  ];
+
+  test("no package declares another schema library", () => {
+    for (const pkg of PACKAGES) {
+      for (const forbidden of OTHER_SCHEMA_LIBRARIES) {
+        expect(allDependencies(pkg)).not.toContain(forbidden);
+      }
+    }
+  });
+
+  test("no source file imports another schema library", () => {
+    for (const pkg of PACKAGES) {
+      for (const file of sourceFiles(pkg)) {
+        for (const specifier of importedPackages(file)) {
+          expect(OTHER_SCHEMA_LIBRARIES).not.toContain(packageOf(specifier));
+        }
+      }
+    }
+  });
+
+  test("a package declares valibot exactly when its source imports it", () => {
+    for (const pkg of PACKAGES) {
+      const importsValibot = sourceFiles(pkg).some((file) =>
+        importedPackages(file).some(
+          (specifier) => packageOf(specifier) === "valibot",
+        ),
+      );
+      const declaresValibot = allDependencies(pkg).includes("valibot");
+      expect({ pkg: pkg.relPath, declaresValibot }).toEqual({
+        pkg: pkg.relPath,
+        declaresValibot: importsValibot,
+      });
+    }
+  });
+});
+
+describe("recorded Flue constraints hold by construction (spec §10)", () => {
+  const dev = PACKAGES.find((pkg) => pkg.relPath === "apps/brunch-agent")!;
+  // Statement-anchored detection (see workspace.ts): a comment mentioning the
+  // directive is not an agent module, but a *misplaced* directive still is —
+  // so the first-statement test below sees it and goes red.
+  const devAgentModules = agentModules(dev);
+
+  test("the dev app has at least one agent module", () => {
+    expect(devAgentModules.length).toBeGreaterThan(0);
+  });
+
+  test("'use agent' is the module's first statement", () => {
+    // The build does NOT catch this: a misplaced directive builds green and
+    // the module simply stops being an agent. Nothing else would notice until
+    // a conversation failed to start.
+    for (const file of devAgentModules) {
+      // Comments are not statements, so a leading doc block is legal and must
+      // not read as a violation.
+      const withoutLeadingComments = file.text
+        .replace(/^/, "")
+        .replace(/^(?:\s*(?:\/\/[^\n]*|\/\*[\s\S]*?\*\/))*\s*/, "");
+      // Judged by the same pattern that detects the directive at all
+      // (workspace.ts), so every form the lexicon declares legal — either
+      // quote style, optional semicolon, trailing comment — passes and only
+      // placement can fail. The old literal comparison spuriously failed
+      // forms this suite's own fixtures assert are legal.
+      const firstStatement = withoutLeadingComments.split("\n")[0] ?? "";
+      expect({
+        file: file.relPath,
+        firstStatementIsDirective:
+          AGENT_DIRECTIVE_STATEMENT.test(firstStatement),
+      }).toEqual({ file: file.relPath, firstStatementIsDirective: true });
+    }
+  });
+
+  test("agentName is a pinned string literal", () => {
+    // Conversation storage keys on it, so a computed value is unsupportable
+    // and a changed value orphans every existing conversation. Extraction
+    // goes through the shared pinnedIdentities pattern — a third hand-copied
+    // regex here could silently disagree with the other suites on what
+    // counts as an identity — and this test adds the shape constraint.
+    for (const file of devAgentModules) {
+      const identities = pinnedIdentities(file);
+      expect({ file: file.relPath, pinned: identities.length > 0 }).toEqual({
+        file: file.relPath,
+        pinned: true,
+      });
+      for (const identity of identities) {
+        expect(identity).toMatch(/^[a-z][a-z0-9-]*$/);
+      }
+    }
+  });
+
+  test("a pinned identity appears only in its own agent module", () => {
+    // The mount path (and anything else naming the agent) must derive from
+    // `agentName`, not copy it: a duplicated literal is the seam the FE-1361
+    // review verified — a copy-pasted second agent shadows the mount while
+    // every test stays green, because nothing ties the copies together.
+    const identities = devAgentModules.flatMap((file) =>
+      pinnedIdentities(file).map((identity) => ({
+        identity,
+        pinnedIn: file.relPath,
+      })),
+    );
+    expect(identities.length).toBeGreaterThan(0);
+    // Quoted occurrences only: prose in a comment may *name* the agent without
+    // duplicating its identity into anything the runtime reads — flagging that
+    // would be the cry-wolf failure this ticket removed from the directive
+    // check. A string literal carrying the identity anywhere else is real
+    // duplication, including inside a longer path like '/agents/…'.
+    const STRING_LITERAL = /(['"`])(?:\\.|(?!\1)[^\\\n])*\1/g;
+    for (const { identity, pinnedIn } of identities) {
+      const duplicatedIn = sourceFiles(dev)
+        .filter((file) => file.relPath !== pinnedIn)
+        .filter((file) =>
+          (file.text.match(STRING_LITERAL) ?? []).some((literal) =>
+            literal.includes(identity),
+          ),
+        )
+        .map((file) => file.relPath);
+      expect({ identity, duplicatedIn }).toEqual({
+        identity,
+        duplicatedIn: [],
+      });
+    }
+  });
+
+  test("vite is pinned to 8, which @flue/vite requires", () => {
+    const pinned = PACKAGES.flatMap((pkg) => {
+      const range =
+        pkg.manifest.devDependencies?.vite ?? pkg.manifest.dependencies?.vite;
+      return range ? [range] : [];
+    });
+    expect(pinned.length).toBeGreaterThan(0);
+    for (const range of pinned) expect(range).toMatch(/^\^?8(\.|$)/);
+  });
+
+  test("the dev app owns the agent module, the mount, and the conversation store", () => {
+    // Every host authors its own thin `'use agent'` module, `app.ts` and
+    // `db.ts` — Flue's build-time scan makes shipping a pre-registered agent
+    // from a library structurally unavailable (spec §12.1).
+    for (const file of ["src/app.ts", "src/db.ts"]) {
+      expect(() => readFileSync(join(dev.path, file), "utf8")).not.toThrow();
+    }
+  });
+
+  test("runtime entrypoints never select Flue's Bun adapter", () => {
+    for (const pkg of PACKAGES) {
+      for (const file of [...sourceFiles(pkg), ...testFiles(pkg)]) {
+        expect(importedPackages(file)).not.toContain("@flue/runtime/bun");
+      }
+    }
+  });
+});
+
+describe("core auxiliary subpaths stay in their assigned lanes (spec §12.2)", () => {
+  test("core exposes browser contracts, storage support and testing as explicit subpaths", () => {
+    const core = PACKAGES.find((pkg) => pkg.name === CORE)!;
+    expect(Object.keys(core.manifest.exports ?? {})).toEqual([
+      ".",
+      "./client-tools",
+      "./storage",
+      "./testing",
+    ]);
+  });
+
+  test("no package source imports core/testing", () => {
+    // Fixtures, arbitraries and the replay driver belong to tests; production
+    // bundles stay clean.
+    for (const pkg of PACKAGES) {
+      for (const file of sourceFiles(pkg)) {
+        expect(importedPackages(file)).not.toContain(`${CORE}/testing`);
+      }
+    }
+  });
+
+  test("only bindings import core/storage", () => {
+    for (const pkg of PACKAGES.filter(
+      (candidate) => !candidate.dir.startsWith("binding-"),
+    )) {
+      for (const file of sourceFiles(pkg)) {
+        expect(importedPackages(file)).not.toContain(`${CORE}/storage`);
+      }
+    }
+  });
+});
+
+describe("the HASH smoke is runnable without a model key or a network (spec §12.5)", () => {
+  test("every Brunch workspace exposes HASH lint, typecheck, and unit-test tasks", () => {
+    for (const pkg of PACKAGES) {
+      expect(pkg.manifest.scripts).toMatchObject({
+        "lint:eslint": expect.any(String),
+        "lint:tsc": expect.any(String),
+        "test:unit": expect.stringContaining("vitest run"),
+      });
+    }
+  });
+
+  /** Every Brunch test file Turbo can reach through the workspace tasks. */
+  const suite = PACKAGES.flatMap((pkg) => testFiles(pkg));
+
+  /**
+   * The test files permitted to import a substrate package, each reviewed once
+   * and recorded here with what makes it hermetic.
+   *
+   * Declared data, not a claim a file makes about itself. The previous gate
+   * admitted any `*.integration.ts` containing the string
+   * `hermetic-substrate-test: faux-provider`, so any new file granted itself
+   * substrate access by copying a comment — the FE-1389 deep read's finding. A
+   * path enters here by review only.
+   */
+  const SUBSTRATE_INTEGRATION_ENTRY_POINTS: Readonly<Record<string, string>> = {
+    "apps/brunch-agent/test/petrinaut-ask.integration.ts":
+      "Boots the real Gherkin elicitor on Flue's node runtime with pi-ai's faux provider and drives the committed application route over app.fetch through a full ask suspend/return/resume cycle plus a refused duplicate — no provider key, no socket, no external checkout mutation.",
+    "apps/brunch-agent/test/petrinaut-chat.integration.ts":
+      "Boots the real Gherkin elicitor on Flue's node runtime with pi-ai's faux provider, drives the committed application AI SDK route over app.fetch, and proves live reasoning/text plus inspection events without a provider key, socket, or external checkout mutation.",
+    "apps/brunch-agent/test/walking-skeleton.integration.ts":
+      "Boots the dev app on Flue's node runtime with pi-ai's faux provider and drives it over app.fetch — no provider key, no socket, no model call. Run as a child process by walking-skeleton.test.ts, which is what makes the node runtime drivable from this suite at all.",
+  };
+
+  test("no test file carries a live model credential", () => {
+    // The spec names an optional secret-gated real-model `flue run` smoke; it
+    // is deliberately not part of this run, and this is what stops it drifting
+    // in unnoticed.
+    expect(suite.length).toBeGreaterThan(0);
+    // Composed in workspace.ts rather than written literally, so this check
+    // does not flag its own source or the pattern's.
+    const modelKey = new RegExp(MODEL_KEY_NAME, "g");
+    for (const file of suite) {
+      expect({
+        file: file.relPath,
+        keys: file.text.match(modelKey) ?? [],
+      }).toEqual({
+        file: file.relPath,
+        keys: [],
+      });
+    }
+  });
+
+  test("the substrate is imported by exactly the reviewed entry points", () => {
+    // Set equality in both directions. An unlisted importer is substrate
+    // access nobody reviewed; a listed file that no longer imports the
+    // substrate is a permission standing for nothing, which is how an
+    // inventory stops describing the tree it governs.
+    const importers = suite
+      .filter((file) =>
+        importedPackages(file).some((s) => isSubstrate(packageOf(s))),
+      )
+      .map((file) => file.relPath)
+      .sort();
+    expect(importers).toEqual(
+      Object.keys(SUBSTRATE_INTEGRATION_ENTRY_POINTS).sort(),
+    );
+  });
+
+  test("every reviewed entry point records what makes it hermetic", () => {
+    for (const [path, review] of Object.entries(
+      SUBSTRATE_INTEGRATION_ENTRY_POINTS,
+    )) {
+      expect({ path, reviewed: review.trim().length > 0 }).toEqual({
+        path,
+        reviewed: true,
+      });
+    }
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/docs-index.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/docs-index.test.ts
new file mode 100644
index 00000000000..ae42774bfa5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/docs-index.test.ts
@@ -0,0 +1,251 @@
+/**
+ * Documentation coverage, as tests rather than as a habit.
+ *
+ * `docs/agents/documentation.md` states the placement rules as obligations —
+ * every document is indexed, living cross-effort docs go in
+ * `docs/planning/_shared/`, agent protocols are reachable from `AGENTS.md`. An
+ * obligation nobody can run is a wish, and this one decays in the quietest way
+ * available: a file lands, the INDEX pass is skipped once, and nothing ever says
+ * so. These are the mechanical checks — they walk the real `docs/` tree, so a
+ * document added later is governed without opting in.
+ *
+ * Both directions matter. A row that no longer points at anything is the same
+ * failure as an unindexed file, one step further along: the index has stopped
+ * describing the tree it governs, and reading it now misinforms.
+ */
+
+import { existsSync, readdirSync, readFileSync, statSync } from "node:fs";
+import { dirname, join, relative, resolve } from "node:path";
+
+import { describe, expect, test } from "vitest";
+
+import { contextRootPresent, REPO_ROOT } from "./workspace";
+
+const DOCS_ROOT = join(REPO_ROOT, "docs");
+const INDEX_RELPATH = "INDEX.md";
+
+/** Gitignored ephemera — in the tree but not of it, so never indexed. */
+const SKIP_DIRECTORIES = ["drafts"];
+/** Filesystem and placeholder artefacts: not documents. */
+const SKIP_FILES = [".DS_Store", ".gitkeep"];
+/**
+ * `docs/agents/` is deliberately outside the INDEX's remit: those files are
+ * pointed at from `AGENTS.md`, which is the pointer an agent actually reads, and
+ * the third rule below governs them there. Listing them twice would let the two
+ * registries disagree about what the protocol set is.
+ */
+const INDEX_EXEMPT = ["agents", INDEX_RELPATH];
+/**
+ * Preserved external analysis containing links into its source checkout and
+ * embedded Markdown examples. Those links are evidence, not context-local
+ * navigation.
+ */
+const LINK_CHECK_EXEMPT = ["reference/amp-analysis-flue-vs-tilde.md"];
+
+/** Posix-shaped, because that is how a markdown link target is written. */
+const relPath = (path: string): string =>
+  relative(DOCS_ROOT, path).replaceAll("\\", "/");
+
+/**
+ * Every documentation file `docs/INDEX.md` is answerable for, relative to
+ * `docs/`.
+ *
+ * Enumerated live rather than snapshotted. A recorded list would go green on the
+ * day someone forgot to update it — the failure mode this file exists to catch,
+ * reproduced inside the check meant to catch it.
+ */
+function documentationFiles(): string[] {
+  const found: string[] = [];
+  const walk = (dir: string): void => {
+    for (const entry of readdirSync(dir).sort()) {
+      if (SKIP_DIRECTORIES.includes(entry) || SKIP_FILES.includes(entry))
+        continue;
+      const path = join(dir, entry);
+      const rel = relPath(path);
+      if (INDEX_EXEMPT.includes(rel)) continue;
+      if (statSync(path).isDirectory()) walk(path);
+      else found.push(rel);
+    }
+  };
+  walk(DOCS_ROOT);
+  return found;
+}
+
+const FILES = contextRootPresent ? documentationFiles() : [];
+
+interface IndexRow {
+  /** 1-based line in `docs/INDEX.md`, so a failure names where to look. */
+  readonly line: number;
+  /** Link target, decoded and relative to `docs/`. May name a file or a directory. */
+  readonly target: string;
+}
+
+const MARKDOWN_LINK = /\[[^\]]*\]\(([^)]+)\)/g;
+
+/**
+ * The document rows of `docs/INDEX.md` — the first cell of each table row.
+ *
+ * Only the first cell, because that is the column that claims to identify a
+ * document; a Digest cell may legitimately link out to a Notion page or a
+ * superseding source without claiming anything lives at that path. Cells are
+ * split on a bare `|`, which is exact for this file and would need revisiting
+ * only for an escaped `\|` or a pipe inside inline code.
+ */
+function indexRows(): IndexRow[] {
+  const rows: IndexRow[] = [];
+  const lines = readFileSync(join(DOCS_ROOT, INDEX_RELPATH), "utf8").split(
+    "\n",
+  );
+  for (const [offset, line] of lines.entries()) {
+    const trimmed = line.trimStart();
+    if (!trimmed.startsWith("|")) continue;
+    const firstCell = trimmed.split("|")[1] ?? "";
+    for (const match of firstCell.matchAll(MARKDOWN_LINK)) {
+      const raw = match[1]!.trim();
+      // `external`-status rows point at the canonical copy outside the repo, and
+      // a bare anchor points within this file. Neither makes a claim about disk.
+      if (/^https?:\/\//.test(raw) || raw.startsWith("#")) continue;
+      const path = raw.split("#")[0]!;
+      // One filename contains a space, so targets are percent-encoded in the
+      // markdown and must be decoded before they name anything on disk.
+      rows.push({ line: offset + 1, target: decodeURIComponent(path) });
+    }
+  }
+  return rows;
+}
+
+const ROWS = contextRootPresent ? indexRows() : [];
+
+/**
+ * Whether a row's target accounts for a file. A target naming a directory covers
+ * everything beneath it: the INDEX deliberately indexes some sets as a set — the
+ * thirteen resolved issue files, the baseline experiment's transcripts — because
+ * one digest describes them better than thirteen would.
+ */
+const covers = (target: string, file: string): boolean => {
+  const base = target.replace(/\/$/, "");
+  return file === base || file.startsWith(`${base}/`);
+};
+
+describe.skipIf(!contextRootPresent)(
+  "every document is in the index, and the index is all documents",
+  () => {
+    test("the walk actually finds documents", () => {
+      // Without this, a `docs/` the walker cannot read makes the coverage check
+      // below iterate an empty list and pass vacuously — a silent exemption for
+      // the entire tree, which is worse than having no gate.
+      expect(FILES.length).toBeGreaterThan(0);
+      expect(ROWS.length).toBeGreaterThan(0);
+    });
+
+    test("every file under docs/ is covered by a row in docs/INDEX.md", () => {
+      for (const file of FILES) {
+        expect({
+          file,
+          indexed: ROWS.some((row) => covers(row.target, file)),
+        }).toEqual({
+          file,
+          indexed: true,
+        });
+      }
+    });
+
+    test("every row in docs/INDEX.md points at something real", () => {
+      // A row standing for nothing is not tidiness: the index is what a reader
+      // consults instead of walking the tree, so a stale row is misinformation
+      // with the authority of a registry behind it.
+      for (const row of ROWS) {
+        const path = join(DOCS_ROOT, row.target.replace(/\/$/, ""));
+        const resolves =
+          existsSync(path) &&
+          (statSync(path).isDirectory()
+            ? FILES.some((file) => covers(row.target, file))
+            : true);
+        expect({ line: row.line, target: row.target, resolves }).toEqual({
+          line: row.line,
+          target: row.target,
+          resolves: true,
+        });
+      }
+    });
+  },
+);
+
+test("relative links in context documentation point at existing files", () => {
+  for (const file of FILES) {
+    if (!file.endsWith(".md") || LINK_CHECK_EXEMPT.includes(file)) continue;
+
+    const sourcePath = join(DOCS_ROOT, file);
+    const lines = readFileSync(sourcePath, "utf8").split("\n");
+    for (const [lineOffset, line] of lines.entries()) {
+      for (const match of line.matchAll(MARKDOWN_LINK)) {
+        const rawTarget = match[1]!
+          .trim()
+          .split(/\s+/, 1)[0]!
+          .replace(/^<|>$/g, "");
+        if (
+          rawTarget.startsWith("#") ||
+          rawTarget.startsWith("/") ||
+          /^(?:doc|file|https?|layer|mailto):/.test(rawTarget)
+        )
+          continue;
+
+        const target = decodeURIComponent(rawTarget.split("#", 1)[0]!);
+        if (!target) continue;
+
+        expect({
+          file,
+          line: lineOffset + 1,
+          target: rawTarget,
+          resolves: existsSync(resolve(dirname(sourcePath), target)),
+        }).toEqual({
+          file,
+          line: lineOffset + 1,
+          target: rawTarget,
+          resolves: true,
+        });
+      }
+    }
+  }
+});
+
+test("docs/planning/ holds only effort directories", () => {
+  // Placement rule: a cross-effort living document goes in `_shared/`, and a
+  // record of one effort goes in that effort's directory. A file loose at the
+  // top level is the state both of those replaced — it belongs to everything and
+  // so to nothing, and it is where the last round of drift accumulated.
+  const planning = join(DOCS_ROOT, "planning");
+  const loose = readdirSync(planning)
+    .filter((entry) => !SKIP_FILES.includes(entry))
+    .filter((entry) => !statSync(join(planning, entry)).isDirectory())
+    .sort();
+  expect(loose).toEqual([]);
+});
+
+describe.skipIf(!contextRootPresent)(
+  "every agent protocol doc is reachable from AGENTS.md",
+  () => {
+    // `AGENTS.md` is the file an agent is given; a protocol it does not name is a
+    // protocol that will not be followed, however well written. The pointer form
+    // is established — the path in prose or backticks — so a substring check on
+    // the path is exactly as strict as the convention is.
+    const agentsText = readFileSync(join(REPO_ROOT, "AGENTS.md"), "utf8");
+    const protocols = readdirSync(join(DOCS_ROOT, "agents"))
+      .filter((entry) => entry.endsWith(".md"))
+      .sort();
+
+    test("there are protocol docs to govern", () => {
+      expect(protocols.length).toBeGreaterThan(0);
+    });
+
+    test("AGENTS.md names each one by path", () => {
+      for (const protocol of protocols) {
+        const path = `docs/agents/${protocol}`;
+        expect({ path, namedInAgentsMd: agentsText.includes(path) }).toEqual({
+          path,
+          namedInAgentsMd: true,
+        });
+      }
+    });
+  },
+);
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/fixtures/baseline-anthropic-stub.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/fixtures/baseline-anthropic-stub.ts
new file mode 100644
index 00000000000..160d8f8858d
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/fixtures/baseline-anthropic-stub.ts
@@ -0,0 +1,35 @@
+import { appendFile } from "node:fs/promises";
+
+interface StubReply {
+  text: string;
+  truncated?: boolean;
+}
+
+const replies = JSON.parse(
+  process.env["BASELINE_STUB_REPLIES"] ?? "[]",
+) as StubReply[];
+const requestsPath = process.env["BASELINE_STUB_REQUESTS_PATH"];
+let requestCount = 0;
+
+export default {
+  messages: {
+    create: async (request: unknown) => {
+      if (requestsPath) {
+        await appendFile(requestsPath, `${JSON.stringify(request)}\n`);
+      }
+      const reply = replies[requestCount++];
+      if (!reply) throw new Error(`unexpected model call ${requestCount}`);
+      return {
+        model: "test-model",
+        content: [{ type: "text" as const, text: reply.text }],
+        stop_reason: reply.truncated ? "max_tokens" : "end_turn",
+        usage: {
+          input_tokens: 1,
+          output_tokens: 1,
+          cache_creation_input_tokens: 0,
+          cache_read_input_tokens: 0,
+        },
+      };
+    },
+  },
+};
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/linear-project-graph.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/linear-project-graph.test.ts
new file mode 100644
index 00000000000..c8ceb357d60
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/linear-project-graph.test.ts
@@ -0,0 +1,122 @@
+import { join } from "node:path";
+import { pathToFileURL } from "node:url";
+
+import { describe, expect, test } from "vitest";
+
+import { CONTEXT_ROOT, contextRootPresent } from "./workspace";
+
+/**
+ * The module under test lives at the context root, outside every workspace, so
+ * CI's pruned checkout lacks it. The specifier is computed so `lint:tsc` does
+ * not resolve it statically; the structural types below restate the contract
+ * the tests exercise.
+ */
+const SCRIPT_MODULE_URL = pathToFileURL(
+  join(CONTEXT_ROOT, "scripts/linear-project-graph.ts"),
+).href;
+
+interface ProjectIssue {
+  readonly identifier: string;
+  readonly title: string;
+  readonly stateName: string;
+  readonly parentIdentifier?: string;
+  readonly external: boolean;
+}
+
+interface ProjectGraph {
+  readonly projectName: string;
+  readonly issues: readonly ProjectIssue[];
+  readonly hardEdges: readonly { readonly from: string; readonly to: string }[];
+}
+
+interface LinearProjectGraphModule {
+  readonly renderProjectGraph: (graph: ProjectGraph) => string;
+}
+
+async function loadRenderProjectGraph(): Promise<
+  LinearProjectGraphModule["renderProjectGraph"]
+> {
+  const module = (await import(SCRIPT_MODULE_URL)) as LinearProjectGraphModule;
+  return module.renderProjectGraph;
+}
+
+describe.skipIf(!contextRootPresent)("the compact Linear project graph", () => {
+  test("renders hard-dependency layers with enough issue context for agent inference", async () => {
+    const renderProjectGraph = await loadRenderProjectGraph();
+    const graph: ProjectGraph = {
+      projectName: "brunch-agent",
+      issues: [
+        {
+          identifier: "FE-100",
+          title: "Build the transport",
+          stateName: "In progress",
+          parentIdentifier: "FE-1",
+          external: false,
+        },
+        {
+          identifier: "FE-101",
+          title: "Return client tools",
+          stateName: "Todo",
+          parentIdentifier: "FE-1",
+          external: false,
+        },
+        {
+          identifier: "FE-102",
+          title: "Add private sessions",
+          stateName: "Todo",
+          external: false,
+        },
+        {
+          identifier: "FE-103",
+          title: "Ship the integration",
+          stateName: "Todo",
+          parentIdentifier: "FE-1",
+          external: false,
+        },
+      ],
+      hardEdges: [
+        { from: "FE-100", to: "FE-101" },
+        { from: "FE-100", to: "FE-102" },
+        { from: "FE-101", to: "FE-103" },
+      ],
+    };
+
+    expect(renderProjectGraph(graph)).toBe(`project brunch-agent open=4 hard=3
+legend: L=hard-dependency layer; p=parent; <=blocked by; =>blocks; *=outside project
+L0 FE-100 [In progress p:FE-1] =>FE-101,FE-102 | Build the transport
+L1 FE-101 [Todo p:FE-1] <=FE-100 =>FE-103 | Return client tools
+L1 FE-102 [Todo root] <=FE-100 | Add private sessions
+L2 FE-103 [Todo p:FE-1] <=FE-101 | Ship the integration
+cycles: none`);
+  });
+
+  test("makes a hard-dependency cycle explicit instead of inventing an order", async () => {
+    const renderProjectGraph = await loadRenderProjectGraph();
+    const graph: ProjectGraph = {
+      projectName: "brunch-agent",
+      issues: [
+        {
+          identifier: "FE-100",
+          title: "First issue",
+          stateName: "Todo",
+          external: false,
+        },
+        {
+          identifier: "FE-101",
+          title: "Second issue",
+          stateName: "Todo",
+          external: true,
+        },
+      ],
+      hardEdges: [
+        { from: "FE-100", to: "FE-101" },
+        { from: "FE-101", to: "FE-100" },
+      ],
+    };
+
+    expect(renderProjectGraph(graph)).toContain(
+      "L? FE-101 [Todo root *] <=FE-100 =>FE-100 | Second issue",
+    );
+    expect(renderProjectGraph(graph)).toContain("cycles: FE-100,FE-101");
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.test.ts
new file mode 100644
index 00000000000..3daa437caea
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.test.ts
@@ -0,0 +1,61 @@
+/**
+ * Keeps the open gaps in front of whoever is working, and keeps each entry
+ * well formed enough to act on.
+ *
+ * See `open-gaps.ts` for why the ledger exists and why closing a gap is
+ * deleting its entry rather than satisfying a predicate.
+ */
+
+import { describe, expect, test } from "vitest";
+
+import { OPEN_GAPS } from "./open-gaps";
+
+// Printed once per run, so the list is in front of whoever is working rather
+// than filed somewhere they would have to think to look. Silent when the ledger
+// is empty, because that is the goal state and not a warning.
+if (OPEN_GAPS.length > 0) {
+  console.warn(
+    [
+      "",
+      `⚠ ${OPEN_GAPS.length} verification gaps are open (spec §14.5 and friends):`,
+      ...OPEN_GAPS.map(
+        (entry) => `   · ${entry.id} — ${entry.ticket} (spec ${entry.spec})`,
+      ),
+      "   Closing one means deleting its entry in the commit that lands its proof.",
+      "",
+    ].join("\n"),
+  );
+}
+
+describe("open gaps", () => {
+  test("every entry names its ticket, spec section, gap, and the proof that will delete it", () => {
+    for (const entry of OPEN_GAPS) {
+      // The entry id is pinned on both sides so a failure says which record is
+      // malformed even when the malformed field is the id itself.
+      expect({
+        entry: entry.id,
+        id: entry.id,
+        ticket: entry.ticket,
+        spec: entry.spec,
+        statesGap: entry.gap.trim().length > 0,
+        statesProof: entry.proof.trim().length > 0,
+      }).toEqual({
+        entry: entry.id,
+        id: expect.stringMatching(
+          /^[a-z0-9]+(?:-[a-z0-9]+)*$/,
+        ) as unknown as string,
+        ticket: expect.stringMatching(/^[A-Z]+-\d+$/) as unknown as string,
+        spec: expect.stringMatching(
+          /^§\d+(?:\.\d+)*(?:, §\d+(?:\.\d+)*)*$/,
+        ) as unknown as string,
+        statesGap: true,
+        statesProof: true,
+      });
+    }
+  });
+
+  test("gap ids are unique", () => {
+    const ids = OPEN_GAPS.map((entry) => entry.id);
+    expect(new Set(ids).size).toBe(ids.length);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.ts
new file mode 100644
index 00000000000..71ab2b9b1a1
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/open-gaps.ts
@@ -0,0 +1,61 @@
+/**
+ * The verification gaps this codebase knows are open.
+ *
+ * Spec §14.5 names open verification items, and prose decays: an item nobody
+ * runs into is an item nobody closes. The ones here are exactly that kind — a
+ * substrate behaviour nobody has driven, a durability claim nobody has
+ * restarted into.
+ *
+ * So the ledger is data, and an entry's *existence* is the claim that its gap
+ * is still open. Closing a gap is an explicit repository action: the commit
+ * that lands the behavioural proof deletes the entry, so a single diff carries
+ * the proof and the closure together and a reviewer can check one against the
+ * other.
+ *
+ * Nothing here infers closure from source text, and nothing may be added that
+ * does. The mechanism this replaces searched the tree for a citation token
+ * alongside a `test(`/`expect(` in the same file: it passed for a test that
+ * cited a gap while proving something else, and it went red on any closure
+ * written outside the shape it guessed. A banner that can be wrong in both
+ * directions is a banner nobody reads.
+ */
+
+export interface OpenGap {
+  /** Short stable handle, used in the run banner and on the ticket. */
+  readonly id: string;
+  /** Spec section that names the item. */
+  readonly spec: string;
+  /** The Linear issue that owns closing it. */
+  readonly ticket: string;
+  /** What is not yet known, in one sentence. */
+  readonly gap: string;
+  /** The behavioural proof whose landing commit deletes this entry. */
+  readonly proof: string;
+}
+
+export const OPEN_GAPS: readonly OpenGap[] = [
+  {
+    id: "restart-durability",
+    spec: "§14.5",
+    ticket: "FE-1396",
+    gap: "The capture store survives restart (proven in the ticket-13 prototype), but conversation-store durability with a real db.ts has never been driven across a restart.",
+    proof:
+      "A test under apps/brunch-agent/test that boots the app, holds a conversation, restarts the process, and resumes the same conversation id.",
+  },
+  {
+    id: "compaction-vs-durable-history",
+    spec: "§9.7, §14.5",
+    ticket: "FE-1386",
+    gap: "Flue 2.0.3 source shows compaction appends to the canonical stream and rewrites model context only, but no session has behaviorally pinned that the public message projection and persistent state survive a real compaction boundary.",
+    proof:
+      "A test under libs/@hashintel/brunch-agent/packages/binding-flue/test driving one genuine compaction, deep-comparing complete public messages and settlements aside from offset/incarnation, verifying persistent state, and asserting an FE-1391 archive pointer still resolves.",
+  },
+  {
+    id: "interpretation-render-plugin-seam",
+    spec: "§7.6, §14.5",
+    ticket: "FE-1394",
+    gap: "The plugin-supplied renderer seam for the interpretation render has never been exercised, because no real pack exists yet.",
+    proof:
+      "A plugin supplying a renderer definition typed against its own payload shapes, with a test driving the interpretation render through it — an exported symbol alone leaves the seam uncrossed.",
+  },
+];
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.test.ts
new file mode 100644
index 00000000000..ffc9df70dac
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.test.ts
@@ -0,0 +1,127 @@
+/**
+ * The introspection helpers themselves, at the seams where a wrong answer
+ * makes some other invariant pass vacuously or fail spuriously.
+ *
+ * Agent-module detection is the load-bearing one: the FE-1361 review found the
+ * old bare substring match turned any file whose *comments* mention the
+ * `'use agent'` directive into an "agent module", failing two assertions on a
+ * comment-only change. Detection is now anchored to a directive *statement* —
+ * and deliberately not to the first statement only, so a misplaced directive
+ * is still detected and then failed by the first-statement invariant instead
+ * of escaping it.
+ */
+
+import { mkdirSync, mkdtempSync, rmSync, writeFileSync } from "node:fs";
+import { tmpdir } from "node:os";
+import { basename, join, relative } from "node:path";
+
+import { afterAll, describe, expect, test } from "vitest";
+
+import {
+  isAgentModule,
+  sourceFiles,
+  testFiles,
+  type SourceFile,
+  type WorkspacePackage,
+} from "./workspace";
+
+const file = (text: string): SourceFile => ({
+  path: "/fake/module.ts",
+  relPath: "fake/module.ts",
+  text,
+});
+
+describe("isAgentModule", () => {
+  test("a module whose first statement is the directive is one", () => {
+    expect(isAgentModule(file("'use agent';\nexport function A() {}\n"))).toBe(
+      true,
+    );
+    expect(isAgentModule(file('"use agent";\nexport function A() {}\n'))).toBe(
+      true,
+    );
+  });
+
+  test("a leading doc block before the directive still counts", () => {
+    expect(
+      isAgentModule(file("/** The agent. */\n'use agent';\nexport {};\n")),
+    ).toBe(true);
+  });
+
+  test("a comment mentioning the directive is not a directive", () => {
+    // The regression the FE-1361 review verified: CI went red on a
+    // comment-only change because detection matched raw file text.
+    expect(
+      isAgentModule(
+        file("// the 'use agent' directive must come first\nexport {};\n"),
+      ),
+    ).toBe(false);
+    expect(
+      isAgentModule(
+        file(
+          '/**\n * A file about the "use agent" directive.\n */\nexport {};\n',
+        ),
+      ),
+    ).toBe(false);
+  });
+
+  test("a trailing comment on the directive line does not hide the module", () => {
+    // `'use agent'; // registers X` is still a directive at runtime — comments
+    // are not statements — so it must still be detected, or every downstream
+    // invariant passes vacuously for that module.
+    expect(
+      isAgentModule(
+        file("'use agent'; // registers the elicitor\nexport {};\n"),
+      ),
+    ).toBe(true);
+    expect(
+      isAgentModule(file("'use agent'; /* registered */\nexport {};\n")),
+    ).toBe(true);
+  });
+
+  test("a misplaced directive is still detected, so the first-statement invariant can fail it", () => {
+    // If detection required the directive to be first, a module that misplaced
+    // it would silently stop being checked at all — the exact silent pass the
+    // first-statement test exists to prevent.
+    expect(isAgentModule(file("import 'x';\n'use agent';\nexport {};\n"))).toBe(
+      true,
+    );
+  });
+
+  test("quotes must match", () => {
+    expect(isAgentModule(file("'use agent\";\nexport {};\n"))).toBe(false);
+  });
+});
+
+describe("the source/test partition is total", () => {
+  // A real directory rather than fakes, because the property under test is the
+  // walk itself: the FE-1400 review's verified escape was a file in a *nested*
+  // test directory (`src/test/`), pruned by the source walk but never collected
+  // by the old top-level-only test walk — governed by nothing.
+  const dir = mkdtempSync(join(tmpdir(), "brunch-partition-"));
+  mkdirSync(join(dir, "src/test"), { recursive: true });
+  mkdirSync(join(dir, "__tests__"));
+  writeFileSync(join(dir, "src/index.ts"), "export {};\n");
+  writeFileSync(join(dir, "src/test/nested.ts"), "export {};\n");
+  writeFileSync(join(dir, "__tests__/top.test.ts"), "export {};\n");
+  const pkg: WorkspacePackage = {
+    name: "@hashintel/brunch-agent-fixture",
+    dir: basename(dir),
+    path: dir,
+    relPath: `packages/${basename(dir)}`,
+    kind: "package",
+    manifest: { name: "@hashintel/brunch-agent-fixture" },
+  };
+
+  afterAll(() => rmSync(dir, { recursive: true, force: true }));
+
+  test("every file is exactly one of source or test — nested test dirs included", () => {
+    const source = sourceFiles(pkg)
+      .map((f) => relative(dir, f.path))
+      .sort();
+    const test = testFiles(pkg)
+      .map((f) => relative(dir, f.path))
+      .sort();
+    expect(source).toEqual(["src/index.ts"]);
+    expect(test).toEqual(["__tests__/top.test.ts", "src/test/nested.ts"]);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.ts b/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.ts
new file mode 100644
index 00000000000..26d6acf3180
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/architecture/workspace.ts
@@ -0,0 +1,273 @@
+/**
+ * Workspace introspection for the boundary tests.
+ *
+ * The point of reading the tree rather than listing packages by hand is that a
+ * package added later is governed by the same invariants without anyone
+ * remembering to opt it in. Two rules keep that promise honest:
+ *
+ * - the scan covers a package's whole directory, not a `src/` convention, so a
+ *   package laid out differently cannot fall through every file-level check;
+ * - a workspace directory that cannot be read is reported, never silently
+ *   skipped into a vacuous pass.
+ */
+
+import { existsSync, readdirSync, readFileSync, statSync } from "node:fs";
+import { join, relative } from "node:path";
+import { fileURLToPath } from "node:url";
+
+/** Resolved through `fileURLToPath` — a raw `URL.pathname` is percent-encoded. */
+export const HASH_ROOT = fileURLToPath(
+  new URL("../../../../../../..", import.meta.url),
+).replace(/[/\\]$/, "");
+export const CONTEXT_ROOT = join(HASH_ROOT, "libs/@hashintel/brunch-agent");
+export const REPO_ROOT = CONTEXT_ROOT;
+
+/**
+ * The context root's `docs/` and `scripts/` belong to no workspace, so
+ * `turbo prune` never copies them; CI's prune-repository action copies them
+ * into its pruned checkout via a requested-scope extra-path rule. This guard is the
+ * fallback for a pruned tree where that rule is absent or has drifted: the
+ * context-root tests skip there instead of failing on missing files, and run
+ * in every full checkout, where this is always true.
+ */
+export const contextRootPresent =
+  existsSync(join(CONTEXT_ROOT, "docs")) &&
+  existsSync(join(CONTEXT_ROOT, "scripts"));
+const PACKAGES_ROOT = join(CONTEXT_ROOT, "packages");
+const APP_ROOT = join(HASH_ROOT, "apps/brunch-agent");
+
+export interface WorkspacePackage {
+  /** Package name from its manifest, e.g. `@hashintel/brunch-agent-plugin-gherkin`. */
+  readonly name: string;
+  /** Directory basename — the role-prefixed one, e.g. `plugin-gherkin`. */
+  readonly dir: string;
+  /** Absolute path to the package directory. */
+  readonly path: string;
+  /** Path relative to HASH root. */
+  readonly relPath: string;
+  /** `packages/` holds shells; `apps/` holds hosts. */
+  readonly kind: "package" | "app";
+  readonly manifest: PackageManifest;
+}
+
+export interface PackageManifest {
+  name: string;
+  dependencies?: Record<string, string>;
+  devDependencies?: Record<string, string>;
+  exports?: Record<string, unknown>;
+  scripts?: Record<string, string>;
+}
+
+function directoriesIn(parent: string): string[] {
+  return readdirSync(parent).filter((entry) =>
+    statSync(join(parent, entry)).isDirectory(),
+  );
+}
+
+export function workspacePackages(): WorkspacePackage[] {
+  const packagePaths = directoriesIn(PACKAGES_ROOT).map((dir) => ({
+    dir,
+    kind: "package" as const,
+    path: join(PACKAGES_ROOT, dir),
+  }));
+  const workspacePaths = [
+    ...packagePaths,
+    { dir: "brunch-agent", kind: "app" as const, path: APP_ROOT },
+  ];
+
+  return workspacePaths.map(({ dir, kind, path }) => {
+    const manifestPath = join(path, "package.json");
+    if (!existsSync(manifestPath)) {
+      throw new Error(
+        `${relative(HASH_ROOT, path)} has no package.json — every Brunch workspace needs one.`,
+      );
+    }
+    const manifest = JSON.parse(
+      readFileSync(manifestPath, "utf8"),
+    ) as PackageManifest;
+    return {
+      name: manifest.name,
+      dir,
+      path,
+      relPath: relative(HASH_ROOT, path).replaceAll("\\", "/"),
+      kind,
+      manifest,
+    };
+  });
+}
+
+/** Every declared dependency of a package, production and dev alike. */
+export function allDependencies(pkg: WorkspacePackage): string[] {
+  return [
+    ...Object.keys(pkg.manifest.dependencies ?? {}),
+    ...Object.keys(pkg.manifest.devDependencies ?? {}),
+  ];
+}
+
+/** Runtime dependencies encode the production package direction. */
+export function runtimeDependencies(pkg: WorkspacePackage): string[] {
+  return Object.keys(pkg.manifest.dependencies ?? {});
+}
+
+export interface SourceFile {
+  readonly path: string;
+  readonly relPath: string;
+  readonly text: string;
+}
+
+const SOURCE_EXTENSIONS = /\.(ts|tsx|mts|mjs|js|jsx)$/;
+/** Never scanned: not authored here, or build output. */
+const SKIP_DIRECTORIES = ["node_modules", "dist", ".flue", ".git", ".turbo"];
+const TEST_DIRECTORIES = ["test", "tests", "__tests__"];
+
+/** Every source file under a directory, recursively. A missing directory yields none. */
+export function filesIn(
+  dir: string,
+  skip: readonly string[] = SKIP_DIRECTORIES,
+): SourceFile[] {
+  if (!existsSync(dir)) return [];
+  const skipped = new Set(skip);
+  const found: SourceFile[] = [];
+  const walk = (current: string): void => {
+    for (const entry of readdirSync(current)) {
+      if (skipped.has(entry)) continue;
+      const path = join(current, entry);
+      if (statSync(path).isDirectory()) walk(path);
+      else if (SOURCE_EXTENSIONS.test(entry)) {
+        found.push({
+          path,
+          relPath: relative(HASH_ROOT, path).replaceAll("\\", "/"),
+          text: readFileSync(path, "utf8"),
+        });
+      }
+    }
+  };
+  walk(dir);
+  return found;
+}
+
+/**
+ * Every file of a package, partitioned into source and test — totally: a file
+ * under a test directory at any depth is a test file, and every other file is
+ * source. One walk feeding both sides is what makes the partition total by
+ * construction. The previous pair of independent walks left a hole (pruning
+ * test dirs at any depth on one side, collecting only top-level test dirs on
+ * the other), so a file in e.g. `src/test/` was governed by neither the
+ * source invariants nor the test-hermeticity rules.
+ */
+function partitionedFiles(pkg: WorkspacePackage): {
+  source: SourceFile[];
+  test: SourceFile[];
+} {
+  const source: SourceFile[] = [];
+  const test: SourceFile[] = [];
+  for (const file of filesIn(pkg.path)) {
+    const segments = relative(pkg.path, file.path).split(/[/\\]/);
+    (segments.some((segment) => TEST_DIRECTORIES.includes(segment))
+      ? test
+      : source
+    ).push(file);
+  }
+  return { source, test };
+}
+
+/**
+ * A package's own source files — everything it ships, wherever it puts them.
+ *
+ * Deliberately not `src/`-only: keying the scan off a directory convention
+ * would silently exempt a package laid out any other way from every file-level
+ * invariant, which is the exact failure the boundary suite exists to prevent.
+ * Tests are excluded because they are governed by their own rules.
+ */
+export function sourceFiles(pkg: WorkspacePackage): SourceFile[] {
+  return partitionedFiles(pkg).source;
+}
+
+/** Every test file belonging to a package, at any depth. */
+export function testFiles(pkg: WorkspacePackage): SourceFile[] {
+  return partitionedFiles(pkg).test;
+}
+
+/**
+ * The `'use agent'` directive as a statement: alone on its line, terminated,
+ * quotes matching. Anchoring to a statement rather than matching raw text
+ * keeps a comment that merely *mentions* the directive from turning a file
+ * into an agent module (the FE-1361 review's verified failure: CI red on a
+ * comment-only change).
+ *
+ * Deliberately not anchored to the *first* statement: a misplaced directive
+ * must still be detected, so the first-statement invariant in
+ * `test/boundaries.test.ts` can fail it loudly instead of never seeing it.
+ */
+export const AGENT_DIRECTIVE_STATEMENT =
+  /^\s*(["'])use agent\1;?\s*(?:$|\/\/|\/\*)/mu;
+
+/** Whether a file declares itself an agent module (well-placed or not). */
+export function isAgentModule(file: SourceFile): boolean {
+  return AGENT_DIRECTIVE_STATEMENT.test(file.text);
+}
+
+/**
+ * The pinned identities a file assigns, extracted by the one pattern both
+ * suites share: `test/boundaries.test.ts` checks each identity is never
+ * duplicated in source, `test/build-artifact.test.ts` checks each is bound in
+ * the emitted bundle. Two hand-copies of the regex would let the two checks
+ * silently diverge on what counts as an identity.
+ */
+export function pinnedIdentities(file: SourceFile): string[] {
+  return [...file.text.matchAll(/\w+\.agentName\s*=\s*(["'])([^"']+)\1/gu)].map(
+    (match) => match[2]!,
+  );
+}
+
+/**
+ * A model-key environment variable name, as a pattern source for callers to
+ * anchor or extend. Composed rather than written literally, so the hermeticity
+ * check that reuses it does not flag this file's own source.
+ */
+export const MODEL_KEY_NAME = `[A-Z_]*${"API"}_${"KEY"}`;
+
+/** Every agent module a package ships. */
+export function agentModules(pkg: WorkspacePackage): SourceFile[] {
+  return sourceFiles(pkg).filter(isAgentModule);
+}
+
+/**
+ * The module specifiers a source file imports or re-exports.
+ *
+ * Deliberately textual: the invariants being checked are about which packages
+ * a shell is *allowed to name at all*, so a regex over the source is the right
+ * granularity — and it catches type-only imports, which erase at runtime but
+ * still encode a forbidden dependency direction.
+ */
+export function importedModules(file: SourceFile): string[] {
+  const specifiers = new Set<string>();
+  const patterns = [
+    /(?:^|\n)\s*import\s[^;]*?from\s*['"]([^'"]+)['"]/g,
+    /(?:^|\n)\s*import\s*['"]([^'"]+)['"]/g,
+    /(?:^|\n)\s*export\s[^;]*?from\s*['"]([^'"]+)['"]/g,
+    /\bimport\s*\(\s*['"]([^'"]+)['"]\s*\)/g,
+    /\brequire\s*\(\s*['"]([^'"]+)['"]\s*\)/g,
+  ];
+  for (const pattern of patterns) {
+    for (const match of file.text.matchAll(pattern)) {
+      if (match[1]) specifiers.add(match[1]);
+    }
+  }
+  return [...specifiers];
+}
+
+/** Bare package specifiers only — relative and absolute paths dropped. */
+export function importedPackages(file: SourceFile): string[] {
+  return importedModules(file).filter(
+    (specifier) => !specifier.startsWith(".") && !specifier.startsWith("/"),
+  );
+}
+
+/** `@scope/name` or `name` — the installable unit a specifier resolves to. */
+export function packageOf(specifier: string): string {
+  const parts = specifier.split("/");
+  return specifier.startsWith("@")
+    ? parts.slice(0, 2).join("/")
+    : (parts[0] ?? specifier);
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/ask-protocol.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/ask-protocol.test.ts
new file mode 100644
index 00000000000..0055c9d8459
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/ask-protocol.test.ts
@@ -0,0 +1,145 @@
+import * as v from "valibot";
+import { describe, expect, test } from "vitest";
+
+import {
+  ASK_TOOL_DESCRIPTION,
+  askProtocolInstructionFragments,
+  AskSubmission,
+  buildReplyBindingSignalPayload,
+  decideAskReplyAdmission,
+  decidePendingAffordance,
+  mintAskAffordance,
+  pendingAskAffordanceId,
+} from "../src/ask-protocol";
+
+import type { SweepSessionEntry } from "../src/sweep-protocol";
+
+const firstAffordance = mintAskAffordance(
+  "What outcome should the scenario describe?",
+  "tool-call-1",
+);
+
+describe("ask protocol", () => {
+  test("mints the free-text affordance from the question and call id", () => {
+    expect(firstAffordance).toEqual({
+      id: "affordance_tool-call-1",
+      form: "free-text",
+      markdown: "What outcome should the scenario describe?",
+      payload: { question: "What outcome should the scenario describe?" },
+    });
+  });
+
+  test("accepts the first live affordance", () => {
+    const candidate = mintAskAffordance(
+      "Who initiates the outcome?",
+      "tool-call-2",
+    );
+
+    expect(decidePendingAffordance(null, candidate)).toEqual({
+      ok: true,
+      pending: candidate,
+    });
+  });
+
+  test("refuses a second live affordance with the existing diagnostic", () => {
+    const candidate = mintAskAffordance("What happens next?", "tool-call-2");
+
+    expect(decidePendingAffordance(firstAffordance, candidate)).toEqual({
+      ok: false,
+      reason:
+        "An interactive affordance is already pending (affordance_tool-call-1); wait for its reply before asking another question.",
+    });
+  });
+
+  test("builds the mechanical reply-binding signal from the pending affordance", () => {
+    expect(buildReplyBindingSignalPayload(firstAffordance)).toEqual({
+      type: "affordance-reply-bound",
+      tagName: "affordance-reply-bound",
+      body: [
+        "The immediately preceding user message is mechanically bound as the reply to this pending affordance:",
+        "What outcome should the scenario describe?",
+      ].join("\n\n"),
+      attributes: { affordanceId: "affordance_tool-call-1" },
+    });
+  });
+
+  test("reports the last emitted affordance without a bound reply as pending", () => {
+    const entries: SweepSessionEntry[] = [
+      { id: "entry-1", kind: "user", text: "Start." },
+      {
+        id: "entry-2",
+        kind: "assistant",
+        text: "",
+        affordances: [
+          { id: "affordance_tool-call-1", markdown: "First question?" },
+        ],
+      },
+    ];
+
+    expect(pendingAskAffordanceId(entries)).toBe("affordance_tool-call-1");
+  });
+
+  test("stops reporting an affordance as pending once a reply is bound to it", () => {
+    const entries: SweepSessionEntry[] = [
+      {
+        id: "entry-1",
+        kind: "assistant",
+        text: "",
+        affordances: [
+          { id: "affordance_tool-call-1", markdown: "First question?" },
+        ],
+      },
+      {
+        id: "entry-2",
+        kind: "user-affordance-payload",
+        text: "The answer.",
+        replyToAffordanceId: "affordance_tool-call-1",
+      },
+    ];
+
+    expect(pendingAskAffordanceId(entries)).toBeUndefined();
+    expect(pendingAskAffordanceId([])).toBeUndefined();
+  });
+
+  test("admits only the pending ask’s correlated submission", () => {
+    expect(
+      decideAskReplyAdmission("affordance_tool-call-1", "tool-call-1"),
+    ).toEqual({ ok: true });
+    expect(decideAskReplyAdmission(undefined, "tool-call-1")).toEqual({
+      ok: false,
+      reason: "no-pending-ask",
+    });
+    expect(
+      decideAskReplyAdmission("affordance_tool-call-1", "tool-call-9"),
+    ).toEqual({
+      ok: false,
+      reason: "different-ask-pending",
+    });
+  });
+
+  test("accepts only a non-empty answer as a submitted ask output", () => {
+    expect(
+      v.safeParse(AskSubmission, { answer: "A settled order." }).success,
+    ).toBe(true);
+    for (const output of [
+      { answer: "" },
+      {},
+      null,
+      "A settled order.",
+      { answer: 42 },
+    ]) {
+      expect(v.safeParse(AskSubmission, output).success).toBe(false);
+    }
+  });
+
+  test("supplies render-invariant instruction fragments", () => {
+    expect(ASK_TOOL_DESCRIPTION).toBe(
+      "Ask one free-text question and suspend this turn for the person’s reply. A second ask in the same tool batch is rejected.",
+    );
+    expect(askProtocolInstructionFragments("gherkin")).toEqual([
+      "You are interviewing someone to elicit gherkin.",
+      "Ask one question at a time with brunch_ask.",
+      "Continue the conversation after each reply, using the harness-provided reply binding as a mechanical fact.",
+    ]);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/capture-store.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/capture-store.test.ts
new file mode 100644
index 00000000000..fb59595d102
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/capture-store.test.ts
@@ -0,0 +1,1322 @@
+import { beforeEach, describe, expect, test } from "vitest";
+
+import {
+  applyCaptureStoreCommand as applyCaptureStoreCommandWithArchive,
+  createEmptyCaptureStoreSnapshot,
+  deriveCaptureStatus,
+  deriveIssueStatus,
+  parseCaptureStoreSnapshot,
+  type CaptureInputProposal,
+  type CaptureStoreCommand,
+  type CaptureStoreSnapshot,
+  type EvidenceSpan,
+} from "../src/capture-store";
+import {
+  archiveSessionLogRead,
+  createEmptySessionLogArchive,
+  type EvidenceQuote,
+} from "../src/session-log";
+
+const excerptsByEntry = new Map<number, Set<string>>();
+
+beforeEach(() => excerptsByEntry.clear());
+
+const userEvidence = (excerpt: string, entry = 1): EvidenceQuote => {
+  const excerpts = excerptsByEntry.get(entry) ?? new Set<string>();
+  excerpts.add(excerpt);
+  excerptsByEntry.set(entry, excerpts);
+  return { excerpt };
+};
+
+const storedEvidence = (excerpt: string, entry = 1): EvidenceSpan => ({
+  excerpt,
+  pointer: { sessionId: "session-1", entryStart: entry, entryEnd: entry },
+  source: "user",
+});
+
+const evidenceArchive = () => {
+  const maxEntry = Math.max(1, ...excerptsByEntry.keys());
+  return archiveSessionLogRead(createEmptySessionLogArchive(), {
+    sessionId: "session-1",
+    offset: String(maxEntry),
+    entries: Array.from({ length: maxEntry }, (_, index) => {
+      const ordinal = index + 1;
+      const text = [
+        ...(excerptsByEntry.get(ordinal) ?? [`filler-${ordinal}`]),
+      ].join("\n");
+      return {
+        substrateEntryId: `message-${ordinal}`,
+        kind: "user" as const,
+        text,
+        materialized: { id: `message-${ordinal}`, text },
+      };
+    }),
+    settlements: [],
+  });
+};
+
+const applyCaptureStoreCommand = (
+  snapshot: CaptureStoreSnapshot,
+  command: CaptureStoreCommand,
+) =>
+  applyCaptureStoreCommandWithArchive(snapshot, command, {
+    sessionId: "session-1",
+    archive: evidenceArchive(),
+  });
+
+type UserCaptureProposal = Extract<
+  CaptureInputProposal,
+  { readonly evidence: readonly EvidenceQuote[] }
+>;
+
+const valueProposal = (
+  value: string,
+  evidence = userEvidence(value),
+  overrides: Partial<Omit<UserCaptureProposal, "content" | "evidence">> = {},
+): UserCaptureProposal => ({
+  evidence: [evidence],
+  epistemicStatus: "explicit",
+  confidence: "high",
+  content: { value },
+  ...overrides,
+});
+
+const apply = (
+  snapshot: CaptureStoreSnapshot,
+  command: Parameters<typeof applyCaptureStoreCommand>[1],
+) => {
+  const result = applyCaptureStoreCommand(snapshot, command);
+  expect(result.ok).toBe(true);
+  if (!result.ok) throw new Error(result.refusal.message);
+  // The closure property, checked on every command this suite accepts rather
+  // than on a chosen few: what a command returns has to survive the trip
+  // through the file it will be kept in, and come back the same snapshot. The
+  // JSON hop is part of the property — persistence goes through JSON, so a
+  // value the command surface accepts and JSON cannot carry is a snapshot the
+  // next read cannot reproduce.
+  expect(
+    parseCaptureStoreSnapshot(JSON.parse(JSON.stringify(result.snapshot))),
+  ).toEqual(result.snapshot);
+  return result;
+};
+
+describe("capture-store contract", () => {
+  test("harness-invariant: 5 — retries deduplicate by evidence and content, not epistemic status", () => {
+    const proposal = valueProposal("budget = €20,000");
+    const first = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [proposal],
+    });
+    const retry = apply(first.snapshot, {
+      type: "apply-sweep",
+      proposals: [{ ...proposal, epistemicStatus: "tentative" }],
+    });
+
+    expect(first.snapshot.captures).toHaveLength(1);
+    expect(retry.snapshot.captures).toHaveLength(1);
+    expect(retry.value).toEqual({
+      appliedCaptureIds: [],
+      skippedDedupKeys: [first.snapshot.captures[0]!.dedupKey],
+      advisories: [],
+    });
+
+    const originalId = retry.snapshot.captures[0]!.id;
+    const revisedReading = apply(retry.snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        { ...proposal, epistemicStatus: "tentative", supersedes: originalId },
+      ],
+    });
+    expect(revisedReading.snapshot.captures).toHaveLength(2);
+    expect(revisedReading.snapshot.captures[1]).toMatchObject({
+      dedupKey: first.snapshot.captures[0]!.dedupKey,
+      epistemicStatus: "tentative",
+      supersedes: originalId,
+    });
+  });
+
+  test("a negative-zero capture value is refused, not silently flattened to zero", () => {
+    // JSON.stringify(-0) is "0", so accepting -0 mints a snapshot whose read
+    // path returns a different number than the command accepted — found by the
+    // round-trip property's JSON hop.
+    const result = applyCaptureStoreCommand(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        {
+          evidence: [userEvidence("minus zero", 1)],
+          epistemicStatus: "explicit",
+          confidence: "high",
+          content: { value: -0 },
+        },
+      ],
+    });
+    expect(result.ok).toBe(false);
+    expect(result).toMatchObject({ refusal: { code: "invalid-envelope" } });
+
+    const nested = applyCaptureStoreCommand(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        {
+          evidence: [userEvidence("nested minus zero", 1)],
+          epistemicStatus: "explicit",
+          confidence: "high",
+          content: { value: { offset: -0 } },
+        },
+      ],
+    });
+    expect(nested.ok).toBe(false);
+  });
+
+  test("same-evidence and near-identical active values surface ephemeral equivalence advisories", () => {
+    const sharedEvidence = userEvidence("The launch is June.", 1);
+    const result = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("launch = June", sharedEvidence),
+        valueProposal("release = June", sharedEvidence),
+        valueProposal(
+          "  LAUNCH   = june ",
+          userEvidence("June is the launch month.", 2),
+        ),
+      ],
+    });
+    if (!("appliedCaptureIds" in result.value))
+      throw new Error("A sweep did not return advisories.");
+
+    expect(
+      result.value.advisories
+        .filter((advisory) => advisory.type === "possibly-equivalent")
+        .map((advisory) => advisory.reason)
+        .sort(),
+    ).toEqual(["near-identical-payload", "same-evidence"]);
+    expect(result.snapshot.events).toEqual([]);
+  });
+
+  test("harness-invariant: 7 — one invalid proposal refuses the whole sweep", () => {
+    const before = createEmptyCaptureStoreSnapshot();
+    const result = applyCaptureStoreCommand(before, {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("valid"),
+        {
+          evidence: [userEvidence("invalid", 2)],
+          epistemicStatus: "explicit",
+          confidence: "high",
+          content: { value: "value", absence: "deferred" },
+        } as unknown as CaptureInputProposal,
+      ],
+    });
+
+    expect(result.ok).toBe(false);
+    expect(result).toMatchObject({ refusal: { code: "invalid-envelope" } });
+    expect(before).toEqual(createEmptyCaptureStoreSnapshot());
+  });
+
+  test("harness-invariant: 9 — all six absence values remain first-class capture content", () => {
+    const absences = [
+      "unknown-to-user",
+      "not-yet-decided",
+      "not-applicable",
+      "explicitly-absent",
+      "declined",
+      "deferred",
+    ] as const;
+    const proposals: CaptureInputProposal[] = absences.map(
+      (absence, index) => ({
+        evidence: [userEvidence(absence, index + 1)],
+        epistemicStatus: "inferred",
+        confidence: "medium",
+        content: { absence },
+      }),
+    );
+
+    const result = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals,
+    });
+
+    expect(result.snapshot.captures.map((capture) => capture.content)).toEqual(
+      absences.map((absence) => ({ absence })),
+    );
+    expect(
+      result.snapshot.captures.every(
+        (capture) => "status" in capture === false,
+      ),
+    ).toBe(true);
+  });
+
+  test("harness-invariant: 10 — explicit, inferred, and defaulted remain distinct", () => {
+    const proposals: CaptureInputProposal[] = [
+      valueProposal("value-0", userEvidence("evidence-0", 1)),
+      valueProposal("value-1", userEvidence("evidence-1", 2), {
+        epistemicStatus: "inferred",
+      }),
+      {
+        basis: {
+          type: "declared-default",
+          description: "Default from the target contract.",
+        },
+        epistemicStatus: "defaulted",
+        confidence: "high",
+        content: { value: "value-2" },
+      },
+    ];
+
+    const result = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals,
+    });
+
+    expect(
+      result.snapshot.captures.map((capture) => capture.epistemicStatus),
+    ).toEqual(["explicit", "inferred", "defaulted"]);
+  });
+
+  test("defaulted and external values cite their non-user provenance instead of a user span", () => {
+    const proposals: CaptureInputProposal[] = [
+      {
+        basis: {
+          type: "declared-default",
+          description: "Default from the target contract.",
+        },
+        epistemicStatus: "defaulted",
+        confidence: "high",
+        content: { value: "default value" },
+      },
+      {
+        basis: {
+          type: "documented-transformation",
+          description: "Converted from the external source record.",
+        },
+        epistemicStatus: "external-lookup",
+        confidence: "high",
+        content: { value: "looked-up value" },
+      },
+    ];
+
+    const result = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals,
+    });
+    expect(
+      result.snapshot.captures.map((capture) => capture.epistemicStatus),
+    ).toEqual(["defaulted", "external-lookup"]);
+
+    const userCitedDefault = applyCaptureStoreCommand(result.snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        {
+          ...valueProposal("invalid default"),
+          epistemicStatus: "defaulted",
+        } as unknown as CaptureInputProposal,
+      ],
+    });
+    expect(userCitedDefault).toMatchObject({
+      ok: false,
+      refusal: { code: "invalid-envelope" },
+    });
+  });
+
+  test("harness-invariant: 4 — supersession keeps history and status is derived", () => {
+    const original = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [valueProposal("budget = €20,000")],
+    });
+    const originalId = original.snapshot.captures[0]!.id;
+    const corrected = apply(original.snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("budget = €25,000", userEvidence("Actually €25,000", 2), {
+          supersedes: originalId,
+        }),
+      ],
+    });
+    const correctionId = corrected.snapshot.captures[1]!.id;
+
+    expect(corrected.snapshot.captures).toHaveLength(2);
+    expect(deriveCaptureStatus(corrected.snapshot, originalId)).toBe(
+      "superseded",
+    );
+    expect(deriveCaptureStatus(corrected.snapshot, correctionId)).toBe(
+      "active",
+    );
+    expect(
+      corrected.snapshot.captures.every(
+        (capture) => "status" in capture === false,
+      ),
+    ).toBe(true);
+
+    const stale = applyCaptureStoreCommand(corrected.snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("budget = €30,000", userEvidence("No, €30,000", 3), {
+          supersedes: originalId,
+        }),
+      ],
+    });
+    expect(stale).toMatchObject({
+      ok: false,
+      refusal: {
+        code: "superseded-target-not-active",
+        targetCaptureId: originalId,
+        currentHeadIds: [correctionId],
+      },
+    });
+  });
+
+  test("harness-invariant: 2 — a conflict closes only through a user-cited resolution record", () => {
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("launch = March", userEvidence("Launch in March", 1)),
+        valueProposal("launch = June", userEvidence("Maybe June", 2), {
+          epistemicStatus: "tentative",
+        }),
+      ],
+    });
+    const [marchId, juneId] = captures.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+    const issueId = issue.value.issueId;
+
+    expect(
+      applyCaptureStoreCommand(issue.snapshot, {
+        type: "close-issue",
+        issueId,
+      }),
+    ).toMatchObject({ ok: false, refusal: { code: "resolution-required" } });
+    expect(
+      applyCaptureStoreCommand(issue.snapshot, {
+        type: "resolve-conflict",
+        issueId,
+        decision: "June wins",
+        evidence: [
+          {
+            ...userEvidence("I suggest June", 3),
+            source: "agent",
+          } as unknown as EvidenceQuote,
+        ],
+        winnerCaptureId: juneId!,
+        loserCaptureIds: [marchId!],
+      }),
+    ).toMatchObject({ ok: false, refusal: { code: "invalid-resolution" } });
+    expect(
+      applyCaptureStoreCommand(issue.snapshot, {
+        type: "resolve-conflict",
+        issueId,
+        decision: "June wins",
+        evidence: [
+          {
+            ...userEvidence("June", 4),
+            source: "user-affordance-payload",
+          } as unknown as EvidenceQuote,
+        ],
+        winnerCaptureId: juneId!,
+        loserCaptureIds: [marchId!],
+      }),
+    ).toMatchObject({ ok: false, refusal: { code: "invalid-resolution" } });
+
+    const resolved = apply(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId,
+      decision: "June wins",
+      evidence: [userEvidence("Confirmed: June", 4)],
+      winnerCaptureId: juneId!,
+      loserCaptureIds: [marchId!],
+    });
+
+    expect(deriveIssueStatus(resolved.snapshot, issueId)).toBe("closed");
+    expect(deriveCaptureStatus(resolved.snapshot, marchId!)).toBe("superseded");
+    expect(deriveCaptureStatus(resolved.snapshot, juneId!)).toBe("active");
+    expect(resolved.snapshot.issues[0]).not.toHaveProperty("status");
+  });
+
+  test("a resolution accounts for every capture named by the conflict", () => {
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        valueProposal("September", userEvidence("September", 3)),
+      ],
+    });
+    const captureIds = captures.snapshot.captures.map((capture) => capture.id);
+    const issue = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: captureIds,
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+
+    const partial = applyCaptureStoreCommand(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId: issue.value.issueId,
+      decision: "September wins",
+      evidence: [userEvidence("September wins", 4)],
+      winnerCaptureId: captureIds[2]!,
+      loserCaptureIds: [captureIds[0]!],
+    });
+    expect(partial).toMatchObject({
+      ok: false,
+      refusal: { code: "invalid-resolution" },
+    });
+  });
+
+  test("persisted issue-close events cannot silently close a conflict", () => {
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        captures: [],
+        issues: [
+          {
+            id: "issue-1",
+            type: "conflicting",
+            origin: { type: "harness" },
+            // Two references, and the assertion names the rule it means: with
+            // one reference this fixture is refused for referencing too few
+            // captures, and would have gone green without reaching the
+            // issue-closed rule at all.
+            references: ["capture-1", "capture-2"],
+            canDefault: false,
+          },
+        ],
+        events: [{ id: "event-1", type: "issue-closed", issueId: "issue-1" }],
+      }),
+    ).toThrow(/without a resolution record/i);
+  });
+
+  test("persisted snapshots refuse more than one closing event for an issue", () => {
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [valueProposal("March", userEvidence("March", 1))],
+    }).snapshot;
+    const captureId = captures.captures[0]!.id;
+    const issue = apply(captures, {
+      type: "open-issue",
+      issueType: "ambiguous",
+      origin: { type: "harness" },
+      references: [captureId],
+      canDefault: true,
+    }).snapshot;
+    const closed = apply(issue, {
+      type: "close-issue",
+      issueId: issue.issues[0]!.id,
+    }).snapshot;
+
+    expect(() => parseCaptureStoreSnapshot(closed)).not.toThrow();
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...closed,
+        events: [
+          ...closed.events,
+          {
+            id: "event-duplicate-close",
+            type: "issue-closed",
+            issueId: issue.issues[0]!.id,
+          },
+        ],
+      }),
+    ).toThrow(/more than one closing event/i);
+  });
+
+  test("persisted snapshots refuse stale keys and forking supersession graphs", () => {
+    const base = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("original", userEvidence("original", 1)),
+        valueProposal("first correction", userEvidence("first correction", 2)),
+        valueProposal(
+          "second correction",
+          userEvidence("second correction", 3),
+        ),
+      ],
+    }).snapshot;
+
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...base,
+        captures: [
+          { ...base.captures[0], dedupKey: "stale-key" },
+          ...base.captures.slice(1),
+        ],
+      }),
+    ).toThrow(/dedup key/i);
+
+    const originalId = base.captures[0]!.id;
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...base,
+        captures: [
+          base.captures[0],
+          { ...base.captures[1], supersedes: originalId },
+          { ...base.captures[2], supersedes: originalId },
+        ],
+      }),
+    ).toThrow(/fork/i);
+  });
+
+  test("open-issue refuses every issue the persisted contract would reject", () => {
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [valueProposal("launch = June")],
+    });
+    const captureId = created.snapshot.captures[0]!.id;
+    const wellFormed = {
+      type: "open-issue",
+      issueType: "ambiguous",
+      origin: { type: "harness" },
+      references: [captureId],
+      canDefault: false,
+    } as const;
+
+    for (const [reason, overrides] of [
+      ["an issue type outside the vocabulary", { issueType: "nonsense" }],
+      ["a plugin origin naming no producer", { origin: { type: "plugin" } }],
+      [
+        "a plugin origin whose namespace is empty",
+        { origin: { type: "plugin", namespace: "" } },
+      ],
+      ["no references at all", { references: [] }],
+      [
+        "the same capture referenced twice",
+        { references: [captureId, captureId] },
+      ],
+      [
+        "a reference to a capture that does not exist",
+        { references: ["capture-missing"] },
+      ],
+      ["a non-boolean can-default", { canDefault: "yes" }],
+    ] as const) {
+      const result = applyCaptureStoreCommand(created.snapshot, {
+        ...wellFormed,
+        ...overrides,
+      } as unknown as Parameters<typeof applyCaptureStoreCommand>[1]);
+      expect({
+        reason,
+        refused: !result.ok,
+        code: result.ok ? undefined : result.refusal.code,
+      }).toEqual({ reason, refused: true, code: "invalid-envelope" });
+    }
+
+    // The positive control: the same command without an override is accepted,
+    // so the table is refusing the overrides and not the shape they start from.
+    expect(apply(created.snapshot, wellFormed).snapshot.issues).toHaveLength(1);
+  });
+
+  test("a conflicting issue opens only over two or more distinct active captures", () => {
+    // Every refusal here is a conflict that could never have closed. Closing a
+    // conflict takes a resolution; a resolution cites a winner and at least one
+    // loser, all still active, and exactly the issue's reference set. A single
+    // reference cannot equal a set of two or more, and a superseded or retracted
+    // reference fails the activity rule no matter who is cited.
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        valueProposal("September", userEvidence("September", 3)),
+      ],
+    });
+    const [marchId, juneId, septemberId] = created.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    // March is superseded by a correction; September is retracted.
+    const corrected = apply(created.snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("April", userEvidence("Actually April", 4), {
+          supersedes: marchId!,
+        }),
+      ],
+    });
+    const withRetraction = apply(corrected.snapshot, {
+      type: "retract-capture",
+      captureId: septemberId!,
+      evidence: [userEvidence("Forget September", 5)],
+    });
+    const aprilId = corrected.snapshot.captures.at(-1)!.id;
+    const openConflict = (references: readonly string[]) =>
+      applyCaptureStoreCommand(withRetraction.snapshot, {
+        type: "open-issue",
+        issueType: "conflicting",
+        origin: { type: "harness" },
+        references,
+        canDefault: false,
+      });
+
+    for (const [reason, references, expectedMessage] of [
+      [
+        "a conflict of one capture",
+        [juneId!],
+        /conflicting issue needs at least two/i,
+      ],
+      [
+        "a conflict naming a superseded capture",
+        [juneId!, marchId!],
+        /active captures.*superseded/i,
+      ],
+      [
+        "a conflict naming a retracted capture",
+        [juneId!, septemberId!],
+        /active captures.*retracted/i,
+      ],
+    ] as const) {
+      const result = openConflict(references);
+      expect({
+        reason,
+        refused: !result.ok,
+        code: result.ok ? undefined : result.refusal.code,
+        message: result.ok ? undefined : result.refusal.message,
+      }).toEqual({
+        reason,
+        refused: true,
+        code: "invalid-envelope",
+        message: expect.stringMatching(expectedMessage),
+      });
+    }
+
+    // The positive control, and the reason the rule is worth having: a conflict
+    // over two active captures opens and then closes.
+    const issue = apply(withRetraction.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [juneId!, aprilId],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+    const resolved = apply(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId: issue.value.issueId,
+      decision: "June wins",
+      evidence: [userEvidence("Confirmed: June", 6)],
+      winnerCaptureId: juneId!,
+      loserCaptureIds: [aprilId],
+    });
+    expect(deriveIssueStatus(resolved.snapshot, issue.value.issueId)).toBe(
+      "closed",
+    );
+
+    // A non-conflicting issue is untouched by either rule: one reference is a
+    // complete population, and close-issue can always close it.
+    const ambiguous = apply(withRetraction.snapshot, {
+      type: "open-issue",
+      issueType: "ambiguous",
+      origin: { type: "harness" },
+      references: [marchId!],
+      canDefault: true,
+    });
+    if (!("issueId" in ambiguous.value))
+      throw new Error("Opening an issue did not return its id.");
+    const closed = apply(ambiguous.snapshot, {
+      type: "close-issue",
+      issueId: ambiguous.value.issueId,
+    });
+    expect(deriveIssueStatus(closed.snapshot, ambiguous.value.issueId)).toBe(
+      "closed",
+    );
+  });
+
+  test("open conflicts stay pairwise disjoint so every conflict keeps a legal closing path", () => {
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        valueProposal("September", userEvidence("September", 3)),
+        valueProposal("December", userEvidence("December", 4)),
+      ],
+    });
+    const [marchId, juneId, septemberId, decemberId] =
+      captures.snapshot.captures.map((capture) => capture.id);
+    const first = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+
+    for (const [reason, references] of [
+      ["shares the first capture", [marchId!, septemberId!]],
+      ["shares the second capture", [juneId!, septemberId!]],
+      ["contains the first conflict", [marchId!, juneId!, septemberId!]],
+    ] as const) {
+      const result = applyCaptureStoreCommand(first.snapshot, {
+        type: "open-issue",
+        issueType: "conflicting",
+        origin: { type: "harness" },
+        references,
+        canDefault: false,
+      });
+      expect({
+        reason,
+        refused: !result.ok,
+        code: result.ok ? undefined : result.refusal.code,
+        message: result.ok ? undefined : result.refusal.message,
+      }).toEqual({
+        reason,
+        refused: true,
+        code: "invalid-envelope",
+        message: expect.stringMatching(/open conflict.*share/i),
+      });
+    }
+
+    const disjoint = apply(first.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [septemberId!, decemberId!],
+      canDefault: false,
+    });
+    expect(disjoint.snapshot.issues).toHaveLength(2);
+
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...first.snapshot,
+        issues: [
+          ...first.snapshot.issues,
+          {
+            id: "issue-overlap",
+            type: "conflicting",
+            origin: { type: "harness" },
+            references: [juneId!, septemberId!],
+            canDefault: false,
+          },
+        ],
+      }),
+    ).toThrow(/open conflict.*share/i);
+
+    // The command surface pins these captures, but a persisted snapshot could
+    // have been edited or written by an older producer. The read boundary must
+    // enforce the same closure property instead of reviving an unresolvable
+    // open conflict.
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...first.snapshot,
+        events: [
+          ...first.snapshot.events,
+          {
+            id: "event-illegal-retraction",
+            type: "retraction",
+            captureId: marchId!,
+            evidence: [storedEvidence("Forget March", 5)],
+          },
+        ],
+      }),
+    ).toThrow(/open conflict.*inactive capture/i);
+  });
+
+  test("an unresolved conflict pins its captures against supersession and retraction", () => {
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        // Named by no conflict, so it stays free to correct and retract — the
+        // guard pins the disputed captures, not the store.
+        valueProposal("Venue", userEvidence("Venue is the hall", 3)),
+      ],
+    });
+    const [marchId, juneId, venueId] = captures.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+    const issueId = issue.value.issueId;
+
+    for (const [attempt, command] of [
+      [
+        "superseding the March side",
+        {
+          type: "apply-sweep",
+          proposals: [
+            valueProposal("April", userEvidence("Actually April", 4), {
+              supersedes: marchId!,
+            }),
+          ],
+        },
+      ],
+      [
+        "superseding the June side",
+        {
+          type: "apply-sweep",
+          proposals: [
+            valueProposal("July", userEvidence("Actually July", 5), {
+              supersedes: juneId!,
+            }),
+          ],
+        },
+      ],
+      [
+        "retracting the March side",
+        {
+          type: "retract-capture",
+          captureId: marchId!,
+          evidence: [userEvidence("Forget it", 6)],
+        },
+      ],
+      [
+        "retracting the June side",
+        {
+          type: "retract-capture",
+          captureId: juneId!,
+          evidence: [userEvidence("Forget it", 7)],
+        },
+      ],
+    ] as const) {
+      const result = applyCaptureStoreCommand(issue.snapshot, command);
+      expect({
+        attempt,
+        refused: !result.ok,
+        code: result.ok ? undefined : result.refusal.code,
+        blocking: result.ok
+          ? undefined
+          : "blockingIssueIds" in result.refusal
+            ? result.refusal.blockingIssueIds
+            : undefined,
+      }).toEqual({
+        attempt,
+        refused: true,
+        code: "blocked-by-open-conflict",
+        blocking: [issueId],
+      });
+    }
+
+    // A capture no conflict names is unaffected.
+    expect(
+      apply(issue.snapshot, {
+        type: "retract-capture",
+        captureId: venueId!,
+        evidence: [userEvidence("Not the hall after all", 8)],
+      }).snapshot.events,
+    ).toHaveLength(1);
+
+    // And the pin lifts once the conflict closes the one way it can: the loser
+    // is superseded by the resolution itself, and the winner is free again.
+    const resolved = apply(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId,
+      decision: "June wins",
+      evidence: [userEvidence("Confirmed: June", 9)],
+      winnerCaptureId: juneId!,
+      loserCaptureIds: [marchId!],
+    });
+    expect(deriveCaptureStatus(resolved.snapshot, marchId!)).toBe("superseded");
+    expect(
+      apply(resolved.snapshot, {
+        type: "retract-capture",
+        captureId: juneId!,
+        evidence: [userEvidence("Forget June too", 10)],
+      }).snapshot.events,
+    ).toHaveLength(2);
+  });
+
+  test("a persisted conflicting issue of one capture is not readable", () => {
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+      ],
+    });
+    const [marchId, juneId] = created.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(created.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    }).snapshot;
+
+    expect(() => parseCaptureStoreSnapshot(issue)).not.toThrow();
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...issue,
+        issues: [{ ...issue.issues[0]!, references: [marchId!] }],
+      }),
+    ).toThrow(/at least two captures/i);
+  });
+
+  test("a resolution accounts for its conflict by set equality, not by count and membership", () => {
+    // The combination the old pair admitted: an issue referencing one capture
+    // twice, and a resolution citing two — equal in length, every reference
+    // present among the cited, and the cited distinct. Unique references make
+    // the issue unrepresentable at both surfaces, which is the point.
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+      ],
+    });
+    const [marchId, juneId] = captures.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+    const resolved = apply(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId: issue.value.issueId,
+      decision: "June wins",
+      evidence: [userEvidence("Confirmed: June", 3)],
+      winnerCaptureId: juneId!,
+      loserCaptureIds: [marchId!],
+    }).snapshot;
+
+    expect(() => parseCaptureStoreSnapshot(resolved)).not.toThrow();
+    expect(() =>
+      parseCaptureStoreSnapshot({
+        ...resolved,
+        issues: [{ ...resolved.issues[0]!, references: [marchId!, marchId!] }],
+      }),
+    ).toThrow(/distinct/i);
+  });
+
+  test("a command stores its own copy of the evidence and ids the caller passed", () => {
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+      ],
+    });
+    const [marchId, juneId] = created.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(created.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+
+    const resolutionEvidence = [userEvidence("Confirmed: June", 3)];
+    const losers = [marchId!];
+    const resolved = apply(issue.snapshot, {
+      type: "resolve-conflict",
+      issueId: issue.value.issueId,
+      decision: "June wins",
+      evidence: resolutionEvidence,
+      winnerCaptureId: juneId!,
+      loserCaptureIds: losers,
+    });
+    const retractionEvidence = [userEvidence("Forget June too", 4)];
+    const retracted = apply(resolved.snapshot, {
+      type: "retract-capture",
+      captureId: juneId!,
+      evidence: retractionEvidence,
+    });
+
+    // Everything the caller still holds, edited after the store accepted it.
+    (resolutionEvidence[0] as { excerpt: string }).excerpt =
+      "Mutated resolution quote";
+    resolutionEvidence.push(userEvidence("Injected into the resolution", 5));
+    losers.push("capture-injected");
+    (retractionEvidence[0] as { excerpt: string }).excerpt =
+      "Mutated retraction quote";
+    retractionEvidence.push(userEvidence("Injected into the retraction", 6));
+
+    const resolution = retracted.snapshot.events.find(
+      (event) => event.type === "resolution",
+    );
+    const retraction = retracted.snapshot.events.find(
+      (event) => event.type === "retraction",
+    );
+    if (
+      resolution?.type !== "resolution" ||
+      retraction?.type !== "retraction"
+    ) {
+      throw new Error("The store did not record both events.");
+    }
+    expect({
+      resolutionEvidence: resolution.evidence,
+      loserCaptureIds: resolution.loserCaptureIds,
+      retractionEvidence: retraction.evidence,
+    }).toEqual({
+      resolutionEvidence: [storedEvidence("Confirmed: June", 3)],
+      loserCaptureIds: [marchId!],
+      retractionEvidence: [storedEvidence("Forget June too", 4)],
+    });
+    // And the snapshot the caller could still reach is one the parser accepts.
+    expect(() => parseCaptureStoreSnapshot(retracted.snapshot)).not.toThrow();
+  });
+
+  test("a caller-supplied evidence range is refused at every evidence command surface", () => {
+    const reversed: EvidenceSpan = {
+      excerpt: "Reversed range",
+      pointer: { sessionId: "session-1", entryStart: 5, entryEnd: 4 },
+      source: "user",
+    };
+    const captures = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        // Outside the conflict opened below, so the retraction row is refused
+        // for its reversed span rather than by the open-conflict guard.
+        valueProposal("September", userEvidence("September", 3)),
+      ],
+    });
+    const [marchId, juneId, septemberId] = captures.snapshot.captures.map(
+      (capture) => capture.id,
+    );
+    const issue = apply(captures.snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in issue.value))
+      throw new Error("Opening an issue did not return its id.");
+
+    for (const [surface, command, code] of [
+      [
+        "apply-sweep",
+        {
+          type: "apply-sweep",
+          proposals: [
+            valueProposal("reversed", reversed as unknown as EvidenceQuote),
+          ],
+        },
+        "invalid-envelope",
+      ],
+      [
+        "resolve-conflict",
+        {
+          type: "resolve-conflict",
+          issueId: issue.value.issueId,
+          decision: "June wins",
+          evidence: [reversed as unknown as EvidenceQuote],
+          winnerCaptureId: juneId!,
+          loserCaptureIds: [marchId!],
+        },
+        "invalid-resolution",
+      ],
+      [
+        "retract-capture",
+        {
+          type: "retract-capture",
+          captureId: septemberId!,
+          evidence: [reversed as unknown as EvidenceQuote],
+        },
+        "invalid-retraction",
+      ],
+    ] as const) {
+      const result = applyCaptureStoreCommand(issue.snapshot, command);
+      expect({
+        surface,
+        refused: !result.ok,
+        code: result.ok ? undefined : result.refusal.code,
+      }).toEqual({ surface, refused: true, code });
+    }
+  });
+
+  test("persisted snapshots refuse a reversed evidence range in a capture or an event", () => {
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [valueProposal("launch = June")],
+    });
+    const retracted = apply(created.snapshot, {
+      type: "retract-capture",
+      captureId: created.snapshot.captures[0]!.id,
+      evidence: [userEvidence("Forget the June date", 2)],
+    }).snapshot;
+
+    // Bent from a snapshot the store itself produced, so the reversed range is
+    // the only thing wrong with what the parser is handed.
+    type EvidenceBearing = { evidence: { pointer: Record<string, unknown> }[] };
+    const withReversedRange = (family: "captures" | "events"): unknown => {
+      const clone = structuredClone(retracted) as unknown as Record<
+        string,
+        EvidenceBearing[]
+      >;
+      const span = clone[family]![0]!.evidence[0]!;
+      span.pointer = { ...span.pointer, entryStart: 5, entryEnd: 4 };
+      return clone;
+    };
+
+    expect(() => parseCaptureStoreSnapshot(retracted)).not.toThrow();
+    expect(() =>
+      parseCaptureStoreSnapshot(withReversedRange("captures")),
+    ).toThrow(/range/i);
+    expect(() =>
+      parseCaptureStoreSnapshot(withReversedRange("events")),
+    ).toThrow(/range/i);
+  });
+
+  test("every command type round-trips its accepted result through persisted parsing", () => {
+    // `apply` checks the round-trip on every command the suite accepts, so this
+    // test does not repeat the check — it pins the *coverage*: that a script
+    // exists exercising each command type, and that the set is complete. The
+    // `Record<CaptureStoreCommand['type'], …>` annotation is what keeps it
+    // complete: a sixth command will not typecheck until it appears here.
+    const exercised: Record<CaptureStoreCommand["type"], boolean> = {
+      "apply-sweep": false,
+      "open-issue": false,
+      "close-issue": false,
+      "resolve-conflict": false,
+      "retract-capture": false,
+    };
+
+    let snapshot = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("March", userEvidence("March", 1)),
+        valueProposal("June", userEvidence("June", 2)),
+        valueProposal("Venue", userEvidence("Venue is the hall", 3)),
+        {
+          basis: {
+            type: "declared-default",
+            description: "Default from the target contract.",
+          },
+          epistemicStatus: "defaulted",
+          confidence: "high",
+          content: { absence: "not-yet-decided" },
+        },
+      ],
+    }).snapshot;
+    exercised["apply-sweep"] = true;
+    const [marchId, juneId, venueId] = snapshot.captures.map(
+      (capture) => capture.id,
+    );
+
+    // A supersession, so the round-trip covers a capture carrying `supersedes`
+    // and a snapshot with a supersession link in it.
+    snapshot = apply(snapshot, {
+      type: "apply-sweep",
+      proposals: [
+        valueProposal("The garden", userEvidence("Actually the garden", 4), {
+          supersedes: venueId!,
+          alternativeGroup: "venue",
+        }),
+      ],
+    }).snapshot;
+
+    const ambiguous = apply(snapshot, {
+      type: "open-issue",
+      issueType: "ambiguous",
+      origin: { type: "plugin", namespace: "gherkin" },
+      references: [marchId!],
+      canDefault: true,
+    });
+    exercised["open-issue"] = true;
+    if (!("issueId" in ambiguous.value))
+      throw new Error("Opening an issue did not return its id.");
+    snapshot = apply(ambiguous.snapshot, {
+      type: "close-issue",
+      issueId: ambiguous.value.issueId,
+    }).snapshot;
+    exercised["close-issue"] = true;
+
+    const conflict = apply(snapshot, {
+      type: "open-issue",
+      issueType: "conflicting",
+      origin: { type: "harness" },
+      references: [marchId!, juneId!],
+      canDefault: false,
+    });
+    if (!("issueId" in conflict.value))
+      throw new Error("Opening an issue did not return its id.");
+    snapshot = apply(conflict.snapshot, {
+      type: "resolve-conflict",
+      issueId: conflict.value.issueId,
+      decision: "June wins",
+      evidence: [userEvidence("Confirmed: June", 5)],
+      winnerCaptureId: juneId!,
+      loserCaptureIds: [marchId!],
+    }).snapshot;
+    exercised["resolve-conflict"] = true;
+
+    snapshot = apply(snapshot, {
+      type: "retract-capture",
+      captureId: juneId!,
+      evidence: [userEvidence("Forget June too", 6)],
+    }).snapshot;
+    exercised["retract-capture"] = true;
+
+    const unexercised = Object.entries(exercised)
+      .filter(([, seen]) => !seen)
+      .map(([type]) => type);
+    expect(unexercised).toEqual([]);
+    // The whole accumulated history, not only the last step's addition.
+    expect(
+      parseCaptureStoreSnapshot(JSON.parse(JSON.stringify(snapshot))),
+    ).toEqual(snapshot);
+    expect({
+      captures: snapshot.captures.length,
+      issues: snapshot.issues.length,
+      events: snapshot.events.length,
+    }).toEqual({ captures: 5, issues: 2, events: 3 });
+  });
+
+  test("retraction is a user-cited event with no successor", () => {
+    const created = apply(createEmptyCaptureStoreSnapshot(), {
+      type: "apply-sweep",
+      proposals: [valueProposal("launch = June")],
+    });
+    const captureId = created.snapshot.captures[0]!.id;
+    expect(
+      applyCaptureStoreCommand(created.snapshot, {
+        type: "retract-capture",
+        captureId,
+        evidence: [
+          {
+            ...userEvidence("Forget the June date", 2),
+            source: "user-affordance-payload",
+          } as unknown as EvidenceQuote,
+        ],
+      }),
+    ).toMatchObject({ ok: false, refusal: { code: "invalid-retraction" } });
+
+    const retracted = apply(created.snapshot, {
+      type: "retract-capture",
+      captureId,
+      evidence: [userEvidence("Forget the June date", 2)],
+    });
+
+    expect(deriveCaptureStatus(retracted.snapshot, captureId)).toBe(
+      "retracted",
+    );
+    expect(retracted.snapshot.captures[0]).not.toHaveProperty("status");
+    expect(retracted.snapshot.events.at(-1)).toMatchObject({
+      type: "retraction",
+      captureId,
+    });
+    expect(retracted.snapshot.events.at(-1)).not.toHaveProperty(
+      "successorCaptureId",
+    );
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/naming.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/naming.test.ts
new file mode 100644
index 00000000000..4113e30b975
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/naming.test.ts
@@ -0,0 +1,97 @@
+import { describe, expect, test } from "vitest";
+
+import {
+  OPERATIONS,
+  PRODUCT_NAME,
+  toolName,
+  toolPrefix,
+  type Operation,
+  type ToolName,
+} from "../src/naming";
+
+// Spec §12.3: architectural strings name identity, not function. The tool
+// prefix derives from the product name so the unresolved name-fog costs one
+// edit, not a repo-wide rename.
+describe("tool namespacing", () => {
+  test("the prefix derives from the product name", () => {
+    expect(toolPrefix("Loom")).toBe("loom_");
+    expect(toolPrefix("bl")).toBe("bl_");
+  });
+
+  test("the prefix normalizes punctuation and spacing out of a product name", () => {
+    expect(toolPrefix("Well-Spoken 2")).toBe("wellspoken2_");
+  });
+
+  test("a product name with no usable characters is refused, not silently emptied", () => {
+    expect(() => toolPrefix("  -- ")).toThrow(/product name/i);
+    expect(() => toolPrefix("")).toThrow(/product name/i);
+  });
+
+  test("a product name that starts with a digit is refused", () => {
+    // Tool names have to read as identifiers to the model and the substrate.
+    expect(() => toolPrefix("2fast")).toThrow(/product name/i);
+  });
+
+  test("tool names are the prefix applied to an abstract operation name", () => {
+    expect(toolName("ask", "Loom")).toBe("loom_ask");
+  });
+
+  test("tool names default to the current product name", () => {
+    const askToolName: ToolName<"ask"> = toolName("ask");
+    expect(askToolName).toBe(`${toolPrefix(PRODUCT_NAME)}ask`);
+  });
+
+  test("an operation name that is not an identifier is refused", () => {
+    // Cast on purpose: the parameter type already forbids these, and the
+    // runtime guard behind it is what this test pins for untyped callers.
+    expect(() => toolName("ask user!" as unknown as Operation, "Loom")).toThrow(
+      /operation/i,
+    );
+    expect(() => toolName("" as unknown as Operation, "Loom")).toThrow(
+      /operation/i,
+    );
+  });
+
+  test("an operation core never declared does not compile", () => {
+    // The FE-1361 review's verified finding: with a plain-string parameter,
+    // `toolName('aks')` compiled and shipped a misnamed model-facing tool.
+    // Never called — 'aks' is a well-formed identifier, so only the type
+    // rejects it. If the directive ever reports as unused, the parameter has
+    // widened back to string and the typo channel is open again.
+    // @ts-expect-error -- 'aks' is not an Operation
+    const misspelled = () => toolName("aks");
+    expect(misspelled).toBeInstanceOf(Function);
+  });
+});
+
+describe("the settled product name", () => {
+  test("names identity, never function", () => {
+    // Spec §12.3's surviving rule. The ban on `brunch` lapsed when the name
+    // settled (ADR-0001); the ban on naming what a tool *does* did not, and it
+    // is the half that was load-bearing — `elicit_*` would fix the product's
+    // purpose in every model-facing string it owns.
+    const prefix = toolPrefix(PRODUCT_NAME);
+    expect(prefix).not.toContain("elicit");
+    for (const operation of OPERATIONS) {
+      expect(toolName(operation)).not.toContain("elicit");
+    }
+  });
+
+  test("every model-facing tool carries the product prefix", () => {
+    // Flue requires globally unique tool names per render and reserves some of
+    // its own; the prefix is what keeps this product's tools from colliding
+    // with a co-mounted library's.
+    for (const operation of OPERATIONS) {
+      expect(toolName(operation).startsWith(toolPrefix(PRODUCT_NAME))).toBe(
+        true,
+      );
+    }
+  });
+
+  test("every declared operation renders a distinct, well-formed tool name", () => {
+    const names = OPERATIONS.map((operation) => toolName(operation));
+    expect(new Set(names).size).toBe(names.length);
+    for (const name of names)
+      expect(name).toMatch(/^[a-z][a-z0-9]*_[a-z][a-z0-9_]*$/);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/session-log.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/session-log.test.ts
new file mode 100644
index 00000000000..235234d77ad
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/session-log.test.ts
@@ -0,0 +1,179 @@
+import { describe, expect, test } from "vitest";
+
+import {
+  archiveSessionLogRead,
+  createEmptySessionLogArchive,
+  readArchivedEntryRange,
+  resolveEvidenceQuotes,
+  type SessionLogRead,
+} from "../src/session-log";
+
+const read = (
+  offset: string,
+  entries: SessionLogRead["entries"],
+  settlements: SessionLogRead["settlements"] = [],
+): SessionLogRead => ({
+  sessionId: "session-1",
+  offset,
+  incarnation: "incarnation-1",
+  entries,
+  settlements,
+});
+
+const entry = (
+  substrateEntryId: string,
+  kind: SessionLogRead["entries"][number]["kind"],
+  text: string,
+  materialized: SessionLogRead["entries"][number]["materialized"] = { text },
+): SessionLogRead["entries"][number] => ({
+  substrateEntryId,
+  kind,
+  text,
+  materialized,
+});
+
+describe("session-log archive", () => {
+  test("identity-merges evolving entries, versions changed materializations, and skips exact duplicates", () => {
+    const first = archiveSessionLogRead(
+      createEmptySessionLogArchive(),
+      read("0", [
+        entry("message-user", "user", "Budget is twenty thousand euros."),
+        entry("message-assistant", "assistant", "Let me", {
+          parts: [{ type: "text", text: "Let me", state: "streaming" }],
+        }),
+      ]),
+    );
+    const repeated = archiveSessionLogRead(first, read("0", firstReadEntries));
+    const evolved = archiveSessionLogRead(
+      repeated,
+      read(
+        "1",
+        [
+          entry("message-user", "user", "Budget is twenty thousand euros."),
+          entry("message-assistant", "assistant", "Let me confirm that.", {
+            parts: [
+              { type: "text", text: "Let me confirm that.", state: "done" },
+            ],
+          }),
+        ],
+        [{ submissionId: "submission-1", outcome: "completed" }],
+      ),
+    );
+
+    const session = evolved.sessions[0]!;
+    expect(
+      session.entries.map(({ ordinal, substrateEntryId }) => ({
+        ordinal,
+        substrateEntryId,
+      })),
+    ).toEqual([
+      { ordinal: 1, substrateEntryId: "message-user" },
+      { ordinal: 2, substrateEntryId: "message-assistant" },
+    ]);
+    expect(session.entries[0]!.versions).toHaveLength(1);
+    expect(session.entries[1]!.versions).toHaveLength(2);
+    expect(session.reads.map(({ offset }) => offset)).toEqual(["0", "1"]);
+    expect(session.reads[1]!.settlements).toEqual([
+      { submissionId: "submission-1", outcome: "completed" },
+    ]);
+  });
+
+  test("resolves true-user and harness-classified affordance quotes to archive ordinals", () => {
+    const archive = archiveSessionLogRead(
+      createEmptySessionLogArchive(),
+      read("3", [
+        entry("message-injected", "non-user", "Begin the interview."),
+        entry("message-user-1", "user", "June works."),
+        entry("message-affordance", "user-affordance-payload", "June works."),
+      ]),
+    );
+
+    expect(
+      resolveEvidenceQuotes(archive, "session-1", [{ excerpt: "June works." }]),
+    ).toEqual({
+      ok: true,
+      evidence: [
+        {
+          excerpt: "June works.",
+          pointer: { sessionId: "session-1", entryStart: 3, entryEnd: 3 },
+          source: "user-affordance-payload",
+        },
+      ],
+      advisories: [
+        {
+          type: "multiple-evidence-matches",
+          excerpt: "June works.",
+          matchCount: 2,
+          message:
+            "The quote matched 2 user entries; the latest match was selected.",
+        },
+      ],
+    });
+  });
+
+  test("distinguishes no match from an injected non-user match and provides repair guidance", () => {
+    const archive = archiveSessionLogRead(
+      createEmptySessionLogArchive(),
+      read("1", [
+        entry("message-injected", "non-user", "Begin the interview."),
+      ]),
+    );
+
+    expect(
+      resolveEvidenceQuotes(archive, "session-1", [{ excerpt: "missing" }]),
+    ).toEqual({
+      ok: false,
+      refusal: {
+        code: "evidence-quote-not-found",
+        excerpt: "missing",
+        message:
+          'No user entry contains the verbatim quote "missing". Repair the quote to match the user\'s words exactly.',
+      },
+    });
+    expect(
+      resolveEvidenceQuotes(archive, "session-1", [
+        { excerpt: "Begin the interview." },
+      ]),
+    ).toEqual({
+      ok: false,
+      refusal: {
+        code: "non-user-evidence",
+        excerpt: "Begin the interview.",
+        message:
+          'The quote "Begin the interview." occurs only in injected non-user entries and cannot be cited as user evidence.',
+      },
+    });
+  });
+
+  test("retrieves every entry in a stored pointer range without consulting the substrate", () => {
+    const archive = archiveSessionLogRead(
+      createEmptySessionLogArchive(),
+      read("2", [
+        entry("message-1", "user", "first"),
+        entry("message-2", "assistant", "second"),
+      ]),
+    );
+
+    expect(
+      readArchivedEntryRange(archive, {
+        sessionId: "session-1",
+        entryStart: 1,
+        entryEnd: 2,
+      }).map((archived) => archived.substrateEntryId),
+    ).toEqual(["message-1", "message-2"]);
+    expect(() =>
+      readArchivedEntryRange(archive, {
+        sessionId: "session-1",
+        entryStart: 2,
+        entryEnd: 3,
+      }),
+    ).toThrow(/not archived/i);
+  });
+});
+
+const firstReadEntries: SessionLogRead["entries"] = [
+  entry("message-user", "user", "Budget is twenty thousand euros."),
+  entry("message-assistant", "assistant", "Let me", {
+    parts: [{ type: "text", text: "Let me", state: "streaming" }],
+  }),
+];
diff --git a/libs/@hashintel/brunch-agent/packages/core/test/sweep-protocol.test.ts b/libs/@hashintel/brunch-agent/packages/core/test/sweep-protocol.test.ts
new file mode 100644
index 00000000000..049383c556a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/test/sweep-protocol.test.ts
@@ -0,0 +1,229 @@
+import { describe, expect, test } from "vitest";
+
+import {
+  advanceSweepHighWater,
+  buildSettlementCheckSignal,
+  buildSweepRepairSignal,
+  buildSweepExtractionPrompt,
+  computeUnaccountedAskAdvisories,
+  createInitialSweepState,
+  decideSettlementTrigger,
+  parseSweepState,
+  pendingSweepRepair,
+  reopenSweepAfterRefusal,
+  settlementProtocolInstructionFragments,
+  sweepableRange,
+  unsweptTail,
+  type SweepSessionEntry,
+} from "../src/sweep-protocol";
+
+const entries: readonly SweepSessionEntry[] = [
+  {
+    id: "assistant-ask",
+    kind: "assistant",
+    text: "",
+    affordances: [{ id: "affordance-1", markdown: "What outcome matters?" }],
+  },
+  {
+    id: "user-reply",
+    kind: "user-affordance-payload",
+    text: "A shopper completes checkout.",
+    replyToAffordanceId: "affordance-1",
+  },
+  {
+    id: "reply-binding",
+    kind: "non-user",
+    text: "Harness reply binding.",
+  },
+];
+
+describe("settlement and sweep protocol", () => {
+  test("keeps the high-water and loop guard in one parse-checked sweep state", () => {
+    const initial = createInitialSweepState();
+    expect(initial).toEqual({
+      sweptThroughUserEntryId: null,
+      lastCheckedUserEntryId: null,
+    });
+    expect(parseSweepState(initial)).toEqual(initial);
+    expect(() => parseSweepState({ ...initial, invented: true })).toThrow();
+  });
+
+  test("computes the unswept range through the latest true-user entry only", () => {
+    expect(unsweptTail(entries, createInitialSweepState())).toEqual(
+      entries.slice(0, 2),
+    );
+
+    const swept = advanceSweepHighWater(
+      createInitialSweepState(),
+      "user-reply",
+    );
+    expect(parseSweepState(swept)).toEqual({
+      sweptThroughUserEntryId: "user-reply",
+      lastCheckedUserEntryId: "user-reply",
+    });
+    expect(unsweptTail(entries, swept)).toEqual([]);
+    expect(sweepableRange(entries)).toEqual(entries.slice(0, 2));
+
+    expect(() =>
+      unsweptTail(entries, {
+        sweptThroughUserEntryId: "missing-entry",
+        lastCheckedUserEntryId: null,
+      }),
+    ).toThrow(/high-water/i);
+  });
+
+  test("nudges once per latest user entry, declines legally, and suppresses suspended asks", () => {
+    const initial = createInitialSweepState();
+    const pending = decideSettlementTrigger({
+      entries,
+      state: initial,
+      pendingAffordance: true,
+    });
+    expect(pending).toEqual({ action: "skip", reason: "pending-affordance" });
+
+    const first = decideSettlementTrigger({
+      entries,
+      state: initial,
+      pendingAffordance: false,
+    });
+    expect(first).toMatchObject({
+      action: "nudge",
+      throughUserEntryId: "user-reply",
+      nextState: { lastCheckedUserEntryId: "user-reply" },
+    });
+    if (first.action !== "nudge")
+      throw new Error("expected a settlement nudge");
+    expect(parseSweepState(first.nextState)).toEqual(first.nextState);
+
+    // Declining is represented by doing nothing. A later would-stop over the
+    // same latest user entry must therefore settle without another nudge.
+    expect(
+      decideSettlementTrigger({
+        entries: [
+          ...entries,
+          { id: "agent-declines", kind: "assistant", text: "Not yet." },
+        ],
+        state: first.nextState,
+        pendingAffordance: false,
+      }),
+    ).toEqual({ action: "skip", reason: "already-checked" });
+
+    const withNewUser: readonly SweepSessionEntry[] = [
+      ...entries,
+      { id: "user-2", kind: "user", text: "The receipt is emailed." },
+    ];
+    expect(
+      decideSettlementTrigger({
+        entries: withNewUser,
+        state: first.nextState,
+        pendingAffordance: false,
+      }),
+    ).toMatchObject({ action: "nudge", throughUserEntryId: "user-2" });
+  });
+
+  test("renders computed tail facts without exposing harness entry identities", () => {
+    const signal = buildSettlementCheckSignal(entries.slice(0, 2));
+    expect(signal).toMatchObject({
+      type: "settlement-check",
+      tagName: "settlement-check",
+    });
+    expect(signal.body).toContain("What outcome matters?");
+    expect(signal.body).toContain("A shopper completes checkout.");
+    expect(signal.body).toContain("Declining is legal");
+    expect(signal.body).not.toContain("assistant-ask");
+    expect(signal.body).not.toContain("user-reply");
+  });
+
+  test("keeps extraction quote-only and delegates the interior contract to the plugin", () => {
+    const prompt = buildSweepExtractionPrompt(
+      {
+        targetDomain: "gherkin",
+        proposalNames: ["statement-noted"],
+      },
+      entries.slice(0, 2),
+    );
+    expect(prompt).toContain("verbatim quote");
+    expect(prompt).toContain("statement-noted");
+    expect(prompt).toContain("declared proposal schema");
+    expect(prompt).toContain("A shopper completes checkout.");
+    expect(prompt).not.toContain("user-reply");
+  });
+
+  test("reports asks without an affordance-bound capture as advisory-only facts", () => {
+    const unanswered: readonly SweepSessionEntry[] = [
+      entries[0]!,
+      { id: "redirect", kind: "user", text: "Let us discuss payment instead." },
+    ];
+    expect(computeUnaccountedAskAdvisories(unanswered, new Set())).toEqual([
+      {
+        type: "unaccounted-ask",
+        affordanceId: "affordance-1",
+        question: "What outcome matters?",
+        message:
+          "The swept range contains an ask with no affordance-bound capture.",
+      },
+    ]);
+    expect(
+      computeUnaccountedAskAdvisories(entries.slice(0, 2), new Set()),
+    ).toHaveLength(1);
+    expect(
+      computeUnaccountedAskAdvisories(
+        entries.slice(0, 2),
+        new Set(["user-reply"]),
+      ),
+    ).toEqual([]);
+  });
+
+  test("gives a refused settled range one same-response repair continuation", () => {
+    const refusal = {
+      code: "evidence-quote-not-found",
+      message: "Use an exact quote.",
+    };
+    expect(buildSweepRepairSignal(refusal)).toEqual({
+      type: "sweep-repair",
+      tagName: "sweep-repair",
+      body: "The sweep was refused: Use an exact quote. Repair the proposal and call brunch_sweep again. Declining is legal.",
+    });
+    const refused: readonly SweepSessionEntry[] = [
+      ...entries,
+      {
+        id: "refusal",
+        kind: "assistant",
+        text: "",
+        sweepResult: { status: "refused", refusal },
+      },
+    ];
+    expect(pendingSweepRepair(refused)).toEqual(refusal);
+    expect(
+      pendingSweepRepair([
+        ...refused,
+        { id: "repair", kind: "non-user", text: "", sweepRepairSignal: true },
+      ]),
+    ).toBeNull();
+  });
+
+  test("reopens settlement judgment when application refuses", () => {
+    const checked = {
+      sweptThroughUserEntryId: "user-reply",
+      lastCheckedUserEntryId: "user-2",
+    };
+    expect(reopenSweepAfterRefusal(checked)).toEqual({
+      sweptThroughUserEntryId: "user-reply",
+      lastCheckedUserEntryId: "user-reply",
+    });
+    expect(
+      reopenSweepAfterRefusal({
+        sweptThroughUserEntryId: null,
+        lastCheckedUserEntryId: "user-reply",
+      }),
+    ).toEqual({ sweptThroughUserEntryId: null, lastCheckedUserEntryId: null });
+  });
+
+  test("adds settlement judgment and sweep cadence without domain payload guidance", () => {
+    expect(settlementProtocolInstructionFragments()).toEqual([
+      "When the harness reports an unswept tail, judge whether that range has settled. Declining is legal.",
+      "When it has settled, call brunch_sweep. The harness privately extracts quote-anchored proposals, refreshes durable history, applies them atomically, and advances the swept high-water mark only on success.",
+      "Projection and validation are read-time operations; do not treat sweep completion as a stored derived result.",
+    ]);
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/core/tsconfig.json b/libs/@hashintel/brunch-agent/packages/core/tsconfig.json
new file mode 100644
index 00000000000..844edbd8e66
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/tsconfig.json
@@ -0,0 +1,19 @@
+{
+  "compilerOptions": {
+    "target": "es2024",
+    "lib": ["ESNext"],
+    "types": ["node"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedIndexedAccess": true,
+    "resolveJsonModule": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "isolatedModules": true
+  },
+  "include": ["src", "test"]
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/turbo.json b/libs/@hashintel/brunch-agent/packages/core/turbo.json
new file mode 100644
index 00000000000..8e6bf27513e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/turbo.json
@@ -0,0 +1,20 @@
+{
+  "extends": ["//"],
+  "tasks": {
+    "baseline:run": {
+      "cache": false,
+      "passThroughEnv": [
+        "ANTHROPIC_API_KEY",
+        "BRUNCH_BASELINE_ANTHROPIC_MODULE"
+      ]
+    },
+    "build": {
+      "dependsOn": ["^build"],
+      "outputs": ["dist/**"],
+      "cache": false
+    },
+    "linear:graph": {
+      "cache": false
+    }
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/core/vite.config.ts b/libs/@hashintel/brunch-agent/packages/core/vite.config.ts
new file mode 100644
index 00000000000..fc0aa45b6c5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/core/vite.config.ts
@@ -0,0 +1,32 @@
+import { fileURLToPath } from "node:url";
+
+import { defineConfig } from "vitest/config";
+
+const packageRoot = fileURLToPath(new URL(".", import.meta.url));
+
+export default defineConfig({
+  build: {
+    lib: {
+      entry: {
+        "client-tools": fileURLToPath(
+          new URL("src/client-tools.ts", import.meta.url),
+        ),
+        index: fileURLToPath(new URL("src/index.ts", import.meta.url)),
+        storage: fileURLToPath(new URL("src/storage.ts", import.meta.url)),
+        "testing/index": fileURLToPath(
+          new URL("src/testing/index.ts", import.meta.url),
+        ),
+      },
+      fileName: (_format, entryName) => `${entryName}.js`,
+      formats: ["es"],
+    },
+    rolldownOptions: {
+      external: [/^node:/u, "valibot"],
+    },
+    sourcemap: true,
+  },
+  root: packageRoot,
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/LICENSE.md b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/LICENSE.md
new file mode 100644
index 00000000000..c7d627721e2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/LICENSE.md
@@ -0,0 +1,607 @@
+GNU Affero General Public License
+=================================
+
+_Version 3, 19 November 2007_
+_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+## Preamble
+
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+Developers that use our General Public Licenses protect your rights
+with two steps: **(1)** assert copyright on the software, and **(2)** offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+The precise terms and conditions for copying, distribution and
+modification follow.
+
+## TERMS AND CONDITIONS
+
+### 0. Definitions
+
+“This License” refers to version 3 of the GNU Affero General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as “you”.  “Licensees” and
+“recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a “modified version” of the
+earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based
+on the Program.
+
+To “propagate” a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices”
+to the extent that it includes a convenient and prominently visible
+feature that **(1)** displays an appropriate copyright notice, and **(2)**
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+### 1. Source Code
+
+The “source code” for a work means the preferred form of the work
+for making modifications to it.  “Object code” means any non-source
+form of a work.
+
+A “Standard Interface” means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other
+than the work as a whole, that **(a)** is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and **(b)** serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+“Major Component”, in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+The Corresponding Source for a work in source code form is that
+same work.
+
+### 2. Basic Permissions
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+### 3. Protecting Users' Legal Rights From Anti-Circumvention Law
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+### 4. Conveying Verbatim Copies
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+### 5. Conveying Modified Source Versions
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+* **a)** The work must carry prominent notices stating that you modified
+it, and giving a relevant date.
+* **b)** The work must carry prominent notices stating that it is
+released under this License and any conditions added under section 7.
+This requirement modifies the requirement in section 4 to
+“keep intact all notices”.
+* **c)** You must license the entire work, as a whole, under this
+License to anyone who comes into possession of a copy.  This
+License will therefore apply, along with any applicable section 7
+additional terms, to the whole of the work, and all its parts,
+regardless of how they are packaged.  This License gives no
+permission to license the work in any other way, but it does not
+invalidate such permission if you have separately received it.
+* **d)** If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your
+work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+“aggregate” if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+### 6. Conveying Non-Source Forms
+
+You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+* **a)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium
+customarily used for software interchange.
+* **b)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a
+written offer, valid for at least three years and valid for as
+long as you offer spare parts or customer support for that product
+model, to give anyone who possesses the object code either **(1)** a
+copy of the Corresponding Source for all the software in the
+product that is covered by this License, on a durable physical
+medium customarily used for software interchange, for a price no
+more than your reasonable cost of physically performing this
+conveying of source, or **(2)** access to copy the
+Corresponding Source from a network server at no charge.
+* **c)** Convey individual copies of the object code with a copy of the
+written offer to provide the Corresponding Source.  This
+alternative is allowed only occasionally and noncommercially, and
+only if you received the object code with such an offer, in accord
+with subsection 6b.
+* **d)** Convey the object code by offering access from a designated
+place (gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to
+copy the object code is a network server, the Corresponding Source
+may be on a different server (operated by you or a third party)
+that supports equivalent copying facilities, provided you maintain
+clear directions next to the object code saying where to find the
+Corresponding Source.  Regardless of what server hosts the
+Corresponding Source, you remain obligated to ensure that it is
+available for as long as needed to satisfy these requirements.
+* **e)** Convey the object code using peer-to-peer transmission, provided
+you inform other peers where the object code and Corresponding
+Source of the work are being offered to the general public at no
+charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A “User Product” is either **(1)** a “consumer product”, which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or **(2)** anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, “normally used” refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+### 7. Additional Terms
+
+“Additional permissions” are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+* **a)** Disclaiming warranty or limiting liability differently from the
+terms of sections 15 and 16 of this License; or
+* **b)** Requiring preservation of specified reasonable legal notices or
+author attributions in that material or in the Appropriate Legal
+Notices displayed by works containing it; or
+* **c)** Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+* **d)** Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+* **e)** Declining to grant rights under trademark law for use of some
+trade names, trademarks, or service marks; or
+* **f)** Requiring indemnification of licensors and authors of that
+material by anyone who conveys the material (or modified versions of
+it) with contractual assumptions of liability to the recipient, for
+any liability that these contractual assumptions directly impose on
+those licensors and authors.
+
+All other non-permissive additional terms are considered “further
+restrictions” within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+### 8. Termination
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated **(a)**
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and **(b)** permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+### 9. Acceptance Not Required for Having Copies
+
+You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+### 10. Automatic Licensing of Downstream Recipients
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+### 11. Patents
+
+A “contributor” is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, “control” includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To “grant” such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either **(1)** cause the Corresponding Source to be so
+available, or **(2)** arrange to deprive yourself of the benefit of the
+patent license for this particular work, or **(3)** arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  “Knowingly relying” means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is “discriminatory” if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license **(a)** in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or **(b)** primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+### 12. No Surrender of Others' Freedom
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+### 13. Remote Network Interaction; Use with the GNU General Public License
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+### 14. Revised Versions of this License
+
+The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License “or any later version” applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+### 15. Disclaimer of Warranty
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+### 16. Limitation of Liability
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+### 17. Interpretation of Sections 15 and 16
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/package.json b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/package.json
new file mode 100644
index 00000000000..1808988f8d0
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/package.json
@@ -0,0 +1,33 @@
+{
+  "name": "@hashintel/brunch-agent-plugin-gherkin",
+  "version": "0.0.0-private",
+  "private": true,
+  "description": "The gherkin target: the tracer plugin, wired end-to-end first as the cheap mechanism proof.",
+  "license": "AGPL-3.0",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "import": "./dist/index.js"
+    }
+  },
+  "scripts": {
+    "build": "vite build",
+    "fix:eslint": "oxlint --fix --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:eslint": "oxlint --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:tsc": "tsgo --noEmit",
+    "test:unit": "vitest run"
+  },
+  "dependencies": {
+    "@hashintel/brunch-agent": "workspace:*",
+    "valibot": "1.4.2"
+  },
+  "devDependencies": {
+    "@types/node": "22.18.13",
+    "@typescript/native-preview": "7.0.0-dev.20260511.1",
+    "oxlint": "1.63.0",
+    "oxlint-tsgolint": "0.22.1",
+    "vite": "8.1.0",
+    "vitest": "4.1.10"
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/src/index.ts b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/src/index.ts
new file mode 100644
index 00000000000..2d517da3ca2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/src/index.ts
@@ -0,0 +1,54 @@
+/**
+ * `@hashintel/brunch-agent-plugin-gherkin` — the gherkin target-domain (spec §13.1).
+ *
+ * The tracer target: cheap enough to wire end-to-end first, and deliberately
+ * trivial, so it must not be the plugin that freezes the contract (spec §13's
+ * two-targets-on-each-axis rule). Its packs, `project`, and `validate` land
+ * with their own slice.
+ *
+ * **This package resolves `@hashintel/brunch-agent` and nothing else** — never the binding,
+ * never Flue. Target policy has no business knowing which substrate it is
+ * running on, and it is storage-blind besides (spec §9.6).
+ */
+
+import * as v from "valibot";
+
+import { definePlugin } from "@hashintel/brunch-agent";
+
+const nonEmptyString = v.pipe(v.string(), v.nonEmpty());
+const evidenceQuote = v.strictObject({ excerpt: nonEmptyString });
+
+const StatementNotedProposal = v.pipe(
+  v.strictObject({
+    evidence: v.pipe(v.array(evidenceQuote), v.minLength(1)),
+    epistemicStatus: v.literal("explicit"),
+    confidence: v.picklist(["firm", "hedged", "speculative"]),
+    content: v.strictObject({
+      value: v.strictObject({
+        type: v.literal("statement-noted"),
+        interior: v.strictObject({ verbatim: nonEmptyString }),
+      }),
+    }),
+  }),
+  v.check(
+    (proposal) =>
+      proposal.evidence.some(
+        (evidence) =>
+          evidence.excerpt === proposal.content.value.interior.verbatim,
+      ),
+    "The verbatim interior must equal one cited user quote.",
+  ),
+);
+
+export const gherkin = definePlugin({
+  name: "plugin-gherkin",
+  targetDomain: "gherkin",
+  proposalCatalog: [
+    {
+      name: "statement-noted",
+      description:
+        "Record one condition-shaped statement at the verbatim grade floor, with no parsed structure.",
+      schema: StatementNotedProposal,
+    },
+  ],
+});
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/test/statement-noted.test.ts b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/test/statement-noted.test.ts
new file mode 100644
index 00000000000..04a01a4748c
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/test/statement-noted.test.ts
@@ -0,0 +1,81 @@
+import * as v from "valibot";
+import { describe, expect, test } from "vitest";
+
+import { createSweepExtractionResultSchema } from "@hashintel/brunch-agent";
+
+import { gherkin } from "../src/index";
+
+const quote = "Payment is authorized before fulfillment.";
+const statementNoted = {
+  evidence: [{ excerpt: quote }],
+  epistemicStatus: "explicit" as const,
+  confidence: "firm" as const,
+  content: {
+    value: {
+      type: "statement-noted" as const,
+      interior: { verbatim: quote },
+    },
+  },
+};
+
+describe("the Gherkin verbatim-grade proposal floor", () => {
+  test("declares exactly one statement proposal and compiles it into sweep extraction", () => {
+    expect(gherkin.proposalCatalog.map((proposal) => proposal.name)).toEqual([
+      "statement-noted",
+    ]);
+    expect(
+      v.parse(createSweepExtractionResultSchema(gherkin), {
+        proposals: [statementNoted],
+      }),
+    ).toEqual({ proposals: [statementNoted] });
+  });
+
+  test("refuses silent hardening and structure above the verbatim grade", () => {
+    const schema = createSweepExtractionResultSchema(gherkin);
+    expect(() =>
+      v.parse(schema, {
+        proposals: [
+          {
+            ...statementNoted,
+            content: {
+              value: {
+                type: "statement-noted",
+                interior: { verbatim: "authorization precedes fulfillment" },
+              },
+            },
+          },
+        ],
+      }),
+    ).toThrow(/verbatim/i);
+    expect(() =>
+      v.parse(schema, {
+        proposals: [
+          {
+            ...statementNoted,
+            content: {
+              value: {
+                type: "statement-noted",
+                interior: { verbatim: quote, parsed: { operator: "before" } },
+              },
+            },
+          },
+        ],
+      }),
+    ).toThrow();
+    expect(() =>
+      v.parse(schema, {
+        proposals: [
+          {
+            ...statementNoted,
+            evidence: [
+              {
+                excerpt: quote,
+                pointer: { sessionId: "invented", entryStart: 1, entryEnd: 1 },
+              },
+            ],
+          },
+        ],
+      }),
+    ).toThrow();
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/tsconfig.json b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/tsconfig.json
new file mode 100644
index 00000000000..844edbd8e66
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/tsconfig.json
@@ -0,0 +1,19 @@
+{
+  "compilerOptions": {
+    "target": "es2024",
+    "lib": ["ESNext"],
+    "types": ["node"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedIndexedAccess": true,
+    "resolveJsonModule": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "isolatedModules": true
+  },
+  "include": ["src", "test"]
+}
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/turbo.json b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/turbo.json
new file mode 100644
index 00000000000..6d9a1d1f9e5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/turbo.json
@@ -0,0 +1,10 @@
+{
+  "extends": ["//"],
+  "tasks": {
+    "build": {
+      "dependsOn": ["^build"],
+      "outputs": ["dist/**"],
+      "cache": false
+    }
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/plugin-gherkin/vite.config.ts b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/vite.config.ts
new file mode 100644
index 00000000000..62daeca5b55
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/plugin-gherkin/vite.config.ts
@@ -0,0 +1,23 @@
+import { fileURLToPath } from "node:url";
+
+import { defineConfig } from "vitest/config";
+
+const packageRoot = fileURLToPath(new URL(".", import.meta.url));
+
+export default defineConfig({
+  build: {
+    lib: {
+      entry: fileURLToPath(new URL("src/index.ts", import.meta.url)),
+      fileName: "index",
+      formats: ["es"],
+    },
+    rolldownOptions: {
+      external: [/^@hashintel\/brunch-agent(?:\/.*)?$/u, "valibot"],
+    },
+    sourcemap: true,
+  },
+  root: packageRoot,
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/LICENSE.md b/libs/@hashintel/brunch-agent/packages/transport-aisdk/LICENSE.md
new file mode 100644
index 00000000000..c7d627721e2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/LICENSE.md
@@ -0,0 +1,607 @@
+GNU Affero General Public License
+=================================
+
+_Version 3, 19 November 2007_
+_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
+
+## Preamble
+
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
+
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.
+
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+Developers that use our General Public Licenses protect your rights
+with two steps: **(1)** assert copyright on the software, and **(2)** offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
+
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
+
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
+
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing under
+this license.
+
+The precise terms and conditions for copying, distribution and
+modification follow.
+
+## TERMS AND CONDITIONS
+
+### 0. Definitions
+
+“This License” refers to version 3 of the GNU Affero General Public License.
+
+“Copyright” also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+“The Program” refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as “you”.  “Licensees” and
+“recipients” may be individuals or organizations.
+
+To “modify” a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a “modified version” of the
+earlier work or a work “based on” the earlier work.
+
+A “covered work” means either the unmodified Program or a work based
+on the Program.
+
+To “propagate” a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To “convey” a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+An interactive user interface displays “Appropriate Legal Notices”
+to the extent that it includes a convenient and prominently visible
+feature that **(1)** displays an appropriate copyright notice, and **(2)**
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+### 1. Source Code
+
+The “source code” for a work means the preferred form of the work
+for making modifications to it.  “Object code” means any non-source
+form of a work.
+
+A “Standard Interface” means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+The “System Libraries” of an executable work include anything, other
+than the work as a whole, that **(a)** is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and **(b)** serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+“Major Component”, in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The “Corresponding Source” for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+The Corresponding Source for a work in source code form is that
+same work.
+
+### 2. Basic Permissions
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+### 3. Protecting Users' Legal Rights From Anti-Circumvention Law
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+### 4. Conveying Verbatim Copies
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+### 5. Conveying Modified Source Versions
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+* **a)** The work must carry prominent notices stating that you modified
+it, and giving a relevant date.
+* **b)** The work must carry prominent notices stating that it is
+released under this License and any conditions added under section 7.
+This requirement modifies the requirement in section 4 to
+“keep intact all notices”.
+* **c)** You must license the entire work, as a whole, under this
+License to anyone who comes into possession of a copy.  This
+License will therefore apply, along with any applicable section 7
+additional terms, to the whole of the work, and all its parts,
+regardless of how they are packaged.  This License gives no
+permission to license the work in any other way, but it does not
+invalidate such permission if you have separately received it.
+* **d)** If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your
+work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+“aggregate” if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+### 6. Conveying Non-Source Forms
+
+You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+* **a)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium
+customarily used for software interchange.
+* **b)** Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a
+written offer, valid for at least three years and valid for as
+long as you offer spare parts or customer support for that product
+model, to give anyone who possesses the object code either **(1)** a
+copy of the Corresponding Source for all the software in the
+product that is covered by this License, on a durable physical
+medium customarily used for software interchange, for a price no
+more than your reasonable cost of physically performing this
+conveying of source, or **(2)** access to copy the
+Corresponding Source from a network server at no charge.
+* **c)** Convey individual copies of the object code with a copy of the
+written offer to provide the Corresponding Source.  This
+alternative is allowed only occasionally and noncommercially, and
+only if you received the object code with such an offer, in accord
+with subsection 6b.
+* **d)** Convey the object code by offering access from a designated
+place (gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to
+copy the object code is a network server, the Corresponding Source
+may be on a different server (operated by you or a third party)
+that supports equivalent copying facilities, provided you maintain
+clear directions next to the object code saying where to find the
+Corresponding Source.  Regardless of what server hosts the
+Corresponding Source, you remain obligated to ensure that it is
+available for as long as needed to satisfy these requirements.
+* **e)** Convey the object code using peer-to-peer transmission, provided
+you inform other peers where the object code and Corresponding
+Source of the work are being offered to the general public at no
+charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A “User Product” is either **(1)** a “consumer product”, which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or **(2)** anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, “normally used” refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+“Installation Information” for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+### 7. Additional Terms
+
+“Additional permissions” are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+* **a)** Disclaiming warranty or limiting liability differently from the
+terms of sections 15 and 16 of this License; or
+* **b)** Requiring preservation of specified reasonable legal notices or
+author attributions in that material or in the Appropriate Legal
+Notices displayed by works containing it; or
+* **c)** Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+* **d)** Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+* **e)** Declining to grant rights under trademark law for use of some
+trade names, trademarks, or service marks; or
+* **f)** Requiring indemnification of licensors and authors of that
+material by anyone who conveys the material (or modified versions of
+it) with contractual assumptions of liability to the recipient, for
+any liability that these contractual assumptions directly impose on
+those licensors and authors.
+
+All other non-permissive additional terms are considered “further
+restrictions” within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+### 8. Termination
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated **(a)**
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and **(b)** permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+### 9. Acceptance Not Required for Having Copies
+
+You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+### 10. Automatic Licensing of Downstream Recipients
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An “entity transaction” is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+### 11. Patents
+
+A “contributor” is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's “contributor version”.
+
+A contributor's “essential patent claims” are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, “control” includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a “patent license” is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To “grant” such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either **(1)** cause the Corresponding Source to be so
+available, or **(2)** arrange to deprive yourself of the benefit of the
+patent license for this particular work, or **(3)** arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  “Knowingly relying” means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is “discriminatory” if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license **(a)** in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or **(b)** primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+### 12. No Surrender of Others' Freedom
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+### 13. Remote Network Interaction; Use with the GNU General Public License
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your version
+supports such interaction) an opportunity to receive the Corresponding
+Source of your version by providing access to the Corresponding Source
+from a network server at no charge, through some standard or customary
+means of facilitating copying of software.  This Corresponding Source
+shall include the Corresponding Source for any work covered by version 3
+of the GNU General Public License that is incorporated pursuant to the
+following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+### 14. Revised Versions of this License
+
+The Free Software Foundation may publish revised and/or new versions of
+the GNU Affero General Public License from time to time.  Such new versions
+will be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU Affero General
+Public License “or any later version” applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future
+versions of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+### 15. Disclaimer of Warranty
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+### 16. Limitation of Liability
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+### 17. Interpretation of Sections 15 and 16
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/package.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/package.json
new file mode 100644
index 00000000000..6095c8f6a15
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/package.json
@@ -0,0 +1,38 @@
+{
+  "name": "@hashintel/brunch-agent-transport-aisdk",
+  "version": "0.0.0-private",
+  "private": true,
+  "description": "AI SDK UI-message-stream transport for harness reply parts.",
+  "license": "AGPL-3.0",
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./src/index.ts",
+      "import": "./dist/index.js"
+    },
+    "./client-tools": {
+      "types": "./src/client-tools.ts",
+      "import": "./dist/client-tools.js"
+    }
+  },
+  "scripts": {
+    "build": "vite build",
+    "fix:eslint": "oxlint --fix --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:eslint": "oxlint --type-aware --report-unused-disable-directives-severity=error .",
+    "lint:tsc": "tsgo --noEmit",
+    "test:unit": "vitest run"
+  },
+  "dependencies": {
+    "@hashintel/brunch-agent": "workspace:*",
+    "ai": "6.0.182",
+    "valibot": "1.4.2"
+  },
+  "devDependencies": {
+    "@types/node": "22.18.13",
+    "@typescript/native-preview": "7.0.0-dev.20260511.1",
+    "oxlint": "1.63.0",
+    "oxlint-tsgolint": "0.22.1",
+    "vite": "8.1.0",
+    "vitest": "4.1.10"
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/client-tools.ts b/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/client-tools.ts
new file mode 100644
index 00000000000..d2de4a7c9d8
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/client-tools.ts
@@ -0,0 +1,22 @@
+/**
+ * Browser-safe wire contract for the Brunch tools a host UI executes.
+ */
+
+import * as v from "valibot";
+
+import {
+  AskInput,
+  AskSubmission,
+  toolName,
+} from "@hashintel/brunch-agent/client-tools";
+
+export const ASK_TOOL_NAME = toolName("ask");
+
+export type BrunchAskInput = v.InferOutput<typeof AskInput>;
+export type BrunchAskOutput = v.InferOutput<typeof AskSubmission>;
+
+export const parseBrunchAskInput = (input: unknown): BrunchAskInput =>
+  v.parse(AskInput, input);
+
+export const parseBrunchAskOutput = (output: unknown): BrunchAskOutput =>
+  v.parse(AskSubmission, output);
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/index.ts b/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/index.ts
new file mode 100644
index 00000000000..503793f2bea
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/src/index.ts
@@ -0,0 +1,652 @@
+/**
+ * AI SDK transport for the harness reply protocol.
+ *
+ * This package owns only the UI-message-stream wire. An application supplies a
+ * substrate-backed `runTurn`; the transport never imports a binding or Flue.
+ */
+
+import {
+  createUIMessageStream,
+  createUIMessageStreamResponse,
+  type UIMessageChunk,
+} from "ai";
+import * as v from "valibot";
+
+import {
+  AskSubmission,
+  type AskReplyAdmission,
+  type HarnessReplyEvent,
+} from "@hashintel/brunch-agent";
+
+import { ASK_TOOL_NAME } from "./client-tools";
+
+export {
+  type AskReplyAdmission,
+  type HarnessReplyEvent,
+} from "@hashintel/brunch-agent";
+export {
+  ASK_TOOL_NAME,
+  type BrunchAskInput,
+  type BrunchAskOutput,
+  parseBrunchAskInput,
+  parseBrunchAskOutput,
+} from "./client-tools";
+
+export interface HarnessTurnInput {
+  readonly conversationId: string;
+  readonly idempotencyKey: string;
+  readonly userMessage: {
+    readonly id: string;
+    readonly text: string;
+  };
+}
+
+export type HarnessTurnRunner = (
+  input: HarnessTurnInput,
+  emit: (event: HarnessReplyEvent) => void,
+) => Promise<void>;
+
+export interface HarnessAskReplyInput {
+  readonly conversationId: string;
+  /** Existing assistant UI message whose pending tool call this continues. */
+  readonly assistantMessageId: string;
+  readonly idempotencyKey: string;
+  readonly ask: {
+    readonly toolCallId: string;
+    readonly answer: string;
+  };
+}
+
+/**
+ * The application's ask-return seam. `admit` consults durable pending-ask
+ * state before anything is dispatched; `run` projects the admitted answer
+ * into the harness's user-affordance reply path and streams the resumed turn.
+ */
+export interface AskReplyHandler {
+  admit(input: HarnessAskReplyInput): Promise<AskReplyAdmission>;
+  run(
+    input: HarnessAskReplyInput,
+    emit: (event: HarnessReplyEvent) => void,
+  ): Promise<void>;
+}
+
+export type TransportInspectionEvent =
+  | {
+      readonly type: "request-start";
+      readonly requestId: string;
+      readonly conversationId: string;
+      readonly userMessageId: string;
+    }
+  | {
+      readonly type: "response-start";
+      readonly requestId: string;
+      readonly messageId: string;
+    }
+  | {
+      readonly type: "turn-start";
+      readonly requestId: string;
+      readonly turnId: string;
+      readonly messageId: string;
+    }
+  | {
+      readonly type: "part-emitted";
+      readonly requestId: string;
+      readonly kind:
+        | "text"
+        | "reasoning"
+        | "tool-input"
+        | "tool-output"
+        | "tool-output-error";
+      readonly partId?: string;
+      readonly toolCallId?: string;
+    }
+  | {
+      readonly type: "turn-finish";
+      readonly requestId: string;
+      readonly turnId: string;
+    }
+  | {
+      readonly type: "request-finish";
+      readonly requestId: string;
+      readonly terminalState: "completed" | "failed" | "aborted";
+      readonly finishReason: "stop" | "tool-calls" | "error";
+    }
+  | {
+      readonly type: "ask-await";
+      readonly requestId: string;
+      readonly toolCallId: string;
+    }
+  | {
+      readonly type: "ask-reply-admitted";
+      readonly requestId: string;
+      readonly conversationId: string;
+      readonly toolCallId: string;
+    }
+  | {
+      readonly type: "ask-reply-refused";
+      readonly requestId: string;
+      readonly conversationId: string;
+      readonly toolCallId: string;
+      readonly reason: "no-pending-ask" | "different-ask-pending";
+    };
+
+export interface AiSdkChatHandlerOptions {
+  readonly runTurn: HarnessTurnRunner;
+  /**
+   * Ask-return support. Absent, every tool-result follow-up stays refused
+   * (the FE-1436 negative contract); present, exactly the pending ask's
+   * correlated submission resumes the conversation.
+   */
+  readonly askReply?: AskReplyHandler;
+  /** Exact browser origins allowed to call this endpoint across origins. */
+  readonly allowedOrigins?: readonly string[];
+  /** Opt-in diagnostic sink. Events are metadata only and never re-enter the conversation. */
+  readonly inspect?: (event: TransportInspectionEvent) => void;
+}
+
+const panelPartSchema = v.looseObject({
+  type: v.optional(v.unknown()),
+  text: v.optional(v.unknown()),
+  toolName: v.optional(v.unknown()),
+  toolCallId: v.optional(v.unknown()),
+  state: v.optional(v.unknown()),
+  output: v.optional(v.unknown()),
+});
+
+const panelMessageSchema = v.looseObject({
+  id: v.optional(v.unknown()),
+  role: v.optional(v.unknown()),
+  parts: v.optional(v.array(panelPartSchema)),
+});
+
+const panelPostBodySchema = v.looseObject({
+  id: v.optional(v.unknown()),
+  messageId: v.optional(v.unknown()),
+  messages: v.optional(v.array(panelMessageSchema)),
+  trigger: v.optional(v.unknown()),
+});
+
+type PanelMessage = v.InferOutput<typeof panelMessageSchema>;
+type PanelPostBody = v.InferOutput<typeof panelPostBodySchema>;
+
+type TransportRequestRefusal =
+  | {
+      readonly reason: "invalid-chat-request";
+      readonly status: 400;
+      readonly error: "invalid_chat_request";
+    }
+  | {
+      readonly reason: "tool-result-follow-up-not-supported";
+      readonly status: 422;
+      readonly error: "tool_result_follow_up_not_supported";
+    }
+  | {
+      readonly reason: "invalid-ask-submission";
+      readonly status: 400;
+      readonly error: "invalid_ask_submission";
+    };
+
+const transportRequestRefusals = {
+  invalidChatRequest: {
+    reason: "invalid-chat-request",
+    status: 400,
+    error: "invalid_chat_request",
+  },
+  toolResultFollowUpNotSupported: {
+    reason: "tool-result-follow-up-not-supported",
+    status: 422,
+    error: "tool_result_follow_up_not_supported",
+  },
+  invalidAskSubmission: {
+    reason: "invalid-ask-submission",
+    status: 400,
+    error: "invalid_ask_submission",
+  },
+} as const satisfies Record<string, TransportRequestRefusal>;
+
+const askReplyRefusalErrors = {
+  "no-pending-ask": "ask_not_pending",
+  "different-ask-pending": "ask_mismatch",
+} as const;
+
+const jsonResponse = (
+  body: unknown,
+  status: number,
+  headers?: Headers,
+): Response => Response.json(body, { status, headers });
+
+const corsHeaders = (origin: string): Headers =>
+  new Headers({
+    "access-control-allow-origin": origin,
+    "access-control-allow-methods": "POST, OPTIONS",
+    "access-control-allow-headers": "content-type, x-request-id",
+    vary: "Origin",
+  });
+
+const withHeaders = (response: Response, headers: Headers): Response => {
+  for (const [name, value] of headers) response.headers.set(name, value);
+  return response;
+};
+
+const userTextFrom = (message: PanelMessage): string | undefined => {
+  if (!Array.isArray(message.parts)) return undefined;
+  const text = message.parts
+    .filter(
+      (part): part is { readonly type: "text"; readonly text: string } =>
+        typeof part === "object" &&
+        part !== null &&
+        "type" in part &&
+        part.type === "text" &&
+        "text" in part &&
+        typeof part.text === "string",
+    )
+    .map((part) => part.text)
+    .join("");
+  return text.length > 0 ? text : undefined;
+};
+
+type ParsedTransportRequest =
+  | { readonly kind: "initial"; readonly value: HarnessTurnInput }
+  | { readonly kind: "ask-reply"; readonly value: HarnessAskReplyInput }
+  | { readonly kind: "refused"; readonly refusal: TransportRequestRefusal };
+
+const isAnsweredAskPart = (
+  part: NonNullable<PanelMessage["parts"]>[number],
+): boolean =>
+  ((part.type === "dynamic-tool" && part.toolName === ASK_TOOL_NAME) ||
+    part.type === `tool-${ASK_TOOL_NAME}`) &&
+  part.state === "output-available";
+
+/**
+ * Classify one tool-result follow-up POST. A human answer submitted through
+ * the registered ask component travels tool-output-shaped but is not a
+ * machine tool result: exactly one submitted `brunch_ask` output on the
+ * referenced assistant message is a candidate reply. Everything else —
+ * Petrinaut mutation outputs, the synthetic diagnostics message — remains
+ * the machine-input protocol this transport still refuses (FE-1438 owns it).
+ */
+const parseAskReplyTurn = (body: PanelPostBody): ParsedTransportRequest => {
+  if (
+    typeof body.id !== "string" ||
+    body.id.length === 0 ||
+    typeof body.messageId !== "string" ||
+    body.messageId.length === 0 ||
+    body.trigger !== "submit-message" ||
+    !Array.isArray(body.messages)
+  ) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidChatRequest,
+    };
+  }
+
+  const message = body.messages.find(
+    (candidate) =>
+      candidate.id === body.messageId && candidate.role === "assistant",
+  );
+  const askParts = (message?.parts ?? []).filter(isAnsweredAskPart);
+  if (askParts.length === 0) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.toolResultFollowUpNotSupported,
+    };
+  }
+  const askPart = askParts[0]!;
+  const submission = v.safeParse(AskSubmission, askPart.output);
+  if (
+    askParts.length !== 1 ||
+    typeof askPart.toolCallId !== "string" ||
+    askPart.toolCallId.length === 0 ||
+    !submission.success
+  ) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidAskSubmission,
+    };
+  }
+
+  return {
+    kind: "ask-reply",
+    value: {
+      conversationId: body.id,
+      assistantMessageId: body.messageId,
+      // Keyed by the ask itself: concurrent duplicate submissions of the same
+      // pending ask collapse to one dispatch at the substrate.
+      idempotencyKey: `${body.id}:ask:${askPart.toolCallId}`,
+      ask: { toolCallId: askPart.toolCallId, answer: submission.output.answer },
+    },
+  };
+};
+
+const parseInitialTurn = (body: PanelPostBody): ParsedTransportRequest => {
+  if (
+    typeof body.id !== "string" ||
+    body.id.length === 0 ||
+    body.trigger !== "submit-message"
+  ) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidChatRequest,
+    };
+  }
+  if (!Array.isArray(body.messages)) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidChatRequest,
+    };
+  }
+
+  const message = body.messages.at(-1) as PanelMessage | undefined;
+  if (
+    message?.role !== "user" ||
+    typeof message.id !== "string" ||
+    message.id.length === 0 ||
+    message.id === "petrinaut-diagnostics-context"
+  ) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidChatRequest,
+    };
+  }
+  const text = userTextFrom(message);
+  if (text === undefined) {
+    return {
+      kind: "refused",
+      refusal: transportRequestRefusals.invalidChatRequest,
+    };
+  }
+
+  return {
+    kind: "initial",
+    value: {
+      conversationId: body.id,
+      idempotencyKey: `${body.id}:${message.id}`,
+      userMessage: { id: message.id, text },
+    },
+  };
+};
+
+const toUiChunk = (event: HarnessReplyEvent): UIMessageChunk => {
+  switch (event.type) {
+    case "response-start":
+      return { type: "start", messageId: event.messageId };
+    case "turn-start":
+      return { type: "start-step" };
+    case "part-start":
+      return { type: `${event.kind}-start`, id: event.partId };
+    case "part-delta":
+      return {
+        type: `${event.kind}-delta`,
+        id: event.partId,
+        delta: event.delta,
+      };
+    case "part-end":
+      return { type: `${event.kind}-end`, id: event.partId };
+    case "tool-input":
+      return {
+        type: "tool-input-available",
+        toolCallId: event.toolCallId,
+        toolName: event.toolName,
+        input: event.input,
+        ...(event.execution === "server" ? { providerExecuted: true } : {}),
+      };
+    case "tool-output":
+      return {
+        type: "tool-output-available",
+        toolCallId: event.toolCallId,
+        output: event.output,
+        ...(event.execution === "server" ? { providerExecuted: true } : {}),
+      };
+    case "tool-output-error":
+      return {
+        type: "tool-output-error",
+        toolCallId: event.toolCallId,
+        errorText: event.errorText,
+        ...(event.execution === "server" ? { providerExecuted: true } : {}),
+      };
+    case "turn-finish":
+      return { type: "finish-step" };
+    case "response-finish":
+      switch (event.terminalState) {
+        case "completed":
+          return { type: "finish", finishReason: event.finishReason };
+        case "failed":
+          return { type: "error", errorText: "The elicitor turn failed." };
+        case "aborted":
+          return { type: "abort", reason: "Harness response aborted." };
+      }
+  }
+};
+
+const inspectionFor = (
+  event: HarnessReplyEvent,
+  requestId: string,
+  messageId: string | undefined,
+): TransportInspectionEvent | undefined => {
+  switch (event.type) {
+    case "response-start":
+      return { type: "response-start", requestId, messageId: event.messageId };
+    case "turn-start":
+      return messageId === undefined
+        ? undefined
+        : { type: "turn-start", requestId, turnId: event.turnId, messageId };
+    case "part-start":
+      return {
+        type: "part-emitted",
+        requestId,
+        kind: event.kind,
+        partId: event.partId,
+      };
+    case "tool-input":
+      return {
+        type: "part-emitted",
+        requestId,
+        kind: "tool-input",
+        toolCallId: event.toolCallId,
+      };
+    case "tool-output":
+      return {
+        type: "part-emitted",
+        requestId,
+        kind: "tool-output",
+        toolCallId: event.toolCallId,
+      };
+    case "tool-output-error":
+      return {
+        type: "part-emitted",
+        requestId,
+        kind: "tool-output-error",
+        toolCallId: event.toolCallId,
+      };
+    case "turn-finish":
+      return {
+        type: "turn-finish",
+        requestId,
+        turnId: event.turnId,
+      };
+    case "response-finish":
+      return {
+        type: "request-finish",
+        requestId,
+        terminalState: event.terminalState,
+        finishReason: event.finishReason,
+      };
+    case "part-delta":
+    case "part-end":
+      return undefined;
+  }
+};
+
+export const createAiSdkChatHandler =
+  (options: AiSdkChatHandlerOptions) =>
+  async (request: Request): Promise<Response> => {
+    const origin = request.headers.get("origin");
+    const crossOriginHeaders =
+      origin !== null && options.allowedOrigins?.includes(origin) === true
+        ? corsHeaders(origin)
+        : undefined;
+    if (origin !== null && crossOriginHeaders === undefined) {
+      return jsonResponse({ error: "origin_not_allowed" }, 403);
+    }
+    if (request.method === "OPTIONS") {
+      return new Response(null, { status: 204, headers: crossOriginHeaders });
+    }
+    if (request.method !== "POST") {
+      return jsonResponse(
+        { error: "method_not_allowed" },
+        405,
+        crossOriginHeaders,
+      );
+    }
+
+    let body: unknown;
+    try {
+      body = await request.json();
+    } catch {
+      return jsonResponse(
+        { error: "invalid_chat_request" },
+        400,
+        crossOriginHeaders,
+      );
+    }
+    const validatedBody = v.safeParse(panelPostBodySchema, body);
+    if (!validatedBody.success) {
+      const refusal = transportRequestRefusals.invalidChatRequest;
+      return jsonResponse(
+        { error: refusal.error },
+        refusal.status,
+        crossOriginHeaders,
+      );
+    }
+    const postBody = validatedBody.output;
+    // The follow-up admits exactly the pending ask's correlated human answer;
+    // absent an application ask-reply seam, every follow-up stays refused.
+    const parsed =
+      postBody.messageId !== undefined && options.askReply !== undefined
+        ? parseAskReplyTurn(postBody)
+        : postBody.messageId !== undefined
+          ? ({
+              kind: "refused",
+              refusal: transportRequestRefusals.toolResultFollowUpNotSupported,
+            } as const)
+          : parseInitialTurn(postBody);
+    if (parsed.kind === "refused") {
+      return jsonResponse(
+        { error: parsed.refusal.error },
+        parsed.refusal.status,
+        crossOriginHeaders,
+      );
+    }
+
+    const requestId =
+      request.headers.get("x-request-id") || crypto.randomUUID();
+
+    let run: (emit: (event: HarnessReplyEvent) => void) => Promise<void>;
+    if (parsed.kind === "ask-reply") {
+      const askReply = options.askReply!;
+      const admission = await askReply.admit(parsed.value);
+      if (!admission.ok) {
+        options.inspect?.({
+          type: "ask-reply-refused",
+          requestId,
+          conversationId: parsed.value.conversationId,
+          toolCallId: parsed.value.ask.toolCallId,
+          reason: admission.reason,
+        });
+        return jsonResponse(
+          { error: askReplyRefusalErrors[admission.reason] },
+          409,
+          crossOriginHeaders,
+        );
+      }
+      options.inspect?.({
+        type: "ask-reply-admitted",
+        requestId,
+        conversationId: parsed.value.conversationId,
+        toolCallId: parsed.value.ask.toolCallId,
+      });
+      const input = parsed.value;
+      run = (emit) => askReply.run(input, emit);
+    } else {
+      options.inspect?.({
+        type: "request-start",
+        requestId,
+        conversationId: parsed.value.conversationId,
+        userMessageId: parsed.value.userMessage.id,
+      });
+      const input = parsed.value;
+      run = (emit) => options.runTurn(input, emit);
+    }
+
+    let messageId: string | undefined;
+    const continuationMessageId =
+      parsed.kind === "ask-reply" ? parsed.value.assistantMessageId : undefined;
+    let terminalEventEmitted = false;
+    const awaitingAskToolCallIds = new Set<string>();
+    const stream = createUIMessageStream({
+      execute: async ({ writer }) => {
+        try {
+          await run((event) => {
+            if (event.type === "response-start") messageId = event.messageId;
+            // An ask suspends the turn for a human answer: its call goes to the
+            // panel as an awaiting client tool, and the harness's own output
+            // record (the minted affordance) never reaches the wire — the
+            // registered component supplies the output when the person submits.
+            if (
+              event.type === "tool-input" &&
+              event.toolName === ASK_TOOL_NAME
+            ) {
+              awaitingAskToolCallIds.add(event.toolCallId);
+              writer.write({
+                type: "tool-input-available",
+                toolCallId: event.toolCallId,
+                toolName: event.toolName,
+                input: event.input,
+              });
+              const inspection = inspectionFor(event, requestId, messageId);
+              if (inspection) options.inspect?.(inspection);
+              return;
+            }
+            if (
+              event.type === "tool-output" &&
+              awaitingAskToolCallIds.has(event.toolCallId)
+            ) {
+              options.inspect?.({
+                type: "ask-await",
+                requestId,
+                toolCallId: event.toolCallId,
+              });
+              return;
+            }
+            const wireEvent =
+              event.type === "response-start" &&
+              continuationMessageId !== undefined
+                ? { ...event, messageId: continuationMessageId }
+                : event;
+            writer.write(toUiChunk(wireEvent));
+            if (event.type === "response-finish") terminalEventEmitted = true;
+            const inspection = inspectionFor(event, requestId, messageId);
+            if (inspection) options.inspect?.(inspection);
+          });
+        } catch (error) {
+          // Flue delivers a failed/aborted settlement to the projector and then
+          // rejects read(). Once that terminal event is on the wire, the
+          // rejection carries no new state and must not create a second ending.
+          if (terminalEventEmitted) return;
+          options.inspect?.({
+            type: "request-finish",
+            requestId,
+            terminalState: "failed",
+            finishReason: "error",
+          });
+          throw error;
+        }
+      },
+      onError: () => "The elicitor turn failed.",
+    });
+
+    const response = createUIMessageStreamResponse({ stream });
+    return crossOriginHeaders === undefined
+      ? response
+      : withHeaders(response, crossOriginHeaders);
+  };
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/ask-reply.test.ts b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/ask-reply.test.ts
new file mode 100644
index 00000000000..a12578e635e
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/ask-reply.test.ts
@@ -0,0 +1,362 @@
+/**
+ * FE-1449 wire contracts: the ask suspension leaves the server as an awaiting
+ * client tool, and the return POST resumes the conversation only when it
+ * carries the pending ask's correlated human submission.
+ */
+
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, test } from "vitest";
+
+import { toolName } from "@hashintel/brunch-agent";
+
+import {
+  ASK_TOOL_NAME,
+  createAiSdkChatHandler,
+  type AskReplyHandler,
+  type HarnessAskReplyInput,
+  type HarnessReplyEvent,
+  type TransportInspectionEvent,
+} from "../src/index";
+
+type StreamChunk = Record<string, unknown> & { readonly type: string };
+
+const FIXTURES = join(import.meta.dirname, "fixtures");
+
+test("keeps the client ask tool name aligned with the Brunch product name", () => {
+  expect(ASK_TOOL_NAME).toBe(toolName("ask"));
+});
+
+const responseChunks = async (
+  response: Response,
+): Promise<readonly StreamChunk[]> =>
+  (await response.text())
+    .trim()
+    .split("\n\n")
+    .slice(0, -1)
+    .map((frame) => JSON.parse(frame.slice("data: ".length)) as StreamChunk);
+
+const post = (body: unknown): Request =>
+  new Request("http://brunch.test/api/petrinaut/chat", {
+    method: "POST",
+    headers: {
+      "content-type": "application/json",
+      "x-request-id": "request-fe1449",
+    },
+    body: typeof body === "string" ? body : JSON.stringify(body),
+  });
+
+/** The suspended ask turn as the harness emits it: call, minted affordance, settle. */
+const askSuspensionEvents: readonly HarnessReplyEvent[] = [
+  { type: "response-start", messageId: "assistant-fe1449-1" },
+  { type: "turn-start", turnId: "turn-fe1449-1" },
+  {
+    type: "tool-input",
+    toolCallId: "tool-ask-fe1449",
+    toolName: "brunch_ask",
+    input: { question: "What outcome should this process reliably produce?" },
+    execution: "server",
+  },
+  {
+    type: "tool-output",
+    toolCallId: "tool-ask-fe1449",
+    output: {
+      id: "affordance_tool-ask-fe1449",
+      form: "free-text",
+      markdown: "What outcome should this process reliably produce?",
+      payload: {
+        question: "What outcome should this process reliably produce?",
+      },
+    },
+    execution: "server",
+  },
+  { type: "turn-finish", turnId: "turn-fe1449-1" },
+  { type: "response-finish", terminalState: "completed", finishReason: "stop" },
+];
+
+const askReturnPost = {
+  id: "conversation-fe1449",
+  trigger: "submit-message",
+  messageId: "assistant-fe1449-1",
+  messages: [
+    {
+      id: "user-fe1449-1",
+      role: "user",
+      parts: [{ type: "text", text: "Help me model checkout." }],
+    },
+    {
+      id: "assistant-fe1449-1",
+      role: "assistant",
+      parts: [
+        { type: "step-start" },
+        {
+          type: "tool-brunch_ask",
+          toolCallId: "tool-ask-fe1449",
+          state: "output-available",
+          input: {
+            question: "What outcome should this process reliably produce?",
+          },
+          output: { answer: "A confirmed order with payment settled." },
+        },
+      ],
+    },
+    {
+      id: "petrinaut-diagnostics-context",
+      role: "user",
+      parts: [
+        {
+          type: "text",
+          text: "Petrinaut diagnostics context only; this is not a user request.",
+        },
+      ],
+    },
+  ],
+};
+
+const admitAll: AskReplyHandler["admit"] = async () => ({ ok: true });
+
+const resumedTurn: AskReplyHandler["run"] = async (_input, emit) => {
+  emit({ type: "response-start", messageId: "assistant-fe1449-2" });
+  emit({ type: "turn-start", turnId: "turn-fe1449-2" });
+  emit({ type: "part-start", kind: "text", partId: "text-fe1449-2" });
+  emit({
+    type: "part-delta",
+    kind: "text",
+    partId: "text-fe1449-2",
+    delta: "Payment settled — who initiates the checkout?",
+  });
+  emit({ type: "part-end", kind: "text", partId: "text-fe1449-2" });
+  emit({ type: "turn-finish", turnId: "turn-fe1449-2" });
+  emit({
+    type: "response-finish",
+    terminalState: "completed",
+    finishReason: "stop",
+  });
+};
+
+describe("FE-1449 ask suspension on the wire", () => {
+  test("translates the ask as an awaiting client tool and withholds the affordance output", async () => {
+    const inspections: TransportInspectionEvent[] = [];
+    const handler = createAiSdkChatHandler({
+      inspect: (event) => inspections.push(event),
+      async runTurn(_input, emit) {
+        for (const event of askSuspensionEvents) emit(event);
+      },
+    });
+
+    const response = await handler(
+      post({
+        id: "conversation-fe1449",
+        trigger: "submit-message",
+        messages: [
+          {
+            id: "user-fe1449-1",
+            role: "user",
+            parts: [{ type: "text", text: "Help me model checkout." }],
+          },
+        ],
+      }),
+    );
+
+    expect(response.status).toBe(200);
+    const chunks = await responseChunks(response);
+    expect(
+      chunks.find((chunk) => chunk.type === "tool-input-available"),
+    ).toEqual({
+      type: "tool-input-available",
+      toolCallId: "tool-ask-fe1449",
+      toolName: "brunch_ask",
+      input: { question: "What outcome should this process reliably produce?" },
+    });
+    expect(chunks.some((chunk) => chunk.type === "tool-output-available")).toBe(
+      false,
+    );
+    expect(chunks.at(-1)).toMatchObject({
+      type: "finish",
+      finishReason: "stop",
+    });
+    expect(inspections).toContainEqual({
+      type: "ask-await",
+      requestId: "request-fe1449",
+      toolCallId: "tool-ask-fe1449",
+    });
+  });
+});
+
+describe("FE-1449 ask return POST", () => {
+  test("resumes the conversation with the correlated submission only", async () => {
+    const admitted: HarnessAskReplyInput[] = [];
+    const inspections: TransportInspectionEvent[] = [];
+    const handler = createAiSdkChatHandler({
+      inspect: (event) => inspections.push(event),
+      async runTurn() {
+        throw new Error("the initial-turn path must not run for a follow-up");
+      },
+      askReply: {
+        async admit(input) {
+          admitted.push(input);
+          return { ok: true };
+        },
+        run: resumedTurn,
+      },
+    });
+
+    const response = await handler(post(askReturnPost));
+
+    expect(response.status).toBe(200);
+    expect(admitted).toEqual([
+      {
+        conversationId: "conversation-fe1449",
+        assistantMessageId: "assistant-fe1449-1",
+        idempotencyKey: "conversation-fe1449:ask:tool-ask-fe1449",
+        ask: {
+          toolCallId: "tool-ask-fe1449",
+          answer: "A confirmed order with payment settled.",
+        },
+      },
+    ]);
+    const chunks = await responseChunks(response);
+    expect(chunks[0]).toEqual({
+      type: "start",
+      messageId: "assistant-fe1449-1",
+    });
+    expect(chunks.find((chunk) => chunk.type === "text-delta")).toMatchObject({
+      delta: "Payment settled — who initiates the checkout?",
+    });
+    expect(chunks.at(-1)).toMatchObject({
+      type: "finish",
+      finishReason: "stop",
+    });
+    expect(inspections[0]).toEqual({
+      type: "ask-reply-admitted",
+      requestId: "request-fe1449",
+      conversationId: "conversation-fe1449",
+      toolCallId: "tool-ask-fe1449",
+    });
+    expect(inspections.at(-1)).toMatchObject({
+      type: "request-finish",
+      terminalState: "completed",
+    });
+  });
+
+  test("refuses stale, duplicate, and forged submissions before any dispatch", async () => {
+    for (const [reason, error] of [
+      ["no-pending-ask", "ask_not_pending"],
+      ["different-ask-pending", "ask_mismatch"],
+    ] as const) {
+      let resumed = false;
+      const inspections: TransportInspectionEvent[] = [];
+      const handler = createAiSdkChatHandler({
+        inspect: (event) => inspections.push(event),
+        async runTurn() {},
+        askReply: {
+          async admit() {
+            return { ok: false, reason };
+          },
+          async run() {
+            resumed = true;
+          },
+        },
+      });
+
+      const response = await handler(post(askReturnPost));
+
+      expect({
+        reason,
+        status: response.status,
+        body: await response.json(),
+      }).toEqual({
+        reason,
+        status: 409,
+        body: { error },
+      });
+      expect(resumed).toBe(false);
+      expect(inspections).toEqual([
+        {
+          type: "ask-reply-refused",
+          requestId: "request-fe1449",
+          conversationId: "conversation-fe1449",
+          toolCallId: "tool-ask-fe1449",
+          reason,
+        },
+      ]);
+    }
+  });
+
+  test("keeps refusing machine-only follow-ups: mutation outputs and diagnostics stay non-user", async () => {
+    let resumed = false;
+    const handler = createAiSdkChatHandler({
+      async runTurn() {},
+      askReply: {
+        admit: admitAll,
+        async run() {
+          resumed = true;
+        },
+      },
+    });
+
+    const response = await handler(
+      post(
+        readFileSync(join(FIXTURES, "panel-tool-results.post.json"), "utf8"),
+      ),
+    );
+
+    expect(response.status).toBe(422);
+    expect(await response.json()).toEqual({
+      error: "tool_result_follow_up_not_supported",
+    });
+    expect(resumed).toBe(false);
+  });
+
+  test("refuses a malformed or ambiguous ask submission as invalid", async () => {
+    const askPart = askReturnPost.messages[1]!.parts[1]!;
+    const withParts = (parts: readonly unknown[]): unknown => ({
+      ...askReturnPost,
+      messages: [
+        askReturnPost.messages[0],
+        {
+          ...askReturnPost.messages[1],
+          parts: [{ type: "step-start" }, ...parts],
+        },
+      ],
+    });
+
+    for (const body of [
+      withParts([{ ...askPart, output: { answer: "" } }]),
+      withParts([{ ...askPart, output: "not-an-object" }]),
+      withParts([{ ...askPart, toolCallId: "" }]),
+      withParts([askPart, { ...askPart, toolCallId: "tool-ask-second" }]),
+    ]) {
+      let resumed = false;
+      const handler = createAiSdkChatHandler({
+        async runTurn() {},
+        askReply: {
+          admit: admitAll,
+          async run() {
+            resumed = true;
+          },
+        },
+      });
+
+      const response = await handler(post(body));
+
+      expect(response.status).toBe(400);
+      expect(await response.json()).toEqual({
+        error: "invalid_ask_submission",
+      });
+      expect(resumed).toBe(false);
+    }
+  });
+
+  test("refuses every follow-up when no ask-reply seam is configured", async () => {
+    const handler = createAiSdkChatHandler({ async runTurn() {} });
+
+    const response = await handler(post(askReturnPost));
+
+    expect(response.status).toBe(422);
+    expect(await response.json()).toEqual({
+      error: "tool_result_follow_up_not_supported",
+    });
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/elicitor-initial.normalized.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/elicitor-initial.normalized.json
new file mode 100644
index 00000000000..5554c02fdd5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/elicitor-initial.normalized.json
@@ -0,0 +1,36 @@
+[
+  { "type": "start", "messageId": "$message" },
+  { "type": "start-step" },
+  { "type": "reasoning-start", "id": "$message:reasoning:1" },
+  {
+    "type": "reasoning-delta",
+    "id": "$message:reasoning:1",
+    "delta": "I should establish the process outcome before proposing structure."
+  },
+  { "type": "reasoning-end", "id": "$message:reasoning:1" },
+  { "type": "text-start", "id": "$message:text:2" },
+  {
+    "type": "text-delta",
+    "id": "$message:text:2",
+    "delta": "What outcome should this process reliably produce?"
+  },
+  { "type": "text-end", "id": "$message:text:2" },
+  { "type": "finish-step" },
+  { "type": "start-step" },
+  { "type": "reasoning-start", "id": "$message:reasoning:3" },
+  {
+    "type": "reasoning-delta",
+    "id": "$message:reasoning:3",
+    "delta": "The settlement check does not add user evidence."
+  },
+  { "type": "reasoning-end", "id": "$message:reasoning:3" },
+  { "type": "text-start", "id": "$message:text:4" },
+  {
+    "type": "text-delta",
+    "id": "$message:text:4",
+    "delta": "We can start with the outcome and then work backward through the process."
+  },
+  { "type": "text-end", "id": "$message:text:4" },
+  { "type": "finish-step" },
+  { "type": "finish", "finishReason": "stop" }
+]
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-follow-up.sse b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-follow-up.sse
new file mode 100644
index 00000000000..e9feebd56b2
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-follow-up.sse
@@ -0,0 +1,15 @@
+data: {"type":"start","messageId":"assistant-fe1435-2"}
+
+data: {"type":"start-step"}
+
+data: {"type":"text-start","id":"text-fe1435-2"}
+
+data: {"type":"text-delta","id":"text-fe1435-2","delta":"The live editor applied both client tools, returned both outputs in one follow-up, and the wrapped transport added diagnostics context."}
+
+data: {"type":"text-end","id":"text-fe1435-2"}
+
+data: {"type":"finish-step"}
+
+data: {"type":"finish","finishReason":"stop"}
+
+data: [DONE]
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.post.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.post.json
new file mode 100644
index 00000000000..b771e13bd0f
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.post.json
@@ -0,0 +1,16 @@
+{
+  "id": "m5z0GU9KJPzhOTlx",
+  "messages": [
+    {
+      "parts": [
+        {
+          "type": "text",
+          "text": "Run the FE-1435 transport probe."
+        }
+      ],
+      "id": "6ddgGkjhSxGjOtiv",
+      "role": "user"
+    }
+  ],
+  "trigger": "submit-message"
+}
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.sse b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.sse
new file mode 100644
index 00000000000..42fe77dae8a
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-initial.sse
@@ -0,0 +1,31 @@
+data: {"type":"start","messageId":"assistant-fe1435-1"}
+
+data: {"type":"start-step"}
+
+data: {"type":"reasoning-start","id":"reasoning-fe1435-1"}
+
+data: {"type":"reasoning-delta","id":"reasoning-fe1435-1","delta":"**Checking the wire seam**\n\nThe harness stream is translating reasoning parts."}
+
+data: {"type":"reasoning-delta","id":"reasoning-fe1435-1","delta":" It will now drive both server and browser tools."}
+
+data: {"type":"reasoning-end","id":"reasoning-fe1435-1"}
+
+data: {"type":"text-start","id":"text-fe1435-1"}
+
+data: {"type":"text-delta","id":"text-fe1435-1","delta":"Harness-streamed text reached Petrinaut before tool execution."}
+
+data: {"type":"text-end","id":"text-fe1435-1"}
+
+data: {"type":"tool-input-available","toolCallId":"tool-server-fe1435","toolName":"serverProbe","input":{"scope":"real-panel"},"providerExecuted":true}
+
+data: {"type":"tool-output-available","toolCallId":"tool-server-fe1435","output":{"ok":true,"source":"fake-harness-loop"},"providerExecuted":true}
+
+data: {"type":"tool-input-available","toolCallId":"tool-place-fe1435","toolName":"addPlace","input":{"id":"place__fe1435_buffer","name":"SpikeBuffer","colorId":null,"dynamicsEnabled":false,"differentialEquationId":null,"showAsInitialState":true,"x":180,"y":140}}
+
+data: {"type":"tool-input-available","toolCallId":"tool-transition-fe1435","toolName":"addTransition","input":{"id":"transition__fe1435_dispatch","name":"Spike dispatch","inputArcs":[],"outputArcs":[],"lambdaType":"predicate","lambdaCode":"export const Lambda = () => true;","transitionKernelCode":"export const TransitionKernel = () => ({});","x":420,"y":140}}
+
+data: {"type":"finish-step"}
+
+data: {"type":"finish","finishReason":"tool-calls"}
+
+data: [DONE]
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-tool-results.post.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-tool-results.post.json
new file mode 100644
index 00000000000..72446d0b4ab
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/fixtures/panel-tool-results.post.json
@@ -0,0 +1,118 @@
+{
+  "id": "m5z0GU9KJPzhOTlx",
+  "messages": [
+    {
+      "parts": [
+        {
+          "type": "text",
+          "text": "Run the FE-1435 transport probe."
+        }
+      ],
+      "id": "6ddgGkjhSxGjOtiv",
+      "role": "user"
+    },
+    {
+      "id": "assistant-fe1435-1",
+      "role": "assistant",
+      "parts": [
+        {
+          "type": "step-start"
+        },
+        {
+          "type": "reasoning",
+          "text": "**Checking the wire seam**\n\nThe harness stream is translating reasoning parts. It will now drive both server and browser tools.",
+          "providerMetadata": {
+            "petrinaut": {
+              "startedAt": 1787132360061,
+              "finishedAt": 1787132360424
+            }
+          },
+          "state": "done"
+        },
+        {
+          "type": "text",
+          "text": "Harness-streamed text reached Petrinaut before tool execution.",
+          "state": "done"
+        },
+        {
+          "type": "tool-serverProbe",
+          "toolCallId": "tool-server-fe1435",
+          "state": "output-available",
+          "input": {
+            "scope": "real-panel"
+          },
+          "output": {
+            "ok": true,
+            "source": "fake-harness-loop"
+          },
+          "providerExecuted": true
+        },
+        {
+          "type": "tool-addPlace",
+          "toolCallId": "tool-place-fe1435",
+          "state": "output-available",
+          "input": {
+            "id": "place__fe1435_buffer",
+            "name": "SpikeBuffer",
+            "colorId": null,
+            "dynamicsEnabled": false,
+            "differentialEquationId": null,
+            "showAsInitialState": true,
+            "x": 180,
+            "y": 140
+          },
+          "output": {
+            "title": "Added place SpikeBuffer",
+            "target": {
+              "kind": "selection",
+              "item": {
+                "type": "place",
+                "id": "place__fe1435_buffer"
+              }
+            },
+            "applied": true
+          }
+        },
+        {
+          "type": "tool-addTransition",
+          "toolCallId": "tool-transition-fe1435",
+          "state": "output-available",
+          "input": {
+            "id": "transition__fe1435_dispatch",
+            "name": "Spike dispatch",
+            "inputArcs": [],
+            "outputArcs": [],
+            "lambdaType": "predicate",
+            "lambdaCode": "export const Lambda = () => true;",
+            "transitionKernelCode": "export const TransitionKernel = () => ({});",
+            "x": 420,
+            "y": 140
+          },
+          "output": {
+            "title": "Added transition Spike dispatch",
+            "target": {
+              "kind": "selection",
+              "item": {
+                "type": "transition",
+                "id": "transition__fe1435_dispatch"
+              }
+            },
+            "applied": true
+          }
+        }
+      ]
+    },
+    {
+      "id": "petrinaut-diagnostics-context",
+      "role": "user",
+      "parts": [
+        {
+          "type": "text",
+          "text": "Petrinaut diagnostics context only; this is not a user request.\nThe following TypeScript diagnostics reflect the current Petrinaut model after client-side tool execution.\nUse them to decide whether more tool calls are needed before replying to the user.\n\nCurrent TypeScript diagnostics (3 issues):\n- Transition: Spike dispatch lambda: error TS2451 at Ln 1, Col 1: Cannot redeclare block-scoped variable 'Lambda'.\n- Transition: Spike dispatch lambda: error TS2451 at Ln 1, Col 1: Cannot redeclare block-scoped variable 'Lambda'.\n- Transition: Spike dispatch lambda: error TS2451 at Ln 1, Col 14: Cannot redeclare block-scoped variable 'Lambda'."
+        }
+      ]
+    }
+  ],
+  "trigger": "submit-message",
+  "messageId": "assistant-fe1435-1"
+}
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/golden.test.ts b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/golden.test.ts
new file mode 100644
index 00000000000..1e1cc5fa867
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/test/golden.test.ts
@@ -0,0 +1,138 @@
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, test } from "vitest";
+
+type MessagePart = {
+  readonly input?: unknown;
+  readonly output?: { readonly applied?: boolean };
+  readonly providerExecuted?: boolean;
+  readonly state?: string;
+  readonly text?: string;
+  readonly toolCallId?: string;
+  readonly toolName?: string;
+  readonly type: string;
+};
+
+type PanelMessage = {
+  readonly id: string;
+  readonly parts: MessagePart[];
+  readonly role: string;
+};
+
+type PanelPostBody = {
+  readonly id: string;
+  readonly messageId?: string;
+  readonly messages: PanelMessage[];
+  readonly trigger: string;
+};
+
+type StreamChunk = MessagePart & {
+  readonly delta?: string;
+  readonly finishReason?: string;
+  readonly messageId?: string;
+};
+
+const FIXTURES = join(import.meta.dirname, "fixtures");
+
+const readPostBody = (name: string): PanelPostBody =>
+  JSON.parse(readFileSync(join(FIXTURES, name), "utf8")) as PanelPostBody;
+
+const readSseChunks = (name: string): StreamChunk[] => {
+  const frames = readFileSync(join(FIXTURES, name), "utf8")
+    .trim()
+    .split("\n\n");
+  expect(frames.at(-1)).toBe("data: [DONE]");
+  return frames.slice(0, -1).map((frame) => {
+    expect(frame.startsWith("data: ")).toBe(true);
+    return JSON.parse(frame.slice("data: ".length)) as StreamChunk;
+  });
+};
+
+describe("FE-1435 real-panel wire transcript", () => {
+  test("validates the load-bearing fields in the complete initial panel POST fixture", () => {
+    const body = readPostBody("panel-initial.post.json");
+    expect(body.trigger).toBe("submit-message");
+    expect(body.messages).toHaveLength(1);
+    expect(body.messages[0]?.role).toBe("user");
+    expect(body.messages[0]?.parts).toEqual([
+      { type: "text", text: "Run the FE-1435 transport probe." },
+    ]);
+  });
+
+  test("validates one batched follow-up with both client outputs and diagnostics decoration", () => {
+    const body = readPostBody("panel-tool-results.post.json");
+    expect(body.messageId).toBe("assistant-fe1435-1");
+    expect(body.messages).toHaveLength(3);
+
+    const assistant = body.messages[1]!;
+    const clientToolOutputs = assistant.parts.filter(
+      (part) =>
+        part.type === "tool-addPlace" || part.type === "tool-addTransition",
+    );
+    expect(clientToolOutputs).toHaveLength(2);
+    expect(clientToolOutputs.map((part) => part.state)).toEqual([
+      "output-available",
+      "output-available",
+    ]);
+    expect(clientToolOutputs.map((part) => part.output?.applied)).toEqual([
+      true,
+      true,
+    ]);
+
+    const serverTool = assistant.parts.find(
+      (part) => part.type === "tool-serverProbe",
+    );
+    expect(serverTool).toMatchObject({
+      providerExecuted: true,
+      state: "output-available",
+      toolCallId: "tool-server-fe1435",
+    });
+
+    const diagnostics = body.messages[2]!;
+    expect(diagnostics.id).toBe("petrinaut-diagnostics-context");
+    expect(
+      diagnostics.parts[0]?.text?.startsWith(
+        "Petrinaut diagnostics context only; this is not a user request.",
+      ),
+    ).toBe(true);
+  });
+
+  test("validates streamed reasoning, text, server tool, and client calls", () => {
+    const chunks = readSseChunks("panel-initial.sse");
+    expect(chunks.some((chunk) => chunk.type === "reasoning-delta")).toBe(true);
+    expect(chunks.some((chunk) => chunk.type === "text-delta")).toBe(true);
+    expect(
+      chunks.some(
+        (chunk) =>
+          chunk.type === "tool-output-available" &&
+          chunk.toolCallId === "tool-server-fe1435" &&
+          chunk.providerExecuted === true,
+      ),
+    ).toBe(true);
+    expect(
+      chunks
+        .filter(
+          (chunk) =>
+            chunk.type === "tool-input-available" &&
+            chunk.providerExecuted !== true,
+        )
+        .map((chunk) => chunk.toolName),
+    ).toEqual(["addPlace", "addTransition"]);
+    expect(chunks.at(-1)).toMatchObject({
+      type: "finish",
+      finishReason: "tool-calls",
+    });
+  });
+
+  test("validates the follow-up stream produced after the panel posts tool outputs", () => {
+    const chunks = readSseChunks("panel-follow-up.sse");
+    expect(chunks.find((chunk) => chunk.type === "text-delta")?.delta).toBe(
+      "The live editor applied both client tools, returned both outputs in one follow-up, and the wrapped transport added diagnostics context.",
+    );
+    expect(chunks.at(-1)).toMatchObject({
+      type: "finish",
+      finishReason: "stop",
+    });
+  });
+});
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/tsconfig.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/tsconfig.json
new file mode 100644
index 00000000000..ab0d55ef6a8
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/tsconfig.json
@@ -0,0 +1,19 @@
+{
+  "compilerOptions": {
+    "target": "es2024",
+    "lib": ["DOM", "ESNext"],
+    "types": ["node"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUncheckedIndexedAccess": true,
+    "resolveJsonModule": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "isolatedModules": true
+  },
+  "include": ["src", "test"]
+}
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/turbo.json b/libs/@hashintel/brunch-agent/packages/transport-aisdk/turbo.json
new file mode 100644
index 00000000000..6d9a1d1f9e5
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/turbo.json
@@ -0,0 +1,10 @@
+{
+  "extends": ["//"],
+  "tasks": {
+    "build": {
+      "dependsOn": ["^build"],
+      "outputs": ["dist/**"],
+      "cache": false
+    }
+  }
+}
diff --git a/libs/@hashintel/brunch-agent/packages/transport-aisdk/vite.config.ts b/libs/@hashintel/brunch-agent/packages/transport-aisdk/vite.config.ts
new file mode 100644
index 00000000000..77a7a9fe479
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/packages/transport-aisdk/vite.config.ts
@@ -0,0 +1,28 @@
+import { fileURLToPath } from "node:url";
+
+import { defineConfig } from "vitest/config";
+
+const packageRoot = fileURLToPath(new URL(".", import.meta.url));
+
+export default defineConfig({
+  build: {
+    lib: {
+      entry: {
+        "client-tools": fileURLToPath(
+          new URL("src/client-tools.ts", import.meta.url),
+        ),
+        index: fileURLToPath(new URL("src/index.ts", import.meta.url)),
+      },
+      fileName: (_format, entryName) => `${entryName}.js`,
+      formats: ["es"],
+    },
+    rolldownOptions: {
+      external: [/^@hashintel\/brunch-agent(?:\/.*)?$/u, "ai", "valibot"],
+    },
+    sourcemap: true,
+  },
+  root: packageRoot,
+  test: {
+    include: ["test/**/*.test.ts"],
+  },
+});
diff --git a/libs/@hashintel/brunch-agent/scripts/linear-project-graph.ts b/libs/@hashintel/brunch-agent/scripts/linear-project-graph.ts
new file mode 100644
index 00000000000..470966adde3
--- /dev/null
+++ b/libs/@hashintel/brunch-agent/scripts/linear-project-graph.ts
@@ -0,0 +1,531 @@
+import { spawnSync } from "node:child_process";
+import { resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+
+export interface ProjectIssue {
+  readonly identifier: string;
+  readonly title: string;
+  readonly stateName: string;
+  readonly parentIdentifier?: string;
+  readonly external: boolean;
+}
+
+export interface HardEdge {
+  readonly from: string;
+  readonly to: string;
+}
+
+export interface ProjectGraph {
+  readonly projectName: string;
+  readonly issues: readonly ProjectIssue[];
+  readonly hardEdges: readonly HardEdge[];
+}
+
+interface LinearState {
+  readonly name: string;
+  readonly type: string;
+}
+
+interface LinearIssueRef {
+  readonly identifier: string;
+  readonly title: string;
+  readonly state: LinearState;
+  readonly project: { readonly name: string } | null;
+}
+
+interface LinearRelation {
+  readonly type: string;
+  readonly issue?: LinearIssueRef;
+  readonly relatedIssue?: LinearIssueRef;
+}
+
+interface LinearIssueRecord extends LinearIssueRef {
+  readonly parent: { readonly identifier: string } | null;
+  readonly relations: {
+    readonly pageInfo: { readonly hasNextPage: boolean };
+    readonly nodes: readonly LinearRelation[];
+  };
+  readonly inverseRelations: {
+    readonly pageInfo: { readonly hasNextPage: boolean };
+    readonly nodes: readonly LinearRelation[];
+  };
+}
+
+interface ProjectIssuePage {
+  readonly projectName: string;
+  readonly issues: readonly LinearIssueRecord[];
+  readonly hasNextPage: boolean;
+  readonly endCursor: string | null;
+}
+
+const PROJECT_QUERY = `
+query ProjectGraph($project: String!, $after: String) {
+  projects(filter: { name: { eq: $project } }, first: 2) {
+    nodes {
+      name
+      issues(first: 25, after: $after) {
+        pageInfo { hasNextPage endCursor }
+        nodes {
+          identifier
+          title
+          state { name type }
+          parent { identifier }
+          project { name }
+          relations(first: 15) {
+            pageInfo { hasNextPage }
+            nodes {
+              type
+              relatedIssue {
+                identifier
+                title
+                state { name type }
+                project { name }
+              }
+            }
+          }
+          inverseRelations(first: 15) {
+            pageInfo { hasNextPage }
+            nodes {
+              type
+              issue {
+                identifier
+                title
+                state { name type }
+                project { name }
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+}`;
+
+const CLOSED_STATE_TYPES = new Set(["completed", "canceled", "duplicate"]);
+
+const compareIdentifiers = (left: string, right: string): number =>
+  left.localeCompare(right, undefined, { numeric: true });
+
+const normalizedTitle = (title: string): string =>
+  title.replaceAll("|", "/").replaceAll(/\s+/g, " ").trim();
+
+const cycleMembers = (
+  issueIds: readonly string[],
+  outgoing: ReadonlyMap<string, readonly string[]>,
+): Set<string> => {
+  const cycleIds = new Set<string>();
+
+  const reachesStart = (
+    start: string,
+    current: string,
+    visited: Set<string>,
+  ): boolean => {
+    for (const next of outgoing.get(current) ?? []) {
+      if (next === start) return true;
+      if (visited.has(next)) continue;
+      visited.add(next);
+      if (reachesStart(start, next, visited)) return true;
+    }
+    return false;
+  };
+
+  for (const issueId of issueIds) {
+    if (reachesStart(issueId, issueId, new Set([issueId])))
+      cycleIds.add(issueId);
+  }
+  return cycleIds;
+};
+
+export function renderProjectGraph(graph: ProjectGraph): string {
+  const issuesById = new Map(
+    graph.issues.map((issue) => [issue.identifier, issue]),
+  );
+  const hardEdges = graph.hardEdges
+    .filter((edge) => issuesById.has(edge.from) && issuesById.has(edge.to))
+    .filter(
+      (edge, index, edges) =>
+        edges.findIndex(
+          (candidate) =>
+            candidate.from === edge.from && candidate.to === edge.to,
+        ) === index,
+    )
+    .sort(
+      (left, right) =>
+        compareIdentifiers(left.from, right.from) ||
+        compareIdentifiers(left.to, right.to),
+    );
+  const incoming = new Map<string, string[]>();
+  const outgoing = new Map<string, string[]>();
+  const indegree = new Map(graph.issues.map((issue) => [issue.identifier, 0]));
+
+  for (const edge of hardEdges) {
+    incoming.set(edge.to, [...(incoming.get(edge.to) ?? []), edge.from]);
+    outgoing.set(edge.from, [...(outgoing.get(edge.from) ?? []), edge.to]);
+    indegree.set(edge.to, (indegree.get(edge.to) ?? 0) + 1);
+  }
+  for (const issueIds of [...incoming.values(), ...outgoing.values()]) {
+    issueIds.sort(compareIdentifiers);
+  }
+
+  const layerById = new Map<string, number>();
+  let frontier = [...indegree]
+    .filter(([, degree]) => degree === 0)
+    .map(([issueId]) => issueId)
+    .sort(compareIdentifiers);
+  let layer = 0;
+
+  while (frontier.length > 0) {
+    const nextFrontier = new Set<string>();
+    for (const issueId of frontier) {
+      layerById.set(issueId, layer);
+      for (const blockedId of outgoing.get(issueId) ?? []) {
+        const remaining = (indegree.get(blockedId) ?? 0) - 1;
+        indegree.set(blockedId, remaining);
+        if (remaining === 0) nextFrontier.add(blockedId);
+      }
+    }
+    frontier = [...nextFrontier].sort(compareIdentifiers);
+    layer += 1;
+  }
+
+  const unlayeredIds = graph.issues
+    .map((issue) => issue.identifier)
+    .filter((issueId) => !layerById.has(issueId));
+  const cycles = [...cycleMembers(unlayeredIds, outgoing)].sort(
+    compareIdentifiers,
+  );
+  const externalCount = graph.issues.filter((issue) => issue.external).length;
+  const projectIssueCount = graph.issues.length - externalCount;
+  const header = [
+    `project ${graph.projectName}`,
+    `open=${projectIssueCount}`,
+    `hard=${hardEdges.length}`,
+    ...(externalCount > 0 ? [`external=${externalCount}`] : []),
+  ].join(" ");
+  const issueLines = [...graph.issues]
+    .sort((left, right) => {
+      const leftLayer =
+        layerById.get(left.identifier) ?? Number.POSITIVE_INFINITY;
+      const rightLayer =
+        layerById.get(right.identifier) ?? Number.POSITIVE_INFINITY;
+      return (
+        leftLayer - rightLayer ||
+        compareIdentifiers(left.identifier, right.identifier)
+      );
+    })
+    .map((issue) => {
+      const issueLayer = layerById.get(issue.identifier);
+      const tags = [
+        issue.stateName,
+        issue.parentIdentifier ? `p:${issue.parentIdentifier}` : "root",
+        ...(issue.external ? ["*"] : []),
+      ].join(" ");
+      const blockers = incoming.get(issue.identifier);
+      const blocks = outgoing.get(issue.identifier);
+      return [
+        `L${issueLayer ?? "?"}`,
+        issue.identifier,
+        `[${tags}]`,
+        ...(blockers?.length ? [`<=${blockers.join(",")}`] : []),
+        ...(blocks?.length ? [`=>${blocks.join(",")}`] : []),
+        "|",
+        normalizedTitle(issue.title),
+      ].join(" ");
+    });
+
+  return [
+    header,
+    "legend: L=hard-dependency layer; p=parent; <=blocked by; =>blocks; *=outside project",
+    ...issueLines,
+    `cycles: ${cycles.length > 0 ? cycles.join(",") : "none"}`,
+  ].join("\n");
+}
+
+const isRecord = (value: unknown): value is Record<string, unknown> =>
+  typeof value === "object" && value !== null;
+
+const isLinearIssueRef = (value: unknown): value is LinearIssueRef =>
+  isRecord(value) &&
+  typeof value.identifier === "string" &&
+  typeof value.title === "string" &&
+  isRecord(value.state) &&
+  typeof value.state.name === "string" &&
+  typeof value.state.type === "string" &&
+  (value.project === null ||
+    (isRecord(value.project) && typeof value.project.name === "string"));
+
+const readProjectIssuePage = (value: unknown): ProjectIssuePage => {
+  if (!isRecord(value))
+    throw new Error("Linear returned a non-object response.");
+  if (Array.isArray(value.errors) && value.errors.length > 0) {
+    const messages = value.errors
+      .map((error) =>
+        isRecord(error) && typeof error.message === "string"
+          ? error.message
+          : null,
+      )
+      .filter((message): message is string => message !== null);
+    throw new Error(
+      `Linear GraphQL refused the project query: ${messages.join("; ")}`,
+    );
+  }
+  const data = value.data;
+  const projects =
+    isRecord(data) && isRecord(data.projects) ? data.projects.nodes : undefined;
+  if (
+    !Array.isArray(projects) ||
+    projects.length !== 1 ||
+    !isRecord(projects[0])
+  ) {
+    throw new Error(
+      `Expected exactly one Linear project, received ${
+        Array.isArray(projects) ? projects.length : 0
+      }.`,
+    );
+  }
+  const project = projects[0];
+  const issuesConnection = project.issues;
+  if (
+    typeof project.name !== "string" ||
+    !isRecord(issuesConnection) ||
+    !Array.isArray(issuesConnection.nodes) ||
+    !isRecord(issuesConnection.pageInfo) ||
+    typeof issuesConnection.pageInfo.hasNextPage !== "boolean"
+  ) {
+    throw new Error("Linear returned an unexpected project issue shape.");
+  }
+  const issues = issuesConnection.nodes as readonly LinearIssueRecord[];
+  for (const issue of issues) {
+    if (
+      !isRecord(issue) ||
+      typeof issue.identifier !== "string" ||
+      typeof issue.title !== "string" ||
+      !isRecord(issue.state) ||
+      typeof issue.state.name !== "string" ||
+      typeof issue.state.type !== "string" ||
+      !isRecord(issue.relations) ||
+      !isRecord(issue.inverseRelations) ||
+      !Array.isArray(issue.relations.nodes) ||
+      !Array.isArray(issue.inverseRelations.nodes) ||
+      !isRecord(issue.relations.pageInfo) ||
+      typeof issue.relations.pageInfo.hasNextPage !== "boolean" ||
+      !isRecord(issue.inverseRelations.pageInfo) ||
+      typeof issue.inverseRelations.pageInfo.hasNextPage !== "boolean" ||
+      (issue.parent !== null &&
+        (!isRecord(issue.parent) ||
+          typeof issue.parent.identifier !== "string"))
+    ) {
+      throw new Error("Linear returned an unexpected issue shape.");
+    }
+    for (const relation of issue.relations.nodes) {
+      if (
+        !isRecord(relation) ||
+        typeof relation.type !== "string" ||
+        (relation.relatedIssue !== null &&
+          !isLinearIssueRef(relation.relatedIssue)) ||
+        (relation.type === "blocks" && !isLinearIssueRef(relation.relatedIssue))
+      ) {
+        throw new Error(
+          `Linear returned an unexpected relation shape for ${issue.identifier}.`,
+        );
+      }
+    }
+    for (const relation of issue.inverseRelations.nodes) {
+      if (
+        !isRecord(relation) ||
+        typeof relation.type !== "string" ||
+        (relation.issue !== null && !isLinearIssueRef(relation.issue)) ||
+        (relation.type === "blocks" && !isLinearIssueRef(relation.issue))
+      ) {
+        throw new Error(
+          `Linear returned an unexpected inverse relation shape for ${issue.identifier}.`,
+        );
+      }
+    }
+    if (
+      issue.relations.pageInfo.hasNextPage ||
+      issue.inverseRelations.pageInfo.hasNextPage
+    ) {
+      throw new Error(
+        `${issue.identifier} has more than 15 relations; increase the relation page size before trusting this projection.`,
+      );
+    }
+  }
+  const endCursor = issuesConnection.pageInfo.endCursor;
+  if (endCursor !== null && typeof endCursor !== "string") {
+    throw new Error("Linear returned an invalid issue cursor.");
+  }
+  return {
+    projectName: project.name,
+    issues,
+    hasNextPage: issuesConnection.pageInfo.hasNextPage,
+    endCursor,
+  };
+};
+
+const queryProjectPage = (
+  projectName: string,
+  after: string | null,
+): ProjectIssuePage => {
+  const result = spawnSync(
+    "linear",
+    [
+      "api",
+      "--variables-json",
+      JSON.stringify({ project: projectName, after }),
+      PROJECT_QUERY,
+    ],
+    { encoding: "utf8" },
+  );
+  if (result.status !== 0) {
+    throw new Error(`linear api failed: ${result.stderr.trim()}`);
+  }
+  let response: unknown;
+  try {
+    response = JSON.parse(result.stdout);
+  } catch {
+    throw new Error("linear api returned invalid JSON.");
+  }
+  return readProjectIssuePage(response);
+};
+
+const asProjectIssue = (
+  issue: LinearIssueRef,
+  projectName: string,
+  parentIdentifier?: string,
+): ProjectIssue => ({
+  identifier: issue.identifier,
+  title: issue.title,
+  stateName: issue.state.name,
+  ...(parentIdentifier ? { parentIdentifier } : {}),
+  external: issue.project?.name !== projectName,
+});
+
+export const fetchProjectGraph = (
+  projectName: string,
+  includeClosed = false,
+): ProjectGraph => {
+  const projectIssues = new Map<string, LinearIssueRecord>();
+  let after: string | null = null;
+  let resolvedProjectName = projectName;
+
+  do {
+    const page = queryProjectPage(projectName, after);
+    resolvedProjectName = page.projectName;
+    for (const issue of page.issues) projectIssues.set(issue.identifier, issue);
+    after = page.hasNextPage ? page.endCursor : null;
+    if (page.hasNextPage && after === null) {
+      throw new Error("Linear reported another issue page without a cursor.");
+    }
+  } while (after !== null);
+
+  const selected = (issue: LinearIssueRef): boolean =>
+    includeClosed || !CLOSED_STATE_TYPES.has(issue.state.type);
+  const issues = new Map<string, ProjectIssue>();
+  const hardEdges = new Map<string, HardEdge>();
+
+  for (const issue of projectIssues.values()) {
+    if (!selected(issue)) continue;
+    issues.set(
+      issue.identifier,
+      asProjectIssue(issue, resolvedProjectName, issue.parent?.identifier),
+    );
+
+    for (const relation of issue.relations.nodes) {
+      const relatedIssue = relation.relatedIssue;
+      if (
+        relation.type !== "blocks" ||
+        !relatedIssue ||
+        !selected(relatedIssue)
+      )
+        continue;
+      issues.set(
+        relatedIssue.identifier,
+        issues.get(relatedIssue.identifier) ??
+          asProjectIssue(relatedIssue, resolvedProjectName),
+      );
+      const edge = { from: issue.identifier, to: relatedIssue.identifier };
+      hardEdges.set(`${edge.from}>${edge.to}`, edge);
+    }
+    for (const relation of issue.inverseRelations.nodes) {
+      const sourceIssue = relation.issue;
+      if (relation.type !== "blocks" || !sourceIssue || !selected(sourceIssue))
+        continue;
+      issues.set(
+        sourceIssue.identifier,
+        issues.get(sourceIssue.identifier) ??
+          asProjectIssue(sourceIssue, resolvedProjectName),
+      );
+      const edge = { from: sourceIssue.identifier, to: issue.identifier };
+      hardEdges.set(`${edge.from}>${edge.to}`, edge);
+    }
+  }
+
+  return {
+    projectName: resolvedProjectName,
+    issues: [...issues.values()],
+    hardEdges: [...hardEdges.values()],
+  };
+};
+
+const usage = `Usage: turbo run linear:graph --filter '@hashintel/brunch-agent' -- [--project <name>] [--all]
+
+Print a compact, read-only hard-dependency projection for agent sequencing.
+Defaults to open issues in the brunch-agent project. The output is factual input;
+it does not infer priority, soft dependencies, or a sequencing recommendation.`;
+
+const parseArguments = (
+  arguments_: readonly string[],
+): {
+  readonly projectName: string;
+  readonly includeClosed: boolean;
+  readonly help: boolean;
+} => {
+  let projectName = "brunch-agent";
+  let includeClosed = false;
+  let help = false;
+
+  for (let index = 0; index < arguments_.length; index += 1) {
+    const argument = arguments_[index];
+    if (argument === "--help" || argument === "-h") {
+      help = true;
+    } else if (argument === "--all") {
+      includeClosed = true;
+    } else if (argument === "--project") {
+      const value = arguments_[index + 1];
+      if (!value) throw new Error("Missing value after --project.");
+      projectName = value;
+      index += 1;
+    } else {
+      throw new Error(`Unknown argument: ${argument ?? ""}`);
+    }
+  }
+  return { projectName, includeClosed, help };
+};
+
+const isMain =
+  process.argv[1] !== undefined &&
+  fileURLToPath(import.meta.url) === resolve(process.argv[1]);
+
+if (isMain) {
+  try {
+    const options = parseArguments(process.argv.slice(2));
+    if (options.help) {
+      console.log(usage);
+    } else {
+      console.log(
+        renderProjectGraph(
+          fetchProjectGraph(options.projectName, options.includeClosed),
+        ),
+      );
+    }
+  } catch (error) {
+    console.error(
+      `linear:graph: ${error instanceof Error ? error.message : String(error)}`,
+    );
+    console.error(
+      "Run `turbo run linear:graph --filter '@hashintel/brunch-agent' -- --help` for usage.",
+    );
+    process.exitCode = 1;
+  }
+}
diff --git a/libs/@hashintel/petrinaut/docs/ai-assistant.md b/libs/@hashintel/petrinaut/docs/ai-assistant.md
index 43b3c0bb190..9c9c4b27ea3 100644
--- a/libs/@hashintel/petrinaut/docs/ai-assistant.md
+++ b/libs/@hashintel/petrinaut/docs/ai-assistant.md
@@ -29,6 +29,7 @@ The assistant has tools for inspecting and modifying the current net. You'll see
 - **Mutation tools** (green for additions/updates, red for deletions) -- "Added place X", "Updated transition Y", "Removed metric Z", and so on. Multiple successive mutations group under a collapsible "N changes" header.
 - **`setNetTitle`** -- renames the net.
 - **`applyAutoLayout`** -- rearranges places and transitions on the canvas. If the assistant calls this on a net you've already arranged, it asks you first via an inline widget with **Yes, auto-layout** / **No, keep current layout** buttons. Otherwise it'll run it without asking.
+- **Host-specific questions and actions** -- an application embedding Petrinaut may add its own interactive widgets. For example, an elicitation assistant can ask a structured question inline and continue after you submit the answer.
 
 Clicking a mutation card usually selects the entity it touched (place, transition, scenario, metric, etc.) so you can inspect what changed.
 
diff --git a/libs/@hashintel/petrinaut/src/ui/index.ts b/libs/@hashintel/petrinaut/src/ui/index.ts
index fa27bb932fe..cce7c19b3dd 100644
--- a/libs/@hashintel/petrinaut/src/ui/index.ts
+++ b/libs/@hashintel/petrinaut/src/ui/index.ts
@@ -10,10 +10,13 @@
  */
 
 export { Petrinaut } from "./petrinaut";
+export { definePetrinautAiInteractiveTool } from "./views/Editor/panels/ai-assistant-panel/interactive-tools/types";
+export type { InteractiveToolWidgetProps } from "./views/Editor/panels/ai-assistant-panel/interactive-tools/types";
 export type { PetrinautAiMessage } from "./views/Editor/panels/ai-assistant-panel";
 export type {
   PetrinautAiAssistant,
   PetrinautAiChatTransport,
+  PetrinautAiInteractiveTool,
   PetrinautProps,
 } from "./petrinaut";
 export { DefaultChatTransport } from "ai";
diff --git a/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx b/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx
index 4679a478cf9..ad2a7cb6c40 100644
--- a/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/petrinaut.tsx
@@ -33,10 +33,13 @@ import type {
   PetrinautAiMessage,
   PetrinautAiTransport,
 } from "./views/Editor/panels/ai-assistant-panel";
+import type { PetrinautAiInteractiveTool } from "./views/Editor/panels/ai-assistant-panel/interactive-tools/types";
 
 export type PetrinautAiChatTransport = PetrinautAiTransport;
+export type { PetrinautAiInteractiveTool };
 
 export type PetrinautAiAssistant = {
+  interactiveTools?: readonly PetrinautAiInteractiveTool[];
   messages?: PetrinautAiMessage[];
   onClearMessages?: () => void;
   onMessages?: (messages: PetrinautAiMessage[]) => void;
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel.tsx b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel.tsx
index 41852097a3b..6b5cddb7b31 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel.tsx
@@ -1,5 +1,8 @@
 import { useChat } from "@ai-sdk/react";
-import { lastAssistantMessageIsCompleteWithToolCalls } from "ai";
+import {
+  type DynamicToolUIPart,
+  lastAssistantMessageIsCompleteWithToolCalls,
+} from "ai";
 import { use, useEffect, useRef, useState } from "react";
 
 import {
@@ -39,7 +42,10 @@ import { createDiagnosticsAwareAiTransport } from "./ai-assistant-panel/create-d
 import { createReasoningTimingAwareAiTransport } from "./ai-assistant-panel/create-reasoning-timing-aware-ai-transport";
 import { finalizeStreamingMessageParts } from "./ai-assistant-panel/finalize-streaming-message-parts";
 import { formatDiagnosticsForAi } from "./ai-assistant-panel/format-diagnostics-for-ai";
-import { getInteractiveTool } from "./ai-assistant-panel/interactive-tools/registry";
+import {
+  getHostInteractiveTool,
+  getInteractiveTool,
+} from "./ai-assistant-panel/interactive-tools/registry";
 import { petrinautDocsContent } from "./ai-assistant-panel/petrinaut-docs-content";
 import {
   type AiToolOutput,
@@ -106,6 +112,22 @@ const safelyAddToolOutput = (
   void Promise.resolve(addToolOutput(params)).catch(() => {});
 };
 
+const safelyAddDynamicToolOutput = (
+  addToolOutput: ReturnType<
+    typeof useChat<PetrinautAiMessage>
+  >["addToolOutput"],
+  params: {
+    tool: DynamicToolUIPart["toolName"];
+    toolCallId: DynamicToolUIPart["toolCallId"];
+    output: Extract<DynamicToolUIPart, { state: "output-available" }>["output"];
+  },
+) => {
+  const addDynamicToolOutput = addToolOutput as (
+    toolOutput: typeof params,
+  ) => void | PromiseLike<void>;
+  void Promise.resolve(addDynamicToolOutput(params)).catch(() => {});
+};
+
 const waitForDiagnosticsRefresh = async ({
   consumePendingMutationDiagnosticsVersion,
   diagnosticsVersionRef,
@@ -361,6 +383,18 @@ export const AiAssistantPanel = ({
         );
       }
 
+      if (
+        getHostInteractiveTool(
+          toolCall.toolName,
+          toolCall.input,
+          aiAssistant.interactiveTools,
+        )
+      ) {
+        // The host renders this tool inline and supplies its output when the
+        // person submits the widget.
+        return;
+      }
+
       if (toolCall.dynamic) {
         throw new Error(`Unknown AI tool: ${toolCall.toolName}`);
       }
@@ -585,6 +619,7 @@ export const AiAssistantPanel = ({
     <AiAssistantContents
       error={streamError ?? error}
       input={input}
+      interactiveTools={aiAssistant.interactiveTools}
       messages={messages}
       onClearMessages={() => {
         // Clearing aborts any in-flight response too, which fires `onFinish`
@@ -604,21 +639,27 @@ export const AiAssistantPanel = ({
       }}
       onClose={() => setAiAssistantOpen(false)}
       onInputChange={setInput}
-      onInteractiveToolSubmit={({ toolCallId, toolName, output }) => {
-        if (!isPetrinautAiCommandToolName(toolName)) {
-          // Defensive — the registry only exposes AI command tools today.
+      onInteractiveToolSubmit={({ kind, submission, toolCallId, toolName }) => {
+        if (kind === "host") {
+          safelyAddDynamicToolOutput(addToolOutput, {
+            tool: toolName,
+            toolCallId,
+            output: submission,
+          });
           return;
         }
 
         // applyAutoLayout is the only interactive command today. The widget
-        // signals "apply" by passing `{ applied: true }`; we still need to
-        // run the command to compute the real commitCount before reporting
-        // the outcome to the AI. Decline outputs are forwarded verbatim.
-        if (output.applied !== true) {
+        // submits a typed decision; an apply decision still needs to run the
+        // command to compute the real commitCount before reporting the result.
+        if (submission.action === "decline") {
           safelyAddToolOutput(addToolOutput, {
             tool: toolName,
             toolCallId,
-            output,
+            output: {
+              applied: false,
+              reason: "User declined auto-layout.",
+            } satisfies AiToolOutput,
           });
           return;
         }
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents.tsx b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents.tsx
index 259b47254eb..aeab98ac6a6 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents.tsx
@@ -24,6 +24,7 @@ import {
   type OnInteractiveToolSubmit,
 } from "./ai-assistant-contents/tool-list";
 
+import type { PetrinautAiInteractiveTool } from "./interactive-tools/types";
 import type { AiToolTarget } from "./tool-summaries";
 import type { PetrinautAiMessage } from "./types";
 
@@ -32,6 +33,7 @@ type AiAssistantStatus = "submitted" | "streaming" | "ready" | "error";
 export type AiAssistantContentsProps = {
   error?: Error;
   input: string;
+  interactiveTools?: readonly PetrinautAiInteractiveTool[];
   messages: PetrinautAiMessage[];
   onClearMessages?: () => void;
   onClose: () => void;
@@ -340,13 +342,15 @@ type MessageHandlersRef = RefObject<{
 const AiAssistantMessage = memo(
   ({
     handlersRef,
+    interactiveTools,
     message,
   }: {
     handlersRef: MessageHandlersRef;
+    interactiveTools?: readonly PetrinautAiInteractiveTool[];
     message: PetrinautAiMessage;
   }) => {
     const role = message.role === "user" ? "user" : "assistant";
-    const renderItems = getMessageRenderItems(message);
+    const renderItems = getMessageRenderItems(message, interactiveTools);
 
     return (
       <div className={messageStyle({ role })} data-role={role}>
@@ -400,6 +404,7 @@ AiAssistantMessage.displayName = "AiAssistantMessage";
 export const AiAssistantContents = ({
   error,
   input,
+  interactiveTools,
   messages,
   onClearMessages,
   onClose,
@@ -557,9 +562,10 @@ export const AiAssistantContents = ({
           )}
           {messages.map((message) => (
             <AiAssistantMessage
+              handlersRef={handlersRef}
+              interactiveTools={interactiveTools}
               key={message.id}
               message={message}
-              handlersRef={handlersRef}
             />
           ))}
           {error && <div className={errorStyle}>{error.message}</div>}
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/get-message-render-items.ts b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/get-message-render-items.ts
index 2c171dee695..17d76709bbd 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/get-message-render-items.ts
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/get-message-render-items.ts
@@ -6,6 +6,7 @@ import {
 
 import { isToolPart, toToolRenderItem, type ToolRenderItem } from "./tool-list";
 
+import type { PetrinautAiInteractiveTool } from "../interactive-tools/types";
 import type { PetrinautAiMessage } from "../types";
 
 export type MessagePart = PetrinautAiMessage["parts"][number];
@@ -27,6 +28,7 @@ export const isPartActive = (
 
 export const getMessageRenderItems = (
   message: PetrinautAiMessage,
+  hostInteractiveTools: readonly PetrinautAiInteractiveTool[] = [],
 ): MessageRenderItem[] => {
   const items: MessageRenderItem[] = [];
   let pendingTools: ToolRenderItem[] = [];
@@ -66,7 +68,7 @@ export const getMessageRenderItems = (
     }
 
     if (isToolPart(part)) {
-      const tool = toToolRenderItem(message, part);
+      const tool = toToolRenderItem(message, part, hostInteractiveTools);
 
       if (
         tool.toolName === getLatestNetDefinitionToolName ||
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/tool-list.tsx b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/tool-list.tsx
index 5f024ad3f7b..6e49754b54d 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/tool-list.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/ai-assistant-contents/tool-list.tsx
@@ -7,20 +7,27 @@ import {
   getNetCompilationErrorsToolName,
   petrinautAiMutationTools,
   readPetrinautDocToolName,
+  type AiCommandActionName,
   type SelectionItem,
   setNetTitleToolName,
 } from "@hashintel/petrinaut-core";
 
 import { getInteractiveTool } from "../interactive-tools/registry";
 import {
-  type AiToolOutput,
   type AiToolTarget,
   type AiToolSummary,
   summarizePetrinautAiToolCall,
 } from "../tool-summaries";
 import { collapsibleContentStyle } from "./shared/collapsible-content-style";
 
-import type { InteractiveToolDefinition } from "../interactive-tools/types";
+import type {
+  ApplyAutoLayoutDecision,
+  ApplyAutoLayoutResult,
+} from "../interactive-tools/apply-auto-layout-widget";
+import type {
+  InteractiveToolDefinition,
+  PetrinautAiInteractiveTool,
+} from "../interactive-tools/types";
 import type { PetrinautAiMessage } from "../types";
 
 export type ToolTone = "danger" | "info" | "neutral" | "success";
@@ -39,11 +46,24 @@ export type ToolRenderItem = {
   /** Server-reported error message for tools whose state is `output-error`. */
   errorText?: string;
   /** Set when the tool requires an inline widget for human input. */
-  interactive?: {
-    definition: InteractiveToolDefinition<unknown, AiToolOutput>;
-    input: unknown;
-    submittedOutput?: AiToolOutput;
-  };
+  interactive?:
+    | {
+        kind: "petrinaut";
+        definition: InteractiveToolDefinition<
+          unknown,
+          ApplyAutoLayoutDecision,
+          ApplyAutoLayoutResult,
+          AiCommandActionName
+        >;
+        input: unknown;
+        submittedOutput?: ApplyAutoLayoutResult;
+      }
+    | {
+        kind: "host";
+        tool: PetrinautAiInteractiveTool;
+        input: unknown;
+        submittedOutput?: unknown;
+      };
 };
 
 export type RenderableToolPart = PetrinautAiMessage["parts"][number] & {
@@ -56,11 +76,32 @@ export type RenderableToolPart = PetrinautAiMessage["parts"][number] & {
   type: `tool-${string}` | "dynamic-tool";
 };
 
-export type OnInteractiveToolSubmit = (params: {
-  toolCallId: string;
-  toolName: string;
-  output: AiToolOutput;
-}) => void;
+export type OnInteractiveToolSubmit = (
+  params:
+    | {
+        kind: "petrinaut";
+        toolCallId: string;
+        toolName: AiCommandActionName;
+        submission: ApplyAutoLayoutDecision;
+      }
+    | {
+        kind: "host";
+        toolCallId: string;
+        toolName: string;
+        submission: unknown;
+      },
+) => void;
+
+const parseSubmittedOutput = <Output,>(
+  parseOutput: (raw: unknown) => Output,
+  raw: unknown,
+): Output | undefined => {
+  try {
+    return parseOutput(raw);
+  } catch {
+    return undefined;
+  }
+};
 
 const toolListStyle = cva({
   base: {
@@ -454,22 +495,41 @@ const getToolTone = ({
 export const toToolRenderItem = (
   message: PetrinautAiMessage,
   part: RenderableToolPart,
+  hostInteractiveTools: readonly PetrinautAiInteractiveTool[] = [],
 ): ToolRenderItem => {
   const state = part.state ?? "input-available";
   const summary = getToolSummaryFromPart(part);
   const toolName = getToolName(part);
 
-  const interactiveDefinition = getInteractiveTool(toolName, part.input);
-  const interactive = interactiveDefinition
-    ? {
-        definition: interactiveDefinition,
-        input: part.input,
-        submittedOutput:
-          state === "output-available" && part.output
-            ? (part.output as AiToolOutput)
-            : undefined,
-      }
-    : undefined;
+  const resolvedInteractiveTool = getInteractiveTool(
+    toolName,
+    part.input,
+    hostInteractiveTools,
+  );
+  const submittedOutput =
+    state === "output-available" ? part.output : undefined;
+  const interactive: ToolRenderItem["interactive"] =
+    resolvedInteractiveTool?.kind === "petrinaut"
+      ? {
+          kind: "petrinaut",
+          definition: resolvedInteractiveTool.definition,
+          input: part.input,
+          submittedOutput:
+            state === "output-available"
+              ? parseSubmittedOutput(
+                  resolvedInteractiveTool.definition.parseOutput,
+                  part.output,
+                )
+              : undefined,
+        }
+      : resolvedInteractiveTool
+        ? {
+            kind: "host",
+            tool: resolvedInteractiveTool.tool,
+            input: part.input,
+            submittedOutput,
+          }
+        : undefined;
 
   return {
     id:
@@ -498,8 +558,25 @@ const ToolItem = ({
   tool: ToolRenderItem;
 }) => {
   if (tool.interactive) {
-    const { definition, input, submittedOutput } = tool.interactive;
     const submitted = tool.state === "output-available";
+    if (tool.interactive.kind === "host") {
+      const { input, submittedOutput, tool: hostTool } = tool.interactive;
+      return hostTool.render({
+        input,
+        state: submitted ? "submitted" : "awaiting",
+        submit: (submission) => {
+          onInteractiveToolSubmit?.({
+            kind: "host",
+            toolCallId: tool.id,
+            toolName: hostTool.toolName,
+            submission,
+          });
+        },
+        submittedOutput,
+      });
+    }
+
+    const { definition, input, submittedOutput } = tool.interactive;
     const Widget = definition.Widget;
     let typedInput: unknown;
     try {
@@ -510,11 +587,12 @@ const ToolItem = ({
     return (
       <Widget
         input={typedInput}
-        submit={(output) => {
+        submit={(submission) => {
           onInteractiveToolSubmit?.({
+            kind: "petrinaut",
             toolCallId: tool.id,
-            toolName: tool.toolName,
-            output,
+            toolName: definition.toolName,
+            submission,
           });
         }}
         state={submitted ? "submitted" : "awaiting"}
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.test.tsx b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.test.tsx
index 4bf09fa10ed..9162734a198 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.test.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.test.tsx
@@ -4,17 +4,18 @@
 import { cleanup, fireEvent, render, screen } from "@testing-library/react";
 import { afterEach, describe, expect, test, vi } from "vitest";
 
-import { applyAutoLayoutInteractiveTool } from "./apply-auto-layout-widget";
-
-import type { AiToolOutput } from "../tool-summaries";
+import {
+  applyAutoLayoutInteractiveTool,
+  type ApplyAutoLayoutDecision,
+} from "./apply-auto-layout-widget";
 
 const Widget = applyAutoLayoutInteractiveTool.Widget;
 
 afterEach(cleanup);
 
 describe("ApplyAutoLayoutWidget", () => {
-  test("invokes submit with applied: true when the user confirms", () => {
-    const submit = vi.fn<(output: AiToolOutput) => void>();
+  test("submits an apply decision when the user confirms", () => {
+    const submit = vi.fn<(decision: ApplyAutoLayoutDecision) => void>();
 
     render(
       <Widget
@@ -27,12 +28,11 @@ describe("ApplyAutoLayoutWidget", () => {
     fireEvent.click(screen.getByRole("button", { name: /Yes, auto-layout/i }));
 
     expect(submit).toHaveBeenCalledTimes(1);
-    const output: AiToolOutput = submit.mock.calls[0]![0];
-    expect(output).toMatchObject({ applied: true });
+    expect(submit.mock.calls[0]![0]).toEqual({ action: "apply" });
   });
 
-  test("invokes submit with applied: false when the user declines", () => {
-    const submit = vi.fn<(output: AiToolOutput) => void>();
+  test("submits a decline decision when the user declines", () => {
+    const submit = vi.fn<(decision: ApplyAutoLayoutDecision) => void>();
 
     render(
       <Widget
@@ -47,11 +47,7 @@ describe("ApplyAutoLayoutWidget", () => {
     );
 
     expect(submit).toHaveBeenCalledTimes(1);
-    const output: AiToolOutput = submit.mock.calls[0]![0];
-    expect(output).toEqual({
-      applied: false,
-      reason: "User declined auto-layout.",
-    });
+    expect(submit.mock.calls[0]![0]).toEqual({ action: "decline" });
   });
 
   test("renders a static summary once submitted", () => {
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.tsx b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.tsx
index 46309b1d4cd..f50696d9b2d 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.tsx
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/apply-auto-layout-widget.tsx
@@ -6,13 +6,18 @@ import {
   type AiCommandActionName,
 } from "@hashintel/petrinaut-core";
 
-import type { AiToolOutput } from "../tool-summaries";
 import type {
   InteractiveToolDefinition,
   InteractiveToolWidgetProps,
 } from "./types";
 
 type ApplyAutoLayoutInput = AiCommandActionInput<"applyAutoLayout">;
+export type ApplyAutoLayoutDecision =
+  | { readonly action: "apply" }
+  | { readonly action: "decline" };
+export type ApplyAutoLayoutResult =
+  | { readonly applied: true; readonly title: string }
+  | { readonly applied: false; readonly reason: string };
 
 const widgetStyle = css({
   display: "flex",
@@ -39,7 +44,11 @@ const ApplyAutoLayoutWidget = ({
   state,
   submit,
   submittedOutput,
-}: InteractiveToolWidgetProps<ApplyAutoLayoutInput, AiToolOutput>) => {
+}: InteractiveToolWidgetProps<
+  ApplyAutoLayoutInput,
+  ApplyAutoLayoutDecision,
+  ApplyAutoLayoutResult
+>) => {
   if (state === "submitted") {
     const verdict =
       submittedOutput?.applied === true
@@ -64,12 +73,7 @@ const ApplyAutoLayoutWidget = ({
           size="sm"
           variant="solid"
           tone="brand"
-          onClick={() =>
-            submit({
-              applied: true,
-              title: "Auto-layout requested",
-            })
-          }
+          onClick={() => submit({ action: "apply" })}
         >
           Yes, auto-layout
         </Button>
@@ -77,9 +81,7 @@ const ApplyAutoLayoutWidget = ({
           size="sm"
           variant="subtle"
           tone="neutral"
-          onClick={() =>
-            submit({ applied: false, reason: "User declined auto-layout." })
-          }
+          onClick={() => submit({ action: "decline" })}
         >
           No, keep current layout
         </Button>
@@ -95,7 +97,9 @@ const ApplyAutoLayoutWidget = ({
  */
 export const applyAutoLayoutInteractiveTool: InteractiveToolDefinition<
   ApplyAutoLayoutInput,
-  AiToolOutput
+  ApplyAutoLayoutDecision,
+  ApplyAutoLayoutResult,
+  "applyAutoLayout"
 > = {
   toolName: "applyAutoLayout" satisfies AiCommandActionName,
   shouldHandle: (raw): boolean => {
@@ -104,5 +108,27 @@ export const applyAutoLayoutInteractiveTool: InteractiveToolDefinition<
   },
   parseInput: (raw): ApplyAutoLayoutInput =>
     aiCommandActionInputSchemas.applyAutoLayout.parse(raw),
+  parseOutput: (raw): ApplyAutoLayoutResult => {
+    if (typeof raw !== "object" || raw === null) {
+      throw new TypeError("Expected an auto-layout result object.");
+    }
+    if (
+      "applied" in raw &&
+      raw.applied === true &&
+      "title" in raw &&
+      typeof raw.title === "string"
+    ) {
+      return { applied: true, title: raw.title };
+    }
+    if (
+      "applied" in raw &&
+      raw.applied === false &&
+      "reason" in raw &&
+      typeof raw.reason === "string"
+    ) {
+      return { applied: false, reason: raw.reason };
+    }
+    throw new TypeError("Expected a completed auto-layout result.");
+  },
   Widget: ApplyAutoLayoutWidget,
 };
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.test.ts b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.test.ts
new file mode 100644
index 00000000000..754182b3f34
--- /dev/null
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.test.ts
@@ -0,0 +1,36 @@
+import { expect, test } from "vitest";
+
+import { getInteractiveTool } from "./registry";
+import { definePetrinautAiInteractiveTool } from "./types";
+
+const brunchAsk = definePetrinautAiInteractiveTool({
+  toolName: "brunch_ask",
+  shouldHandle: () => true,
+  parseInput: String,
+  parseOutput: String,
+  Widget: () => null,
+});
+
+test("resolves a host-supplied interactive tool", () => {
+  expect(
+    getInteractiveTool(
+      "brunch_ask",
+      "What outcome should the process produce?",
+      [brunchAsk],
+    ),
+  ).toEqual({ kind: "host", tool: brunchAsk });
+});
+
+test("does not let a host shadow a Petrinaut-owned tool", () => {
+  const shadow = definePetrinautAiInteractiveTool({
+    toolName: "applyAutoLayout",
+    shouldHandle: () => true,
+    parseInput: String,
+    parseOutput: String,
+    Widget: () => null,
+  });
+
+  expect(
+    getInteractiveTool("applyAutoLayout", { askUserFirst: true }, [shadow]),
+  ).not.toBe(shadow);
+});
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.ts b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.ts
index dbec90871c0..32194b2a467 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.ts
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/registry.ts
@@ -1,7 +1,14 @@
 import { applyAutoLayoutInteractiveTool } from "./apply-auto-layout-widget";
 
-import type { AiToolOutput } from "../tool-summaries";
-import type { InteractiveToolDefinition } from "./types";
+import type {
+  ApplyAutoLayoutDecision,
+  ApplyAutoLayoutResult,
+} from "./apply-auto-layout-widget";
+import type {
+  InteractiveToolDefinition,
+  PetrinautAiInteractiveTool,
+} from "./types";
+import type { AiCommandActionName } from "@hashintel/petrinaut-core";
 
 /**
  * Registry of AI tools that require an inline chat widget for user input.
@@ -15,22 +22,68 @@ import type { InteractiveToolDefinition } from "./types";
  */
 export const interactiveTools: Record<
   string,
-  InteractiveToolDefinition<unknown, AiToolOutput>
+  InteractiveToolDefinition<
+    unknown,
+    ApplyAutoLayoutDecision,
+    ApplyAutoLayoutResult,
+    AiCommandActionName
+  >
 > = {
   [applyAutoLayoutInteractiveTool.toolName]:
     applyAutoLayoutInteractiveTool as InteractiveToolDefinition<
       unknown,
-      AiToolOutput
+      ApplyAutoLayoutDecision,
+      ApplyAutoLayoutResult,
+      AiCommandActionName
     >,
 };
 
-export const getInteractiveTool = (
+export type ResolvedInteractiveTool =
+  | {
+      readonly kind: "petrinaut";
+      readonly definition: InteractiveToolDefinition<
+        unknown,
+        ApplyAutoLayoutDecision,
+        ApplyAutoLayoutResult,
+        AiCommandActionName
+      >;
+    }
+  | {
+      readonly kind: "host";
+      readonly tool: PetrinautAiInteractiveTool;
+    };
+
+export const findHostInteractiveTool = (
+  toolName: string,
+  hostTools: readonly PetrinautAiInteractiveTool[] = [],
+): PetrinautAiInteractiveTool | undefined => {
+  if (interactiveTools[toolName]) {
+    return undefined;
+  }
+  return hostTools.find((hostTool) => hostTool.toolName === toolName);
+};
+
+export const getHostInteractiveTool = (
   toolName: string,
   input: unknown,
-): InteractiveToolDefinition<unknown, AiToolOutput> | undefined => {
-  const descriptor = interactiveTools[toolName];
+  hostTools: readonly PetrinautAiInteractiveTool[] = [],
+): PetrinautAiInteractiveTool | undefined => {
+  const descriptor = findHostInteractiveTool(toolName, hostTools);
   if (!descriptor) {
     return undefined;
   }
   return descriptor.shouldHandle(input) ? descriptor : undefined;
 };
+
+export const getInteractiveTool = (
+  toolName: string,
+  input: unknown,
+  hostTools: readonly PetrinautAiInteractiveTool[] = [],
+): ResolvedInteractiveTool | undefined => {
+  const petrinautDefinition = interactiveTools[toolName];
+  if (petrinautDefinition?.shouldHandle(input)) {
+    return { kind: "petrinaut", definition: petrinautDefinition };
+  }
+  const hostTool = getHostInteractiveTool(toolName, input, hostTools);
+  return hostTool ? { kind: "host", tool: hostTool } : undefined;
+};
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.test.ts b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.test.ts
new file mode 100644
index 00000000000..43e6443961e
--- /dev/null
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.test.ts
@@ -0,0 +1,71 @@
+import { expect, test } from "vitest";
+
+import { definePetrinautAiInteractiveTool } from "./types";
+
+const HostWidget = () => null;
+
+test("does not throw or mount the widget when parseInput rejects", () => {
+  const hostTool = definePetrinautAiInteractiveTool({
+    toolName: "host_tool",
+    shouldHandle: () => true,
+    parseInput: () => {
+      throw new Error("incomplete input");
+    },
+    parseOutput: String,
+    Widget: HostWidget,
+  });
+
+  expect(() =>
+    hostTool.render({
+      input: {},
+      state: "awaiting",
+      submit: () => {},
+    }),
+  ).not.toThrow();
+  expect(
+    hostTool.render({
+      input: {},
+      state: "awaiting",
+      submit: () => {},
+    }),
+  ).toBeNull();
+});
+
+test("mounts the widget when input parses and still swallows a throwing parseOutput", () => {
+  const hostTool = definePetrinautAiInteractiveTool({
+    toolName: "host_tool",
+    shouldHandle: () => true,
+    parseInput: (raw): { question: string } => {
+      if (
+        typeof raw !== "object" ||
+        raw === null ||
+        !("question" in raw) ||
+        typeof raw.question !== "string" ||
+        raw.question.length === 0
+      ) {
+        throw new Error("incomplete input");
+      }
+      return { question: raw.question };
+    },
+    parseOutput: () => {
+      throw new Error("corrupt output");
+    },
+    Widget: HostWidget,
+  });
+
+  const node = hostTool.render({
+    input: { question: "What outcome should the process produce?" },
+    state: "submitted",
+    submit: () => {},
+    submittedOutput: { bad: true },
+  });
+
+  expect(node).toMatchObject({
+    type: HostWidget,
+    props: {
+      input: { question: "What outcome should the process produce?" },
+      state: "submitted",
+      submittedOutput: undefined,
+    },
+  });
+});
diff --git a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.ts b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.ts
index 3d31eabd336..0714a05b495 100644
--- a/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.ts
+++ b/libs/@hashintel/petrinaut/src/ui/views/Editor/panels/ai-assistant-panel/interactive-tools/types.ts
@@ -1,22 +1,26 @@
-import type { ComponentType } from "react";
+import { createElement, type ComponentType, type ReactNode } from "react";
 
 /**
  * Props passed to every interactive tool widget. The widget renders inline in
  * the AI chat while a tool call is awaiting human input, then becomes a
  * read-only summary once the user submits.
  */
-export type InteractiveToolWidgetProps<Input, Output> = {
+export type InteractiveToolWidgetProps<
+  Input,
+  Submission,
+  SubmittedOutput = Submission,
+> = {
   /** Validated input the AI passed to the tool. */
   input: Input;
   /**
    * Submit a tool output to the chat. After submission, the widget remains
    * mounted in `submitted` state with the chosen output visible.
    */
-  submit: (output: Output) => void;
+  submit: (submission: Submission) => void;
   /** "awaiting" while the user has not yet picked; "submitted" afterwards. */
   state: "awaiting" | "submitted";
   /** Output that was submitted (only set when `state === "submitted"`). */
-  submittedOutput?: Output;
+  submittedOutput?: SubmittedOutput;
 };
 
 /**
@@ -26,8 +30,13 @@ export type InteractiveToolWidgetProps<Input, Output> = {
  * `true`, and the surface renders the registered {@link Widget} until the
  * user submits.
  */
-export type InteractiveToolDefinition<Input = unknown, Output = unknown> = {
-  toolName: string;
+export type InteractiveToolDefinition<
+  Input = unknown,
+  Submission = unknown,
+  SubmittedOutput = Submission,
+  ToolName extends string = string,
+> = {
+  toolName: ToolName;
   /**
    * Whether this tool call should be handled interactively. Lets a single
    * tool branch between interactive and non-interactive paths based on its
@@ -37,5 +46,49 @@ export type InteractiveToolDefinition<Input = unknown, Output = unknown> = {
   shouldHandle: (input: unknown) => boolean;
   /** Parse the raw input into the widget's typed input. */
   parseInput: (raw: unknown) => Input;
-  Widget: ComponentType<InteractiveToolWidgetProps<Input, Output>>;
+  /** Parse a persisted tool output into the widget's read-only result view. */
+  parseOutput: (raw: unknown) => SubmittedOutput;
+  Widget: ComponentType<
+    InteractiveToolWidgetProps<Input, Submission, SubmittedOutput>
+  >;
 };
+
+/**
+ * Opaque host capability consumed by the heterogeneous interactive-tool
+ * registry. Host-specific input and output types stay sealed inside
+ * {@link definePetrinautAiInteractiveTool}.
+ */
+export type PetrinautAiInteractiveTool = {
+  readonly toolName: string;
+  shouldHandle(input: unknown): boolean;
+  render(props: InteractiveToolWidgetProps<unknown, unknown>): ReactNode;
+};
+
+export const definePetrinautAiInteractiveTool = <Input, Output>(
+  definition: InteractiveToolDefinition<Input, Output>,
+): PetrinautAiInteractiveTool => ({
+  toolName: definition.toolName,
+  shouldHandle: definition.shouldHandle,
+  render: ({ input, state, submit, submittedOutput }) => {
+    let parsedInput: Input;
+    try {
+      parsedInput = definition.parseInput(input);
+    } catch {
+      return null;
+    }
+    let parsedOutput: Output | undefined;
+    if (state === "submitted") {
+      try {
+        parsedOutput = definition.parseOutput(submittedOutput);
+      } catch {
+        parsedOutput = undefined;
+      }
+    }
+    return createElement(definition.Widget, {
+      input: parsedInput,
+      state,
+      submit: (output: Output) => submit(output),
+      submittedOutput: parsedOutput,
+    });
+  },
+});
diff --git a/oxfmt.config.ts b/oxfmt.config.ts
index 99290d85b26..62aaa3398dc 100644
--- a/oxfmt.config.ts
+++ b/oxfmt.config.ts
@@ -59,6 +59,9 @@ export default defineConfig({
   ignorePatterns: [
     // License files have intentional formatting that shouldn't be touched
     "**/LICENSE*.md",
+    // Imported Brunch context docs, including hash-pinned frozen data
+    // snapshots whose bytes must not be rewritten
+    "libs/@hashintel/brunch-agent/docs/**",
     // While supported, it doesn't yet support the full breadth
     // of taplo configuration options that we have set
     // see: https://github.com/oxc-project/oxc/issues/18580
diff --git a/package.json b/package.json
index a084e2d55b1..7c07af5d451 100644
--- a/package.json
+++ b/package.json
@@ -80,6 +80,7 @@
     "oxfmt": "0.50.0"
   },
   "resolutions": {
+    "@anthropic-ai/bedrock-sdk/@anthropic-ai/sdk": "0.74.0",
     "@blockprotocol/core": "0.1.5",
     "@changesets/assemble-release-plan@npm:^6.0.9": "patch:@changesets/assemble-release-plan@npm%3A6.0.9#~/.yarn/patches/@changesets-assemble-release-plan-npm-6.0.9-e01af97ef4.patch",
     "@playwright/test": "1.58.2",
diff --git a/yarn.lock b/yarn.lock
index bd39a606455..df8f3cfdc8b 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -92,7 +92,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@anthropic-ai/sdk@npm:0.74.0, @anthropic-ai/sdk@npm:>=0.50.3 <1":
+"@anthropic-ai/sdk@npm:0.74.0":
   version: 0.74.0
   resolution: "@anthropic-ai/sdk@npm:0.74.0"
   dependencies:
@@ -108,6 +108,22 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@anthropic-ai/sdk@npm:0.91.1":
+  version: 0.91.1
+  resolution: "@anthropic-ai/sdk@npm:0.91.1"
+  dependencies:
+    json-schema-to-ts: "npm:^3.1.1"
+  peerDependencies:
+    zod: ^3.25.0 || ^4.0.0
+  peerDependenciesMeta:
+    zod:
+      optional: true
+  bin:
+    anthropic-ai-sdk: bin/cli
+  checksum: 10c0/aa9fb1b3d0ae47f492ee7a94b76d341ac7c5486b222a9426b4815b07a65a0b6f502430b0250ff5bf2201a0cdae725a5d4f1f7a4aaa075e9fb32cc2ac10d70241
+  languageName: node
+  linkType: hard
+
 "@apidevtools/json-schema-ref-parser@npm:15.1.3":
   version: 15.1.3
   resolution: "@apidevtools/json-schema-ref-parser@npm:15.1.3"
@@ -414,6 +430,34 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@apps/brunch-agent@workspace:apps/brunch-agent":
+  version: 0.0.0-use.local
+  resolution: "@apps/brunch-agent@workspace:apps/brunch-agent"
+  dependencies:
+    "@earendil-works/pi-ai": "npm:0.83.0"
+    "@flue/react": "npm:2.0.3"
+    "@flue/runtime": "npm:2.0.3"
+    "@flue/sdk": "npm:2.0.3"
+    "@flue/vite": "npm:2.0.3"
+    "@hashintel/brunch-agent": "workspace:*"
+    "@hashintel/brunch-agent-binding-flue": "workspace:*"
+    "@hashintel/brunch-agent-plugin-gherkin": "workspace:*"
+    "@hashintel/brunch-agent-transport-aisdk": "workspace:*"
+    "@types/node": "npm:22.18.13"
+    "@types/react": "npm:19.2.14"
+    "@types/react-dom": "npm:19.2.3"
+    "@typescript/native-preview": "npm:7.0.0-dev.20260511.1"
+    hono: "npm:4.13.2"
+    oxlint: "npm:1.63.0"
+    oxlint-tsgolint: "npm:0.22.1"
+    react: "npm:19.2.6"
+    react-dom: "npm:19.2.6"
+    valibot: "npm:1.4.2"
+    vite: "npm:8.1.0"
+    vitest: "npm:4.1.10"
+  languageName: unknown
+  linkType: soft
+
 "@apps/hash-ai-worker-ts@workspace:*, @apps/hash-ai-worker-ts@workspace:apps/hash-ai-worker-ts":
   version: 0.0.0-use.local
   resolution: "@apps/hash-ai-worker-ts@workspace:apps/hash-ai-worker-ts"
@@ -870,6 +914,7 @@ __metadata:
   resolution: "@apps/petrinaut-website@workspace:apps/petrinaut-website"
   dependencies:
     "@ai-sdk/openai": "npm:3.0.63"
+    "@hashintel/brunch-agent-transport-aisdk": "workspace:*"
     "@hashintel/ds-components": "workspace:*"
     "@hashintel/ds-helpers": "workspace:*"
     "@hashintel/petrinaut": "workspace:*"
@@ -1550,59 +1595,25 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/client-bedrock-runtime@npm:^3.797.0":
-  version: 3.913.0
-  resolution: "@aws-sdk/client-bedrock-runtime@npm:3.913.0"
+"@aws-sdk/client-bedrock-runtime@npm:3.1048.0, @aws-sdk/client-bedrock-runtime@npm:^3.797.0":
+  version: 3.1048.0
+  resolution: "@aws-sdk/client-bedrock-runtime@npm:3.1048.0"
   dependencies:
     "@aws-crypto/sha256-browser": "npm:5.2.0"
     "@aws-crypto/sha256-js": "npm:5.2.0"
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/credential-provider-node": "npm:3.913.0"
-    "@aws-sdk/eventstream-handler-node": "npm:3.910.0"
-    "@aws-sdk/middleware-eventstream": "npm:3.910.0"
-    "@aws-sdk/middleware-host-header": "npm:3.910.0"
-    "@aws-sdk/middleware-logger": "npm:3.910.0"
-    "@aws-sdk/middleware-recursion-detection": "npm:3.910.0"
-    "@aws-sdk/middleware-user-agent": "npm:3.911.0"
-    "@aws-sdk/middleware-websocket": "npm:3.910.0"
-    "@aws-sdk/region-config-resolver": "npm:3.910.0"
-    "@aws-sdk/token-providers": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/util-endpoints": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-browser": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-node": "npm:3.911.0"
-    "@smithy/config-resolver": "npm:^4.3.2"
-    "@smithy/core": "npm:^3.16.1"
-    "@smithy/eventstream-serde-browser": "npm:^4.2.2"
-    "@smithy/eventstream-serde-config-resolver": "npm:^4.3.2"
-    "@smithy/eventstream-serde-node": "npm:^4.2.2"
-    "@smithy/fetch-http-handler": "npm:^5.3.3"
-    "@smithy/hash-node": "npm:^4.2.2"
-    "@smithy/invalid-dependency": "npm:^4.2.2"
-    "@smithy/middleware-content-length": "npm:^4.2.2"
-    "@smithy/middleware-endpoint": "npm:^4.3.3"
-    "@smithy/middleware-retry": "npm:^4.4.3"
-    "@smithy/middleware-serde": "npm:^4.2.2"
-    "@smithy/middleware-stack": "npm:^4.2.2"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/node-http-handler": "npm:^4.4.1"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/smithy-client": "npm:^4.8.1"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/url-parser": "npm:^4.2.2"
-    "@smithy/util-base64": "npm:^4.3.0"
-    "@smithy/util-body-length-browser": "npm:^4.2.0"
-    "@smithy/util-body-length-node": "npm:^4.2.1"
-    "@smithy/util-defaults-mode-browser": "npm:^4.3.2"
-    "@smithy/util-defaults-mode-node": "npm:^4.2.3"
-    "@smithy/util-endpoints": "npm:^3.2.2"
-    "@smithy/util-middleware": "npm:^4.2.2"
-    "@smithy/util-retry": "npm:^4.2.2"
-    "@smithy/util-stream": "npm:^4.5.2"
-    "@smithy/util-utf8": "npm:^4.2.0"
-    "@smithy/uuid": "npm:^1.1.0"
+    "@aws-sdk/core": "npm:^3.974.11"
+    "@aws-sdk/credential-provider-node": "npm:^3.972.42"
+    "@aws-sdk/eventstream-handler-node": "npm:^3.972.16"
+    "@aws-sdk/middleware-eventstream": "npm:^3.972.12"
+    "@aws-sdk/middleware-websocket": "npm:^3.972.19"
+    "@aws-sdk/token-providers": "npm:3.1048.0"
+    "@aws-sdk/types": "npm:^3.973.8"
+    "@smithy/core": "npm:^3.24.2"
+    "@smithy/fetch-http-handler": "npm:^5.4.2"
+    "@smithy/node-http-handler": "npm:^4.7.2"
+    "@smithy/types": "npm:^4.14.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/2119e75734be5bbb85642ce9e4e9aaed2438fd1cd1b863b932a214b2fc0af2a78a853d273d5117faf87023cb05b47b8c24f3c3cb64fc86c619e76009fdf81b78
+  checksum: 10c0/8172a964cf580631e02906bc1312f1b44ad862a367417600e45f65f79a6f35318a713393ba565af6b73292071ee52751d405696a864820b12c70ffdb75dc06c1
   languageName: node
   linkType: hard
 
@@ -1735,86 +1746,19 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/client-sso@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/client-sso@npm:3.911.0"
+"@aws-sdk/core@npm:^3.973.7, @aws-sdk/core@npm:^3.974.11, @aws-sdk/core@npm:^3.974.14, @aws-sdk/core@npm:^3.977.7":
+  version: 3.977.7
+  resolution: "@aws-sdk/core@npm:3.977.7"
   dependencies:
-    "@aws-crypto/sha256-browser": "npm:5.2.0"
-    "@aws-crypto/sha256-js": "npm:5.2.0"
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/middleware-host-header": "npm:3.910.0"
-    "@aws-sdk/middleware-logger": "npm:3.910.0"
-    "@aws-sdk/middleware-recursion-detection": "npm:3.910.0"
-    "@aws-sdk/middleware-user-agent": "npm:3.911.0"
-    "@aws-sdk/region-config-resolver": "npm:3.910.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/util-endpoints": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-browser": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-node": "npm:3.911.0"
-    "@smithy/config-resolver": "npm:^4.3.2"
-    "@smithy/core": "npm:^3.16.1"
-    "@smithy/fetch-http-handler": "npm:^5.3.3"
-    "@smithy/hash-node": "npm:^4.2.2"
-    "@smithy/invalid-dependency": "npm:^4.2.2"
-    "@smithy/middleware-content-length": "npm:^4.2.2"
-    "@smithy/middleware-endpoint": "npm:^4.3.3"
-    "@smithy/middleware-retry": "npm:^4.4.3"
-    "@smithy/middleware-serde": "npm:^4.2.2"
-    "@smithy/middleware-stack": "npm:^4.2.2"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/node-http-handler": "npm:^4.4.1"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/smithy-client": "npm:^4.8.1"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/url-parser": "npm:^4.2.2"
-    "@smithy/util-base64": "npm:^4.3.0"
-    "@smithy/util-body-length-browser": "npm:^4.2.0"
-    "@smithy/util-body-length-node": "npm:^4.2.1"
-    "@smithy/util-defaults-mode-browser": "npm:^4.3.2"
-    "@smithy/util-defaults-mode-node": "npm:^4.2.3"
-    "@smithy/util-endpoints": "npm:^3.2.2"
-    "@smithy/util-middleware": "npm:^4.2.2"
-    "@smithy/util-retry": "npm:^4.2.2"
-    "@smithy/util-utf8": "npm:^4.2.0"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/ef07589cf448bb30136e015d6ea594aa84704b45234fc984d0d9824a2d2f2f7595d14090766b92f46b116b39f41071b083f41d2e95a0eb4ebf8fbc39105903fd
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/core@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/core@npm:3.911.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/xml-builder": "npm:3.911.0"
-    "@smithy/core": "npm:^3.16.1"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/signature-v4": "npm:^5.3.2"
-    "@smithy/smithy-client": "npm:^4.8.1"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/util-base64": "npm:^4.3.0"
-    "@smithy/util-middleware": "npm:^4.2.2"
-    "@smithy/util-utf8": "npm:^4.2.0"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/438e7c7a5d75d970650c31d76d81a8d4152a779df0b2d757b7a4b110f31104989ce878f260b843ffa083f6dd3cef2e58304884373c9d750a4bad60e9a669a50f
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/core@npm:^3.973.7, @aws-sdk/core@npm:^3.974.14, @aws-sdk/core@npm:^3.974.15":
-  version: 3.974.15
-  resolution: "@aws-sdk/core@npm:3.974.15"
-  dependencies:
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@aws-sdk/xml-builder": "npm:^3.972.26"
-    "@aws/lambda-invoke-store": "npm:^0.2.2"
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/signature-v4": "npm:^5.4.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@aws-sdk/xml-builder": "npm:^3.972.38"
+    "@aws/lambda-invoke-store": "npm:^0.3.0"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/signature-v4": "npm:^5.6.12"
+    "@smithy/types": "npm:^4.16.1"
     bowser: "npm:^2.11.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/d875337bd51b45477d4266b309e2c1b14488ddeb1b8516737cc4b43abfd9a80abfec282ebfa063852b5f78918d90b7c4fa0066d915a5657a1eb2ef5d7723c98f
+  checksum: 10c0/305bc5d7bd61b33bbdbec7abc5dbf03fb64ea8e2b60fcda9e4ab22ce2fc09eea6db71769010ead7437e75d09c6407acedfe1f8a52e9b1ea97ba5c0ebd3e348e0
   languageName: node
   linkType: hard
 
@@ -1841,138 +1785,66 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-env@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/credential-provider-env@npm:3.911.0"
-  dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/09e9b080fdf63bb48575e9ef9e233ad5fcc895cd727fd3db2d45a012d188cb3612bc0e4b04fee1cf302f14c1a5fcc01b32e3e154263853bddec0a7f72a259707
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-env@npm:^3.972.40, @aws-sdk/credential-provider-env@npm:^3.972.5":
-  version: 3.972.40
-  resolution: "@aws-sdk/credential-provider-env@npm:3.972.40"
-  dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/4882aaa01c60642c5d04956b2bff21398f3cbdba04fc6adf82a208d1540ba9c25fdabf0caa805e556d091dc8bffcf9beb6e01302bbf90f3723faca46a6e54245
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-http@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/credential-provider-http@npm:3.911.0"
+"@aws-sdk/credential-provider-env@npm:^3.972.40, @aws-sdk/credential-provider-env@npm:^3.972.5, @aws-sdk/credential-provider-env@npm:^3.972.68":
+  version: 3.972.68
+  resolution: "@aws-sdk/credential-provider-env@npm:3.972.68"
   dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/fetch-http-handler": "npm:^5.3.3"
-    "@smithy/node-http-handler": "npm:^4.4.1"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/smithy-client": "npm:^4.8.1"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/util-stream": "npm:^4.5.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/9bfe10fb49989e22db9b5fffcade6195e1fe9633d9eb8baf92b8e7e5a985f2a34df185ad42e05c66d8ace37851284c576ebc6e601e27cee5b8f833741567fa73
+  checksum: 10c0/31b9d5fd71d00556ecf1bc5da793e8cb04f98d09ccb00c8b65a59b88a6a860a7737e1aeefcb5f7e62f322f9f3a7eba279b205c8623e912d936fe01a667ab724a
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-http@npm:^3.972.42, @aws-sdk/credential-provider-http@npm:^3.972.7":
-  version: 3.972.42
-  resolution: "@aws-sdk/credential-provider-http@npm:3.972.42"
+"@aws-sdk/credential-provider-http@npm:^3.972.42, @aws-sdk/credential-provider-http@npm:^3.972.7, @aws-sdk/credential-provider-http@npm:^3.972.70":
+  version: 3.972.70
+  resolution: "@aws-sdk/credential-provider-http@npm:3.972.70"
   dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/fetch-http-handler": "npm:^5.4.3"
-    "@smithy/node-http-handler": "npm:^4.7.3"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/fetch-http-handler": "npm:^5.6.13"
+    "@smithy/node-http-handler": "npm:^4.9.13"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/3955a4af3d39d7a38b433a7f39b873bb1bc1633ca701af4aed0c61756234d3085123e99c6335726c43ccad4858d5570ecef4923fe6cb1bd3bc522f6ed67b8b63
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-ini@npm:3.913.0":
-  version: 3.913.0
-  resolution: "@aws-sdk/credential-provider-ini@npm:3.913.0"
-  dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/credential-provider-env": "npm:3.911.0"
-    "@aws-sdk/credential-provider-http": "npm:3.911.0"
-    "@aws-sdk/credential-provider-process": "npm:3.911.0"
-    "@aws-sdk/credential-provider-sso": "npm:3.911.0"
-    "@aws-sdk/credential-provider-web-identity": "npm:3.911.0"
-    "@aws-sdk/nested-clients": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/credential-provider-imds": "npm:^4.2.2"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
+  checksum: 10c0/9230d722c0307bbafd0b56a42c25708a25a0d087c9993c37f628fbae8e142120d73a34738b6b0bf15f57efdbcf664feb6ae773e2526b3729663ce54403393487
+  languageName: node
+  linkType: hard
+
+"@aws-sdk/credential-provider-ini@npm:^3.972.44, @aws-sdk/credential-provider-ini@npm:^3.972.5, @aws-sdk/credential-provider-ini@npm:^3.973.13":
+  version: 3.973.13
+  resolution: "@aws-sdk/credential-provider-ini@npm:3.973.13"
+  dependencies:
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/credential-provider-env": "npm:^3.972.68"
+    "@aws-sdk/credential-provider-http": "npm:^3.972.70"
+    "@aws-sdk/credential-provider-login": "npm:^3.972.75"
+    "@aws-sdk/credential-provider-process": "npm:^3.972.68"
+    "@aws-sdk/credential-provider-sso": "npm:^3.973.12"
+    "@aws-sdk/credential-provider-web-identity": "npm:^3.972.74"
+    "@aws-sdk/nested-clients": "npm:^3.997.42"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/credential-provider-imds": "npm:^4.4.16"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/567cf87a9b069b5d20fb829355802be30edff0c8e07e7660f13eb02341106b18a0ea8428eadc2f2ba2ab7374d2ea90a7eef3af89262fded4eecddb2024793ae8
+  checksum: 10c0/0d7c76a3227f21e8c08af3db03e369651c9efb795b964707f243d69bdc1fb322b712a1be7e7d474ffaca25118eb00ce6eeb56a646850d72a14a8f7e6120cc02c
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-ini@npm:^3.972.44, @aws-sdk/credential-provider-ini@npm:^3.972.5":
-  version: 3.972.44
-  resolution: "@aws-sdk/credential-provider-ini@npm:3.972.44"
+"@aws-sdk/credential-provider-login@npm:^3.972.44, @aws-sdk/credential-provider-login@npm:^3.972.75":
+  version: 3.972.75
+  resolution: "@aws-sdk/credential-provider-login@npm:3.972.75"
   dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/credential-provider-env": "npm:^3.972.40"
-    "@aws-sdk/credential-provider-http": "npm:^3.972.42"
-    "@aws-sdk/credential-provider-login": "npm:^3.972.44"
-    "@aws-sdk/credential-provider-process": "npm:^3.972.40"
-    "@aws-sdk/credential-provider-sso": "npm:^3.972.44"
-    "@aws-sdk/credential-provider-web-identity": "npm:^3.972.44"
-    "@aws-sdk/nested-clients": "npm:^3.997.12"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/credential-provider-imds": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/34f3bb770df3cb31bf9129ea9e2fc72a122cd131054481d67c2dd5e509967771fd2c7426f574ba9a1bd855b8446add0125776353c7d63bc6a88b1ea5e6eda9f0
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-login@npm:^3.972.44":
-  version: 3.972.45
-  resolution: "@aws-sdk/credential-provider-login@npm:3.972.45"
-  dependencies:
-    "@aws-sdk/core": "npm:^3.974.15"
-    "@aws-sdk/nested-clients": "npm:^3.997.13"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/nested-clients": "npm:^3.997.42"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/2d688c72094752bd6a947a8c64e7f180f9469ddf2bb710237a1c43cadd48c10ef3410844502a4beaa14df2d25dbfb69682c48310681c595882af9b45a3e1ec04
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-node@npm:3.913.0":
-  version: 3.913.0
-  resolution: "@aws-sdk/credential-provider-node@npm:3.913.0"
-  dependencies:
-    "@aws-sdk/credential-provider-env": "npm:3.911.0"
-    "@aws-sdk/credential-provider-http": "npm:3.911.0"
-    "@aws-sdk/credential-provider-ini": "npm:3.913.0"
-    "@aws-sdk/credential-provider-process": "npm:3.911.0"
-    "@aws-sdk/credential-provider-sso": "npm:3.911.0"
-    "@aws-sdk/credential-provider-web-identity": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/credential-provider-imds": "npm:^4.2.2"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/096e5967f22143b8bb14c1d7e104c186b85d474424717caa909cbcd9c3aaa152c3bc6737ecb533ccf5707b8fba7b3f20ced668f23a454a46eaeb526cf59a8484
+  checksum: 10c0/ab05ddced3fe6bc9360b79950fb07ed01a06c103771c36686d3495135a18d55ebbc8b5fb56744b120e2cc2cc9e413615ce6e1b1c5186ca97b8eb68142162081e
   languageName: node
   linkType: hard
 
@@ -1996,109 +1868,64 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-node@npm:^3.972.45, @aws-sdk/credential-provider-node@npm:^3.972.6":
-  version: 3.972.45
-  resolution: "@aws-sdk/credential-provider-node@npm:3.972.45"
-  dependencies:
-    "@aws-sdk/credential-provider-env": "npm:^3.972.40"
-    "@aws-sdk/credential-provider-http": "npm:^3.972.42"
-    "@aws-sdk/credential-provider-ini": "npm:^3.972.44"
-    "@aws-sdk/credential-provider-process": "npm:^3.972.40"
-    "@aws-sdk/credential-provider-sso": "npm:^3.972.44"
-    "@aws-sdk/credential-provider-web-identity": "npm:^3.972.44"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/credential-provider-imds": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/0060df16c887a68c2878087fecfa5f20a110bfce60d8227844a975ad04ae064d54a4b205f42eda88108a3f55c5e652cc6227d49be7742ca0ed6a9f19bb3c5ffd
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-process@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/credential-provider-process@npm:3.911.0"
+"@aws-sdk/credential-provider-node@npm:^3.972.42, @aws-sdk/credential-provider-node@npm:^3.972.45, @aws-sdk/credential-provider-node@npm:^3.972.6":
+  version: 3.972.79
+  resolution: "@aws-sdk/credential-provider-node@npm:3.972.79"
   dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/credential-provider-env": "npm:^3.972.68"
+    "@aws-sdk/credential-provider-http": "npm:^3.972.70"
+    "@aws-sdk/credential-provider-ini": "npm:^3.973.13"
+    "@aws-sdk/credential-provider-process": "npm:^3.972.68"
+    "@aws-sdk/credential-provider-sso": "npm:^3.973.12"
+    "@aws-sdk/credential-provider-web-identity": "npm:^3.972.74"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/credential-provider-imds": "npm:^4.4.16"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/02563d2bd90b2a3b89d2ed338ea9dd2bb6a8f7585f7a77b4c3fc040f2d84e20b28196c2a61fc2b1298c0184a6a7ead22b7d5d87f8949c5d96057d638f06dd858
+  checksum: 10c0/0c7b282b9b8a6774e0acc987e1fff59d10926afe336b0dfe0fa4af84d333b46df50f8679b2cce95d73b75b0ae593b44ad4896bc8d54e337a3b611666cf1ceb6a
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-process@npm:^3.972.40, @aws-sdk/credential-provider-process@npm:^3.972.5":
-  version: 3.972.40
-  resolution: "@aws-sdk/credential-provider-process@npm:3.972.40"
+"@aws-sdk/credential-provider-process@npm:^3.972.40, @aws-sdk/credential-provider-process@npm:^3.972.5, @aws-sdk/credential-provider-process@npm:^3.972.68":
+  version: 3.972.68
+  resolution: "@aws-sdk/credential-provider-process@npm:3.972.68"
   dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/e87bafcd71005b7947f5cfdd34fad36225f2922206d5039e93f3fdbc55d5b29d7083f766a02084621006cd219f206e72f3cb75a0806cf4e6ac0acdb924bb9fc7
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-sso@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/credential-provider-sso@npm:3.911.0"
-  dependencies:
-    "@aws-sdk/client-sso": "npm:3.911.0"
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/token-providers": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/9f590b512ae089ed072b637a341696a498dea0665d75440845f6b33e87b63d2719f2d06fe9a6ec8e40b02e18dbe054d2d4c5a444a8ea6c3ebd9d028825a8e881
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/credential-provider-sso@npm:^3.972.44, @aws-sdk/credential-provider-sso@npm:^3.972.5":
-  version: 3.972.44
-  resolution: "@aws-sdk/credential-provider-sso@npm:3.972.44"
-  dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/nested-clients": "npm:^3.997.12"
-    "@aws-sdk/token-providers": "npm:3.1054.0"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/cfcba3bfc222cb307d40b5de2f699462b9681b5ed17dfe1068d9ddf2795bdf43b9e9bc1a2aa6414d3e691ef4cd5b83abe1841a22586f3f4f1bcf760b7e85a1db
+  checksum: 10c0/97a7061fdf997588ab8ea2feb4a5a268e3c94e841e3418faf683fade3bca1c627b6e30969666d7ca96207a37fe7178e704eb8adc720ac8eb391e8c1e85291f11
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-web-identity@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/credential-provider-web-identity@npm:3.911.0"
+"@aws-sdk/credential-provider-sso@npm:^3.972.44, @aws-sdk/credential-provider-sso@npm:^3.972.5, @aws-sdk/credential-provider-sso@npm:^3.973.12":
+  version: 3.973.12
+  resolution: "@aws-sdk/credential-provider-sso@npm:3.973.12"
   dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/nested-clients": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/nested-clients": "npm:^3.997.42"
+    "@aws-sdk/token-providers": "npm:3.1108.0"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/bc7a5581d202dcc7d3d5d5d4295dc8408dd35eb7b630c38a3e73e4465500f5746901664207cf0e8313bc237fa319966f6ad29d1555617ad8f7832b6128cc8073
+  checksum: 10c0/061f0219ace75565abe79480f81920eb4bfe45e84b53901941c3b7d6c9aee7a67542e1058fbeb40139fd4887bb42cdf759ba1ebdb7b7cbb2fa9cd1e033e32871
   languageName: node
   linkType: hard
 
-"@aws-sdk/credential-provider-web-identity@npm:^3.972.44, @aws-sdk/credential-provider-web-identity@npm:^3.972.5":
-  version: 3.972.44
-  resolution: "@aws-sdk/credential-provider-web-identity@npm:3.972.44"
+"@aws-sdk/credential-provider-web-identity@npm:^3.972.44, @aws-sdk/credential-provider-web-identity@npm:^3.972.5, @aws-sdk/credential-provider-web-identity@npm:^3.972.74":
+  version: 3.972.74
+  resolution: "@aws-sdk/credential-provider-web-identity@npm:3.972.74"
   dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/nested-clients": "npm:^3.997.12"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/nested-clients": "npm:^3.997.42"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/55a4c5a4e74e2ea71eccac48e45bf9432c67ae5b04b7e40042697f63c2f759c62a6e60adaca8c8763aa405be504d11e7e2537a93a7f9576ab6c62de42cf6e755
+  checksum: 10c0/9c1da6479fdc329a7540420e0e5a1030f159f689150acb7d1d67ae9c91b99415b47f0abce859bc8987e9a7aee109e411e45f0e197b5e1d94c3c31379c8a426b2
   languageName: node
   linkType: hard
 
@@ -2127,15 +1954,15 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/eventstream-handler-node@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/eventstream-handler-node@npm:3.910.0"
+"@aws-sdk/eventstream-handler-node@npm:^3.972.16":
+  version: 3.972.32
+  resolution: "@aws-sdk/eventstream-handler-node@npm:3.972.32"
   dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/eventstream-codec": "npm:^4.2.2"
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/2764f42bdda331963a65c22407d74cffa422c215aac450c390acc956eafb2d5d912af3fff0403387f3a1cbf7f01247530e932ba389b7d0baef6686b8e8b2a824
+  checksum: 10c0/b2558cbd0d7560f046bb932a07f046fd50fe9a043a2ee49d8fc120852253bf9b38f4cca883a1fbaf1a6bd6d2b5acd069c7290a1560f8d5ea90d9c31e0293755f
   languageName: node
   linkType: hard
 
@@ -2154,15 +1981,15 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-eventstream@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/middleware-eventstream@npm:3.910.0"
+"@aws-sdk/middleware-eventstream@npm:^3.972.12":
+  version: 3.972.27
+  resolution: "@aws-sdk/middleware-eventstream@npm:3.972.27"
   dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/a07f9ef0e4e2d25ca554806ed7e149242c1c03294744dd505c9e557d46f5f4e045ff0ed6e500084a7a16192bdd6c0ae079543cea35b27d047455e24bb53baa37
+  checksum: 10c0/dec54753749f12e51d20507674e3014a850a3637c1083792aa4f9b96d21ddc53c40dc10d2c8529fe041a174631bca86497509fa3b0a9889e8172502a57f0c5d4
   languageName: node
   linkType: hard
 
@@ -2200,18 +2027,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-host-header@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/middleware-host-header@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/bfd348a15b855a89a46a5c3cc18dbca94eda541847c3260b2d66b8c84440976cd527831bab7adaf3f6bc68fb9b61b885b69762dee3830cb960a2a18a8c517482
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/middleware-host-header@npm:^3.972.3":
   version: 3.972.3
   resolution: "@aws-sdk/middleware-host-header@npm:3.972.3"
@@ -2235,17 +2050,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-logger@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/middleware-logger@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/33d0ec8c067701e8fb80f792ec4208decb0eb61502fd34377976bcd0aea5ee2c554a0861b3f42547a6a11abfe7ca5324c419d87dbe88def282b9ce4da2edb068
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/middleware-logger@npm:^3.972.3":
   version: 3.972.3
   resolution: "@aws-sdk/middleware-logger@npm:3.972.3"
@@ -2257,19 +2061,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-recursion-detection@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/middleware-recursion-detection@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws/lambda-invoke-store": "npm:^0.0.1"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/bdf27349e500c8abffc67c5ed017dad8749b5a007d1e1da0fea7f12cb5e85a6255e28811e517566454a1a6a201fea6fe94cb8e90d4f8d8023cbcbf412afddcdd
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/middleware-recursion-detection@npm:^3.972.3":
   version: 3.972.3
   resolution: "@aws-sdk/middleware-recursion-detection@npm:3.972.3"
@@ -2316,21 +2107,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-user-agent@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/middleware-user-agent@npm:3.911.0"
-  dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/util-endpoints": "npm:3.910.0"
-    "@smithy/core": "npm:^3.16.1"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/4c8084ef88e5b62da3ac6dc0f28da12bea2b94a4962f95012253ee4c1ddb271e53448f7aa72c4a1fb5640f8a6621ec84713ce385943486c8e093b55c64ba6599
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/middleware-user-agent@npm:^3.972.7":
   version: 3.972.7
   resolution: "@aws-sdk/middleware-user-agent@npm:3.972.7"
@@ -2346,99 +2122,34 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/middleware-websocket@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/middleware-websocket@npm:3.910.0"
+"@aws-sdk/middleware-websocket@npm:^3.972.19":
+  version: 3.972.50
+  resolution: "@aws-sdk/middleware-websocket@npm:3.972.50"
   dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/util-format-url": "npm:3.910.0"
-    "@smithy/eventstream-codec": "npm:^4.2.2"
-    "@smithy/eventstream-serde-browser": "npm:^4.2.2"
-    "@smithy/fetch-http-handler": "npm:^5.3.3"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/signature-v4": "npm:^5.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/util-hex-encoding": "npm:^4.2.0"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/fetch-http-handler": "npm:^5.6.13"
+    "@smithy/signature-v4": "npm:^5.6.12"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/fb3e2bf805ec6eacb446cce3a79da58fde271e90295ffb8be6b2cc907c47df80dfb8162b4141bdc013496101a3524c42c46e3f7d528e11a2593aadf14a544ad2
+  checksum: 10c0/b113332ca3a10a2fc32b2438497c594047bfe7dc31b6f873652be491c15d01072a87282e6ddf7878a586e25229c9dc35decad4bfaa53a228496db458fa10d5db
   languageName: node
   linkType: hard
 
-"@aws-sdk/nested-clients@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/nested-clients@npm:3.911.0"
+"@aws-sdk/nested-clients@npm:^3.997.12, @aws-sdk/nested-clients@npm:^3.997.13, @aws-sdk/nested-clients@npm:^3.997.42, @aws-sdk/nested-clients@npm:^3.997.9":
+  version: 3.997.42
+  resolution: "@aws-sdk/nested-clients@npm:3.997.42"
   dependencies:
-    "@aws-crypto/sha256-browser": "npm:5.2.0"
-    "@aws-crypto/sha256-js": "npm:5.2.0"
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/middleware-host-header": "npm:3.910.0"
-    "@aws-sdk/middleware-logger": "npm:3.910.0"
-    "@aws-sdk/middleware-recursion-detection": "npm:3.910.0"
-    "@aws-sdk/middleware-user-agent": "npm:3.911.0"
-    "@aws-sdk/region-config-resolver": "npm:3.910.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@aws-sdk/util-endpoints": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-browser": "npm:3.910.0"
-    "@aws-sdk/util-user-agent-node": "npm:3.911.0"
-    "@smithy/config-resolver": "npm:^4.3.2"
-    "@smithy/core": "npm:^3.16.1"
-    "@smithy/fetch-http-handler": "npm:^5.3.3"
-    "@smithy/hash-node": "npm:^4.2.2"
-    "@smithy/invalid-dependency": "npm:^4.2.2"
-    "@smithy/middleware-content-length": "npm:^4.2.2"
-    "@smithy/middleware-endpoint": "npm:^4.3.3"
-    "@smithy/middleware-retry": "npm:^4.4.3"
-    "@smithy/middleware-serde": "npm:^4.2.2"
-    "@smithy/middleware-stack": "npm:^4.2.2"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/node-http-handler": "npm:^4.4.1"
-    "@smithy/protocol-http": "npm:^5.3.2"
-    "@smithy/smithy-client": "npm:^4.8.1"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/url-parser": "npm:^4.2.2"
-    "@smithy/util-base64": "npm:^4.3.0"
-    "@smithy/util-body-length-browser": "npm:^4.2.0"
-    "@smithy/util-body-length-node": "npm:^4.2.1"
-    "@smithy/util-defaults-mode-browser": "npm:^4.3.2"
-    "@smithy/util-defaults-mode-node": "npm:^4.2.3"
-    "@smithy/util-endpoints": "npm:^3.2.2"
-    "@smithy/util-middleware": "npm:^4.2.2"
-    "@smithy/util-retry": "npm:^4.2.2"
-    "@smithy/util-utf8": "npm:^4.2.0"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/d1c993ad22f7e58d10d2fccade5f4e9d12b04f8304a6b06615c088f827105b75c75e14be4698d120038d6f7d6e7244204c15813a5c2d5f87d9ef6e347fc320ec
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/nested-clients@npm:^3.997.12, @aws-sdk/nested-clients@npm:^3.997.13":
-  version: 3.997.13
-  resolution: "@aws-sdk/nested-clients@npm:3.997.13"
-  dependencies:
-    "@aws-crypto/sha256-browser": "npm:5.2.0"
-    "@aws-crypto/sha256-js": "npm:5.2.0"
-    "@aws-sdk/core": "npm:^3.974.15"
-    "@aws-sdk/signature-v4-multi-region": "npm:^3.996.30"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/fetch-http-handler": "npm:^5.4.5"
-    "@smithy/node-http-handler": "npm:^4.7.5"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/6c29476d5a68d5f6dd44342230702bad7799678e5aa8f9c1d8555001790d6f67715cc33b0ba134ed7e61bef0c79abe619ef64c1cca4c2f28abf1b44b9534350b
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/region-config-resolver@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/region-config-resolver@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/util-config-provider": "npm:^4.2.0"
-    "@smithy/util-middleware": "npm:^4.2.2"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/signature-v4-multi-region": "npm:^3.996.44"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/fetch-http-handler": "npm:^5.6.13"
+    "@smithy/node-http-handler": "npm:^4.9.13"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/03bc2172d0c3b134cbb496e8546606a8821fc4f0272ea03aadfd653b29956ddbbfa2ad3e12b7937d3e98d7b0f92e8fedb2af6559f2389c2d1d4ffc37bb55c5b0
+  checksum: 10c0/1405a73a86aa904fa503592fcc0793dc5b8ab994d1c9eda1b017ca26bd1a659fd87cd9af762c713466ebc8950ced06ee49521a5dea25a99edbe011720e1d86e3
   languageName: node
   linkType: hard
 
@@ -2502,64 +2213,53 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/signature-v4-multi-region@npm:^3.996.30":
-  version: 3.996.30
-  resolution: "@aws-sdk/signature-v4-multi-region@npm:3.996.30"
-  dependencies:
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/signature-v4": "npm:^5.4.5"
-    "@smithy/types": "npm:^4.14.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/87f237c9b719da0946eb87612ba965d78603ec14367f7c50416a52070cc8a6c65021f374b1d13cab98b1ebc29de009d6ba6c5d6c2e4576034f891b17fb2b3f1d
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/token-providers@npm:3.1054.0":
-  version: 3.1054.0
-  resolution: "@aws-sdk/token-providers@npm:3.1054.0"
+"@aws-sdk/signature-v4-multi-region@npm:^3.996.44":
+  version: 3.996.44
+  resolution: "@aws-sdk/signature-v4-multi-region@npm:3.996.44"
   dependencies:
-    "@aws-sdk/core": "npm:^3.974.14"
-    "@aws-sdk/nested-clients": "npm:^3.997.12"
-    "@aws-sdk/types": "npm:^3.973.9"
-    "@smithy/core": "npm:^3.24.3"
-    "@smithy/types": "npm:^4.14.2"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/signature-v4": "npm:^5.6.12"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/27d315a3238c50fc88ace785f4a0efe6e49034ab61af7af5585b43cef235fc740cd6ac7bd9fed789344ef1eb289e4f871caa332454f8bdcb923826db67132830
+  checksum: 10c0/b9c970abad58f9f87dcb2577f9121c7c9015ea18b4101e4813ff92bb5c19524c8634f6507f3c273ad8694d5ef6f272d5bd0648993c16431fcb09dcc402dd7d72
   languageName: node
   linkType: hard
 
-"@aws-sdk/token-providers@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/token-providers@npm:3.911.0"
+"@aws-sdk/token-providers@npm:3.1048.0":
+  version: 3.1048.0
+  resolution: "@aws-sdk/token-providers@npm:3.1048.0"
   dependencies:
-    "@aws-sdk/core": "npm:3.911.0"
-    "@aws-sdk/nested-clients": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/property-provider": "npm:^4.2.2"
-    "@smithy/shared-ini-file-loader": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/core": "npm:^3.974.11"
+    "@aws-sdk/nested-clients": "npm:^3.997.9"
+    "@aws-sdk/types": "npm:^3.973.8"
+    "@smithy/core": "npm:^3.24.2"
+    "@smithy/types": "npm:^4.14.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/287a1777c8885a6e0a2af0856356e3fc063c1d8d28abda3602b862d0aa4a56593751d4e2b820cb0588432b890d68f432b00720cdf4e04fc04a6c79cc9f9c3439
+  checksum: 10c0/4dbca618047f9a051999031e0f027098fbd880fe7732bcd38cd0fd48461c41d7f28797bbf4292aa573815d7a2cdd44a0dad1fafd1922f52792f70c54bfd165b2
   languageName: node
   linkType: hard
 
-"@aws-sdk/types@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/types@npm:3.910.0"
+"@aws-sdk/token-providers@npm:3.1108.0":
+  version: 3.1108.0
+  resolution: "@aws-sdk/token-providers@npm:3.1108.0"
   dependencies:
-    "@smithy/types": "npm:^4.7.1"
+    "@aws-sdk/core": "npm:^3.977.7"
+    "@aws-sdk/nested-clients": "npm:^3.997.42"
+    "@aws-sdk/types": "npm:^3.974.3"
+    "@smithy/core": "npm:^3.31.1"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/b91c035d68999dfef31ffb81f0f6dea6d9a763339293d4267975dc9bc0f946d39d48fa51dbe643360d8643686e6ccce783f2ae1e3dfabd4d470bb8834c1186d3
+  checksum: 10c0/4593b1228d55cfc960cb22c6eecfe29032f4b1a01f0452f46ba22cdaa7bcde051f5749cfcc465ef682f659cc7a4f0d7c55ce254158b88eacf3ca1c3fa7946e7e
   languageName: node
   linkType: hard
 
-"@aws-sdk/types@npm:^3.222.0, @aws-sdk/types@npm:^3.973.1, @aws-sdk/types@npm:^3.973.9":
-  version: 3.973.9
-  resolution: "@aws-sdk/types@npm:3.973.9"
+"@aws-sdk/types@npm:^3.222.0, @aws-sdk/types@npm:^3.973.1, @aws-sdk/types@npm:^3.973.8, @aws-sdk/types@npm:^3.973.9, @aws-sdk/types@npm:^3.974.3":
+  version: 3.974.3
+  resolution: "@aws-sdk/types@npm:3.974.3"
   dependencies:
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/8164f908a004c23927109b86f44e9d112804aaa32cd654b260f79b7c2c2f9fb6802b72ccf73cbbf6fa1c613e660ce5b45835018db94713a59714e8ff762aaf2a
+  checksum: 10c0/6850403d8d9358ea497a63eaa50129f1989a2acc959878bb473525f04238099ab85f9bb7877f9d03191f3397941cf841ce80aaf0f319c94273e41fedf51661d7
   languageName: node
   linkType: hard
 
@@ -2572,19 +2272,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/util-endpoints@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/util-endpoints@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/types": "npm:^4.7.1"
-    "@smithy/url-parser": "npm:^4.2.2"
-    "@smithy/util-endpoints": "npm:^3.2.2"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/1944c8ff7fd50ef6e018a27c378ae0eba7672900827cbc2b1604d04ce08ec2a74dea11eb3a9ba63a00e4083206be93e9a90aaa424f841e5f5c55888cf0e07073
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/util-endpoints@npm:3.985.0":
   version: 3.985.0
   resolution: "@aws-sdk/util-endpoints@npm:3.985.0"
@@ -2611,18 +2298,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/util-format-url@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/util-format-url@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/querystring-builder": "npm:^4.2.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/f65f56ac79b557a6ab98143c3cb607ea92bb5d785bc3bed0c077365e9f04119c3a34e3d05e14c0e9d99ec2064de32e30cdc03d901cee0a59d4d1da9f85e9aebd
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/util-format-url@npm:^3.972.3":
   version: 3.972.3
   resolution: "@aws-sdk/util-format-url@npm:3.972.3"
@@ -2644,18 +2319,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/util-user-agent-browser@npm:3.910.0":
-  version: 3.910.0
-  resolution: "@aws-sdk/util-user-agent-browser@npm:3.910.0"
-  dependencies:
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/types": "npm:^4.7.1"
-    bowser: "npm:^2.11.0"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/7f331a95df724548198a076f560cb1a7491c4b87dc76b2eea623ef6acc2c4b186e50a393336a26ecf83fadb9375c9eb668e5b5bc154adcf3e17ecf7ae0f89cc0
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/util-user-agent-browser@npm:^3.972.3":
   version: 3.972.3
   resolution: "@aws-sdk/util-user-agent-browser@npm:3.972.3"
@@ -2668,24 +2331,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/util-user-agent-node@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/util-user-agent-node@npm:3.911.0"
-  dependencies:
-    "@aws-sdk/middleware-user-agent": "npm:3.911.0"
-    "@aws-sdk/types": "npm:3.910.0"
-    "@smithy/node-config-provider": "npm:^4.3.2"
-    "@smithy/types": "npm:^4.7.1"
-    tslib: "npm:^2.6.2"
-  peerDependencies:
-    aws-crt: ">=1.0.0"
-  peerDependenciesMeta:
-    aws-crt:
-      optional: true
-  checksum: 10c0/e7ceaa43633aa27f7d3239fc1006d844a23ab720635c2898f0da5024588feb77a1c77cd3142d1450d751b93ee4ae404756c7364230b2ac7b4ef473372ada1378
-  languageName: node
-  linkType: hard
-
 "@aws-sdk/util-user-agent-node@npm:^3.972.5":
   version: 3.972.5
   resolution: "@aws-sdk/util-user-agent-node@npm:3.972.5"
@@ -2713,32 +2358,13 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@aws-sdk/xml-builder@npm:3.911.0":
-  version: 3.911.0
-  resolution: "@aws-sdk/xml-builder@npm:3.911.0"
-  dependencies:
-    "@smithy/types": "npm:^4.7.1"
-    fast-xml-parser: "npm:5.2.5"
-    tslib: "npm:^2.6.2"
-  checksum: 10c0/174aa60f5be883954b33082af65a20238a64bd69c4983ee7617786b77624325ddd8ae844b7a59e5d3bb92d33519e5bb9a6d626ce2fa547bd60455ba65867ddda
-  languageName: node
-  linkType: hard
-
-"@aws-sdk/xml-builder@npm:^3.972.26":
-  version: 3.972.26
-  resolution: "@aws-sdk/xml-builder@npm:3.972.26"
+"@aws-sdk/xml-builder@npm:^3.972.38":
+  version: 3.972.38
+  resolution: "@aws-sdk/xml-builder@npm:3.972.38"
   dependencies:
-    "@smithy/types": "npm:^4.14.2"
-    fast-xml-parser: "npm:5.7.3"
+    "@smithy/types": "npm:^4.16.1"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/f9501c0e475455d6ce6dd66aba781d07094a7e80c09a0b894e755a373afd6ec0f0f8f235e46d92f22902db7c3f9225beeab3b22993dd429999a7e618a8f9f9f1
-  languageName: node
-  linkType: hard
-
-"@aws/lambda-invoke-store@npm:^0.0.1":
-  version: 0.0.1
-  resolution: "@aws/lambda-invoke-store@npm:0.0.1"
-  checksum: 10c0/0bbf3060014a462177fb743e132e9b106a6743ad9cd905df4bd26e9ca8bfe2cc90473b03a79938fa908934e45e43f366f57af56a697991abda71d9ac92f5018f
+  checksum: 10c0/8f4c500bea2e1060b2cf47aac4be87b80e9bdf5389d3d3aeaca66397ebc4b15cdc39a8d3f0d54df2c39597c3c2957edce4cca0d92a7a875aedcfdb094d6910ec
   languageName: node
   linkType: hard
 
@@ -2749,6 +2375,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@aws/lambda-invoke-store@npm:^0.3.0":
+  version: 0.3.0
+  resolution: "@aws/lambda-invoke-store@npm:0.3.0"
+  checksum: 10c0/b4a2e6b3b5397bc606053e64270d26dc5c886336f88a98cad587b1592eec17058f8fb172f1827a9f0e591f3595cf8f01575c8c9b36cde38c06456f8a65204046
+  languageName: node
+  linkType: hard
+
 "@babel/code-frame@npm:^7.0.0, @babel/code-frame@npm:^7.10.4, @babel/code-frame@npm:^7.26.2, @babel/code-frame@npm:^7.29.0, @babel/code-frame@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/code-frame@npm:7.29.7"
@@ -2760,6 +2393,16 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/code-frame@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/code-frame@npm:8.0.0"
+  dependencies:
+    "@babel/helper-validator-identifier": "npm:^8.0.0"
+    js-tokens: "npm:^10.0.0"
+  checksum: 10c0/2ea8614018bcd8c86358ab6aa930508115d2205e5e111f736d355b150453818bdf487850f6dec5ec92a10bf27ba4536f4b3b8ad9204514e43d8d68ff2e542443
+  languageName: node
+  linkType: hard
+
 "@babel/compat-data@npm:^7.27.7, @babel/compat-data@npm:^7.28.0, @babel/compat-data@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/compat-data@npm:7.29.7"
@@ -2854,6 +2497,20 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/generator@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/generator@npm:8.0.0"
+  dependencies:
+    "@babel/parser": "npm:^8.0.0"
+    "@babel/types": "npm:^8.0.0"
+    "@jridgewell/gen-mapping": "npm:^0.3.12"
+    "@jridgewell/trace-mapping": "npm:^0.3.28"
+    "@types/jsesc": "npm:^2.5.0"
+    jsesc: "npm:^3.0.2"
+  checksum: 10c0/2b2d171beaedcacca62164f0f39bc8962df5f9700a54c5515174276ea20b3a53933e9804e0b35c2be1059108a764447d99d0c5beb63ecbbf8c66035ca6c003c4
+  languageName: node
+  linkType: hard
+
 "@babel/helper-annotate-as-pure@npm:^7.18.6, @babel/helper-annotate-as-pure@npm:^7.27.1, @babel/helper-annotate-as-pure@npm:^7.27.3":
   version: 7.27.3
   resolution: "@babel/helper-annotate-as-pure@npm:7.27.3"
@@ -2863,6 +2520,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-annotate-as-pure@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-annotate-as-pure@npm:8.0.0"
+  dependencies:
+    "@babel/types": "npm:^8.0.0"
+  checksum: 10c0/3705ef8d1e95d86f3bb3380a9fb45a92be03eb77dfc5a684295dbdeb65e93c681516e98f5a6cbdc5f67186a68e3dae3e0528012ad4e626ed46853ad1e0bfd1c7
+  languageName: node
+  linkType: hard
+
 "@babel/helper-compilation-targets@npm:^7.27.1, @babel/helper-compilation-targets@npm:^7.27.2, @babel/helper-compilation-targets@npm:^7.28.6, @babel/helper-compilation-targets@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/helper-compilation-targets@npm:7.29.7"
@@ -2893,6 +2559,23 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-create-class-features-plugin@npm:^8.0.1":
+  version: 8.0.1
+  resolution: "@babel/helper-create-class-features-plugin@npm:8.0.1"
+  dependencies:
+    "@babel/helper-annotate-as-pure": "npm:^8.0.0"
+    "@babel/helper-member-expression-to-functions": "npm:^8.0.0"
+    "@babel/helper-optimise-call-expression": "npm:^8.0.0"
+    "@babel/helper-replace-supers": "npm:^8.0.1"
+    "@babel/helper-skip-transparent-expression-wrappers": "npm:^8.0.0"
+    "@babel/traverse": "npm:^8.0.0"
+    semver: "npm:^7.7.3"
+  peerDependencies:
+    "@babel/core": ^8.0.0
+  checksum: 10c0/ead1f980e3f400a87cd1f77e29789d3a85f6b322df51e59c20d21eb42745699561b6ffec6aa42877ad08c59a5e5bf5fc3d660b3a8518178d2a4e246d8bad4c4b
+  languageName: node
+  linkType: hard
+
 "@babel/helper-create-regexp-features-plugin@npm:^7.18.6, @babel/helper-create-regexp-features-plugin@npm:^7.27.1":
   version: 7.27.1
   resolution: "@babel/helper-create-regexp-features-plugin@npm:7.27.1"
@@ -2928,6 +2611,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-globals@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-globals@npm:8.0.0"
+  checksum: 10c0/c53a9fcf451df5c8d3aa72f282d1f058e2874e2ccbbdbb5572a805595d75a9355461822d01a6cac3128f5d9ab9a3a99538c6be4ebd728068afb20a65a4d1d986
+  languageName: node
+  linkType: hard
+
 "@babel/helper-member-expression-to-functions@npm:^7.27.1, @babel/helper-member-expression-to-functions@npm:^7.28.5":
   version: 7.28.5
   resolution: "@babel/helper-member-expression-to-functions@npm:7.28.5"
@@ -2938,6 +2628,16 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-member-expression-to-functions@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-member-expression-to-functions@npm:8.0.0"
+  dependencies:
+    "@babel/traverse": "npm:^8.0.0"
+    "@babel/types": "npm:^8.0.0"
+  checksum: 10c0/7cf5d0344a014c8315136689f4db8e23d96c90fceb86beab695e79c5cb5fd69f8400b84547d4ee1cf43d8c88c90092828f278e3f8c8e1e2adb8abb92b971c9d0
+  languageName: node
+  linkType: hard
+
 "@babel/helper-module-imports@npm:^7.16.7, @babel/helper-module-imports@npm:^7.25.9, @babel/helper-module-imports@npm:^7.27.1, @babel/helper-module-imports@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/helper-module-imports@npm:7.29.7"
@@ -2970,6 +2670,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-optimise-call-expression@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-optimise-call-expression@npm:8.0.0"
+  dependencies:
+    "@babel/types": "npm:^8.0.0"
+  checksum: 10c0/8871c1a17ed816f6728b3ec4941c1922a7bcf8e1b293a592a90ff62525460b05b82405938ca9d2c9adcc66b7f28eaf138e43388d807395a14317b7ba1b55c9fe
+  languageName: node
+  linkType: hard
+
 "@babel/helper-plugin-utils@npm:^7.0.0, @babel/helper-plugin-utils@npm:^7.10.4, @babel/helper-plugin-utils@npm:^7.14.5, @babel/helper-plugin-utils@npm:^7.18.6, @babel/helper-plugin-utils@npm:^7.18.9, @babel/helper-plugin-utils@npm:^7.20.2, @babel/helper-plugin-utils@npm:^7.25.9, @babel/helper-plugin-utils@npm:^7.27.1, @babel/helper-plugin-utils@npm:^7.28.6, @babel/helper-plugin-utils@npm:^7.29.7, @babel/helper-plugin-utils@npm:^7.8.0, @babel/helper-plugin-utils@npm:^7.8.3":
   version: 7.29.7
   resolution: "@babel/helper-plugin-utils@npm:7.29.7"
@@ -2977,6 +2686,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-plugin-utils@npm:^8.0.1":
+  version: 8.0.1
+  resolution: "@babel/helper-plugin-utils@npm:8.0.1"
+  peerDependencies:
+    "@babel/core": ^8.0.0
+  checksum: 10c0/ec56d98187a58dfbc2ce9d75fd5f880d6acacefb314e32fe40c57293c6c65c659fa116c665e430aff8b153b7d0ea63f16ca290e9d2283196e3c7a3dd61bffa94
+  languageName: node
+  linkType: hard
+
 "@babel/helper-remap-async-to-generator@npm:^7.27.1":
   version: 7.27.1
   resolution: "@babel/helper-remap-async-to-generator@npm:7.27.1"
@@ -3003,6 +2721,19 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-replace-supers@npm:^8.0.1":
+  version: 8.0.1
+  resolution: "@babel/helper-replace-supers@npm:8.0.1"
+  dependencies:
+    "@babel/helper-member-expression-to-functions": "npm:^8.0.0"
+    "@babel/helper-optimise-call-expression": "npm:^8.0.0"
+    "@babel/traverse": "npm:^8.0.0"
+  peerDependencies:
+    "@babel/core": ^8.0.0
+  checksum: 10c0/1289ab0f58c6f5150f5d5caf627de9a1e20b32d08bf1b9c90569aca7b0c32779482fadb1c38142b50f98a3794c9ac175fd4184a5fccc2edc76769f16c4dbaf14
+  languageName: node
+  linkType: hard
+
 "@babel/helper-skip-transparent-expression-wrappers@npm:^7.20.0, @babel/helper-skip-transparent-expression-wrappers@npm:^7.27.1":
   version: 7.27.1
   resolution: "@babel/helper-skip-transparent-expression-wrappers@npm:7.27.1"
@@ -3013,6 +2744,16 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-skip-transparent-expression-wrappers@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-skip-transparent-expression-wrappers@npm:8.0.0"
+  dependencies:
+    "@babel/traverse": "npm:^8.0.0"
+    "@babel/types": "npm:^8.0.0"
+  checksum: 10c0/b66b8db1438efd7754eeb5d1198f2a6c34f19c06f76af057c480ae354c5f4d1488f6ca92c581d957f28d16881f931a1092b5a70c893924a1158258384d9f6597
+  languageName: node
+  linkType: hard
+
 "@babel/helper-string-parser@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/helper-string-parser@npm:7.29.7"
@@ -3020,14 +2761,14 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@babel/helper-string-parser@npm:^8.0.0-rc.4":
-  version: 8.0.0-rc.4
-  resolution: "@babel/helper-string-parser@npm:8.0.0-rc.4"
-  checksum: 10c0/8e9950d36b8cd5fb5d03c56cd2cce91cf98efa093110d519e160a948a9e77eade71f292204d7395212c5e763af23b2b6687550fbcaa281a1efd3494a46bd99ca
+"@babel/helper-string-parser@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/helper-string-parser@npm:8.0.0"
+  checksum: 10c0/b2272a9eaa63a1bc9ce2673d580e69620fd79786f3e3cf1891f406801f8211810f194f2739fef920f01a97ae06ae465b2dfd238ab8037a3182d0869939ca9a5d
   languageName: node
   linkType: hard
 
-"@babel/helper-validator-identifier@npm:8.0.0-rc.4, @babel/helper-validator-identifier@npm:^8.0.0-rc.4":
+"@babel/helper-validator-identifier@npm:8.0.0-rc.4":
   version: 8.0.0-rc.4
   resolution: "@babel/helper-validator-identifier@npm:8.0.0-rc.4"
   checksum: 10c0/dc523bdc206cff0b2a4db97459e7cf31d315d60fa7dff1fdcc8101568dc9e6a929c2126eb96a078b1e8eb26b6b4978526bbf8b5f50d91d809c77956a3b84064f
@@ -3041,6 +2782,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/helper-validator-identifier@npm:^8.0.0, @babel/helper-validator-identifier@npm:^8.0.4":
+  version: 8.0.4
+  resolution: "@babel/helper-validator-identifier@npm:8.0.4"
+  checksum: 10c0/9d3c639a42b70613016fda026487a3b8056df918cb40221a48ef666a3bd2574475e315ee509c552baef4bef55a627ee8ea530e9af5b376512ab248c37aeab336
+  languageName: node
+  linkType: hard
+
 "@babel/helper-validator-option@npm:^7.27.1, @babel/helper-validator-option@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/helper-validator-option@npm:7.29.7"
@@ -3069,7 +2817,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@babel/parser@npm:8.0.0-rc.4, @babel/parser@npm:^8.0.0-beta.4, @babel/parser@npm:^8.0.0-rc.4":
+"@babel/parser@npm:8.0.0-rc.4":
   version: 8.0.0-rc.4
   resolution: "@babel/parser@npm:8.0.0-rc.4"
   dependencies:
@@ -3091,6 +2839,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/parser@npm:^8.0.0, @babel/parser@npm:^8.0.0-beta.4, @babel/parser@npm:^8.0.0-rc.4, @babel/parser@npm:^8.0.4":
+  version: 8.0.4
+  resolution: "@babel/parser@npm:8.0.4"
+  dependencies:
+    "@babel/types": "npm:^8.0.4"
+  bin:
+    parser: ./bin/babel-parser.js
+  checksum: 10c0/b98ebc350e6583ccec0c59ab653e6c5967935826b8e03210a96e638a98b0c552587d4ca9cc44502964bac42463e2bab93ca1a6ac519279a25e190bd78f3ce513
+  languageName: node
+  linkType: hard
+
 "@babel/plugin-bugfix-firefox-class-in-computed-class-key@npm:^7.27.1":
   version: 7.27.1
   resolution: "@babel/plugin-bugfix-firefox-class-in-computed-class-key@npm:7.27.1"
@@ -3175,6 +2934,19 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/plugin-proposal-decorators@npm:^8.0.2":
+  version: 8.0.2
+  resolution: "@babel/plugin-proposal-decorators@npm:8.0.2"
+  dependencies:
+    "@babel/helper-create-class-features-plugin": "npm:^8.0.1"
+    "@babel/helper-plugin-utils": "npm:^8.0.1"
+    "@babel/plugin-syntax-decorators": "npm:^8.0.1"
+  peerDependencies:
+    "@babel/core": ^8.0.0
+  checksum: 10c0/f584eb0da64b2a43d296a0cbfee5f0225d7f443b4e77b9c25f2fa6eef4e16831716ec0a18ece13e6c1d7525f33f7626564dcf4a8bfdc008b5bb271b46ad18b58
+  languageName: node
+  linkType: hard
+
 "@babel/plugin-proposal-export-namespace-from@npm:^7.18.9":
   version: 7.18.9
   resolution: "@babel/plugin-proposal-export-namespace-from@npm:7.18.9"
@@ -3270,6 +3042,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/plugin-syntax-decorators@npm:^8.0.1":
+  version: 8.0.1
+  resolution: "@babel/plugin-syntax-decorators@npm:8.0.1"
+  dependencies:
+    "@babel/helper-plugin-utils": "npm:^8.0.1"
+  peerDependencies:
+    "@babel/core": ^8.0.0
+  checksum: 10c0/e5db01d20743f6c76f3b3c4cc7bd9f9fedd16d6eeca70c0fafbf66258508346344c633f6e8e6deed73ec8a7be6cf4067ca746e374c37cc01ad77f6fa19ab020d
+  languageName: node
+  linkType: hard
+
 "@babel/plugin-syntax-dynamic-import@npm:^7.8.3":
   version: 7.8.3
   resolution: "@babel/plugin-syntax-dynamic-import@npm:7.8.3"
@@ -4253,7 +4036,16 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@babel/runtime@npm:^7.0.0, @babel/runtime@npm:^7.12.5, @babel/runtime@npm:^7.13.10, @babel/runtime@npm:^7.15.4, @babel/runtime@npm:^7.16.3, @babel/runtime@npm:^7.18.3, @babel/runtime@npm:^7.18.6, @babel/runtime@npm:^7.23.8, @babel/runtime@npm:^7.23.9, @babel/runtime@npm:^7.24.5, @babel/runtime@npm:^7.26.10, @babel/runtime@npm:^7.28.4, @babel/runtime@npm:^7.28.6, @babel/runtime@npm:^7.5.5, @babel/runtime@npm:^7.7.6, @babel/runtime@npm:^7.8.7, @babel/runtime@npm:^7.9.2":
+"@babel/runtime-corejs3@npm:^7.26.0":
+  version: 7.29.7
+  resolution: "@babel/runtime-corejs3@npm:7.29.7"
+  dependencies:
+    core-js-pure: "npm:^3.48.0"
+  checksum: 10c0/3ea24ca1b0d92a3421afab2078e1ff21ea8a8d872f9bcd56b21145eec44f123b4e629e89e47bae2301fa12e22411150dc42a71fd29ec687b97001069867cfd6d
+  languageName: node
+  linkType: hard
+
+"@babel/runtime@npm:^7.0.0, @babel/runtime@npm:^7.12.5, @babel/runtime@npm:^7.13.10, @babel/runtime@npm:^7.15.4, @babel/runtime@npm:^7.16.3, @babel/runtime@npm:^7.18.3, @babel/runtime@npm:^7.18.6, @babel/runtime@npm:^7.23.8, @babel/runtime@npm:^7.23.9, @babel/runtime@npm:^7.24.5, @babel/runtime@npm:^7.26.0, @babel/runtime@npm:^7.26.10, @babel/runtime@npm:^7.28.4, @babel/runtime@npm:^7.28.6, @babel/runtime@npm:^7.5.5, @babel/runtime@npm:^7.7.6, @babel/runtime@npm:^7.8.7, @babel/runtime@npm:^7.9.2":
   version: 7.29.7
   resolution: "@babel/runtime@npm:7.29.7"
   checksum: 10c0/ca11572f7146b21e0bde6a9ed4bb6a89eafbee5f0944c7eb54d0d8a2dac962c33638a1d611e14faa71dfbb92b4b5f9236232208568a6b7d5c6f3f39ddb91771e
@@ -4278,6 +4070,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/template@npm:^8.0.0":
+  version: 8.0.0
+  resolution: "@babel/template@npm:8.0.0"
+  dependencies:
+    "@babel/code-frame": "npm:^8.0.0"
+    "@babel/parser": "npm:^8.0.0"
+    "@babel/types": "npm:^8.0.0"
+  checksum: 10c0/8a5e5687299517cc6b0efff3a6342cf4c4256aeeffa14753cc8d08106aaf0ba1916707c0e1f385b511a7b42c6c87806fecaecd4fe06316207475e0d4d1148e2c
+  languageName: node
+  linkType: hard
+
 "@babel/traverse@npm:^7.22.8, @babel/traverse@npm:^7.26.10, @babel/traverse@npm:^7.26.4, @babel/traverse@npm:^7.27.1, @babel/traverse@npm:^7.28.0, @babel/traverse@npm:^7.28.3, @babel/traverse@npm:^7.28.4, @babel/traverse@npm:^7.28.5, @babel/traverse@npm:^7.29.0, @babel/traverse@npm:^7.29.7":
   version: 7.29.7
   resolution: "@babel/traverse@npm:7.29.7"
@@ -4293,6 +4096,21 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@babel/traverse@npm:^8.0.0":
+  version: 8.0.4
+  resolution: "@babel/traverse@npm:8.0.4"
+  dependencies:
+    "@babel/code-frame": "npm:^8.0.0"
+    "@babel/generator": "npm:^8.0.0"
+    "@babel/helper-globals": "npm:^8.0.0"
+    "@babel/parser": "npm:^8.0.4"
+    "@babel/template": "npm:^8.0.0"
+    "@babel/types": "npm:^8.0.4"
+    obug: "npm:^2.1.1"
+  checksum: 10c0/0b7917580320c10027f660c97b754f883d11430bd4c9f877b1f57f424f31fd5a1e7260170be08f0197cbcf8abe65078063864e358cf024c90b64504837f3112e
+  languageName: node
+  linkType: hard
+
 "@babel/types@npm:^7.0.0, @babel/types@npm:^7.18.13, @babel/types@npm:^7.20.7, @babel/types@npm:^7.21.3, @babel/types@npm:^7.22.5, @babel/types@npm:^7.25.6, @babel/types@npm:^7.26.0, @babel/types@npm:^7.26.10, @babel/types@npm:^7.26.3, @babel/types@npm:^7.27.1, @babel/types@npm:^7.27.3, @babel/types@npm:^7.28.2, @babel/types@npm:^7.28.5, @babel/types@npm:^7.29.0, @babel/types@npm:^7.29.7, @babel/types@npm:^7.4.4":
   version: 7.29.7
   resolution: "@babel/types@npm:7.29.7"
@@ -4303,13 +4121,13 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@babel/types@npm:^8.0.0-rc.4":
-  version: 8.0.0-rc.4
-  resolution: "@babel/types@npm:8.0.0-rc.4"
+"@babel/types@npm:^8.0.0, @babel/types@npm:^8.0.0-rc.4, @babel/types@npm:^8.0.4":
+  version: 8.0.4
+  resolution: "@babel/types@npm:8.0.4"
   dependencies:
-    "@babel/helper-string-parser": "npm:^8.0.0-rc.4"
-    "@babel/helper-validator-identifier": "npm:^8.0.0-rc.4"
-  checksum: 10c0/fd6ba6dcebe79c3f79273da371ec7a5f479a310342f046126f54839b951b00816e1cad8ccefd326ef7cbd62b96ca49f7805c4351904b83e7388f122ff0bb7512
+    "@babel/helper-string-parser": "npm:^8.0.0"
+    "@babel/helper-validator-identifier": "npm:^8.0.4"
+  checksum: 10c0/c1549372b5544a797c9dd3cfba27c17e0c986cfadb1c4a99246743073e3be99c7c671572326be1739b313a2194e3bfe5a74b1bd213d80c4bbc2c520c8cb4ff1f
   languageName: node
   linkType: hard
 
@@ -4549,6 +4367,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@cfworker/json-schema@npm:^4.1.1":
+  version: 4.1.1
+  resolution: "@cfworker/json-schema@npm:4.1.1"
+  checksum: 10c0/b5253486d346b7de6feec9c73954f612b11019dacb9023d710a5666df2f5fc145dd88b6b913c88726c6d97e2e258a515fa2cab177f58b18da6bac3738cbc4739
+  languageName: node
+  linkType: hard
+
 "@chainsafe/as-chacha20poly1305@npm:^0.1.0":
   version: 0.1.0
   resolution: "@chainsafe/as-chacha20poly1305@npm:0.1.0"
@@ -5278,6 +5103,18 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@durable-streams/client@npm:^0.2.6":
+  version: 0.2.6
+  resolution: "@durable-streams/client@npm:0.2.6"
+  dependencies:
+    "@microsoft/fetch-event-source": "npm:^2.0.1"
+    fastq: "npm:^1.19.1"
+  bin:
+    intent: bin/intent.js
+  checksum: 10c0/c06682ddcf4ac6423302e0d656946cece00a1829b5654f146fde379de98cbebe8eee7437786517094c8c6ffda8f99db4998998da70f98b3b3587a6d80b48a319
+  languageName: node
+  linkType: hard
+
 "@e2b/code-interpreter@npm:2.6.1":
   version: 2.6.1
   resolution: "@e2b/code-interpreter@npm:2.6.1"
@@ -5287,6 +5124,40 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@earendil-works/pi-agent-core@npm:^0.83.0":
+  version: 0.83.0
+  resolution: "@earendil-works/pi-agent-core@npm:0.83.0"
+  dependencies:
+    "@earendil-works/pi-ai": "npm:^0.83.0"
+    diff: "npm:8.0.4"
+    ignore: "npm:7.0.5"
+    typebox: "npm:1.3.7"
+    yaml: "npm:2.9.0"
+  checksum: 10c0/7f71c37779c3a18fd8418647011932f2d37407b05cdf62e488d1f689ca5295b4455c4b015c85bfaca7aa286172a074884b05e1ca31dfed2a174ae40033696ea6
+  languageName: node
+  linkType: hard
+
+"@earendil-works/pi-ai@npm:0.83.0, @earendil-works/pi-ai@npm:^0.83.0":
+  version: 0.83.0
+  resolution: "@earendil-works/pi-ai@npm:0.83.0"
+  dependencies:
+    "@anthropic-ai/sdk": "npm:0.91.1"
+    "@aws-sdk/client-bedrock-runtime": "npm:3.1048.0"
+    "@google/genai": "npm:1.52.0"
+    "@mistralai/mistralai": "npm:2.2.6"
+    "@opentelemetry/api": "npm:1.9.0"
+    "@smithy/node-http-handler": "npm:4.7.3"
+    http-proxy-agent: "npm:7.0.2"
+    https-proxy-agent: "npm:7.0.6"
+    openai: "npm:6.26.0"
+    partial-json: "npm:0.1.7"
+    typebox: "npm:1.3.7"
+  bin:
+    pi-ai: dist/cli.js
+  checksum: 10c0/7c93d7e591e1642ab3ab9a9267a89b76cadea145c39d204c463dd25b614b81f092c9c256072c550718377010eef62918c64f2bdf3e7649a9f159ddc6529b6969
+  languageName: node
+  linkType: hard
+
 "@effect/cluster@npm:0.50.6":
   version: 0.50.6
   resolution: "@effect/cluster@npm:0.50.6"
@@ -5727,9 +5598,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/aix-ppc64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/aix-ppc64@npm:0.28.1"
+"@esbuild/aix-ppc64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/aix-ppc64@npm:0.28.2"
   conditions: os=aix & cpu=ppc64
   languageName: node
   linkType: hard
@@ -5748,9 +5619,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/android-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/android-arm64@npm:0.28.1"
+"@esbuild/android-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/android-arm64@npm:0.28.2"
   conditions: os=android & cpu=arm64
   languageName: node
   linkType: hard
@@ -5769,9 +5640,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/android-arm@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/android-arm@npm:0.28.1"
+"@esbuild/android-arm@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/android-arm@npm:0.28.2"
   conditions: os=android & cpu=arm
   languageName: node
   linkType: hard
@@ -5790,9 +5661,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/android-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/android-x64@npm:0.28.1"
+"@esbuild/android-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/android-x64@npm:0.28.2"
   conditions: os=android & cpu=x64
   languageName: node
   linkType: hard
@@ -5811,9 +5682,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/darwin-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/darwin-arm64@npm:0.28.1"
+"@esbuild/darwin-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/darwin-arm64@npm:0.28.2"
   conditions: os=darwin & cpu=arm64
   languageName: node
   linkType: hard
@@ -5832,9 +5703,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/darwin-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/darwin-x64@npm:0.28.1"
+"@esbuild/darwin-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/darwin-x64@npm:0.28.2"
   conditions: os=darwin & cpu=x64
   languageName: node
   linkType: hard
@@ -5853,9 +5724,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/freebsd-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/freebsd-arm64@npm:0.28.1"
+"@esbuild/freebsd-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/freebsd-arm64@npm:0.28.2"
   conditions: os=freebsd & cpu=arm64
   languageName: node
   linkType: hard
@@ -5874,9 +5745,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/freebsd-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/freebsd-x64@npm:0.28.1"
+"@esbuild/freebsd-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/freebsd-x64@npm:0.28.2"
   conditions: os=freebsd & cpu=x64
   languageName: node
   linkType: hard
@@ -5895,9 +5766,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-arm64@npm:0.28.1"
+"@esbuild/linux-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-arm64@npm:0.28.2"
   conditions: os=linux & cpu=arm64
   languageName: node
   linkType: hard
@@ -5916,9 +5787,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-arm@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-arm@npm:0.28.1"
+"@esbuild/linux-arm@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-arm@npm:0.28.2"
   conditions: os=linux & cpu=arm
   languageName: node
   linkType: hard
@@ -5937,9 +5808,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-ia32@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-ia32@npm:0.28.1"
+"@esbuild/linux-ia32@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-ia32@npm:0.28.2"
   conditions: os=linux & cpu=ia32
   languageName: node
   linkType: hard
@@ -5958,9 +5829,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-loong64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-loong64@npm:0.28.1"
+"@esbuild/linux-loong64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-loong64@npm:0.28.2"
   conditions: os=linux & cpu=loong64
   languageName: node
   linkType: hard
@@ -5979,9 +5850,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-mips64el@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-mips64el@npm:0.28.1"
+"@esbuild/linux-mips64el@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-mips64el@npm:0.28.2"
   conditions: os=linux & cpu=mips64el
   languageName: node
   linkType: hard
@@ -6000,9 +5871,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-ppc64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-ppc64@npm:0.28.1"
+"@esbuild/linux-ppc64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-ppc64@npm:0.28.2"
   conditions: os=linux & cpu=ppc64
   languageName: node
   linkType: hard
@@ -6021,9 +5892,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-riscv64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-riscv64@npm:0.28.1"
+"@esbuild/linux-riscv64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-riscv64@npm:0.28.2"
   conditions: os=linux & cpu=riscv64
   languageName: node
   linkType: hard
@@ -6042,9 +5913,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-s390x@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-s390x@npm:0.28.1"
+"@esbuild/linux-s390x@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-s390x@npm:0.28.2"
   conditions: os=linux & cpu=s390x
   languageName: node
   linkType: hard
@@ -6063,9 +5934,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/linux-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/linux-x64@npm:0.28.1"
+"@esbuild/linux-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/linux-x64@npm:0.28.2"
   conditions: os=linux & cpu=x64
   languageName: node
   linkType: hard
@@ -6084,9 +5955,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/netbsd-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/netbsd-arm64@npm:0.28.1"
+"@esbuild/netbsd-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/netbsd-arm64@npm:0.28.2"
   conditions: os=netbsd & cpu=arm64
   languageName: node
   linkType: hard
@@ -6105,9 +5976,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/netbsd-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/netbsd-x64@npm:0.28.1"
+"@esbuild/netbsd-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/netbsd-x64@npm:0.28.2"
   conditions: os=netbsd & cpu=x64
   languageName: node
   linkType: hard
@@ -6126,9 +5997,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/openbsd-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/openbsd-arm64@npm:0.28.1"
+"@esbuild/openbsd-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/openbsd-arm64@npm:0.28.2"
   conditions: os=openbsd & cpu=arm64
   languageName: node
   linkType: hard
@@ -6147,9 +6018,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/openbsd-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/openbsd-x64@npm:0.28.1"
+"@esbuild/openbsd-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/openbsd-x64@npm:0.28.2"
   conditions: os=openbsd & cpu=x64
   languageName: node
   linkType: hard
@@ -6168,9 +6039,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/openharmony-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/openharmony-arm64@npm:0.28.1"
+"@esbuild/openharmony-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/openharmony-arm64@npm:0.28.2"
   conditions: os=openharmony & cpu=arm64
   languageName: node
   linkType: hard
@@ -6189,9 +6060,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/sunos-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/sunos-x64@npm:0.28.1"
+"@esbuild/sunos-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/sunos-x64@npm:0.28.2"
   conditions: os=sunos & cpu=x64
   languageName: node
   linkType: hard
@@ -6210,9 +6081,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/win32-arm64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/win32-arm64@npm:0.28.1"
+"@esbuild/win32-arm64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/win32-arm64@npm:0.28.2"
   conditions: os=win32 & cpu=arm64
   languageName: node
   linkType: hard
@@ -6231,9 +6102,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/win32-ia32@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/win32-ia32@npm:0.28.1"
+"@esbuild/win32-ia32@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/win32-ia32@npm:0.28.2"
   conditions: os=win32 & cpu=ia32
   languageName: node
   linkType: hard
@@ -6252,9 +6123,9 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@esbuild/win32-x64@npm:0.28.1":
-  version: 0.28.1
-  resolution: "@esbuild/win32-x64@npm:0.28.1"
+"@esbuild/win32-x64@npm:0.28.2":
+  version: 0.28.2
+  resolution: "@esbuild/win32-x64@npm:0.28.2"
   conditions: os=win32 & cpu=x64
   languageName: node
   linkType: hard
@@ -6636,6 +6507,58 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@flue/react@npm:2.0.3":
+  version: 2.0.3
+  resolution: "@flue/react@npm:2.0.3"
+  peerDependencies:
+    "@flue/sdk": 2.0.3
+    react: ">=18"
+  checksum: 10c0/7da13d93502d6f5141d8c934e164c25267d6b6cd9e83c9fc6a32cfa5bb0031de1519893b65ccf7d5766406387561e12123afbcc9212f49a04e245964e1231423
+  languageName: node
+  linkType: hard
+
+"@flue/runtime@npm:2.0.3":
+  version: 2.0.3
+  resolution: "@flue/runtime@npm:2.0.3"
+  dependencies:
+    "@earendil-works/pi-agent-core": "npm:^0.83.0"
+    "@earendil-works/pi-ai": "npm:^0.83.0"
+    "@hono/node-server": "npm:^2.0.3"
+    "@modelcontextprotocol/client": "npm:2.0.0"
+    "@valibot/to-json-schema": "npm:^1.3.0"
+    hono: "npm:^4.8.3"
+    js-yaml: "npm:^5.2.1"
+    ulidx: "npm:^2.4.1"
+    valibot: "npm:^1.1.0"
+  checksum: 10c0/9e9b2787599e377c1148e87a23647b3ac334666c0f8ffb335bbb2ee1d86be2a4ec2067b3476ce4abe606347e655009f9e23638a1bf413d64b53cf98b85549910
+  languageName: node
+  linkType: hard
+
+"@flue/sdk@npm:2.0.3":
+  version: 2.0.3
+  resolution: "@flue/sdk@npm:2.0.3"
+  dependencies:
+    "@durable-streams/client": "npm:^0.2.6"
+  checksum: 10c0/3c95c3d8a4caff66c54065e13d3188ea0a18897a64d07dd362e13d008fb41280ac51b46561d582d1f034b2f86a35810d7a59d30bb34b3817abcda5994761f694
+  languageName: node
+  linkType: hard
+
+"@flue/vite@npm:2.0.3":
+  version: 2.0.3
+  resolution: "@flue/vite@npm:2.0.3"
+  dependencies:
+    "@flue/runtime": "npm:2.0.3"
+    "@hono/node-server": "npm:^2.0.3"
+    agents: "npm:^0.20.1"
+    magic-string: "npm:^1.0.0"
+    tinyglobby: "npm:^0.2.15"
+    ulidx: "npm:^2.4.1"
+  peerDependencies:
+    vite: ^8.0.0
+  checksum: 10c0/6594344a2dd2e6b4a726069c4b0d8319166c1e162c53bba3c4b0d74ea8ebd728440f8bdd51e2655ed79321fd5aef04096a0c9d6a9613bc3a6237cfc4006e9f95
+  languageName: node
+  linkType: hard
+
 "@fontsource-variable/geist-mono@npm:5.2.7":
   version: 5.2.7
   resolution: "@fontsource-variable/geist-mono@npm:5.2.7"
@@ -6769,6 +6692,23 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@google/genai@npm:1.52.0":
+  version: 1.52.0
+  resolution: "@google/genai@npm:1.52.0"
+  dependencies:
+    google-auth-library: "npm:^10.3.0"
+    p-retry: "npm:^4.6.2"
+    protobufjs: "npm:^7.5.4"
+    ws: "npm:^8.18.0"
+  peerDependencies:
+    "@modelcontextprotocol/sdk": ^1.25.2
+  peerDependenciesMeta:
+    "@modelcontextprotocol/sdk":
+      optional: true
+  checksum: 10c0/2d22f6bd4baa915a402289dae4797410acbd5c5add1ed0c8d1bedef3ac7871fe1f04640d0612aa793fe7055f086719487491f55474a5b21597addfdea8631fa6
+  languageName: node
+  linkType: hard
+
 "@google/genai@npm:2.6.0":
   version: 2.6.0
   resolution: "@google/genai@npm:2.6.0"
@@ -7595,6 +7535,70 @@ __metadata:
   languageName: unknown
   linkType: soft
 
+"@hashintel/brunch-agent-binding-flue@workspace:*, @hashintel/brunch-agent-binding-flue@workspace:libs/@hashintel/brunch-agent/packages/binding-flue":
+  version: 0.0.0-use.local
+  resolution: "@hashintel/brunch-agent-binding-flue@workspace:libs/@hashintel/brunch-agent/packages/binding-flue"
+  dependencies:
+    "@flue/runtime": "npm:2.0.3"
+    "@flue/sdk": "npm:2.0.3"
+    "@hashintel/brunch-agent": "workspace:*"
+    "@types/node": "npm:22.18.13"
+    "@typescript/native-preview": "npm:7.0.0-dev.20260511.1"
+    oxlint: "npm:1.63.0"
+    oxlint-tsgolint: "npm:0.22.1"
+    valibot: "npm:1.4.2"
+    vite: "npm:8.1.0"
+    vitest: "npm:4.1.10"
+  languageName: unknown
+  linkType: soft
+
+"@hashintel/brunch-agent-plugin-gherkin@workspace:*, @hashintel/brunch-agent-plugin-gherkin@workspace:libs/@hashintel/brunch-agent/packages/plugin-gherkin":
+  version: 0.0.0-use.local
+  resolution: "@hashintel/brunch-agent-plugin-gherkin@workspace:libs/@hashintel/brunch-agent/packages/plugin-gherkin"
+  dependencies:
+    "@hashintel/brunch-agent": "workspace:*"
+    "@types/node": "npm:22.18.13"
+    "@typescript/native-preview": "npm:7.0.0-dev.20260511.1"
+    oxlint: "npm:1.63.0"
+    oxlint-tsgolint: "npm:0.22.1"
+    valibot: "npm:1.4.2"
+    vite: "npm:8.1.0"
+    vitest: "npm:4.1.10"
+  languageName: unknown
+  linkType: soft
+
+"@hashintel/brunch-agent-transport-aisdk@workspace:*, @hashintel/brunch-agent-transport-aisdk@workspace:libs/@hashintel/brunch-agent/packages/transport-aisdk":
+  version: 0.0.0-use.local
+  resolution: "@hashintel/brunch-agent-transport-aisdk@workspace:libs/@hashintel/brunch-agent/packages/transport-aisdk"
+  dependencies:
+    "@hashintel/brunch-agent": "workspace:*"
+    "@types/node": "npm:22.18.13"
+    "@typescript/native-preview": "npm:7.0.0-dev.20260511.1"
+    ai: "npm:6.0.182"
+    oxlint: "npm:1.63.0"
+    oxlint-tsgolint: "npm:0.22.1"
+    valibot: "npm:1.4.2"
+    vite: "npm:8.1.0"
+    vitest: "npm:4.1.10"
+  languageName: unknown
+  linkType: soft
+
+"@hashintel/brunch-agent@workspace:*, @hashintel/brunch-agent@workspace:libs/@hashintel/brunch-agent/packages/core":
+  version: 0.0.0-use.local
+  resolution: "@hashintel/brunch-agent@workspace:libs/@hashintel/brunch-agent/packages/core"
+  dependencies:
+    "@anthropic-ai/sdk": "npm:0.74.0"
+    "@types/node": "npm:22.18.13"
+    "@typescript/native-preview": "npm:7.0.0-dev.20260511.1"
+    fast-check: "npm:4.9.0"
+    oxlint: "npm:1.63.0"
+    oxlint-tsgolint: "npm:0.22.1"
+    valibot: "npm:1.4.2"
+    vite: "npm:8.1.0"
+    vitest: "npm:4.1.10"
+  languageName: unknown
+  linkType: soft
+
 "@hashintel/design-system@workspace:*, @hashintel/design-system@workspace:libs/@hashintel/design-system":
   version: 0.0.0-use.local
   resolution: "@hashintel/design-system@workspace:libs/@hashintel/design-system"
@@ -7907,6 +7911,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@hono/node-server@npm:^2.0.3":
+  version: 2.1.1
+  resolution: "@hono/node-server@npm:2.1.1"
+  peerDependencies:
+    hono: ^4
+  checksum: 10c0/7ef810ca647c56d8d9386fd81609e18443b3a5634aa5ecabdf357e7ca724613c535e863c15ded9b7ae89b935a073040fb11e6d59041f3b1c3e153d8ecb699880
+  languageName: node
+  linkType: hard
+
 "@humanfs/core@npm:^0.19.1":
   version: 0.19.1
   resolution: "@humanfs/core@npm:0.19.1"
@@ -9981,6 +9994,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@microsoft/fetch-event-source@npm:^2.0.1":
+  version: 2.0.1
+  resolution: "@microsoft/fetch-event-source@npm:2.0.1"
+  checksum: 10c0/38c69e9b9990e6cee715c7bbfa2752f943b42575acadb36facf19bb831f1520c469f854277439154258e0e1dc8650cc85038230d1f451e3f6b62e8faeaa1126c
+  languageName: node
+  linkType: hard
+
 "@microsoft/tsdoc-config@npm:0.18.1, @microsoft/tsdoc-config@npm:~0.18.1":
   version: 0.18.1
   resolution: "@microsoft/tsdoc-config@npm:0.18.1"
@@ -10000,6 +10020,47 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@mistralai/mistralai@npm:2.2.6":
+  version: 2.2.6
+  resolution: "@mistralai/mistralai@npm:2.2.6"
+  dependencies:
+    "@opentelemetry/semantic-conventions": "npm:^1.40.0"
+    ws: "npm:^8.18.0"
+    zod: "npm:^3.25.0 || ^4.0.0"
+    zod-to-json-schema: "npm:^3.25.0"
+  peerDependencies:
+    "@opentelemetry/api": ^1.9.0
+  peerDependenciesMeta:
+    "@opentelemetry/api":
+      optional: true
+  checksum: 10c0/056efabcbb8a6dc0d14a529fef92d021df0f6e485f2ef9786fbfd95a5c70f1359d1b4eb0aee727ad6e76195a0d158808d97d68a367431226db788f8c6863369d
+  languageName: node
+  linkType: hard
+
+"@modelcontextprotocol/client@npm:2.0.0":
+  version: 2.0.0
+  resolution: "@modelcontextprotocol/client@npm:2.0.0"
+  dependencies:
+    "@modelcontextprotocol/core": "npm:2.0.0"
+    cross-spawn: "npm:^7.0.5"
+    eventsource: "npm:^3.0.2"
+    eventsource-parser: "npm:^3.0.0"
+    jose: "npm:^6.1.3"
+    pkce-challenge: "npm:^5.0.0"
+    zod: "npm:^4.2.0"
+  checksum: 10c0/23d1d16539c76a69d1848dc67c495b3aa6d048946dd894ed449bca0de7ce9835a71904476c6eeb9f75fe8dfca1964c61372d9d7d283b7cabfa3258d288db6859
+  languageName: node
+  linkType: hard
+
+"@modelcontextprotocol/core@npm:2.0.0":
+  version: 2.0.0
+  resolution: "@modelcontextprotocol/core@npm:2.0.0"
+  dependencies:
+    zod: "npm:^4.2.0"
+  checksum: 10c0/1cb96fcebfb60651775bcaa3b1e92b47b9317239e9e0352a2d6a404f77d1abfb68ce5b462becd073cddc4db08f2f0024cd3c7dd2582e3463ddb958f65b73fbe3
+  languageName: node
+  linkType: hard
+
 "@modelcontextprotocol/sdk@npm:^1.29.0":
   version: 1.29.0
   resolution: "@modelcontextprotocol/sdk@npm:1.29.0"
@@ -10778,6 +10839,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@opentelemetry/api@npm:1.9.0":
+  version: 1.9.0
+  resolution: "@opentelemetry/api@npm:1.9.0"
+  checksum: 10c0/9aae2fe6e8a3a3eeb6c1fdef78e1939cf05a0f37f8a4fae4d6bf2e09eb1e06f966ece85805626e01ba5fab48072b94f19b835449e58b6d26720ee19a58298add
+  languageName: node
+  linkType: hard
+
 "@opentelemetry/api@npm:1.9.1, @opentelemetry/api@npm:^1.3.0, @opentelemetry/api@npm:^1.9.0, @opentelemetry/api@npm:^1.9.1":
   version: 1.9.1
   resolution: "@opentelemetry/api@npm:1.9.1"
@@ -11078,10 +11146,10 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@opentelemetry/semantic-conventions@npm:^1.24.0, @opentelemetry/semantic-conventions@npm:^1.27.0, @opentelemetry/semantic-conventions@npm:^1.29.0":
-  version: 1.41.1
-  resolution: "@opentelemetry/semantic-conventions@npm:1.41.1"
-  checksum: 10c0/c54b1edf845766e93026d30fd95e15da9dba8d7a5b58f8c320c5d36ab542c77b37868f3e8e3d78ec162da8ee2afd24781f0a65934c9bdbc1aea86b47b12f074c
+"@opentelemetry/semantic-conventions@npm:^1.24.0, @opentelemetry/semantic-conventions@npm:^1.27.0, @opentelemetry/semantic-conventions@npm:^1.29.0, @opentelemetry/semantic-conventions@npm:^1.40.0":
+  version: 1.43.0
+  resolution: "@opentelemetry/semantic-conventions@npm:1.43.0"
+  checksum: 10c0/ea4b4b07c9414b0c5e7ce7349f608cb2572d16922d96077fb0882b59f173ec9b94aada74896bd5dd4aeb1759924503bd5a34b6dc2847a84c36f71626a0578ec4
   languageName: node
   linkType: hard
 
@@ -13973,6 +14041,28 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@rolldown/plugin-babel@npm:^0.2.3":
+  version: 0.2.3
+  resolution: "@rolldown/plugin-babel@npm:0.2.3"
+  dependencies:
+    picomatch: "npm:^4.0.4"
+  peerDependencies:
+    "@babel/core": ^7.29.0 || ^8.0.0-rc.1
+    "@babel/plugin-transform-runtime": ^7.29.0 || ^8.0.0-rc.1
+    "@babel/runtime": ^7.27.0 || ^8.0.0-rc.1
+    rolldown: ^1.0.0-rc.5
+    vite: ^8.0.0
+  peerDependenciesMeta:
+    "@babel/plugin-transform-runtime":
+      optional: true
+    "@babel/runtime":
+      optional: true
+    vite:
+      optional: true
+  checksum: 10c0/84afe9854137b576f963f4fd11080dc0b8afe6243d565513d33ddfed9ea9149652110def881a3911b5e889f5fa505df036c6839f4d0fd01d4222297d7f2baa21
+  languageName: node
+  linkType: hard
+
 "@rolldown/pluginutils@npm:1.0.0-beta.27":
   version: 1.0.0-beta.27
   resolution: "@rolldown/pluginutils@npm:1.0.0-beta.27"
@@ -15636,7 +15726,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/config-resolver@npm:^4.3.2, @smithy/config-resolver@npm:^4.4.6":
+"@smithy/config-resolver@npm:^4.4.6":
   version: 4.4.6
   resolution: "@smithy/config-resolver@npm:4.4.6"
   dependencies:
@@ -15650,25 +15740,24 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/core@npm:^3.16.1, @smithy/core@npm:^3.22.1, @smithy/core@npm:^3.24.3, @smithy/core@npm:^3.24.5":
-  version: 3.24.5
-  resolution: "@smithy/core@npm:3.24.5"
+"@smithy/core@npm:^3.22.1, @smithy/core@npm:^3.24.2, @smithy/core@npm:^3.24.3, @smithy/core@npm:^3.24.5, @smithy/core@npm:^3.31.1, @smithy/core@npm:^3.32.0, @smithy/core@npm:^3.33.0":
+  version: 3.33.0
+  resolution: "@smithy/core@npm:3.33.0"
   dependencies:
-    "@aws-crypto/crc32": "npm:5.2.0"
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/types": "npm:^4.17.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/53cb81211eb58b7c28517ff3e423178e32cbe2f20c79f33ad511041d897d06671c3fe222124abc432db7bbeaac737f1894b346852f5d5fce01677302d3aaf117
+  checksum: 10c0/d640655fa8f0703cfff739c6fecf88a4c8116faca22197b27eaa47805c8e7360cdfc18ee8e7e02a355207f57afd8d398141f51a88f3a6c80e615c50deea1841d
   languageName: node
   linkType: hard
 
-"@smithy/credential-provider-imds@npm:^4.2.2, @smithy/credential-provider-imds@npm:^4.2.8, @smithy/credential-provider-imds@npm:^4.3.2":
-  version: 4.3.5
-  resolution: "@smithy/credential-provider-imds@npm:4.3.5"
+"@smithy/credential-provider-imds@npm:^4.2.8, @smithy/credential-provider-imds@npm:^4.3.2, @smithy/credential-provider-imds@npm:^4.4.16":
+  version: 4.5.0
+  resolution: "@smithy/credential-provider-imds@npm:4.5.0"
   dependencies:
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/core": "npm:^3.32.0"
+    "@smithy/types": "npm:^4.17.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/8959dab1ac45640860e477efc4f15080771320c3180463c392c9929d55544d0833cee34ae7b2b9a1d591805e750846fdaf39d8861b5a4e38712089dbc0f888cb
+  checksum: 10c0/b639b737fe6a03f5c0bc8e95301a041f9ec3df9d2adc55e59a8079e73da0e8865511bb67f9f052e492a3413a84acd02b6ba1b34972e886c3311ee3bd77afbfdb
   languageName: node
   linkType: hard
 
@@ -15684,7 +15773,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/eventstream-codec@npm:^4.2.2, @smithy/eventstream-codec@npm:^4.2.8":
+"@smithy/eventstream-codec@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/eventstream-codec@npm:4.2.8"
   dependencies:
@@ -15696,7 +15785,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/eventstream-serde-browser@npm:^4.2.2, @smithy/eventstream-serde-browser@npm:^4.2.8":
+"@smithy/eventstream-serde-browser@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/eventstream-serde-browser@npm:4.2.8"
   dependencies:
@@ -15707,7 +15796,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/eventstream-serde-config-resolver@npm:^4.3.2, @smithy/eventstream-serde-config-resolver@npm:^4.3.8":
+"@smithy/eventstream-serde-config-resolver@npm:^4.3.8":
   version: 4.3.8
   resolution: "@smithy/eventstream-serde-config-resolver@npm:4.3.8"
   dependencies:
@@ -15728,7 +15817,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/eventstream-serde-node@npm:^4.2.2, @smithy/eventstream-serde-node@npm:^4.2.8":
+"@smithy/eventstream-serde-node@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/eventstream-serde-node@npm:4.2.8"
   dependencies:
@@ -15774,14 +15863,14 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/fetch-http-handler@npm:^5.0.4, @smithy/fetch-http-handler@npm:^5.3.3, @smithy/fetch-http-handler@npm:^5.3.9, @smithy/fetch-http-handler@npm:^5.4.3, @smithy/fetch-http-handler@npm:^5.4.5":
-  version: 5.4.5
-  resolution: "@smithy/fetch-http-handler@npm:5.4.5"
+"@smithy/fetch-http-handler@npm:^5.0.4, @smithy/fetch-http-handler@npm:^5.3.9, @smithy/fetch-http-handler@npm:^5.4.2, @smithy/fetch-http-handler@npm:^5.4.3, @smithy/fetch-http-handler@npm:^5.6.13":
+  version: 5.7.0
+  resolution: "@smithy/fetch-http-handler@npm:5.7.0"
   dependencies:
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/core": "npm:^3.32.0"
+    "@smithy/types": "npm:^4.17.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/b75cd641e6ca78fa89d8659e201d9dbdbbdaec59f5abc4a3cc4b6b6e56345b61e370647a4bccd3830a3b2a11639d0e98aaf958e9cacd88353d24bea648341a3e
+  checksum: 10c0/2384d4f000855c8f1b097f959136820da1f133bf5c73883d2365c295776b0142f5bc3660721ee66e99d2c6a1ccce93158ee2c42f5983cf9f00d86ccab8c5dd0b
   languageName: node
   linkType: hard
 
@@ -15797,7 +15886,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/hash-node@npm:^4.2.2, @smithy/hash-node@npm:^4.2.8":
+"@smithy/hash-node@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/hash-node@npm:4.2.8"
   dependencies:
@@ -15820,7 +15909,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/invalid-dependency@npm:^4.2.2, @smithy/invalid-dependency@npm:^4.2.8":
+"@smithy/invalid-dependency@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/invalid-dependency@npm:4.2.8"
   dependencies:
@@ -15868,7 +15957,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/middleware-content-length@npm:^4.2.2, @smithy/middleware-content-length@npm:^4.2.8":
+"@smithy/middleware-content-length@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/middleware-content-length@npm:4.2.8"
   dependencies:
@@ -15894,7 +15983,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/middleware-endpoint@npm:^4.3.3, @smithy/middleware-endpoint@npm:^4.4.13":
+"@smithy/middleware-endpoint@npm:^4.4.13":
   version: 4.4.13
   resolution: "@smithy/middleware-endpoint@npm:4.4.13"
   dependencies:
@@ -15910,7 +15999,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/middleware-retry@npm:^4.4.3, @smithy/middleware-retry@npm:^4.4.30":
+"@smithy/middleware-retry@npm:^4.4.30":
   version: 4.4.30
   resolution: "@smithy/middleware-retry@npm:4.4.30"
   dependencies:
@@ -15937,7 +16026,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/middleware-serde@npm:^4.2.2, @smithy/middleware-serde@npm:^4.2.9":
+"@smithy/middleware-serde@npm:^4.2.9":
   version: 4.2.9
   resolution: "@smithy/middleware-serde@npm:4.2.9"
   dependencies:
@@ -15958,7 +16047,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/middleware-stack@npm:^4.2.2, @smithy/middleware-stack@npm:^4.2.8":
+"@smithy/middleware-stack@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/middleware-stack@npm:4.2.8"
   dependencies:
@@ -15980,7 +16069,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/node-config-provider@npm:^4.3.2, @smithy/node-config-provider@npm:^4.3.8":
+"@smithy/node-config-provider@npm:^4.3.8":
   version: 4.3.8
   resolution: "@smithy/node-config-provider@npm:4.3.8"
   dependencies:
@@ -15992,6 +16081,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@smithy/node-http-handler@npm:4.7.3":
+  version: 4.7.3
+  resolution: "@smithy/node-http-handler@npm:4.7.3"
+  dependencies:
+    "@smithy/core": "npm:^3.24.3"
+    "@smithy/types": "npm:^4.14.2"
+    tslib: "npm:^2.6.2"
+  checksum: 10c0/805002fc7e55f48f61d15de738dcd79f7bf8fbd372157b2967a9ac7616d76b744a410cc58efd672fa9c8f1592f5a8410aff35e3bd77ea5dfc47ff7c08fe42373
+  languageName: node
+  linkType: hard
+
 "@smithy/node-http-handler@npm:^2.5.0":
   version: 2.5.0
   resolution: "@smithy/node-http-handler@npm:2.5.0"
@@ -16005,14 +16105,14 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/node-http-handler@npm:^4.4.1, @smithy/node-http-handler@npm:^4.4.9, @smithy/node-http-handler@npm:^4.7.3, @smithy/node-http-handler@npm:^4.7.5":
-  version: 4.7.5
-  resolution: "@smithy/node-http-handler@npm:4.7.5"
+"@smithy/node-http-handler@npm:^4.4.9, @smithy/node-http-handler@npm:^4.7.2, @smithy/node-http-handler@npm:^4.7.3, @smithy/node-http-handler@npm:^4.9.13":
+  version: 4.11.0
+  resolution: "@smithy/node-http-handler@npm:4.11.0"
   dependencies:
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/core": "npm:^3.33.0"
+    "@smithy/types": "npm:^4.17.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/c346cd2db2021a39f6e45d3436bafd3e4114f0bc3e81ed2da385a49bf434b9b3d336dd21df9d15c39227f23b73756a6420a2d3d49ff0f69dda73c8b4828c2c16
+  checksum: 10c0/3e496c49bb61f2948020da8f08cb2331d2678754ec2a11532dd80b90a061972d6fafc6f8908fece77b4e36c9750da6ad88c0fbff6ac8eddf0dc020bee02b0696
   languageName: node
   linkType: hard
 
@@ -16026,7 +16126,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/property-provider@npm:^4.2.2, @smithy/property-provider@npm:^4.2.8":
+"@smithy/property-provider@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/property-provider@npm:4.2.8"
   dependencies:
@@ -16056,7 +16156,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/protocol-http@npm:^5.3.2, @smithy/protocol-http@npm:^5.3.3, @smithy/protocol-http@npm:^5.3.8":
+"@smithy/protocol-http@npm:^5.3.3, @smithy/protocol-http@npm:^5.3.8":
   version: 5.3.8
   resolution: "@smithy/protocol-http@npm:5.3.8"
   dependencies:
@@ -16077,7 +16177,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/querystring-builder@npm:^4.2.2, @smithy/querystring-builder@npm:^4.2.8":
+"@smithy/querystring-builder@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/querystring-builder@npm:4.2.8"
   dependencies:
@@ -16127,7 +16227,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/shared-ini-file-loader@npm:^4.3.2, @smithy/shared-ini-file-loader@npm:^4.4.3":
+"@smithy/shared-ini-file-loader@npm:^4.4.3":
   version: 4.4.3
   resolution: "@smithy/shared-ini-file-loader@npm:4.4.3"
   dependencies:
@@ -16168,14 +16268,14 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/signature-v4@npm:^5.3.2, @smithy/signature-v4@npm:^5.3.8, @smithy/signature-v4@npm:^5.4.5":
-  version: 5.4.5
-  resolution: "@smithy/signature-v4@npm:5.4.5"
+"@smithy/signature-v4@npm:^5.3.8, @smithy/signature-v4@npm:^5.6.12":
+  version: 5.7.0
+  resolution: "@smithy/signature-v4@npm:5.7.0"
   dependencies:
-    "@smithy/core": "npm:^3.24.5"
-    "@smithy/types": "npm:^4.14.2"
+    "@smithy/core": "npm:^3.32.0"
+    "@smithy/types": "npm:^4.17.0"
     tslib: "npm:^2.6.2"
-  checksum: 10c0/cfb86297144958ee0a3928a165c8d1688e2b086ae4fa7237eb54561a851d795ea5b12684a379ceb4ce78ad9d74ef5bc534e83693bc58bde4f48bfffabfbf6050
+  checksum: 10c0/4ac74ae7f1e6f40ca153ae2adb185754871c8696bb176a0b759e275b1bc634b4d82f2e85d6bad12a1ec8efb0f26c424328f9e39ce58a5ac6c2ba7a72ed992128
   languageName: node
   linkType: hard
 
@@ -16193,7 +16293,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/smithy-client@npm:^4.11.2, @smithy/smithy-client@npm:^4.8.1":
+"@smithy/smithy-client@npm:^4.11.2":
   version: 4.11.2
   resolution: "@smithy/smithy-client@npm:4.11.2"
   dependencies:
@@ -16226,12 +16326,12 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/types@npm:^4.12.0, @smithy/types@npm:^4.14.2, @smithy/types@npm:^4.7.1, @smithy/types@npm:^4.8.0":
-  version: 4.14.2
-  resolution: "@smithy/types@npm:4.14.2"
+"@smithy/types@npm:^4.12.0, @smithy/types@npm:^4.14.1, @smithy/types@npm:^4.14.2, @smithy/types@npm:^4.16.1, @smithy/types@npm:^4.17.0, @smithy/types@npm:^4.8.0":
+  version: 4.17.0
+  resolution: "@smithy/types@npm:4.17.0"
   dependencies:
     tslib: "npm:^2.6.2"
-  checksum: 10c0/8bdad874d9e47233c6f2f74ac001e810b87b0a7c6504b9a9490536c9733ffec36b7b2a73010b31044f22553819a8d1e8bb9b2310f09257b1278a048a5f9679f8
+  checksum: 10c0/f985f116e02ad60168a4bcd97140e971ee0a83a083574a8800d3364c62c2445d1fa2314214f19d16446acda18bed9f0ee632cacdd897804c51339a5a1c9ce422
   languageName: node
   linkType: hard
 
@@ -16246,7 +16346,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/url-parser@npm:^4.2.2, @smithy/url-parser@npm:^4.2.8":
+"@smithy/url-parser@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/url-parser@npm:4.2.8"
   dependencies:
@@ -16336,7 +16436,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-defaults-mode-browser@npm:^4.3.2, @smithy/util-defaults-mode-browser@npm:^4.3.29":
+"@smithy/util-defaults-mode-browser@npm:^4.3.29":
   version: 4.3.29
   resolution: "@smithy/util-defaults-mode-browser@npm:4.3.29"
   dependencies:
@@ -16348,7 +16448,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-defaults-mode-node@npm:^4.2.3, @smithy/util-defaults-mode-node@npm:^4.2.32":
+"@smithy/util-defaults-mode-node@npm:^4.2.32":
   version: 4.2.32
   resolution: "@smithy/util-defaults-mode-node@npm:4.2.32"
   dependencies:
@@ -16363,7 +16463,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-endpoints@npm:^3.2.2, @smithy/util-endpoints@npm:^3.2.8":
+"@smithy/util-endpoints@npm:^3.2.8":
   version: 3.2.8
   resolution: "@smithy/util-endpoints@npm:3.2.8"
   dependencies:
@@ -16421,7 +16521,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-middleware@npm:^4.2.2, @smithy/util-middleware@npm:^4.2.3, @smithy/util-middleware@npm:^4.2.8":
+"@smithy/util-middleware@npm:^4.2.3, @smithy/util-middleware@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/util-middleware@npm:4.2.8"
   dependencies:
@@ -16431,7 +16531,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-retry@npm:^4.2.2, @smithy/util-retry@npm:^4.2.8":
+"@smithy/util-retry@npm:^4.2.8":
   version: 4.2.8
   resolution: "@smithy/util-retry@npm:4.2.8"
   dependencies:
@@ -16458,7 +16558,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@smithy/util-stream@npm:^4.5.11, @smithy/util-stream@npm:^4.5.2":
+"@smithy/util-stream@npm:^4.5.11":
   version: 4.5.11
   resolution: "@smithy/util-stream@npm:4.5.11"
   dependencies:
@@ -19711,6 +19811,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@valibot/to-json-schema@npm:^1.3.0":
+  version: 1.7.1
+  resolution: "@valibot/to-json-schema@npm:1.7.1"
+  peerDependencies:
+    valibot: ^1.4.0
+  checksum: 10c0/15ef472fae3229ab0dc6860325e5c6d21e724e4edbb1794ec603bc3881925bcaf5db44b30536925141758abea155b33b640129dcbb0ddfb47414cb967a6eeae1
+  languageName: node
+  linkType: hard
+
 "@vercel/edge-config-fs@npm:0.1.0":
   version: 0.1.0
   resolution: "@vercel/edge-config-fs@npm:0.1.0"
@@ -21675,6 +21784,61 @@ __metadata:
   languageName: node
   linkType: hard
 
+"agents@npm:^0.20.1":
+  version: 0.20.1
+  resolution: "agents@npm:0.20.1"
+  dependencies:
+    "@babel/plugin-proposal-decorators": "npm:^8.0.2"
+    "@cfworker/json-schema": "npm:^4.1.1"
+    "@rolldown/plugin-babel": "npm:^0.2.3"
+    cron-schedule: "npm:^6.0.0"
+    esbuild: "npm:^0.28.1"
+    mimetext: "npm:^3.0.28"
+    nanoid: "npm:^5.1.16"
+    partyserver: "npm:^0.5.8"
+    partysocket: "npm:1.3.0"
+    yaml: "npm:^2.9.0"
+    yargs: "npm:^18.0.0"
+  peerDependencies:
+    "@ai-sdk/react": ^3.0.0 || ^4.0.0
+    "@cloudflare/codemode": ">=0.5.0"
+    "@modelcontextprotocol/client": 2.0.0
+    "@modelcontextprotocol/sdk": 1.30.0
+    "@modelcontextprotocol/server": 2.0.0
+    "@tanstack/ai": ">=0.10.2 <1.0.0"
+    "@x402/core": ^2.0.0
+    "@x402/evm": ^2.0.0
+    ai: ^6.0.0 || ^7.0.0
+    chat: ^4.29.0
+    just-bash: ^3.0.0
+    react: ^19.0.0
+    vite: ">=6.0.0 <9.0.0"
+    zod: ^4.0.0
+  peerDependenciesMeta:
+    "@ai-sdk/react":
+      optional: true
+    "@cloudflare/codemode":
+      optional: true
+    "@tanstack/ai":
+      optional: true
+    "@x402/core":
+      optional: true
+    "@x402/evm":
+      optional: true
+    ai:
+      optional: true
+    chat:
+      optional: true
+    just-bash:
+      optional: true
+    vite:
+      optional: true
+  bin:
+    agents: dist/cli/index.js
+  checksum: 10c0/8f9544542f72e06b09997e484f6aa31d61b4dd54f303da3221279effbed90fc13f6a376fd5ddd49731ad59737d011a7cb95904162c3dea24a5e0ff49f0addd91
+  languageName: node
+  linkType: hard
+
 "ai@npm:6.0.182":
   version: 6.0.182
   resolution: "ai@npm:6.0.182"
@@ -24385,10 +24549,10 @@ __metadata:
   languageName: node
   linkType: hard
 
-"core-js-pure@npm:^3.23.3":
-  version: 3.39.0
-  resolution: "core-js-pure@npm:3.39.0"
-  checksum: 10c0/5d954e467703ea1e860eb070bd72cf9dc5bfddd7037c09d750f0eba3ffc4066db741a595af86dc833a709929e161a909e48da3cbdd2d9bee7795cb516dc9f7d4
+"core-js-pure@npm:^3.23.3, core-js-pure@npm:^3.48.0":
+  version: 3.50.0
+  resolution: "core-js-pure@npm:3.50.0"
+  checksum: 10c0/e882678bec8dfb1d58371b4645d77f071b9c5989478e5c74c981e553b480a49cad48255377331ec60589338069d529a222af9e4e957c0af80c1b865f8a298fb6
   languageName: node
   linkType: hard
 
@@ -24479,6 +24643,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"cron-schedule@npm:^6.0.0":
+  version: 6.0.0
+  resolution: "cron-schedule@npm:6.0.0"
+  checksum: 10c0/e3aa84a2f926dff8e74a49dd1428c7b011a94536cee13df51598a4c481e34545146d597763ed4a9a280607b8173f6b1d9105d5c568610b79505d67681b009e50
+  languageName: node
+  linkType: hard
+
 "cross-inspect@npm:1.0.1":
   version: 1.0.1
   resolution: "cross-inspect@npm:1.0.1"
@@ -25396,7 +25567,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"diff@npm:^8.0.3, diff@npm:~8.0.2":
+"diff@npm:8.0.4, diff@npm:^8.0.3, diff@npm:~8.0.2":
   version: 8.0.4
   resolution: "diff@npm:8.0.4"
   checksum: 10c0/7ee5d03926db4039be7252ac3b0abaae1bd122a2ca971e5ca7270e444e36ff83dd906fad1a719740ca347e97ed5dc8f458a76a8391dbcd7aff363bdafb348a00
@@ -26431,36 +26602,36 @@ __metadata:
   languageName: node
   linkType: hard
 
-"esbuild@npm:^0.28.0":
-  version: 0.28.1
-  resolution: "esbuild@npm:0.28.1"
-  dependencies:
-    "@esbuild/aix-ppc64": "npm:0.28.1"
-    "@esbuild/android-arm": "npm:0.28.1"
-    "@esbuild/android-arm64": "npm:0.28.1"
-    "@esbuild/android-x64": "npm:0.28.1"
-    "@esbuild/darwin-arm64": "npm:0.28.1"
-    "@esbuild/darwin-x64": "npm:0.28.1"
-    "@esbuild/freebsd-arm64": "npm:0.28.1"
-    "@esbuild/freebsd-x64": "npm:0.28.1"
-    "@esbuild/linux-arm": "npm:0.28.1"
-    "@esbuild/linux-arm64": "npm:0.28.1"
-    "@esbuild/linux-ia32": "npm:0.28.1"
-    "@esbuild/linux-loong64": "npm:0.28.1"
-    "@esbuild/linux-mips64el": "npm:0.28.1"
-    "@esbuild/linux-ppc64": "npm:0.28.1"
-    "@esbuild/linux-riscv64": "npm:0.28.1"
-    "@esbuild/linux-s390x": "npm:0.28.1"
-    "@esbuild/linux-x64": "npm:0.28.1"
-    "@esbuild/netbsd-arm64": "npm:0.28.1"
-    "@esbuild/netbsd-x64": "npm:0.28.1"
-    "@esbuild/openbsd-arm64": "npm:0.28.1"
-    "@esbuild/openbsd-x64": "npm:0.28.1"
-    "@esbuild/openharmony-arm64": "npm:0.28.1"
-    "@esbuild/sunos-x64": "npm:0.28.1"
-    "@esbuild/win32-arm64": "npm:0.28.1"
-    "@esbuild/win32-ia32": "npm:0.28.1"
-    "@esbuild/win32-x64": "npm:0.28.1"
+"esbuild@npm:^0.28.0, esbuild@npm:^0.28.1":
+  version: 0.28.2
+  resolution: "esbuild@npm:0.28.2"
+  dependencies:
+    "@esbuild/aix-ppc64": "npm:0.28.2"
+    "@esbuild/android-arm": "npm:0.28.2"
+    "@esbuild/android-arm64": "npm:0.28.2"
+    "@esbuild/android-x64": "npm:0.28.2"
+    "@esbuild/darwin-arm64": "npm:0.28.2"
+    "@esbuild/darwin-x64": "npm:0.28.2"
+    "@esbuild/freebsd-arm64": "npm:0.28.2"
+    "@esbuild/freebsd-x64": "npm:0.28.2"
+    "@esbuild/linux-arm": "npm:0.28.2"
+    "@esbuild/linux-arm64": "npm:0.28.2"
+    "@esbuild/linux-ia32": "npm:0.28.2"
+    "@esbuild/linux-loong64": "npm:0.28.2"
+    "@esbuild/linux-mips64el": "npm:0.28.2"
+    "@esbuild/linux-ppc64": "npm:0.28.2"
+    "@esbuild/linux-riscv64": "npm:0.28.2"
+    "@esbuild/linux-s390x": "npm:0.28.2"
+    "@esbuild/linux-x64": "npm:0.28.2"
+    "@esbuild/netbsd-arm64": "npm:0.28.2"
+    "@esbuild/netbsd-x64": "npm:0.28.2"
+    "@esbuild/openbsd-arm64": "npm:0.28.2"
+    "@esbuild/openbsd-x64": "npm:0.28.2"
+    "@esbuild/openharmony-arm64": "npm:0.28.2"
+    "@esbuild/sunos-x64": "npm:0.28.2"
+    "@esbuild/win32-arm64": "npm:0.28.2"
+    "@esbuild/win32-ia32": "npm:0.28.2"
+    "@esbuild/win32-x64": "npm:0.28.2"
   dependenciesMeta:
     "@esbuild/aix-ppc64":
       optional: true
@@ -26516,7 +26687,7 @@ __metadata:
       optional: true
   bin:
     esbuild: bin/esbuild
-  checksum: 10c0/29cd456a79ce35ac2c7e05fe871330416b2c395c045d849653f843e51378d6e0d6e774d6dcd01b35f4e83238a29bf8decd04fcd34b3780c589a250b21e5f92bb
+  checksum: 10c0/9b19edb63bd7780fd2e8e65a1394a0e8a05a17d697f73f0647ffe3c134709d8dbe744ab3fd57b35c9470db268cae7678fafd3dcd3ce1f34fc590568c2433f5d2
   languageName: node
   linkType: hard
 
@@ -27620,6 +27791,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"event-target-polyfill@npm:^0.0.4":
+  version: 0.0.4
+  resolution: "event-target-polyfill@npm:0.0.4"
+  checksum: 10c0/7052b838df6509e8290f110daf94604dd05828834db4ad6fe4a12abc693da1a3274100cfd4ff3e47a941d5aa3fb7cdb8164d85402b93d85340bb3adc596d8732
+  languageName: node
+  linkType: hard
+
 "event-target-shim@npm:^5.0.0":
   version: 5.0.1
   resolution: "event-target-shim@npm:5.0.1"
@@ -27945,6 +28123,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"fast-check@npm:4.9.0":
+  version: 4.9.0
+  resolution: "fast-check@npm:4.9.0"
+  dependencies:
+    pure-rand: "npm:^8.0.0"
+  checksum: 10c0/d31e6cf7b4ef01dc654193ea7c34a894c51b1553b6781f22a50808d5535d825c2ff2adff23a7c2f14d0452c90917bd20a84c1e807d1f8064aa4d984a21e72788
+  languageName: node
+  linkType: hard
+
 "fast-check@npm:^3.23.1":
   version: 3.23.2
   resolution: "fast-check@npm:3.23.2"
@@ -28104,12 +28291,12 @@ __metadata:
   languageName: node
   linkType: hard
 
-"fastq@npm:^1.6.0":
-  version: 1.17.1
-  resolution: "fastq@npm:1.17.1"
+"fastq@npm:^1.19.1, fastq@npm:^1.6.0":
+  version: 1.20.1
+  resolution: "fastq@npm:1.20.1"
   dependencies:
     reusify: "npm:^1.0.4"
-  checksum: 10c0/1095f16cea45fb3beff558bb3afa74ca7a9250f5a670b65db7ed585f92b4b48381445cd328b3d87323da81e43232b5d5978a8201bde84e0cd514310f1ea6da34
+  checksum: 10c0/e5dd725884decb1f11e5c822221d76136f239d0236f176fab80b7b8f9e7619ae57e6b4e5b73defc21e6b9ef99437ee7b545cff8e6c2c337819633712fa9d352e
   languageName: node
   linkType: hard
 
@@ -30125,10 +30312,10 @@ __metadata:
   languageName: node
   linkType: hard
 
-"hono@npm:^4.11.4":
-  version: 4.13.0
-  resolution: "hono@npm:4.13.0"
-  checksum: 10c0/d7cfb4d1063be19bea1982ea2a6b3cfa1840e8403a03203e86d17278e76fed11e7483974738345257543e183a935ea73ffc6d4a1e6ad7f0008451f55cdf8be7b
+"hono@npm:4.13.2, hono@npm:^4.11.4, hono@npm:^4.8.3":
+  version: 4.13.2
+  resolution: "hono@npm:4.13.2"
+  checksum: 10c0/063daaa596bfb1ed3a4dc523a9f47725cf8d56e0918c21a241161f6f1996229f5525bf0f70d6b15cc28912720ddde519584eeb06fb92730a66f01e39faba8131
   languageName: node
   linkType: hard
 
@@ -30469,6 +30656,16 @@ __metadata:
   languageName: node
   linkType: hard
 
+"http-proxy-agent@npm:7.0.2, http-proxy-agent@npm:^7.0.0, http-proxy-agent@npm:^7.0.1, http-proxy-agent@npm:^7.0.2":
+  version: 7.0.2
+  resolution: "http-proxy-agent@npm:7.0.2"
+  dependencies:
+    agent-base: "npm:^7.1.0"
+    debug: "npm:^4.3.4"
+  checksum: 10c0/4207b06a4580fb85dd6dff521f0abf6db517489e70863dca1a0291daa7f2d3d2d6015a57bd702af068ea5cf9f1f6ff72314f5f5b4228d299c0904135d2aef921
+  languageName: node
+  linkType: hard
+
 "http-proxy-agent@npm:9.1.0":
   version: 9.1.0
   resolution: "http-proxy-agent@npm:9.1.0"
@@ -30491,16 +30688,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"http-proxy-agent@npm:^7.0.0, http-proxy-agent@npm:^7.0.1, http-proxy-agent@npm:^7.0.2":
-  version: 7.0.2
-  resolution: "http-proxy-agent@npm:7.0.2"
-  dependencies:
-    agent-base: "npm:^7.1.0"
-    debug: "npm:^4.3.4"
-  checksum: 10c0/4207b06a4580fb85dd6dff521f0abf6db517489e70863dca1a0291daa7f2d3d2d6015a57bd702af068ea5cf9f1f6ff72314f5f5b4228d299c0904135d2aef921
-  languageName: node
-  linkType: hard
-
 "http-proxy-middleware@npm:3.0.7":
   version: 3.0.7
   resolution: "http-proxy-middleware@npm:3.0.7"
@@ -32201,6 +32388,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"js-base64@npm:^3.7.7":
+  version: 3.9.2
+  resolution: "js-base64@npm:3.9.2"
+  checksum: 10c0/59bfa7f05953aa3e630812d3fcf96ea56597100b4baf367fdaacb696712e5b774cbb95f90185f88cf0ccbb864fcf62b1f75e8eed283214076d6bec8952f621dc
+  languageName: node
+  linkType: hard
+
 "js-levenshtein@npm:1.1.6":
   version: 1.1.6
   resolution: "js-levenshtein@npm:1.1.6"
@@ -32224,6 +32418,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"js-tokens@npm:^10.0.0":
+  version: 10.0.0
+  resolution: "js-tokens@npm:10.0.0"
+  checksum: 10c0/a93498747812ba3e0c8626f95f75ab29319f2a13613a0de9e610700405760931624433a0de59eb7c27ff8836e526768fb20783861b86ef89be96676f2c996b64
+  languageName: node
+  linkType: hard
+
 "js-tokens@npm:^3.0.0 || ^4.0.0, js-tokens@npm:^4.0.0":
   version: 4.0.0
   resolution: "js-tokens@npm:4.0.0"
@@ -32261,6 +32462,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"js-yaml@npm:^5.2.1":
+  version: 5.3.0
+  resolution: "js-yaml@npm:5.3.0"
+  dependencies:
+    argparse: "npm:^2.0.1"
+  bin:
+    js-yaml: bin/js-yaml.mjs
+  checksum: 10c0/c67383a74026f3b550fe1131c6f0f56df11e227fc9b8b8c1c85154f106831a95a944f2dd4f505498d537790483aec7cd5e3d5e9913fe28fa2d131eeb894a0fd9
+  languageName: node
+  linkType: hard
+
 "jsdoc-type-pratt-parser@npm:^7.0.0":
   version: 7.1.1
   resolution: "jsdoc-type-pratt-parser@npm:7.1.1"
@@ -32796,6 +33008,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"layerr@npm:^3.0.0":
+  version: 3.0.0
+  resolution: "layerr@npm:3.0.0"
+  checksum: 10c0/320c9b9cf1392c73c9ff8f8d1bb7a782093ac7341fe5d7fea6ebfeea6d785af8e0fc573541431b6ffcb268577f8aea66168757e73a15035568a00ab9e4370705
+  languageName: node
+  linkType: hard
+
 "lcid@npm:^2.0.0":
   version: 2.0.0
   resolution: "lcid@npm:2.0.0"
@@ -34883,6 +35102,18 @@ __metadata:
   languageName: node
   linkType: hard
 
+"mimetext@npm:^3.0.28":
+  version: 3.0.28
+  resolution: "mimetext@npm:3.0.28"
+  dependencies:
+    "@babel/runtime": "npm:^7.26.0"
+    "@babel/runtime-corejs3": "npm:^7.26.0"
+    js-base64: "npm:^3.7.7"
+    mime-types: "npm:^2.1.35"
+  checksum: 10c0/c5feea4bbe110de0b2fd599cdb972619b99e462ebe211f39fca80213759a87ed410ae87738f3e26428e3d2095a8d8080eb09cd316bd1d87ac5812f812bdb7ea0
+  languageName: node
+  linkType: hard
+
 "mimic-fn@npm:^2.0.0":
   version: 2.1.0
   resolution: "mimic-fn@npm:2.1.0"
@@ -35478,7 +35709,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"nanoid@npm:^5.1.6":
+"nanoid@npm:^5.1.16, nanoid@npm:^5.1.6, nanoid@npm:^5.1.9":
   version: 5.1.16
   resolution: "nanoid@npm:5.1.16"
   bin:
@@ -36322,6 +36553,23 @@ __metadata:
   languageName: node
   linkType: hard
 
+"openai@npm:6.26.0":
+  version: 6.26.0
+  resolution: "openai@npm:6.26.0"
+  peerDependencies:
+    ws: ^8.18.0
+    zod: ^3.25 || ^4.0
+  peerDependenciesMeta:
+    ws:
+      optional: true
+    zod:
+      optional: true
+  bin:
+    openai: bin/cli
+  checksum: 10c0/dc045e8ed317dead468ecb342040eaee1e5388f2042f926dab4d0d0ec51b3dce41167edf16003ca850d594cbdbc8cc279a0529ec7820d8c86f3b8d33b6941b40
+  languageName: node
+  linkType: hard
+
 "openai@npm:6.6.0":
   version: 6.6.0
   resolution: "openai@npm:6.6.0"
@@ -37174,6 +37422,38 @@ __metadata:
   languageName: node
   linkType: hard
 
+"partial-json@npm:0.1.7":
+  version: 0.1.7
+  resolution: "partial-json@npm:0.1.7"
+  checksum: 10c0/cd5f994c3a5ca903918c028a6947ebc1d46459234c1c57c7ab98e234d8dca49cb46b05a71889ee422b39d1f66b95c59a5ce3a6ae06966aca95a8960ad20c12d2
+  languageName: node
+  linkType: hard
+
+"partyserver@npm:^0.5.8":
+  version: 0.5.10
+  resolution: "partyserver@npm:0.5.10"
+  dependencies:
+    nanoid: "npm:^5.1.9"
+  peerDependencies:
+    "@cloudflare/workers-types": ^4.20260424.1 || ^5.20260703.1
+  checksum: 10c0/28be18867c6be7ec4310e29b557990d13dce202758081e3f57256d3ee04153d91dc58a4689bb699eab2275af7ac5a9ee8a6aac8f90177d4a4d8999dd06adff33
+  languageName: node
+  linkType: hard
+
+"partysocket@npm:1.3.0":
+  version: 1.3.0
+  resolution: "partysocket@npm:1.3.0"
+  dependencies:
+    event-target-polyfill: "npm:^0.0.4"
+  peerDependencies:
+    react: ">=17"
+  peerDependenciesMeta:
+    react:
+      optional: true
+  checksum: 10c0/5b4a11f73f3cb87cab5fa01ed37e6c7aa19725725cb18692816307ea1147a8f74be2684c9e761316d5a37ebe608497a0874a49385596f07e08c8c0d2043f726a
+  languageName: node
+  linkType: hard
+
 "pascal-case@npm:^3.1.2":
   version: 3.1.2
   resolution: "pascal-case@npm:3.1.2"
@@ -38458,6 +38738,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"pure-rand@npm:^8.0.0":
+  version: 8.4.2
+  resolution: "pure-rand@npm:8.4.2"
+  checksum: 10c0/4b2ef2a2e68a258fb311efd26b65305b4865856e28d6b40ff61f7d65bb6a39b4f8ebbcf7dfc843193b3cfe54e7501dbc2c7aba0ecdb97d13cd634db709df83fd
+  languageName: node
+  linkType: hard
+
 "pvtsutils@npm:^1.3.6":
   version: 1.3.6
   resolution: "pvtsutils@npm:1.3.6"
@@ -43738,6 +44025,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"typebox@npm:1.3.7":
+  version: 1.3.7
+  resolution: "typebox@npm:1.3.7"
+  checksum: 10c0/833a11574b1290e9a25bee32dc35a21788009a7aea842f43b6a37cea648016875ca2a1d997ad343f256c63122cb8aa4dd9690230b2bec5ae1ee3e7a4b9949ec1
+  languageName: node
+  linkType: hard
+
 "typed-array-buffer@npm:^1.0.3":
   version: 1.0.3
   resolution: "typed-array-buffer@npm:1.0.3"
@@ -44016,6 +44310,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"ulidx@npm:^2.4.1":
+  version: 2.4.1
+  resolution: "ulidx@npm:2.4.1"
+  dependencies:
+    layerr: "npm:^3.0.0"
+  checksum: 10c0/3cbe05123b4b49d262e26cd0edd3ac38a4f9e97f043d47ae7daa88502748881d1615d832e3bcb29698ca2429947c24494929ba35b40d6bf38df891cb15642d2e
+  languageName: node
+  linkType: hard
+
 "ultrahtml@npm:^1.6.0":
   version: 1.7.0
   resolution: "ultrahtml@npm:1.7.0"
@@ -44777,6 +45080,18 @@ __metadata:
   languageName: node
   linkType: hard
 
+"valibot@npm:1.4.2, valibot@npm:^1.1.0":
+  version: 1.4.2
+  resolution: "valibot@npm:1.4.2"
+  peerDependencies:
+    typescript: ">=5"
+  peerDependenciesMeta:
+    typescript:
+      optional: true
+  checksum: 10c0/71b861de928fd5533b03fc4d84c619c07602f176d2bc6b12c5c80b2a6e889574c4126c843dd0771ce450bbb29566ca6df13d5b538ce5e4c39c2fccfb7623cf4e
+  languageName: node
+  linkType: hard
+
 "validate-npm-package-license@npm:^3.0.1":
   version: 3.0.4
   resolution: "validate-npm-package-license@npm:3.0.4"
@@ -46368,14 +46683,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"yaml@npm:^1.10.0, yaml@npm:^1.5.0":
-  version: 1.10.3
-  resolution: "yaml@npm:1.10.3"
-  checksum: 10c0/c309ff85a0a569a981d71ab9cf0fef68672a16b9cdf40639d1c3b30034f6cd16ee428602bd6d64ecf006f8c8bee499023cac236538f79898aa99fb5db529a2ed
-  languageName: node
-  linkType: hard
-
-"yaml@npm:^2.3.1, yaml@npm:^2.8.3":
+"yaml@npm:2.9.0, yaml@npm:^2.3.1, yaml@npm:^2.8.3, yaml@npm:^2.9.0":
   version: 2.9.0
   resolution: "yaml@npm:2.9.0"
   bin:
@@ -46384,6 +46692,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"yaml@npm:^1.10.0, yaml@npm:^1.5.0":
+  version: 1.10.3
+  resolution: "yaml@npm:1.10.3"
+  checksum: 10c0/c309ff85a0a569a981d71ab9cf0fef68672a16b9cdf40639d1c3b30034f6cd16ee428602bd6d64ecf006f8c8bee499023cac236538f79898aa99fb5db529a2ed
+  languageName: node
+  linkType: hard
+
 "yargs-parser@npm:^11.1.1":
   version: 11.1.1
   resolution: "yargs-parser@npm:11.1.1"
@@ -46579,12 +46894,12 @@ __metadata:
   languageName: node
   linkType: hard
 
-"zod-to-json-schema@npm:^3.25.1":
-  version: 3.25.1
-  resolution: "zod-to-json-schema@npm:3.25.1"
+"zod-to-json-schema@npm:^3.25.0, zod-to-json-schema@npm:^3.25.1":
+  version: 3.25.2
+  resolution: "zod-to-json-schema@npm:3.25.2"
   peerDependencies:
-    zod: ^3.25 || ^4
-  checksum: 10c0/711b30e34d1f1211f1afe64bf457f0d799234199dc005cca720b236ea808804c03164039c232f5df33c46f462023874015a8a0b3aab1585eca14124c324db7e2
+    zod: ^3.25.28 || ^4
+  checksum: 10c0/dd300554393903022487688af14fbda5c719ba8179702bb55b3aa86318830467f0f7beb7d654036975ac963dc4843b72e59636448bfff9a0608f277bb6a14939
   languageName: node
   linkType: hard
 
@@ -46604,7 +46919,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"zod@npm:4.4.3, zod@npm:^3.25 || ^4.0, zod@npm:^3.25.0 || ^4.0.0, zod@npm:^4.0.0, zod@npm:^4.1.5, zod@npm:^4.3.6":
+"zod@npm:4.4.3, zod@npm:^3.25 || ^4.0, zod@npm:^3.25.0 || ^4.0.0, zod@npm:^4.0.0, zod@npm:^4.1.5, zod@npm:^4.2.0, zod@npm:^4.3.6":
   version: 4.4.3
   resolution: "zod@npm:4.4.3"
   checksum: 10c0/7ea31b558e88f9faf44f31dd185e2e1cbf51fed3081787fb96cc2534749b50c0acfc6da7f0922a7353ed092dd358c7d50c28ea96c94d04af64191bd33152eca3