chore: sync local changes

README.md

@@ -1,11 +1,11 @@
 # ocdp-workload-manifests
 
-Standalone Kubernetes manifests and post-render presets for OCDP workloads.
+Standalone Kubernetes manifests and post-renders for OCDP workloads.
 
 This repository is intentionally just a Git repository of app manifests. There is
 no global catalog index and no dependency on the Gitea API. `ocdp-server` stores
 the template contract; the operator renders Helm sources and then applies
-Kustomize presets from this repository.
+Kustomize postRenders from this repository.
 
 ## Architecture
 
@@ -15,36 +15,35 @@ OCDP keeps the responsibilities split:
 Git repo
   apps/<app>/base
   apps/<app>/components
-  packages/<app>/presets/<preset>
+  packages/<app>/post-renders/<postRender>
     kustomization.yaml
     userInputs.yaml
 
 ocdp-server PostgreSQL
   WorkloadTemplate metadata
   WorkloadTemplate Helm source
-  WorkloadTemplate source.preset.repositoryUrl/ref/path
+  WorkloadTemplate source.postRender.repositoryUrl/ref/path
   user-facing values schema / parameters
   access bindings
-  no WorkloadClaim instance storage
+  no Workload instance storage
 
 target cluster
-  WorkloadClaim CR as the canonical user claim
-  Workload CR
+  Workload CR as the canonical user workload
   runtime Kubernetes resources
 ```
 
-This repository stores Git bases, reusable components, and Kustomize presets.
+This repository stores Git bases, reusable components, and Kustomize postRenders.
 For Helm-backed workloads, the operator runs `helm template` first, writes that
-output as `rendered.yaml`, then renders the selected preset with Workload
-`spec.values`. A preset may include `userInputs.yaml` so admins can see which
+output as `rendered.yaml`, then renders the selected postRender with Workload
+`spec.values`. A postRender may include `userInputs.yaml` so admins can see which
 values should become the WorkloadTemplate user-facing parameter schema. This
 metadata file is not a Kubernetes resource and is not referenced by Kustomize.
 
 An admin creates or updates a `WorkloadTemplate` in `ocdp-server`. That template
-can point at a Helm chart plus one of these Git presets:
+can point at a Helm chart plus one of these Git postRenders:
 
 ```yaml
-templateType: kustomize
+templateType: composite
 source:
   type: helm
   repositoryUrl: https://kuoss.github.io/helm-charts
@@ -58,7 +57,7 @@ source:
     persistence:
       enabled: true
       size: 20Gi
-  preset:
+  postRender:
     type: kustomize
     repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
     ref: main
@@ -66,11 +65,11 @@ source:
 ```
 
 After the template is stored in PostgreSQL and assigned to users or groups, users
-call `ocdp-server` to create a claim by submitting `templateId`, `workspaceId`,
+call `ocdp-server` to create a workload by submitting `templateId`, `workspaceId`,
 and values. `ocdp-server` resolves the template from PostgreSQL and writes a
-`WorkloadClaim` CR into the target Kubernetes cluster. The operator renders Helm
-with the resolved values, applies the Kustomize preset, and then applies the
-final Kubernetes resources. The final user-created claim lives in Kubernetes,
+`Workload` CR into the target Kubernetes cluster. The operator renders Helm
+with the resolved values, applies the Kustomize postRender, and then applies the
+final Kubernetes resources. The final user-created workload lives in Kubernetes,
 not in PostgreSQL.
 
 ## Layout
@@ -101,7 +100,7 @@ tests/
 
 ## Server Usage
 
-`ocdp-server` should store a Helm source plus a Kustomize preset reference:
+`ocdp-server` should store a Helm source plus a Kustomize postRender reference:
 
 ```yaml
 source:
@@ -110,7 +109,7 @@ source:
   chart: code-server
   version: 3.16.1
   releaseName: "{{ name }}"
-  preset:
+  postRender:
     type: kustomize
     repositoryUrl: https://gitea.example.com/ocdp/ocdp-workload-manifests.git
     ref: main
@@ -118,16 +117,16 @@ source:
 ```
 
 For one deployment, `ocdp-server` stores the Helm chart reference, static Helm
-values, preset reference, and the template value contract. The preset renders
-with Workload `spec.values`, so environment-specific implementation details
-should live in the selected preset instead of in the WorkloadTemplate create
-form.
+values, postRender reference, and the template value contract. The postRender
+renders with Workload `spec.values`, so environment-specific implementation
+details should live in the selected postRender instead of in the WorkloadTemplate
+create form.
 
 ## Exposure
 
-Base services should stay internally reachable unless an environment preset
+Base services should stay internally reachable unless an environment postRender
 intentionally changes the Service shape. For standard self-service workloads,
-exposure is an admin preset decision and a user read view, not a user claim
+exposure is an admin postRender decision and a user read view, not a user workload
 input.
 
 Reusable components are still useful implementation building blocks:
@@ -137,7 +136,7 @@ Reusable components are still useful implementation building blocks:
 - `components/service-loadbalancer`: change the app Service to `LoadBalancer`.
 - `components/service-nodeport`: change the app Service to `NodePort`.
 
-When a preset needs NodePort, it may leave the concrete nodePort for Kubernetes
+When a postRender needs NodePort, it may leave the concrete nodePort for Kubernetes
 to allocate:
 
 ```yaml