All contributors have signed the CLA. ✅
_{Posted by the CLA Assistant Lite bot.}

I have read the CLA Document and I hereby sign the CLA

Hey @KIvanow 👋

I’ve been playing around with BetterDB and really like what you’re building, especially the MCP integration and semantic cache. While going through the codebase, I came across a few areas that could use some cleanup or improvements and put together a few contributions.

Happy to iterate based on your feedback. No rush at all

Hey @Vswaroop04 , thank you so much for the contribution!

Thanks for the clean refactor - the intent is right. A few things to address before this can merge:

1. Dependency direction in connections.dto.ts
   Importing from connection-registry.service inside a DTO inverts the layering — DTOs should have no knowledge of the service layer. While there's no circular dependency today, this is fragile. The fix is to extract the constant to a dedicated file:

// apps/api/src/connections/connection.constants.ts
export const ENV_DEFAULT_ID = 'env-default';

Then import from there in both the service and the DTO. As a bonus, the seed scripts could also import from this file directly (it has no NestJS dependencies), eliminating the local duplicate copies.

2. SQL injection pattern in seed-demo-data-pg.ts
   // current
   WHERE connection_id <> '${ENV_DEFAULT_ID}'

String interpolation in SQL is the injection pattern regardless of whether the value is currently safe. Please use a parameterized query:

pool.query(
SELECT connection_id, source_host, source_port FROM command_log_entries WHERE connection_id <> $1 ORDER BY captured_at DESC LIMIT 1,
[ENV_DEFAULT_ID]
)

3. Unsigned commits

The commit 130c0e4 is not GPG-signed.

Hey @Vswaroop04 all three issues from the first review are cleanly addressed, thanks for the quick turnaround. One last
minor thing before this merges:

connection-registry.service.spec.ts still imports ENV_DEFAULT_ID from '../connection-registry.service' (the re-export)
rather than from '../connection.constants' directly:

// current
import { ConnectionRegistry, ENV_DEFAULT_ID } from '../connection-registry.service';

// preferred
import { ConnectionRegistry } from '../connection-registry.service';
import { ENV_DEFAULT_ID } from '../connection.constants';

The re-export works, but it slightly undermines the extraction - the spec is still coupled to the service for a value that now lives independently. A one-line import split fixes it. After that this is good to go.