Summary
Beyond the tool handlers addressed in #14, 28+ callsites in non-tool files import _getAdapter() from gsd-db.ts and issue raw SQL directly. These are application-layer modules doing DB work through the internal adapter instead of through named port functions.
Related
Split from #14 which covers the tools/ directory. Same architectural violation, different scope.
Callsites
| File |
Callsites |
Nature |
memory-store.ts |
11 |
Entire module is a DB abstraction layer — should be promoted into gsd-db.ts or use its public API |
context-store.ts |
3 |
Same pattern as memory-store |
db-writer.ts |
3 |
Lower-level module |
workflow-manifest.ts |
1 |
requireDb() helper wrapping _getAdapter() |
workflow-projections.ts |
1 |
Live-DB probe |
workflow-migration.ts |
3 |
Migration utility |
md-importer.ts |
2 |
Import + nullcheck |
auto-post-unit.ts |
1 |
Rogue detection query |
triage-resolution.ts |
1 |
|
commands-maintenance.ts |
1 |
Bulk DELETE during recover |
commands-inspect.ts |
1 |
Admin inspection |
doctor-engine-checks.ts |
1 |
Integrity checks |
Impact
Same as #14 — any schema change, column rename, or DB migration must audit raw SQL scattered across 12+ files outside the DB module. The single-writer architecture's port layer exists precisely to centralize this, but these files bypass it.
Approach
Each file needs individual investigation to determine whether:
- An existing
gsd-db.ts function already covers the query (just swap the call)
- A new named function needs to be added to
gsd-db.ts
- The module itself belongs inside the DB layer (e.g.
memory-store.ts with 11 callsites may be better merged into gsd-db.ts)
Priority: memory-store.ts (11 callsites) and context-store.ts (3 callsites) are the biggest offenders.
Files
All files are under src/resources/extensions/gsd/:
memory-store.ts
context-store.ts
db-writer.ts
workflow-manifest.ts
workflow-projections.ts
workflow-migration.ts
md-importer.ts
auto-post-unit.ts
triage-resolution.ts
commands-maintenance.ts
commands-inspect.ts
doctor-engine-checks.ts
Summary
Beyond the tool handlers addressed in #14, 28+ callsites in non-tool files import
_getAdapter()fromgsd-db.tsand issue raw SQL directly. These are application-layer modules doing DB work through the internal adapter instead of through named port functions.Related
Split from #14 which covers the
tools/directory. Same architectural violation, different scope.Callsites
memory-store.tsgsd-db.tsor use its public APIcontext-store.tsdb-writer.tsworkflow-manifest.tsrequireDb()helper wrapping_getAdapter()workflow-projections.tsworkflow-migration.tsmd-importer.tsauto-post-unit.tstriage-resolution.tscommands-maintenance.tscommands-inspect.tsdoctor-engine-checks.tsImpact
Same as #14 — any schema change, column rename, or DB migration must audit raw SQL scattered across 12+ files outside the DB module. The single-writer architecture's port layer exists precisely to centralize this, but these files bypass it.
Approach
Each file needs individual investigation to determine whether:
gsd-db.tsfunction already covers the query (just swap the call)gsd-db.tsmemory-store.tswith 11 callsites may be better merged intogsd-db.ts)Priority:
memory-store.ts(11 callsites) andcontext-store.ts(3 callsites) are the biggest offenders.Files
All files are under
src/resources/extensions/gsd/:memory-store.tscontext-store.tsdb-writer.tsworkflow-manifest.tsworkflow-projections.tsworkflow-migration.tsmd-importer.tsauto-post-unit.tstriage-resolution.tscommands-maintenance.tscommands-inspect.tsdoctor-engine-checks.ts