Search code, repositories, users, issues, pull requests...

+# 2. Copy ONLY the prisma folder next to cache the Prisma Client generation
+COPY prisma ./prisma/
+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Dockerfile copies only prisma/ and then runs prisma generate before COPY . .. In this
repo, schema.prisma defines only the datasource provider and relies on prisma.config.ts to
provide the datasource URL via env('DATABASE_URL'). Therefore, prisma generate is executed
without the config file present.

Dockerfile[11-44]
prisma/schema.prisma[7-10]
prisma.config.ts[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npx prisma generate` is executed before `prisma.config.ts` exists in the Docker build context inside the image. In this repo the datasource URL is defined via `prisma.config.ts`, while `schema.prisma` does not define a `url`, so the generate step can fail.
### Issue Context
The Dockerfile copies only `prisma/` and then runs Prisma generation. The repo uses `prisma.config.ts` to supply `datasource.url` via `env(&amp;amp;amp;amp;#x27;DATABASE_URL&amp;amp;amp;amp;#x27;)`.
### Fix Focus Areas
- Dockerfile[11-44]
- prisma.config.ts[1-8]
- prisma/schema.prisma[7-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

9. ~~Prisma config missing at generate~~ ☑ 🐞 Bug ✓ Correctness

Description

npx prisma generate runs before prisma.config.ts is copied into the image, but this repo defines
the Prisma datasource URL in prisma.config.ts (the schema has no url), so Docker builds can fail
at the generate step.

Code

+# 2. Copy ONLY the prisma folder next to cache the Prisma Client generation
+COPY prisma ./prisma/
+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Dockerfile copies only prisma/ and then runs prisma generate before COPY . .. In this
repo, schema.prisma defines only the datasource provider and relies on prisma.config.ts to
provide the datasource URL via env('DATABASE_URL'). Therefore, prisma generate is executed
without the config file present.

Dockerfile[11-44]
prisma/schema.prisma[7-10]
prisma.config.ts[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npx prisma generate` is executed before `prisma.config.ts` exists in the Docker build context inside the image. In this repo the datasource URL is defined via `prisma.config.ts`, while `schema.prisma` does not define a `url`, so the generate step can fail.
### Issue Context
The Dockerfile copies only `prisma/` and then runs Prisma generation. The repo uses `prisma.config.ts` to supply `datasource.url` via `env(&amp;amp;amp;amp;amp;#x27;DATABASE_URL&amp;amp;amp;amp;amp;#x27;)`.
### Fix Focus Areas
- Dockerfile[11-44]
- prisma.config.ts[1-8]
- prisma/schema.prisma[7-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

10. ~~Quoted BUILD_DATABASE_URL default~~ ☑ 📘 Rule violation ⛯ Reliability

Description

ARG BUILD_DATABASE_URL is defined with surrounding quotes, which may be passed verbatim into
DATABASE_URL and cause npx prisma generate to fail due to an invalid connection string. This
introduces a fragile build step without guarding against a malformed placeholder value.

Code

Dockerfile[15]
+ARG BUILD_DATABASE_URL="file:./dev.db"

Evidence

PR Compliance ID 3 requires handling potential failure points and edge cases; here the build creates
a placeholder DATABASE_URL for Prisma generation, but the placeholder is defined with quotes that
may make the URL invalid and break the build at the prisma generate step.

Rule 3: Generic: Robust Error Handling and Edge Case Management
Dockerfile[15-15]
Dockerfile[41-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`BUILD_DATABASE_URL` is declared with surrounding quotes, which can be propagated into `DATABASE_URL` and make the Prisma connection string invalid at build time.
## Issue Context
The Docker build runs `npx prisma generate` with `DATABASE_URL=${BUILD_DATABASE_URL}`. If the default value includes literal quotes, Prisma may reject the URL and fail the build.
## Fix Focus Areas
- Dockerfile[14-16]
- Dockerfile[40-41]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

11. ~~Quoted BUILD_DATABASE_URL default~~ ☑ 📘 Rule violation ⛯ Reliability

Description

ARG BUILD_DATABASE_URL is defined with surrounding quotes, which may be passed verbatim into
DATABASE_URL and cause npx prisma generate to fail due to an invalid connection string. This
introduces a fragile build step without guarding against a malformed placeholder value.

Code

Dockerfile[15]
+ARG BUILD_DATABASE_URL="file:./dev.db"

Evidence

PR Compliance ID 3 requires handling potential failure points and edge cases; here the build creates
a placeholder DATABASE_URL for Prisma generation, but the placeholder is defined with quotes that
may make the URL invalid and break the build at the prisma generate step.

Rule 3: Generic: Robust Error Handling and Edge Case Management
Dockerfile[15-15]
Dockerfile[41-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`BUILD_DATABASE_URL` is declared with surrounding quotes, which can be propagated into `DATABASE_URL` and make the Prisma connection string invalid at build time.
## Issue Context
The Docker build runs `npx prisma generate` with `DATABASE_URL=${BUILD_DATABASE_URL}`. If the default value includes literal quotes, Prisma may reject the URL and fail the build.
## Fix Focus Areas
- Dockerfile[14-16]
- Dockerfile[40-41]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

12. ~~Wrong placeholder DB URL scheme~~ ☑ 🐞 Bug ✓ Correctness

Description

BUILD_DATABASE_URL defaults to a SQLite-style file: URL even though Prisma is configured for
PostgreSQL; Prisma CLI typically validates datasource URLs against the provider, so `prisma
generate` (and/or later Prisma commands) may fail during docker build.

Code

Dockerfile[14-42]
prisma/schema.prisma[7-9]
.github/workflows/pull-request-testing.yaml[42-46]

+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Prisma datasource provider is PostgreSQL, but the Dockerfile sets a default build-time URL of
file:./dev.db. The repo’s CI uses a PostgreSQL connection string when running prisma generate,
indicating Prisma expects a postgres-formatted URL for this project.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dockerfile uses `BUILD_DATABASE_URL=&amp;amp;amp;amp;quot;file:./dev.db&amp;amp;amp;amp;quot;` as the placeholder URL, but Prisma is configured with `provider = &amp;amp;amp;amp;quot;postgresql&amp;amp;amp;amp;quot;`. This provider/URL mismatch can break `prisma generate` during docker builds.
### Issue Context
Repo CI uses a `postgresql://...` URL to run Prisma commands.
### Fix Focus Areas
- Dockerfile[14-41]
- prisma/schema.prisma[7-9]
- .github/workflows/pull-request-testing.yaml[42-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

13. ~~Wrong placeholder DB URL scheme~~ ☑ 🐞 Bug ✓ Correctness

Description

BUILD_DATABASE_URL defaults to a SQLite-style file: URL even though Prisma is configured for
PostgreSQL; Prisma CLI typically validates datasource URLs against the provider, so `prisma
generate` (and/or later Prisma commands) may fail during docker build.

Code

Dockerfile[14-42]
prisma/schema.prisma[7-9]
.github/workflows/pull-request-testing.yaml[42-46]

+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Prisma datasource provider is PostgreSQL, but the Dockerfile sets a default build-time URL of
file:./dev.db. The repo’s CI uses a PostgreSQL connection string when running prisma generate,
indicating Prisma expects a postgres-formatted URL for this project.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dockerfile uses `BUILD_DATABASE_URL=&amp;amp;amp;amp;amp;quot;file:./dev.db&amp;amp;amp;amp;amp;quot;` as the placeholder URL, but Prisma is configured with `provider = &amp;amp;amp;amp;amp;quot;postgresql&amp;amp;amp;amp;amp;quot;`. This provider/URL mismatch can break `prisma generate` during docker builds.
### Issue Context
Repo CI uses a `postgresql://...` URL to run Prisma commands.
### Fix Focus Areas
- Dockerfile[14-41]
- prisma/schema.prisma[7-9]
- .github/workflows/pull-request-testing.yaml[42-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

14. ~~Prisma config missing at generate~~ ☑ 🐞 Bug ✓ Correctness

Description

npx prisma generate runs before prisma.config.ts is copied into the image, but this repo defines
the Prisma datasource URL in prisma.config.ts (the schema has no url), so Docker builds can fail
at the generate step.

Code

+# 2. Copy ONLY the prisma folder next to cache the Prisma Client generation
+COPY prisma ./prisma/
+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Dockerfile copies only prisma/ and then runs prisma generate before COPY . .. In this
repo, schema.prisma defines only the datasource provider and relies on prisma.config.ts to
provide the datasource URL via env('DATABASE_URL'). Therefore, prisma generate is executed
without the config file present.

Dockerfile[11-44]
prisma/schema.prisma[7-10]
prisma.config.ts[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npx prisma generate` is executed before `prisma.config.ts` exists in the Docker build context inside the image. In this repo the datasource URL is defined via `prisma.config.ts`, while `schema.prisma` does not define a `url`, so the generate step can fail.
### Issue Context
The Dockerfile copies only `prisma/` and then runs Prisma generation. The repo uses `prisma.config.ts` to supply `datasource.url` via `env(&amp;amp;amp;amp;amp;#x27;DATABASE_URL&amp;amp;amp;amp;amp;#x27;)`.
### Fix Focus Areas
- Dockerfile[11-44]
- prisma.config.ts[1-8]
- prisma/schema.prisma[7-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

15. ~~Prisma config missing at generate~~ ☑ 🐞 Bug ✓ Correctness

Description

npx prisma generate runs before prisma.config.ts is copied into the image, but this repo defines
the Prisma datasource URL in prisma.config.ts (the schema has no url), so Docker builds can fail
at the generate step.

Code

+# 2. Copy ONLY the prisma folder next to cache the Prisma Client generation
+COPY prisma ./prisma/
+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Dockerfile copies only prisma/ and then runs prisma generate before COPY . .. In this
repo, schema.prisma defines only the datasource provider and relies on prisma.config.ts to
provide the datasource URL via env('DATABASE_URL'). Therefore, prisma generate is executed
without the config file present.

Dockerfile[11-44]
prisma/schema.prisma[7-10]
prisma.config.ts[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`npx prisma generate` is executed before `prisma.config.ts` exists in the Docker build context inside the image. In this repo the datasource URL is defined via `prisma.config.ts`, while `schema.prisma` does not define a `url`, so the generate step can fail.
### Issue Context
The Dockerfile copies only `prisma/` and then runs Prisma generation. The repo uses `prisma.config.ts` to supply `datasource.url` via `env(&amp;amp;amp;amp;amp;amp;#x27;DATABASE_URL&amp;amp;amp;amp;amp;amp;#x27;)`.
### Fix Focus Areas
- Dockerfile[11-44]
- prisma.config.ts[1-8]
- prisma/schema.prisma[7-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

16. ~~Wrong placeholder DB URL scheme~~ ☑ 🐞 Bug ✓ Correctness

Description

BUILD_DATABASE_URL defaults to a SQLite-style file: URL even though Prisma is configured for
PostgreSQL; Prisma CLI typically validates datasource URLs against the provider, so `prisma
generate` (and/or later Prisma commands) may fail during docker build.

Code

Dockerfile[14-42]
prisma/schema.prisma[7-9]
.github/workflows/pull-request-testing.yaml[42-46]

+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Prisma datasource provider is PostgreSQL, but the Dockerfile sets a default build-time URL of
file:./dev.db. The repo’s CI uses a PostgreSQL connection string when running prisma generate,
indicating Prisma expects a postgres-formatted URL for this project.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dockerfile uses `BUILD_DATABASE_URL=&amp;amp;amp;amp;amp;quot;file:./dev.db&amp;amp;amp;amp;amp;quot;` as the placeholder URL, but Prisma is configured with `provider = &amp;amp;amp;amp;amp;quot;postgresql&amp;amp;amp;amp;amp;quot;`. This provider/URL mismatch can break `prisma generate` during docker builds.
### Issue Context
Repo CI uses a `postgresql://...` URL to run Prisma commands.
### Fix Focus Areas
- Dockerfile[14-41]
- prisma/schema.prisma[7-9]
- .github/workflows/pull-request-testing.yaml[42-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

17. ~~Wrong placeholder DB URL scheme~~ ☑ 🐞 Bug ✓ Correctness

Description

BUILD_DATABASE_URL defaults to a SQLite-style file: URL even though Prisma is configured for
PostgreSQL; Prisma CLI typically validates datasource URLs against the provider, so `prisma
generate` (and/or later Prisma commands) may fail during docker build.

Code

Dockerfile[14-42]
prisma/schema.prisma[7-9]
.github/workflows/pull-request-testing.yaml[42-46]

+# Define build arguments
+ARG BUILD_DATABASE_URL="file:./dev.db"
ARG DATABASE_URL
ARG DATABASE_URL_DOCKER
ARG META_NAME

Evidence

The Prisma datasource provider is PostgreSQL, but the Dockerfile sets a default build-time URL of
file:./dev.db. The repo’s CI uses a PostgreSQL connection string when running prisma generate,
indicating Prisma expects a postgres-formatted URL for this project.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Dockerfile uses `BUILD_DATABASE_URL=&amp;amp;amp;amp;amp;amp;quot;file:./dev.db&amp;amp;amp;amp;amp;amp;quot;` as the placeholder URL, but Prisma is configured with `provider = &amp;amp;amp;amp;amp;amp;quot;postgresql&amp;amp;amp;amp;amp;amp;quot;`. This provider/URL mismatch can break `prisma generate` during docker builds.
### Issue Context
Repo CI uses a `postgresql://...` URL to run Prisma commands.
### Fix Focus Areas
- Dockerfile[14-41]
- prisma/schema.prisma[7-9]
- .github/workflows/pull-request-testing.yaml[42-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

18. ~~Generated client may be overwritten~~ ☑ 🐞 Bug ⛯ Reliability

Description

The Dockerfile generates Prisma client and then runs COPY . .; for local builds, if a stale
generated/ directory exists in the build context (it’s gitignored), it can overwrite the freshly
generated client and cause mismatched runtime behavior.

Code

.github/workflows/docker-publish.yml[R27-32]

+# 3. Generate Prisma client using the build-only placeholder URL
+RUN DATABASE_URL=${BUILD_DATABASE_URL} npx prisma generate
-RUN npx prisma generate
+# 4. Copy the rest of the application code AFTER dependencies and Prisma are sorted
+COPY . .

Evidence

Prisma client output is configured to land in ../generated (repo root generated/). That
directory is gitignored, so it can commonly exist locally. Because the Dockerfile copies the entire
context after generating, any pre-existing generated/ in the build context can overwrite
/app/generated created by Prisma generation.

Dockerfile[40-44]
prisma/schema.prisma[1-5]
.gitignore[1-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`COPY . .` happens after Prisma client generation. If the docker build context contains a local `generated/` directory, it can overwrite the freshly generated client in the image.
### Issue Context
Prisma outputs client into `/app/generated` (via `output = &amp;amp;amp;amp;quot;../generated&amp;amp;amp;amp;quot;`), and `generated/` is gitignored (so it may exist locally without being tracked).
### Fix Focus Areas
- Dockerfile[40-44]
- prisma/schema.prisma[1-5]
- .gitignore[1-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

19. ~~Only mutable latest tag~~ ☑ 🐞 Bug ⛯ Reliability

Description

The publish workflow builds and pushes only :latest with no immutable tagging (e.g., commit SHA)
and no concurrency safeguards; this makes rollbacks/auditing difficult and can lead to latest
being overwritten unpredictably across rapid successive pushes.

Code

+      - name: Build Docker image
+        run: |
+          docker build -t ghcr.io/${{ github.repository_owner }}/backend:latest .
+      - name: Push Docker image
+        run: |
+          docker push ghcr.io/${{ github.repository_owner }}/backend:latest

Evidence

The workflow tags and pushes a single backend:latest image. Without additional tags (like `${{
github.sha }}`) and/or concurrency controls, deployments cannot reliably pin to an exact build and
latest is always overwritten.

.github/workflows/docker-publish.yml[27-32]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow pushes only a mutable `:latest` tag, which complicates rollbacks and traceability.
## Issue Context
The current steps use raw `docker build` and `docker push` with a single tag.
## Fix Focus Areas
- .github/workflows/docker-publish.yml[1-32]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

20. ~~Unpinned GH Actions~~ ☑ 🐞 Bug ⛨ Security

Description

The publishing workflow uses mutable action tags (e.g., actions/checkout@v4,
docker/login-action@v3). Tag updates can change behavior unexpectedly and increase supply-chain
risk for an image publishing pipeline.

Code

.github/workflows/docker-publish.yml[R17-25]

+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Log in to GitHub Container Registry
+        uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}

Evidence
The workflow directly references major-version tags instead of immutable commit SHAs, meaning the
code executed by CI can change without a repo change.
.github/workflows/docker-publish.yml[16-25]
Best Practice: GitHub Actions security hardening

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow uses mutable action tags (`@v4`, `@v3`). For artifact/image publishing, pinning to SHAs reduces supply-chain risk and avoids unexpected changes.
### Issue Context
This workflow logs in to GHCR and pushes images. A compromised or changed action could impact published artifacts.
### Fix Focus Areas
- .github/workflows/docker-publish.yml[16-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (4)

21. ~~Generated client may be overwritten~~ ☑ 🐞 Bug ⛯ Reliability

Description

The Dockerfile generates Prisma client and then runs COPY . .; for local builds, if a stale
generated/ directory exists in the build context (it’s gitignored), it can overwrite the freshly
generated client and cause mismatched runtime behavior.

Code

+# 3. Generate Prisma client using the build-only placeholder URL
+RUN DATABASE_URL=${BUILD_DATABASE_URL} npx prisma generate
-RUN npx prisma generate
+# 4. Copy the rest of the application code AFTER dependencies and Prisma are sorted
+COPY . .

Evidence

Prisma client output is configured to land in ../generated (repo root generated/). That
directory is gitignored, so it can commonly exist locally. Because the Dockerfile copies the entire
context after generating, any pre-existing generated/ in the build context can overwrite
/app/generated created by Prisma generation.

Dockerfile[40-44]
prisma/schema.prisma[1-5]
.gitignore[1-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`COPY . .` happens after Prisma client generation. If the docker build context contains a local `generated/` directory, it can overwrite the freshly generated client in the image.
### Issue Context
Prisma outputs client into `/app/generated` (via `output = &amp;amp;amp;amp;amp;quot;../generated&amp;amp;amp;amp;amp;quot;`), and `generated/` is gitignored (so it may exist locally without being tracked).
### Fix Focus Areas
- Dockerfile[40-44]
- prisma/schema.prisma[1-5]
- .gitignore[1-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

22. ~~Generated client may be overwritten~~ ☑ 🐞 Bug ⛯ Reliability

Description

The Dockerfile generates Prisma client and then runs COPY . .; for local builds, if a stale
generated/ directory exists in the build context (it’s gitignored), it can overwrite the freshly
generated client and cause mismatched runtime behavior.

Code

.github/workflows/docker-publish.yml[R17-25]

+# 3. Generate Prisma client using the build-only placeholder URL
+RUN DATABASE_URL=${BUILD_DATABASE_URL} npx prisma generate
-RUN npx prisma generate
+# 4. Copy the rest of the application code AFTER dependencies and Prisma are sorted
+COPY . .

Evidence

Prisma client output is configured to land in ../generated (repo root generated/). That
directory is gitignored, so it can commonly exist locally. Because the Dockerfile copies the entire
context after generating, any pre-existing generated/ in the build context can overwrite
/app/generated created by Prisma generation.

Dockerfile[40-44]
prisma/schema.prisma[1-5]
.gitignore[1-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`COPY . .` happens after Prisma client generation. If the docker build context contains a local `generated/` directory, it can overwrite the freshly generated client in the image.
### Issue Context
Prisma outputs client into `/app/generated` (via `output = &amp;amp;amp;amp;amp;quot;../generated&amp;amp;amp;amp;amp;quot;`), and `generated/` is gitignored (so it may exist locally without being tracked).
### Fix Focus Areas
- Dockerfile[40-44]
- prisma/schema.prisma[1-5]
- .gitignore[1-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

23. ~~Unpinned GH Actions~~ ☑ 🐞 Bug ⛨ Security

Description

The publishing workflow uses mutable action tags (e.g., actions/checkout@v4,
docker/login-action@v3). Tag updates can change behavior unexpectedly and increase supply-chain
risk for an image publishing pipeline.

Code

+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Log in to GitHub Container Registry
+        uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}

Evidence
The workflow directly references major-version tags instead of immutable commit SHAs, meaning the
code executed by CI can change without a repo change.
.github/workflows/docker-publish.yml[16-25]
Best Practice: GitHub Actions security hardening

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow uses mutable action tags (`@v4`, `@v3`). For artifact/image publishing, pinning to SHAs reduces supply-chain risk and avoids unexpected changes.
### Issue Context
This workflow logs in to GHCR and pushes images. A compromised or changed action could impact published artifacts.
### Fix Focus Areas
- .github/workflows/docker-publish.yml[16-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

24. ~~Generated client may be overwritten~~ ☑ 🐞 Bug ⛯ Reliability

Description

The Dockerfile generates Prisma client and then runs COPY . .; for local builds, if a stale
generated/ directory exists in the build context (it’s gitignored), it can overwrite the freshly
generated client and cause mismatched runtime behavior.

Code