--- spec: agent-feature status: ready owner: feature-pipeline-agent related-routes: files: # (none listed) --- # agent-feature ## Goal Add a database-level UNIQUE constraint on the Name column for both xyz."Asset" and xyz."CommissioningSystem" (each scoped within its own project shard, since both are project-scoped operational tables). This is a Postgres-only schema change plus a backfill patch to resolve any pre-existing duplicate Name values before the constraint applies. No new tables, no API surface change. ## Behavior changes The approved plan's API2 changes (verbatim): ```yaml none ... ``` ## 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 - Case-insensitive uniqueness (unless data analysis at implementation reveals it's required). - Any column/table changes beyond adding the unique enforcement on Name. - API2 / API1 runtime changes, validation messages, or error-handling changes. - No new tables, so no Citus distribution changes are needed. ## Notes / open questions - Generated by the feature pipeline from the approved architect plan. If any acceptance criterion is ambiguous, ask the human before implementing. ## Decisions - **No api2 (`platform-api`) changes were made.** This spec is a Postgres-only schema change (a `UNIQUE` constraint on `Name` for `xyz."Asset"` and `xyz."CommissioningSystem"`, plus a dedupe backfill patch). The plan's API2 changes are verbatim `none`, and the spec lists "API2 / API1 runtime changes, validation messages, or error-handling changes" as out of scope. - The DDL/migration source for these tables (`PostgreSQLDatabase/Database/xyz/...` and `CitusDistributionLogic`) does **not** live in this repo — it is mounted from a separate database repository via `${DATABASE_REPO_PATH}` at runtime (`docker/docker-compose.yml`). Neither `xyz."Asset"` nor `xyz."CommissioningSystem"` is referenced anywhere in `src/`, `test/`, or the e2e seed dump. The change therefore belongs in the **database repository**, not here. See `_SPECIALIST_REPORT.md` at the repo root for the recommended changelog/constraint SQL handed off to the DB-repo owner.