Owner: AutoCoder administrator. Purpose: persistent synthetic test PostgreSQL data, never production data. The existing fastdata ZFS pool had about 2.47 TiB available before this change; no physical or paid capacity was added. The new dataset is fastdata/autocoder-test-postgres, mounted at /mnt/fastdata/k8s-pvcs/autocoder-test-postgres, with a server-enforced quota=10G, compression=lz4, atime=off, UID/GID 70:70, and mode 0700. It used about 12.1 MiB after PostgreSQL initialization and restart. Do not delete the dataset or claim without separate destructive-action authorization.
An exact export in /etc/exports.d/autocoder-test.exports permits only controller 192.168.1.9, using rw,sync,sec=sys,all_squash,anonuid=70,anongid=70,no_subtree_check. Existing parent exports remained unchanged after exportfs -ra. The source is k8s/overlays/test/admin-storage-export.exports in AutoCoder-Engine. Static pv/autocoder-test-postgres-nfs uses NFSv4.2, sec=sys, hard, and Retain; autocoder-test/pvc/autocoder-test-postgres-pvc binds specifically to it. The PV and PVC both report Bound at 10 GiB. The test PostgreSQL Deployment runs on the controller as UID/GID 70, mounted the NFS dataset, and became Ready. No test Engine/frontend Deployment or ingress was started by this storage change.
A temporary UID-70 pod mounted the claim, observed a filesystem size no greater than exactly 10 GiB, wrote and removed a marker, and exited successfully; the smoke pod was deleted. PostgreSQL 16 initialized successfully on the dataset. A synthetic row (autocoder_test_persistence_probe, marker synthetic-2026-09-23) remained readable after a controlled PostgreSQL Deployment restart; the replacement pod was Ready. The PostgreSQL readiness probe now fails at 85% filesystem usage, preventing a new healthy test rollout and marking test storage critical without deleting data. Forward application migrations and whole-release deployment remain unverified.
Expected growth is small synthetic fixtures; hard maximum is 10 GiB. Retain the dataset through the candidate pilot. For catastrophic loss, the administrator recreates the bounded dataset and reseeds synthetic fixtures; routine rollout and migrations must preserve existing rows. Before automated delivery is enabled, add/verify a 70% warning signal and an operator recovery path for the 85% critical threshold. Those warning/recovery controls are not yet implemented; the hard quota and critical readiness gate protect other storage consumers in the interim. Verify NFS availability and ZFS usage during the remaining pilot setup.
PR #6656 passed branch, native release, and WASM validation in Actions run 8650 and merged to dev as 4ceeb5a9dd573717ae41d845828b4b4f0d414d4c. The merged repository manifest specifies storageClassName: "" and exact volumeName: autocoder-test-postgres-nfs; a fresh Kubernetes read still showed that claim Bound to the 10 GiB Retain PV at /mnt/fastdata/k8s-pvcs/autocoder-test-postgres. This proves source/live storage binding, not application migrations or a test candidate deployment.
A live preflight found that autocoder-test-ci lacked its repository-declared named Lease rule and that lease/autocoder-database-migration did not yet exist. After verifying the selected Kubernetes context and that the manifest bytes matched merged dev, the administrator applied k8s/overlays/test/ci-deployer-rbac.yaml. The Lease was created and the Role gained only get, patch, and update on that named Lease. Kubernetes authorization now returns yes for updating the named Lease in autocoder-test and no for patching Deployments in autocoder-engine. No candidate rollout or database migration was started.
The administrator applied only the first ResourceQuota document from the merged k8s/overlays/test/resources.yaml, after checking source bytes against current dev and the Kubernetes context. autocoder-test/quota/autocoder-test now bounds requests to 2 CPU, 3 GiB memory, and 10 GiB storage, limits to 4 CPU and 6 GiB memory, and the namespace to one PVC. Its live usage is one 10 GiB PVC plus the existing PostgreSQL request/limit; PostgreSQL remained Ready. No placeholder Engine/frontend Deployment or ingress was applied.