▸ AGENT NEO: BACKEND SOFTWARE DEVELOPER

open_question specialist:postgres

**NULL `FileSizeBytes`**: per the plan's risk note, files with unknown size are *included* and ranked lowest (DESC NULLS LAST). A project whose only files have NULL sizes still returns one row. Confirm unknown-size files shouldn't be excluded entirely.

Accept

Dismiss

open_question specialist:postgres

**Tie-break**: equal max sizes resolve by earliest `InsertedOn`, then `FileReferenceId`. Confirm acceptable.

Accept

Dismiss

deviation specialist:api2

**File paths.** The spec's `files:` list names `src/api/v2/projects/files/files.{routes,controller}.ts` and `src/services/files.service.ts`. Those do not exist. The real resource in this repo is `projectfiles` (mounted at `/api/v2/projects/:projectId/files`, service `src/services/projectfiles.service.ts`). I implemented into the existing `projectfiles` files to follow the actual convention instead of creating a parallel, conflicting `files/` tree.

Accept

Dismiss

deviation specialist:api2

**Response shape.** "Full file metadata" is rendered as the same per-item shape the list endpoint returns (`fileReferenceId, fileName, fileExtension, xyzDisplayName, fileSizeBytes, fileHash, createdBy, insertedOn, lastModifiedBy, lastModifiedOn`) — deliberately excluding `downloadUrl` / `CloudStoragePath`, since this is a read-only metadata endpoint.

Accept

Dismiss

open_question specialist:api2

**`fn_GetBiggestFile` must be created in the database.** DB function definitions are not housed in this repo (the e2e dump under `docker/test-data-dump/` only seeds rows). A separate DB-migration change must add `xyz."fn_GetBiggestFile"(projectId)` that (a) returns the single largest non-soft-deleted `xyz.FileReference` row by `FileSizeBytes`, and (b) raises an error containing "No project found for ProjectId" when the project does not exist — that text is what the service maps to a `404`. Until that function and an empty test project (`TestProjects.ProjectId6`) are in the seeded DB, the e2e h

Accept

Dismiss

open_question specialist:api2

Confirm `IMAGE_VIEW` is the intended authority for this read endpoint (chosen to match the sibling `GET /files` and `GET /files/:fileReferenceId` routes).

Accept

Dismiss

open_question specialist:api2

Confirm the desired empty-project response is literally `200` with a JSON `null` body (as the spec states) rather than `204 No Content`.

Accept

Dismiss

deviation specialist:postgres

**`fn_GetProjectShardId` raises, it does not return NULL.** The plan's notes describe the 404 path as "fn_GetProjectShardId returning NULL/no shard"; the actual function `RAISE`s an exception for an unknown project. This still produces the intended 404 at the API2 layer (the error propagates), so the function is unchanged. The integration test therefore does **not** call `fn_GetBiggestFile` with a non-existent project (that path raises by design and is the API2 specialist's 404 concern, not a Postgres zero-rows case).

Accept

Dismiss

deviation specialist:postgres

No schema changes, no constraints, no indexes (`index_changes: none`). Nothing added to `999_indexes.sql`.

Accept

Dismiss

deviation specialist:postgres

**Column coverage:** the function returns the full egress column set listed in the plan's `response_dto` (fileReferenceId, projectId, fileName, fileExtension, xyzDisplayName, description, cloudStoragePath, insertedOn, createdBy, lastModifiedBy, lastModifiedOn, fileSizeBytes, fileHash, importedFromCDE, thirdPartyFileId). No table column was added/removed, so no read/write procs needed amending.

Accept

Dismiss

open_question specialist:postgres

**NULL-size files** — confirm files with unknown `FileSizeBytes` should remain eligible (ranked lowest) rather than excluded entirely (matches the plan's stated design).

Accept

Dismiss

open_question specialist:postgres

**Tie-break** — confirm earliest `InsertedOn` then `FileReferenceId ASC` is the desired deterministic tie-break on equal maximum sizes.

Accept

Dismiss

deviation specialist:api2

**`fn_GetBiggestFile` is a new DB function** that lives in the external database repo (`${DATABASE_REPO_PATH}/PostgreSQLDatabase`, mounted via `docker/docker-compose.yml`), not in api2. Per the spec ("no schema changes"; file list contains no SQL) it was **not** added here. ⚠️ The e2e tests for `/biggest` will only pass once `fn_GetBiggestFile` exists in the database repo / e2e schema. If it is not yet deployed there, those e2e cases will 500. Please confirm the DB function has been (or will be) added in the database repo before merge.

Accept

Dismiss

deviation specialist:api2

Resource naming: implemented on `projectfiles` (the real resource) rather than the spec's non-existent `files` path. Flagging in case the spec intended a separate resource.

Accept

Dismiss