[freeqaz-openai]

TypeScript consumers cannot use SecretReference, SecretBinding, or SecretBindings as schema values from @openclaw-enterprise/contracts: local resource types hide the wildcard-exported values, so calls such as Check(SecretReference, reference) fail with TS1484/TS2693.

Import and explicitly export the three canonical schemas at the package root so each name works as both a type and a value. Local bindings are necessary: direct export … from still fails declaration generation with TS4033/TS4081. Resource declarations, schema identity, runtime validation, and the root-only package API are preserved.

Related work and roadmap

This independent fix targets main and keeps consumers on the supported shared-contract entrypoint. It complements the persistence extraction in #128 and dependency-boundary tooling in #149/#150, supporting the target design's package ownership.

Before and after

flowchart LR
  subgraph B["Before"]
    direction TB
    B1["TypeScript consumer"] --> B2["contracts package root"]
    B2 --> B3["Schema value use<br/>fails TypeScript"]
  end
  subgraph A["After"]
    direction TB
    A1["TypeScript consumer"] --> A2["Same package root<br/>with explicit bindings"]
    A2 --> A3["Types and schema values<br/>compile"]
  end

Loading

Validation

Recorded during implementation:

• The same NodeNext consumer fails on main and passes with the fix; canonical schema identity passes.
• 9 focused contract tests passed with no failures or skips. Clean workspace typecheck, formatting, workspace isolation, OpenAPI, and CI suite-registration checks passed (Node 24.20.0, TypeScript 7.0.2, pnpm 11.15.1).
• 17 documentation tests and the length check passed using Node 24.16.0.
• Independent verification of equivalent source preserved all 100 runtime root exports and compiled consumers of freshly emitted declarations.

Coverage is source, declarations, and local contract behavior.

[kevinlin-openai]

Two P2 checker edge cases reproduced against this head using native Node loading and the actual module-boundary checker. The existing PR tests I ran passed; these findings concern valid import patterns added in isolated fixtures. A checker failure stops pnpm test, pnpm test:conformance, pnpm test:integration, and pnpm test:postgres before their tests run.

[kevinslin]

is this necessary? why can't we just have all dependencies we need exported at the root module? this adds a lot of complexity and duplicates node module resolution logic

[kevinslin]

we should remove testing for this. the tests are just slop. we don't need tests for exporting a module

[freeqaz-openai]

closing this and folding it into #141 instead since it's literally 3 lines now