@ai-matrx/agents 0.7.0 → 0.7.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,45 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.7.1 — 2026-09-08
4
+
5
+ **0.7.0's two catalog entries did not typecheck together.** `./catalog` and
6
+ `./catalog/react` are emitted by two separate tsup passes (only the react group
7
+ carries the `"use client"` banner), so each `.d.ts` holds its own copy of the
8
+ shared declarations. `AgentId` was branded with a `unique symbol`, which is
9
+ NOMINAL — the two copies were unrelated types, and the wiring the 0.7.0
10
+ `Consumer action` prescribes:
11
+
12
+ ```tsx
13
+ <AgentCatalogProvider catalog={createAgentCatalog({ client, identity })}>
14
+ ```
15
+
16
+ failed with *"Two different types with this name exist, but they are
17
+ unrelated"* in every consumer. Every runtime canary was green; only a `tsc` in
18
+ a real host caught it (matrx-extend, on its first compile of the adoption).
19
+
20
+ ### Consumer action (C28)
21
+
22
+ Update to 0.7.1 and the documented wiring compiles. No source change is needed
23
+ in a host — if you worked around this with a cast, DELETE the cast.
24
+
25
+ ### The fix, and the guard
26
+
27
+ - `AgentId` is now branded with a string literal
28
+ (`string & { readonly __agentId: "ai-matrx.agent-id" }`). A literal brand is
29
+ structural, so the two emitted copies unify; a bare `string` still cannot be
30
+ passed where an `AgentId` is required, so the branding is not weakened. Any
31
+ future brand in this package follows the same rule — the reason is recorded
32
+ at the declaration.
33
+ - `scripts/verify-tarball.mjs` grew THE TWO-ENTRY TYPE-IDENTITY CANARY: it
34
+ installs the packed tarball into a scratch consumer with `strict`,
35
+ `exactOptionalPropertyTypes`, `noUncheckedIndexedAccess` and
36
+ `skipLibCheck: false`, then compiles the real provider wiring plus reads that
37
+ cross the seam in both directions. Proven RED against the 0.7.0 brand
38
+ (the same "two different types" error, from the packed types) and GREEN
39
+ after the fix. It runs inside `pnpm check:package`, which the publish
40
+ workflow gates on.
41
+
42
+
3
43
  ## 0.7.0 — 2026-09-08
4
44
 
5
45
  **THE ONE AGENT PICKER moves into the package.** Two new entries — `./catalog`