modwright 0.1.0

package/knowledge/valheim/thunderstore.packaging.yaml

@@ -0,0 +1,217 @@
+game: valheim
+topic: thunderstore.packaging
+title: Thunderstore packaging, tcli, and the r2modman profile as a second deploy target
+facts:
+  - id: valheim.thunderstore.packaging.required-zip-contents
+    claim: A Thunderstore package is a zip whose root contains exactly three required files —
+      `manifest.json`, `icon.png` and `README.md` — and the docs state "File naming is
+      case-sensitive and must match the above exactly!". `icon.png` "must be exactly 256x256 in
+      resolution and in PNG format". `CHANGELOG.md` is optional but supported.
+    status: community
+    source: https://wiki.thunderstore.io/mods/creating-a-package ; CHANGELOG.md from
+      https://wiki.thunderstore.io/mods/updating-a-package
+    tags:
+      - thunderstore
+      - packaging
+      - manifest
+      - icon
+      - readme
+      - validator
+      - build
+    detail: "All four of these are checkable from a mod folder with no game installed: the three files
+      exist at the zip root, the names are exactly cased, and the PNG's IHDR says 256x256. That
+      makes packaging the single cheapest validator family to build for this game."
+  - id: valheim.thunderstore.packaging.manifest-fields
+    claim: '`manifest.json` carries five fields. `name` — "no spaces. Allowed characters: a-z A-Z 0-9
+      _", max 128 characters. `description` — max 250 characters. `version_number` — the
+      three-number `Major.Minor.Patch` semantic version, no suffixes. `dependencies` — a list of
+      strings. `website_url` — optional, but an empty string must still be present.'
+    status: community
+    source: https://wiki.thunderstore.io/mods/creating-a-package
+    tags:
+      - thunderstore
+      - manifest
+      - schema
+      - validator
+      - version
+    detail: Each number is a full integer compared ordinally, so `1.0.10` is nine patches above `1.0.1`,
+      not below it — a real source of mis-ordered releases. Thunderstore always displays the highest
+      version regardless of upload date. Underscores in `name` render as spaces in most views.
+  - id: valheim.thunderstore.packaging.dependency-string-format
+    claim: Every entry in `dependencies` is a single string of the form `{team name}-{package
+      name}-{package version}`, e.g. `MythicManiac-TestMod-1.1.0`; the mod managers install these
+      automatically.
+    status: community
+    source: https://wiki.thunderstore.io/mods/creating-a-package
+    tags:
+      - thunderstore
+      - dependencies
+      - format
+      - validator
+    detail: "The three-part hyphenated form is parseable but ambiguous in principle — team and package
+      names may themselves contain no hyphen, since the allowed character set is `a-z A-Z 0-9 _`, so
+      splitting on the last two hyphens is safe. A real Valheim example: Jötunn's own manifest
+      depends on exactly one package, `denikson-BepInExPack_Valheim-5.4.2333`."
+  - id: valheim.thunderstore.packaging.versions-are-immutable
+    claim: A published version can never be re-uploaded or edited — "Package versions are immutable!
+      Once a version is successfully uploaded, it can no longer be edited", for conflict-freeness
+      and caching reasons. Updating means keeping `name` identical and incrementing
+      `version_number`.
+    status: community
+    source: https://wiki.thunderstore.io/mods/updating-a-package
+    tags:
+      - thunderstore
+      - publishing
+      - immutable
+      - version
+    detail: "This makes a pre-publish validator worth strictly more here than on a platform that allows
+      replacing a file: a bad `manifest.json` that reaches Thunderstore is permanent and can only be
+      superseded, never fixed."
+  - id: valheim.thunderstore.packaging.bepinex-folder-routing
+    claim: Thunderstore's mod managers only preserve folder structure inside specifically named folders
+      — `BepInEx/plugins`, `/core`, `/patchers`, `/monomod` and `/config` — and the `BepInEx` prefix
+      may be omitted; contents of any other folder are flattened on install.
+    status: community
+    source: https://wiki.thunderstore.io/mods/packaging-your-mods
+    tags:
+      - thunderstore
+      - packaging
+      - bepinex
+      - routing
+      - layout
+      - build
+    detail: "This is a build-step rule, not just advice: a package that puts its DLL under a folder name
+      outside that set installs as a loose file in an unpredictable place. A ModWright `build` for
+      this game should stage into exactly these routes."
+  - id: valheim.thunderstore.packaging.ecosystem-install-rules
+    claim: "Thunderstore's ecosystem schema declares Valheim's install routes explicitly:
+      `BepInEx/plugins` (default location, default extension `.dll`, tracking method `subdir`),
+      `BepInEx/core`, `BepInEx/patchers`, `BepInEx/monomod` (default extension `.mm.dll`),
+      `BepInEx/SlimVML` — all `subdir` — and `BepInEx/config` with tracking method `none`."
+    status: community
+    source: https://github.com/thunderstore-io/ecosystem-schema/blob/main/games/data/generated/valheim.yml,
+      the `installRules` list (identical for the game and the dedicated server)
+    tags:
+      - thunderstore
+      - install-rules
+      - modroots
+      - conflictscope
+      - config
+    detail: "That `subdir` versus `none` distinction is exactly ModWright's `conflictScope`: a `subdir`
+      route gives every package its own directory (`isolated`), while `config` is tracked as `none`
+      because config files are loose, shared and merged across mods (`merged`). Having the ecosystem
+      schema state it removes the guesswork from the roots table."
+  - id: valheim.thunderstore.packaging.tcli-does-not-compile
+    claim: '`tcli` (thunderstore-cli, latest release 0.2.5, 2025-12-16; installable with `dotnet tool
+      install -g tcli`) builds and publishes packages from a `thunderstore.toml` config: `tcli init`
+      writes the config plus a default icon and README, `tcli build` zips the project per the
+      `[[build.copy]]` mappings, and `tcli publish` uploads. It explicitly does not compile code —
+      "any actual build actions ... must be performed separately".'
+    status: community
+    source: https://github.com/thunderstore-io/thunderstore-cli (README and wiki); version from the
+      repository's releases
+    tags:
+      - tcli
+      - thunderstore
+      - toolchain
+      - build
+      - packaging
+      - dotnet
+    detail: "That division is a clean fit for ModWright's `core/toolchain` and `core/build`: `dotnet
+      build` is one tool spec producing the DLL, `tcli build` is a second producing the zip, and the
+      staging between them is ModWright's own. The NuGet-distributed `tcli` excludes mod
+      installation; the standalone GitHub release includes it."
+  - id: valheim.thunderstore.packaging.thunderstore-toml-dependency-shape-differs
+    claim: "`thunderstore.toml`'s `[package.dependencies]` is a TOML table mapping `\"Namespace-Name\" =
+      \"version\"`, which is a *different* shape from `manifest.json`'s flat
+      `\"Namespace-Name-version\"` strings; tcli assembles the manifest from the toml."
+    status: inferred
+    source: "`ThunderstoreCLI/Models/ThunderstoreProject.cs` in
+      https://github.com/thunderstore-io/thunderstore-cli, compared against
+      https://wiki.thunderstore.io/mods/creating-a-package"
+    tags:
+      - tcli
+      - thunderstore
+      - toml
+      - manifest
+      - dependencies
+      - validator
+    detail: A validator must therefore know which file it is looking at. Checking a `thunderstore.toml`
+      dependency against the `manifest.json` three-part regex would reject every correct entry, and
+      vice versa.
+  - id: valheim.thunderstore.packaging.r2modman-profile-path
+    claim: An r2modman profile lives at `<ROOT>/<internalFolderName>/profiles/<ProfileName>`, where
+      `ROOT` is the user's configured data directory or, by default, `<Electron
+      appData>/r2modmanPlus-local` — on Windows `%APPDATA%\r2modmanPlus-local`. Valheim's
+      `internalFolderName` is `Valheim`, so the default Windows profile path is
+      `%APPDATA%\r2modmanPlus-local\Valheim\profiles\Default`.
+    status: inferred
+    source: r2modmanPlus `src/App.vue` (`PathResolver.APPDATA_DIR = path.join(appData,
+      'r2modmanPlus-local')`), `src/model/game/GameManager.ts` (`MOD_ROOT = path.join(ROOT,
+      game.internalFolderName)`), `src/model/Profile.ts` (`path.join(MOD_ROOT, 'profiles')`), and
+      `src/assets/data/ecosystem.json` for `internalFolderName`
+    tags:
+      - r2modman
+      - profile
+      - path
+      - deploy
+      - modroots
+      - windows
+    detail: The r2modman wiki documents profile export and import but not the on-disk layout, so this is
+      read from source, not prose. The user-configurable data directory means the path must be
+      treated as a candidate rather than a constant — a Valheim surface should probe it and say "not
+      found" rather than assert it.
+  - id: valheim.thunderstore.packaging.r2modman-profile-is-a-whole-bepinex-install
+    claim: r2modman's BepInEx installer copies everything from the BepInEx package root into the profile
+      root except `manifest.json`, `readme.md` and `icon.png`, so a Valheim profile directory
+      contains a complete BepInEx install — `BepInEx/` with `core`, `plugins`, `config` and
+      `patchers`, plus `winhttp.dll` and `doorstop_config.ini` — living entirely outside the game
+      directory.
+    status: inferred
+    source: r2modmanPlus `src/installers/BepInExInstaller.ts` (the `basePackageFiles` exclusion list),
+      combined with BepInExPack_Valheim's own shipped contents
+    tags:
+      - r2modman
+      - profile
+      - bepinex
+      - deploy
+      - alternate-root
+    detail: This is the reason a Valheim surface cannot assume mod roots are relative to the game
+      install. The same logical root — "BepInEx plugins" — resolves to two entirely different
+      absolute paths depending on how the user launches, and both can exist at once on one machine.
+  - id: valheim.thunderstore.packaging.r2modman-launches-via-doorstop-args
+    claim: r2modman does not copy anything into the game folder to activate a profile; it appends
+      Doorstop command-line arguments to the Steam launch. For Doorstop 3 that is `--doorstop-enable
+      true --doorstop-target <profile>/BepInEx/core/<preloader dll>` and for Doorstop 4
+      `--doorstop-enabled true --doorstop-target-assembly <profile>/BepInEx/core/<preloader dll>`; a
+      vanilla launch passes `--doorstop-enable false`.
+    status: inferred
+    source: r2modmanPlus
+      `src/r2mm/launching/instructions/instructions/loader/BepInExGameInstructions.ts`
+      (`genDoorstopV3` / `genDoorstopV4`)
+    tags:
+      - r2modman
+      - doorstop
+      - launch
+      - profile
+      - deploy
+    detail: Two consequences. A machine can have BepInEx installed in the game folder *and* several
+      r2modman profiles, and which one is live is decided at launch time by an argument ModWright
+      cannot see from the filesystem — so "which install is active" is genuinely undeterminable and
+      must be reported as such rather than guessed. And on Windows the profile is identified purely
+      by the absolute `--doorstop-target` path, with no profile-name argument to read back.
+  - id: valheim.thunderstore.packaging.nexus-is-the-second-channel
+    claim: "Thunderstore is not the only distribution channel for Valheim mods: Nexus Mods is the other
+      long-standing one, and the community's own 1.0 FAQ also names Hexium, reached through the Gale
+      mod manager, as a newer host."
+    status: community
+    source: https://github.com/Valheim-Modding/Wiki/wiki/Valheim-1.0-FAQ
+    tags:
+      - nexus
+      - thunderstore
+      - hexium
+      - gale
+      - distribution
+    detail: Only Thunderstore has a machine-readable package format with a documented schema, which is
+      why it is the only one a ModWright build step can target without scraping. Nexus is a manual
+      upload of an archive whose internal layout is by convention only.

package/knowledge/valheim/toolchain.build.yaml

@@ -0,0 +1,111 @@
+game: valheim
+topic: toolchain.build
+title: what builds and packs a Valheim plugin unattended, and what does not
+facts:
+  - id: valheim.toolchain.build.dotnet-is-the-compiler-and-prints-a-bare-version
+    claim: A plugin is compiled with the .NET SDK's `dotnet build` (the wiki's environment guide targets
+      .NET Framework 4.8 through the SDK's msbuild), and `dotnet --version` prints the SDK version
+      alone on one line (e.g. `8.0.404`), which is the one tool in ModWright's catalogue with a real
+      installer and a fixed Program Files path.
+    status: community
+    source: https://learn.microsoft.com/dotnet/core/tools/dotnet
+    tags:
+      - dotnet
+      - sdk
+      - build
+      - version
+      - toolchain
+      - installer
+    detail: The toolchain spec `dotnet` probes `--version` and matches the leading dotted number; its
+      candidates are `C:/Program Files/dotnet/dotnet.exe` and PATH. Which SDK feature band a given
+      plugin needs is the project's business (`global.json`), not the spec's.
+  - id: valheim.toolchain.build.tcli-packs-but-does-not-compile
+    claim: tcli (thunderstore-cli) is installed as a global .NET tool (`dotnet tool install -g tcli`,
+      landing in `%USERPROFILE%\.dotnet\tools`) and drives `init`, `build` and `publish` from a
+      `thunderstore.toml`; it assembles manifest.json and the zip but performs no compilation — "the
+      build command only supports creation of zip files from files already existing on the
+      filesystem … any actual build actions (e.g. building the c# project for your mod) must be
+      performed separately". Its help output does list a `version` command and a `--version` flag on
+      every verb, but the shape of what they print has not been read from a run, so ModWright's spec
+      leaves version detection unset rather than guess at a pattern.
+    status: community
+    source: https://github.com/thunderstore-io/thunderstore-cli;
+      https://github.com/thunderstore-io/thunderstore-cli/wiki
+    tags:
+      - tcli
+      - thunderstore
+      - pack
+      - publish
+      - toolchain
+      - version
+    detail: The build pipeline is therefore `dotnet build -c Release`, ModWright's own staging of
+      `BepInEx/plugins/<Mod>/` plus the three root files, then `tcli build`; the packaging
+      validators gate the last step, since a published version is immutable.
+    related:
+      - valheim.thunderstore.packaging.tcli-does-not-compile
+      - valheim.thunderstore.packaging.thunderstore-toml-dependency-shape-differs
+  - id: valheim.toolchain.build.icon-must-be-a-256-png
+    claim: "The package icon is checked by its PNG header alone: the eight-byte PNG signature followed
+      by the IHDR chunk, whose width and height (big-endian at offsets 16 and 20) must both be 256.
+      Thunderstore's own wording is \"exactly 256x256 in resolution and in PNG format\", and the
+      file name is `icon.png` exactly."
+    status: community
+    source: https://wiki.thunderstore.io/mods/creating-a-package (icon rule); the PNG specification's
+      file structure (signature, then IHDR as the first chunk)
+    tags:
+      - thunderstore
+      - icon
+      - png
+      - ihdr
+      - validator
+    detail: "`readPngDimensions` in `src/surfaces/valheim/packaging.ts` reads 24 bytes and nothing else;
+      a JPEG renamed to icon.png, or a 512-pixel icon, is a block before upload rather than a
+      rejected upload."
+  - id: valheim.toolchain.build.guid-to-package-name-has-no-registry
+    claim: "Nothing maps a BepInEx plugin GUID (`com.jotunn.jotunn`) to its Thunderstore package name
+      (`ValheimModding-Jotunn`): the manifest lists packages, the attribute lists GUIDs, and the two
+      are only related by convention. A cross-check between them can only match names heuristically
+      (the package name against the GUID's dot-separated segments, ignoring case, `_` and `-`), and
+      must say so in its finding."
+    status: inferred
+    source: Thunderstore's manifest and dependency-string format
+      (https://wiki.thunderstore.io/mods/creating-a-package) against BepInEx's
+      `[BepInDependency(guid)]` contract (v5-lts Contract/Attributes.cs); no registry or schema
+      field joins them in either project's documentation
+    tags:
+      - bepinex
+      - thunderstore
+      - dependency
+      - guid
+      - package
+      - crosscheck
+      - heuristic
+    detail: "`valheim.plugins.dependency-crosscheck` is built on this: a hard [BepInDependency] with no
+      name-matching manifest package warns, a manifest package (other than the loader pack, which
+      has no plugin GUID) that no attribute names is an info, and both findings say the match is by
+      name. A package whose name differs from its GUID is a known false positive."
+    related:
+      - valheim.bepinex.plugins.dependency-attributes
+      - valheim.thunderstore.packaging.dependency-string-format
+  - id: valheim.toolchain.build.bepinexpack-leaves-only-its-scripts-behind
+    claim: "Once installed, denikson's BepInExPack_Valheim leaves nothing on disk that names its own
+      version: r2modman copies everything from the package except manifest.json, README and icon,
+      and a manual install copies the archive's contents. What it leaves that stock BepInEx does not
+      are its run scripts (`start_game_bepinex.sh`, `start_server_bepinex.sh`) and the
+      `doorstop_libs/` folder, so the pack can be detected by presence only, and its version is
+      known only from the console line it prints at startup."
+    status: inferred
+    source: https://thunderstore.io/c/valheim/p/denikson/BepInExPack_Valheim/
+    tags:
+      - bepinexpack
+      - detect
+      - compat
+      - presence
+      - version
+      - marker
+    detail: "`src/surfaces/valheim/compat.ts` reports `bepinexpack` installed when any marker is present
+      and never invents a version. The exact wording of the startup line has not been read from a
+      real log, so no signature captures it yet."
+    related:
+      - valheim.bepinex.loader.bepinexpack-valheim-is-the-distribution
+      - valheim.bepinexpack-valheim-install-shape

package/package.json

@@ -0,0 +1,29 @@
+{
+  "name": "modwright",
+  "version": "0.1.0",
+  "description": "A game-agnostic MCP server for game modding, with per-game surfaces.",
+  "type": "module",
+  "main": "dist/index.js",
+  "bin": {
+    "modwright": "dist/index.js"
+  },
+  "engines": {
+    "node": ">=20"
+  },
+  "license": "MIT",
+  "author": "Jonathan Trachtenberg",
+  "keywords": [
+    "mcp",
+    "modding",
+    "cyberpunk2077",
+    "baldursgate3",
+    "skyrim"
+  ],
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.22.0",
+    "smol-toml": "^1.8.0",
+    "sql.js": "^1.14.2",
+    "yaml": "^2.9.0",
+    "zod": "^3.25.76"
+  }
+}

package/scaffolds/baldursgate3/new-class-injection.yaml

@@ -0,0 +1,148 @@
+# new-class-injection (BG3).
+# Injects spells/passives into a *foreign* class's list at runtime via the
+# Compatibility Framework, rather than authoring a Progression/
+# ClassDescription/SpellList node of its own — the G6 rules this satisfies
+# (subclass-registered-in-parent, type-matches-owner, tableuuid-matches-
+# owner, no-removespells) are all project-target rules over Progression/
+# ClassDescription nodes; a project with none of its own trivially passes
+# them, which is the point: this scaffold's whole risk surface is the Lua
+# module, not a new stats table.
+id: baldursgate3.new-class-injection
+game: baldursgate3
+title: New BG3 class injection (Compatibility Framework)
+summary: Write a Compatibility Framework Lua module that injects spells/passives into an existing (possibly foreign) class's list, plus an MCM Blueprint stub and the two framework dependencies.
+modTypes: [class, subclass, feat]
+needs: {}
+inputs:
+  - type: string
+    name: targetList
+    prompt: "Target SpellList/PassiveList or class name this injects into."
+    pattern: "^[A-Za-z][A-Za-z0-9_]*$"
+  - type: string
+    name: injectedSpells
+    prompt: "Comma-separated spell entry names to inject (blank for none)."
+    default: ""
+  - type: string
+    name: injectedPassives
+    prompt: "Comma-separated passive entry names to inject (blank for none)."
+    default: ""
+  - type: string
+    name: mcmKey
+    prompt: "MCM settings key prefix for the toggle(s) this injection exposes."
+ids: []
+emits:
+  - op: ensure-dir
+    path: "Mods/${project.identity.folder}/ScriptExtender/Lua/Injections"
+  - op: write-text
+    path: "Mods/${project.identity.folder}/ScriptExtender/Lua/Injections/${input.targetList}_Injection.lua"
+    body: |
+      -- ${project.today} — ModWright scaffold: injects into "${input.targetList}" via the
+      -- Compatibility Framework. Never modifies the target mod's own files.
+      local Injection = {}
+
+      Injection.targetList = "${input.targetList}"
+      Injection.spells = { "${input.injectedSpells}" }
+      Injection.passives = { "${input.injectedPassives}" }
+
+      Ext.Require("CompatibilityFramework/API.lua")
+
+      CompatibilityFramework.RegisterListInjection({
+          target = Injection.targetList,
+          spells = Injection.spells,
+          passives = Injection.passives,
+          enabledSetting = "${input.mcmKey}_enabled",
+      })
+
+      return Injection
+  - op: write-text
+    path: "Mods/${project.identity.folder}/ScriptExtender/Lua/Injections/${input.targetList}_MCM.lua"
+    body: |
+      -- ${project.today} — ModWright scaffold: MCM Blueprint stub for the
+      -- ${input.targetList} injection's on/off toggle.
+      return {
+          SchemaVersion = 1,
+          ModName = "${project.identity.folder}",
+          Tabs = {
+              {
+                  TabId = "${input.mcmKey}",
+                  TabName = "${input.targetList} injection",
+                  Sections = {
+                      {
+                          SectionId = "${input.mcmKey}_section",
+                          SectionName = "Options",
+                          Settings = {
+                              {
+                                  Id = "${input.mcmKey}_enabled",
+                                  Name = "Enable injection",
+                                  Type = "checkbox",
+                                  Default = true,
+                              },
+                          },
+                      },
+                  },
+              },
+          },
+      }
+  - op: patch-project
+    add:
+      dependencies:
+        - id: compatibility-framework
+          kind: framework
+          minVersion: "1.0"
+          url: "https://www.nexusmods.com/baldursgate3/mods/2050"
+          notes: "RegisterListInjection: injects spells/passives into a foreign mod's list without editing its files."
+        - id: mcm
+          kind: framework
+          minVersion: "1.0"
+          url: "https://www.nexusmods.com/baldursgate3/mods/2278"
+          notes: "MCM Blueprint stub exposes the injection's on/off toggle."
+templates: []
+satisfies:
+  - bg3.progression.spelllist-selector-resolves
+  - bg3.progression.passives-exist
+  - bg3.progression.no-removespells
+  - bg3.progression.subclass-registered-in-parent
+  - bg3.progression.type-matches-owner
+  - bg3.progression.tableuuid-matches-owner
+manual:
+  - title: Confirm the injection at runtime
+    steps:
+      - "Load a save with both this mod and the target list's owning mod active."
+      - "Toggle ${input.mcmKey}_enabled off/on in the MCM menu and confirm the injected entries appear/disappear."
+    expected: "The target list shows the injected spells/passives only while the MCM toggle is on."
+claim:
+  idSuffix: injects
+  claim: "With the Compatibility Framework and the target mod present, ${input.targetList} gains the injected spells/passives."
+testRows:
+  - gate: C-1
+    title: "Injection Lua loads without error"
+    expected: "RED4ext/SE-equivalent log shows the injection module loaded with no Lua error."
+    manual: true
+    probeKinds: []
+  - gate: C-2
+    title: "Target list carries the injected entries"
+    # No automated probe here, for two independent reasons.
+    #
+    # 1. ${input.targetList} is a SpellList/PassiveList (or a class name) —
+    #    an LSX resource, not a stats entry — so bg3.stat.exists, which is
+    #    Ext.Stats.Get plus Ext.Stats.GetStats over the 13 stat types the
+    #    bridge lists (bridges/bg3-se/.../Probes.lua STAT_TYPES: StatusData,
+    #    SpellData, PassiveData, Armor, Weapon, Character, Object, SpellSet,
+    #    EquipmentSet, TreasureTable, TreasureCategory, ItemGroup,
+    #    NameGroup), would report `fail` for a target that is perfectly fine.
+    # 2. Even for a stats entry, bg3.stat.fields is not a verbatim
+    #    "field -> value map" the way it might read: the
+    #    bridge's own handler returns `status = fail` when ANY requested
+    #    field comes back nil (Probes.lua, `#missing == 0 and
+    #    #unreadable == 0`). Asking for both Spells and Passives would
+    #    therefore fail on a list that legitimately carries only the one
+    #    ${input.injectedSpells}/${input.injectedPassives} names — and which
+    #    of the two applies is a per-run choice this scaffold's fixed
+    #    `probes[]` cannot branch on (it has no expression language).
+    #
+    # The enabled-vs-disabled comparison needs a human regardless: one
+    # arm/poll only ever samples one MCM toggle state.
+    expected: "A human confirms the injected entries are in ${input.targetList} with the MCM toggle on and gone with it off (the list is an LSX resource, not a stats entry, so bg3.stat.exists/bg3.stat.fields cannot check it)."
+    manual: true
+    probeKinds: []
+evidence: ["ModWright research"]