---
spec: agent-feature
status: ready
owner: feature-pipeline-agent
related-routes:
files:
  - src/api/v2/systems/systems.routes.ts
  - src/api/v2/systems/systems.controller.ts
  - src/api/v2/systems/systems.validator.ts
  - src/services/systems.service.ts
  - src/api/v2/systems/systems.routes.ts
  - src/api/v2/systems/systems.controller.ts
  - src/services/systems.service.ts
  - src/api/v2/systems/systems.routes.ts
  - src/api/v2/systems/systems.controller.ts
  - src/api/v2/systems/systems.validator.ts
  - src/services/systems.service.ts
---

# agent-feature

## Goal

Add three read/create REST endpoints under /api/v2/systems for the existing
xyz."CommissioningSystem" table: POST /systems (create), GET /systems
(paginated list of non-deleted systems), and GET /systems/:commissioningSystemId
(single fetch). All DB access wires up to EXISTING stored procedures/functions
already in master; no new DDL, no new DB functions, and no new permissions —
reuse existing project permissions (e.g. PROJECT_EDIT for create, PROJECT_VIEW
for reads).


## Behavior changes

- POST /api/v2/systems
- GET /api/v2/systems
- GET /api/v2/systems/{commissioningSystemId}

## Acceptance criteria

- [ ] The behavior described above is implemented on the listed files.
- [ ] Existing behavior is unchanged when the new feature is not exercised.
- [ ] Unit and (where observable) e2e tests cover the new behavior.

## Out of scope

- Update (PUT/PATCH) endpoint for CommissioningSystem
- Delete / soft-delete endpoint for CommissioningSystem
- Filtering beyond project scope and soft-delete exclusion
- Any new Postgres DDL, tables, columns, procedures, or functions
- Any new permissions/authorities (reuse existing project permissions)

## Notes / open questions

- Generated by the feature pipeline from the approved architect plan. If any
  acceptance criterion is ambiguous, ask the human before implementing.