Remove the knowledge modules #118 left unreachable

[NathanTarbert]

What this changes

Removes the knowledge/ modules that #118 left with no importer, and records why the three tables have to wait.

#118 closed with:

The three tables and the knowledge/ modules are read by nothing after this and should be dropped in a change that says so, rather than as a side effect of this one.

This is the half that can be done at f1701d8.

What went

• server/src/knowledge/acl.ts, repository.ts, types.ts — the directory is gone
• server/tests/knowledge-acl.test.ts (3 tests) and server/tests/knowledge-repository.test.ts (2 tests), which were the only importers

Across every .ts, .tsx, .md, .yaml and .json in the repo, nothing else referenced them.

They are also not a head start on anything #119 wants. InMemoryKnowledgeRepository holds documents, chunks and ACLs in a Map in the server process — the shape #21 took back, for the reason #21 gives. canRead(actor, entries[]) filters ACL rows already pulled into memory, where the rule this repo follows is that the predicate belongs in SQL. Keeping either as a reference would point the next person at the version that has to be thrown away.

Why the tables are still here

#97 has not merged. server/src/connectors/sync-persistence.ts still imports documents, chunks, document_acls, connector_cursors and sync_runs and writes to all of them, so dropping the tables and their schema exports fails typecheck in that file. #118's scope note assumed #97 had landed; only the first half of that condition holds today.

Worth adding, because it decides how urgent this is: sync-persistence.ts is already orphaned at runtime. createSyncPersistence's only caller is its own integration test (server/tests/sync-persistence.integration.test.ts:53), and nothing in server/src wires it up. Same for runConnector, called only from worker/tests/connector-runner.test.ts. So this is a typecheck dependency, not a live one — nothing is writing to those tables in a running deployment.

Two ways to finish it, and it is your call which:

1. Wait for Answer from Google Drive, as the person asking #97, which removes sync-persistence.ts and the worker runner. The drop then becomes a clean schema-only commit, which is what Do not search documents out of our own database #118 described.
2. Take sync-persistence.ts into that commit, which removes more than the tables and overlaps Answer from Google Drive, as the person asking #97's diff.

Happy to do either. The second overlaps #97's diff, which is the reason this PR stops at the modules.

Adjacent, and deliberately left

• connector_instances — live. server/src/connectors.ts selects, updates and inserts against it from production code.
• connector_cursors, sync_runs — referenced only by sync-persistence.ts and schema.test.ts. Connector-side rather than document-index, so they go or stay with Answer from Google Drive, as the person asking #97.
• webhook_subscriptions (core.ts:347) — referenced nowhere at all, not even a test. Genuinely dead, but it is connector plumbing rather than the document index, and removing it here would be scope creep on my own reading. Flagging it instead.
• server/src/agents/knowledge-agent.ts — also has no caller but its own test, and it sits in agents/ rather than knowledge/, so it is outside what Do not search documents out of our own database #118 named. It takes an injected search port, which is at least the shape K3 — Search is a tool call, and retrieval belongs over the tools #119 endorses. Mentioning it rather than quietly deleting it.
• Docs unchanged. docs/architecture.md:22 and README.md:221 describe pgvector holding "knowledge records", which stays true while the tables exist. Those paragraphs become wrong in the same commit that drops them, so they belong there.

Where it runs

All five answers are none. No new state outliving a request, nothing different on a second replica, nothing serialised, nothing fanned out to a browser, no new listener, port or schedule. This deletes in-memory modules that had no callers.

Boundary and audit

• N/A. No gateway, policy, or audit path touched.

Changelog

No entry. Nothing runtime-reachable changed and no schema moved, so no deployment behaves differently. #118's existing Unreleased → Changed entry already states the direction and names the three tables.

For whoever writes the commit that drops them: it destroys data. DROP TABLE documents CASCADE takes the chunk and ACL rows with it, and any deployment that connected a source before #113 was reverted has real rows there. That needs a plainly worded comment in the migration and an "Upgrading" entry, because rollback cannot recover it.

Proof

No migration and no schema change, so the migrations job has nothing to react to. Both of its steps run clean and leave the tree alone:

$ bunx drizzle-kit check --config=drizzle.config.ts
Everything's fine 🐶🔥

$ bunx drizzle-kit generate --config=drizzle.config.ts --name=ci_drift_probe
No schema changes, nothing to migrate 😴

Against unmodified main at f1701d8 on this machine:

	main	this branch
bun run test	918 pass, 8 skip, 112 fail, 1038 / 105 files	913 pass, 8 skip, 112 fail, 1033 / 103 files
bunx biome lint .	25 warnings, 1 info	identical
format:check / typecheck / build	clean	clean

The whole difference is the 5 tests in the 2 deleted files. The 112 failures are the Postgres integration set, unchanged; there is no database and no Docker here and they fail the same way on a clean checkout, which is what the CI tests job runs pgvector for. 1033 is well clear of the 400-test floor in scripts/test-ci.ts.

[davidmckayv]

Verified against origin/main, and every claim in the description holds.

Nothing outside the two deleted test files imports knowledge/acl, knowledge/repository or knowledge/types in any .ts, .tsx, .md, .json or .yaml in the tree. createSyncPersistence and runConnector each have exactly one caller and it is their own test, so sync-persistence.ts is a typecheck dependency on those three tables rather than a live writer. webhookSubscriptions is declared at core.ts:347 and appears nowhere else outside the migration SQL and the snapshots. All five checks pass.

You were right not to keep either module as a reference. InMemoryKnowledgeRepository holds the corpus in a process-local Map, which is the thing #21 took back, and canRead filters ACL rows in application memory when the predicate belongs in SQL. Pointing the next person at the version that has to be thrown away is worse than pointing them at nothing.

On your question: option 1. Wait for #97. It is open and it removes sync-persistence.ts and the worker runner, which is exactly the blocker you identified. Taking that file into the drop commit would overlap Guido's diff for no gain, and given the tables have no live writer there is nothing to be gained by hurrying.

Two things for whoever writes that commit. The data-loss note is right and belongs in the migration itself, plainly worded, plus an Upgrading entry. And the docs at docs/architecture.md:22 and README.md:221 go stale in the same commit that drops the tables, so they change there.

webhook_subscriptions and knowledge-agent.ts: flagging rather than sweeping up was the right call. Both are worth their own change.