fix(service-knowledge): put the test layer in front of tsc, and repair the four defects it was hiding

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.

[os-sales]

Fixes#15049

Clause-②: no

The gap, and which exemplar this is copied from

packages/services/service-knowledge had no typecheck script at all —
its scripts were build and test — so no tsc program anywhere read this
package. Turbo/CI typecheck lanes skipped it silently (a zero-matching filter
run exits 0); tsup transpiles with esbuild and vitest runs through esbuild
type-stripping; neither type-checks. Errors were carried instead as a
DEBT entry of 10 in scripts/check-type-check-coverage.mjs.

Copied from @objectstack/service-cluster (#14181 / PR #15032), the
worked example this card names — not from plugin-auth / plugin-sharing /
core, whose tsconfig.jsonexcludes tests, because AGENTS.md forbids
adding such an exclusion. service-knowledge's tsconfig.json does not
exclude tests (include: ["src"], no **/*.test.ts exclusion) and never
did — the same shape as service-cluster and plugin-webhooks — so the
program that would have read them already existed and was simply never
invoked. tsconfig.json is therefore untouched; the sibling
tsconfig.test.json is the family's uniform instrument over the same files.

Measured error count, before and after

Dependency closure built first (pnpm --filter '@objectstack/service-knowledge^...' build),
measured at merge-base 2cc4610304:

program	before	after
BUILD semantics (tsc --noEmit -p tsconfig.json, undivided)	10	0
test layer (tsc --noEmit -p tsconfig.test.json, the split)	4	0

409 files in the test program (441 in the build program — the gap is dist
declaration-variant granularity for the same three workspace deps under
NodeNext vs bundler resolution, .d.ts/.d.cts chunk files vs .d.mts, not
a difference in which of this package's own src/test files are read),
covering all 4 of the package's src/__tests__/*.test.ts.

The undivided 10 matched the DEBT entry this PR deletes exactly — 3 TS2835
(config-tier: three relative test imports missing .js, required by
moduleResolution: NodeNext) + 4 TS7006 (noise: the unresolved imports make
KnowledgeService resolve to any, cascading into every
out.map((h) => h.documentId) callback over its search results) + 3 code-tier
the ledger's note itemised (TS2339/TS2352/TS2493).

The split did NOT confirm the ledger's 3-code-tier guess — it read 4. This
is the same "a tier split read off an unrepaired config is a guess about what
is UNDER it" lesson scripts/check-type-check-coverage.mjs already states for
@objectstack/metadata and @objectstack/service-storage: fixing the 3
TS2835 removed the any cascade, and doing so re-enabled a TypeScript
excess-property check the cascade had been silently suppressing —
uncovering a 4th real error the undivided reading had masked completely.

The four code-tier defects — all in the test file's own typing, src/ untouched

1. A stale field name.executionContext: { userId: 'u1', roles: ['member'], permissions: [], isSystem: false }
   — roles was renamed to positions (execution-context.zod.ts:
   "Position names held by the user … Formerly roles"). Every other
   executionContext literal in this file already used positions; this one
   simply had never been read by a type checker before, so nothing ever
   caught it. TS2353 (excess property) once the excess-property check could
   see it. Fixed by renaming the field — ExecutionContext itself is correct
   and untouched.
2. An under-typed mock.buildSetup's vi.fn() stand-in for
   IDataEngine.find typed its second parameter as
   { context: { isSystem?: boolean } }, omitting the where field the real
   call site (knowledge-service.ts's RLS re-check) actually passes.
   expect(opts.where).toEqual(...) then read a property TypeScript correctly
   said did not exist (TS2339). Fixed by widening the mock's parameter type to
   match the call it stubs — where and fields added — never by loosening
   the assertion.
3. Two more mocks with no parameter type at all. A find = vi.fn(async () => [...])
   in the reindex test had zero declared parameters, so TypeScript inferred a
   0-arity implementation and typed .mock.calls as an array of empty
   tuples. find.mock.calls[0][1] then indexed past a fixed-length-0 tuple
   — a genuine TS2493 — and the as { context: {...} } cast off the resulting
   undefined compounded into TS2352. Fixed by typing the mock's parameters
   to match the real reindexSource call site (where, limit, context);
   the assertion no longer needs its as cast at all.

Why these and not a widened ExecutionContext or a looser IDataEngine
stub: the spec contract is correct in both cases (the field really was
renamed; find really is called with where/fields/limit) — the defect
was in the test's typing of its own doubles, so the test is where it is
fixed. This is the same contract-first call PR #15032 made for
service-cluster's TS2322 (fix the test, not the contract it stubs).

The three TS2835 — repaired directly, not routed around

.js added to the three relative specifiers
(../knowledge-service-plugin → ../knowledge-service-plugin.js,
../knowledge-service → ../knowledge-service.js ×2). Unlike
service-cluster, whose test files already carried the extension (undivided
and split agreed at 1 both times), this package's did not — and because
tsconfig.json genuinely includes the tests and stays untouched (excluding
them is the one thing AGENTS.md forbids), the package's own typecheck
script's bare tsc --noEmit tsconfig.json step reads these same files under
NodeNext regardless of the new sibling config. They needed fixing either way;
the fix is exactly what TS2835's own message names (Did you mean '../knowledge-service.js'?), not a config change.

tsconfig.test.json

Module semantics only — module: esnext, moduleResolution: bundler,
lib: ["ES2022"] — matching how vitest actually executes these files.
Strictness is inherited and untouched, and it declares no paths (a child's
paths would REPLACE the parent map rather than merge). package.json gains
typecheck / check:test-typecheck, both scripts checked against the
required spellings check-type-check-coverage.mjs and
check-test-typecheck.mts --self-test/--project name.

No test-typecheck-debt.json is created — its absence is the zero: the
gate reads a missing ledger as no entries, so any error in any file here
would be red immediately with nothing to add an entry to.

Ledger consequences

• DEBT entry deleted, not lowered.check-type-check-coverage.mjs
  carried '@objectstack/service-knowledge': { errors: 10, note: '...' }.
  That gate's own invariant — covered packages must not also sit in the
  ledger — makes this a structural requirement, not a courtesy. Deleted, with
  the graduation and its real composition recorded in the file's prose (the
  same convention service-cluster's graduation used).
• No test-typecheck-debt.json — see above.

⚠️check:type-source-resolution — an onboarding re-baseline, please review it as one

Went red on my diff, same shape PR #15032 hit for service-cluster:
onboarding tsconfig.test.json moves the package's tsc PROGRAM SET, and the
gate's doc-block opens an explicit onboarding limb for exactly this.

Term 1 — provenance, all three deps annotated via tsconfig.test.json by
the gate's own failure text; the BUILD program (tsconfig.json) carries zero
dist-resolved workspace type imports both before and after this PR (confirmed
by direct measurement, not inferred), so the exposure is only reachable
through the onboarded program.

Term 2 — numbers, --list before/after on the same checkout (before at
the service-cluster merge, 2cc4610304; after with this card applied):

	packages	programs	pairs	clean
before	58 of 78	119	290	20
after	59 of 78	120	293	19

+1 package, +1 program, +3 pairs — this entry (@objectstack/core,
@objectstack/objectql, @objectstack/spec) and nothing else.

Term 3 — why the entry and not paths, measured both ways. Redirecting
the three deps to source takes this package's test layer from 0 errors to
487, all TS6059 (not under rootDir) and every one in another
package's source (packages/spec/src/**, packages/core/src/**,
packages/objectql/src/**) — billed to a package that cannot pay them down.
Same shape as service-cluster's own 0 → 435 and #12570's +5 for rest, at a
larger scale here because three workspace deps are pulled rather than two.

Gates

Derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands
on the rebased head 2969cef816, plus the roster-silent families this diff's
paths sit inside (check:error-code-casing, check:filter-alias-parity,
check:i18n-stale-fill, check:published-readme-exports,
check:published-list-mirrors, check:swallow-census-controls,
check:authz-resolver, check:console-injection) — silent verdicts read
against a roster, not against these paths, so run rather than trusted.
Exit codes captured redirect-then-read, never across a pipe.

73 gates run: 70 exit 0, 2 exit 3 (NOT MEASURED), 1 exit 1 that is also NOT
MEASURED in substance (below) , 0 red.

NOT MEASURED, quoting each gate's own verdict:

• check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this
  gate reads built output, and some package has no dist/." Zero mentions of
  service-knowledge in its output.
• check:type-check-debt — exit 3: "check-type-check-coverage:
  PREREQUISITE NOT MET … --re-measure cannot run: 18 workspace
  dependenc(ies) of the ledgered packages have no built type entry point on
  disk."service-knowledge graduated out of this ledger in this PR, so it
  is not among the 18.
• check:published-readme-exports — exit 1 (a genuine finding, not this
  gate's own NOT-MEASURED code), but its 84 findings are every OTHER
  unbuilt workspace package's README pointing at a missing dist/. It
  named service-knowledge twice before I built this package's own dist
  (pnpm --filter @objectstack/service-knowledge build); re-run after that
  build: 0service-knowledge mentions, 84 remain for packages this
  card does not touch. None of the three above is evidence about this
  diff — building the other ~60 unbuilt packages is CI's pnpm build step,
  not a scoped card's local obligation.

Package-level, on the final head: pnpm --filter @objectstack/service-knowledge typecheck
exit 0, and pnpm --filter @objectstack/service-knowledge test — 4 files / 40
tests passed.

Declined, with reasons

• ExecutionContext untouched — the test's roles field was stale, the
  contract's renamed positions field is correct.
• No paths rules added — measured at +487 TS6059 in other packages'
  source (above).
• No test skipped, disabled or quarantined; no program narrowed; no
  @ts-expect-error / @ts-ignore added; strict untouched.
• packages/spec not touched (single-owner lane) — only read, to confirm
  the ExecutionContext field rename.
• No content/docs/releases edit.
• Sibling packages/services/* packages with the same gap — not touched.
  service-automation and service-storage still lack a typecheck script
  (dispatched separately, tooling(services): service-automation has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15048 / tooling(services): service-storage has no typecheck script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181) #15050). The family-per-card pattern is
  deliberate.

Changeset

.changeset/service-knowledge-test-tsc-program.md, patch on
@objectstack/service-knowledge. No runtime code changed — src/**
excluding tests is byte-identical, verified — so no shipped behaviour moves;
the level reflects the published package.json gaining typecheck /
check:test-typecheck scripts and a tsx devDependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AUF1NoViznQK32gqpK8wS8

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1876d5dfd8f309483ef424e7ddd69919409a06dc → packageMentionDocs.