feat: add DAL (CM-951)

[ulemons]

Note

Medium Risk
Adds new SQL DAL surfaces for reading/writing projectCatalog and evaluatedProjects, including bulk insert/upsert and status transitions; risk is mainly around correctness of new queries and JSON/typing conversions against the existing schema.

Overview
Adds new DAL modules for projectCatalog and evaluatedProjects, exposing typed CRUD/query functions (single lookups, listing with pagination, counts, and deletes) and wiring them into the library exports.

Includes bulk insert/upsert helpers (via jsonb_to_recordset) and specialized update helpers such as markEvaluatedProjectAsEvaluated, markEvaluatedProjectAsOnboarded, and a join query to fetch pending evaluated projects with catalog metadata.

^{Written by Cursor Bugbot for commit 82f29d9. This will update automatically on new commits. Configure here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull request overview

Adds new Data Access Layer (DAL) modules for the project catalog and evaluated projects domain, and re-exports them from the DAL package entrypoint.

Changes:

• Introduces project-catalog DAL: types plus CRUD-ish query helpers (find/insert/bulk insert/upsert/update/delete).
• Introduces evaluated-projects DAL: types plus query helpers for evaluation lifecycle and bulk insert.
• Exports both modules via services/libs/data-access-layer/src/index.ts.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
services/libs/data-access-layer/src/project-catalog/types.ts	Defines DB-facing types for project catalog records and create/update payloads.
services/libs/data-access-layer/src/project-catalog/projectCatalog.ts	Adds SQL helpers for selecting/inserting/upserting/updating/deleting project catalog rows.
services/libs/data-access-layer/src/project-catalog/index.ts	Barrel export for the project-catalog module.
services/libs/data-access-layer/src/evaluated-projects/types.ts	Defines DB-facing types for evaluated projects and create/update payloads.
services/libs/data-access-layer/src/evaluated-projects/evaluatedProjects.ts	Adds SQL helpers for evaluated project operations (find/insert/bulk insert/update/mark evaluated/onboarded/delete).
services/libs/data-access-layer/src/evaluated-projects/index.ts	Barrel export for the evaluated-projects module.
services/libs/data-access-layer/src/index.ts	Re-exports the newly added modules from the DAL package entrypoint.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In bulkInsertEvaluatedProjects, values pre-serializes evaluation with JSON.stringify(...), but the SQL recordset defines evaluation jsonb. This will cause the inserted JSONB to become a JSON string (or fail coercion), rather than storing the object. Pass the evaluation object directly in values (let JSON.stringify only happen once for the whole values payload) and keep the SQL cast to jsonb.

Suggested change

	evaluation: item.evaluation ? JSON.stringify(item.evaluation) : null,
	evaluation: item.evaluation ?? null,

[Copilot]

The DB migration for "projectCatalog" defines "ossfCriticalityScore" and "lfCriticalityScore" columns (backend/src/database/migrations/V1770653666__add-automatic_projects_discovery-tables.sql), but this DAL type uses a single criticalityScore field. As written, the queries in this module will select/insert/update a column that doesn't exist. Align the DAL types with the actual schema (e.g., expose both score columns, or rename to match whichever column you intend to persist).

[Copilot]

PROJECT_CATALOG_COLUMNS includes criticalityScore, but the "projectCatalog" table (per backend/src/database/migrations/V1770653666__add-automatic_projects_discovery-tables.sql) does not have a "criticalityScore" column (it has "ossfCriticalityScore" and "lfCriticalityScore"). This will cause runtime SQL errors on SELECT/RETURNING. Update the selected column list to match the real table columns.

Suggested change

	const PROJECT_CATALOG_COLUMNS = [
	'id',
	'projectSlug',
	'repoName',
	'repoUrl',
	'criticalityScore',
	'syncedAt',
	'createdAt',
	'updatedAt',
	]
	const PROJECT_CATALOG_COLUMNS = [
	'id',
	'projectSlug',
	'repoName',
	'repoUrl',
	'ossfCriticalityScore',
	'lfCriticalityScore',
	'syncedAt',
	'createdAt',
	'updatedAt',
	]

[Copilot]

insertProjectCatalog is inserting into a "criticalityScore" column, which does not exist in the current "projectCatalog" schema (see backend/src/database/migrations/V1770653666__add-automatic_projects_discovery-tables.sql). This INSERT will fail at runtime. Change the INSERT/params to use the actual score column(s) defined by the table.

[Copilot]

upsertProjectCatalog uses "criticalityScore" in both the INSERT column list and the ON CONFLICT update, but the table schema defines "ossfCriticalityScore" / "lfCriticalityScore" instead. This will error at runtime and also means conflicts won't update the intended score fields. Update the statement to target the actual column name(s).

[Copilot]

IDbEvaluatedProjectCreate allows onboarded/onboardedAt/evaluatedAt, but the insert/bulk-insert queries in evaluatedProjects.ts never write those columns (only defaults apply). This makes the API misleading and can silently ignore caller intent. Either remove these fields from the create type or include them in the INSERT statements (with appropriate default/null handling).

[Copilot]

IDbEvaluatedProjectUpdate types nullable DB columns (e.g. evaluationScore, evaluationReason, evaluatedAt, counts) as non-nullable (number/string). That prevents clearing fields (setting to NULL) even though the table schema allows it. Consider typing these as number | null / string | null etc. so updates can intentionally null out values when needed.

Suggested change

	evaluationScore?: number
	evaluation?: Record<string, unknown>
	evaluationReason?: string
	evaluatedAt?: string
	starsCount?: number
	forksCount?: number
	commitsCount?: number
	pullRequestsCount?: number
	issuesCount?: number
	onboarded?: boolean
	onboardedAt?: string
	}
	export type IDbEvaluatedProjectUpdate = Partial<{
	evaluationStatus: EvaluationStatus
	evaluationScore: number
	evaluation: Record<string, unknown>
	evaluationReason: string
	evaluatedAt: string
	starsCount: number
	forksCount: number
	commitsCount: number
	pullRequestsCount: number
	issuesCount: number
	onboarded: boolean
	onboardedAt: string
	evaluationScore?: number | null
	evaluation?: Record<string, unknown> | null
	evaluationReason?: string | null
	evaluatedAt?: string | null
	starsCount?: number | null
	forksCount?: number | null
	commitsCount?: number | null
	pullRequestsCount?: number | null
	issuesCount?: number | null
	onboarded?: boolean
	onboardedAt?: string | null
	}
	export type IDbEvaluatedProjectUpdate = Partial<{
	evaluationStatus: EvaluationStatus
	evaluationScore: number | null
	evaluation: Record<string, unknown> | null
	evaluationReason: string | null
	evaluatedAt: string | null
	starsCount: number | null
	forksCount: number | null
	commitsCount: number | null
	pullRequestsCount: number | null
	issuesCount: number | null
	onboarded: boolean
	onboardedAt: string | null

[Copilot]

insertEvaluatedProject ignores onboarded, onboardedAt, and evaluatedAt even though they are part of the writable model/type. This can lead to unexpected behavior if callers pass these fields (they'll be silently dropped). Include these columns in the INSERT (or remove them from the create type if they should only be set via dedicated update helpers).

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[themarolt]

@ulemons please check cursor bugbot comments - I think some are pretty valid.