@dataverse-kit/agent-kit 0.2.0 → 0.3.0

package/README.md

@@ -5,8 +5,10 @@ hostable in a custom page, a static web app, or a PCF control.
 
 > The kit is feature-complete for the four surface families — **grounding**, **action/approval
 > cards**, the **Teams-like shell** and **agent ops** (availability, agent picker, run history,
-> traces, usage) — over the base **conversation surface**. What remains is host proof and
-> retiring one of the existing chat implementations.
+> traces, usage) — over the base **conversation surface**. Host proof is done: measured on a live
+> Dynamics form, 20 mount/unmount cycles left the platform's tabster 8.2.0 untouched
+> (`spikes/agent-kit-host-proof` in the workspace repo). `apps/foundry-manager` runs on the kit and
+> its two hand-rolled chat components are deleted.
 
 ```bash
 npm install @dataverse-kit/agent-kit @fluentui/react-components @fluentui/react-icons
@@ -58,6 +60,44 @@ Swap `MockAgentService` for your own `IAgentService` and nothing else changes.
 `./core` and `./services` are framework-agnostic *by gate*, not by convention, so a transport
 adapter can share them with an Azure Function, a web worker or a Node broker.
 
+### ★ Your tsconfig must resolve `exports` — or three of these four subpaths do not exist
+
+Those subpaths are published **only** through the package's `exports` map. TypeScript's classic
+`moduleResolution: "node"` (Node10) ignores `exports` entirely and can resolve a subpath only if it
+happens to be a real directory on disk — which these are not. Under it you get:
+
+```
+TS2307: Cannot find module '@dataverse-kit/agent-kit/host' or its corresponding type declarations.
+```
+
+```jsonc
+{
+  "compilerOptions": {
+    "moduleResolution": "bundler",  // or "node16" / "nodenext"
+    "module": "esnext"              // "bundler" requires an esnext-style module setting
+  }
+}
+```
+
+★★ **This bites PCF controls specifically, and it is not a mistake in your code.**
+`pcf-scripts/tsconfig_base.json` ships `moduleResolution: "node"`, so a control scaffolded with
+`pac pcf init` fails on the import above until you override it. MEASURED on a fresh scaffold,
+2026-09-25. The shipped gallery controls already carry the same pair.
+★ And put any explanatory comment key at the **top level** of `tsconfig.json`, never inside
+`compilerOptions` — there it is `TS5023: Unknown compiler option`, and `pcf-scripts` reports that
+failure **while exiting 0**.
+
+★★★ **`pac pcf push` cannot deploy a control that uses this kit.** It always builds **Debug** (there
+is no build-mode flag) — measured **9,975,780 bytes** against **772,001** for the same control in
+production — and Dataverse rejects it with *"Webresource content size is too big"*. Use the Release
+solution path instead:
+
+```bash
+npm run build -- --buildMode production
+cd solution && dotnet build -c Release      # ~203 KB solution.zip
+pac solution import --path bin/Release/solution.zip --publish-changes
+```
+
 ## The seam
 
 The kit ships **no real transport**. It defines one interface and one fake: