@codiac.io/codiac-cli 1.3.259 → 1.3.260

package/oclif.manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.3.259",
+  "version": "1.3.260",
   "commands": {
     "branch": {
       "id": "branch",

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@codiac.io/codiac-cli",
   "description": "Local command line interface for managing enterprise assets and environments.",
-  "version": "1.3.259",
+  "version": "1.3.260",
   "author": "Codiac",
   "bin": {
     "codiac": "./bin/run",

package/skill/references/concepts.md

@@ -150,7 +150,7 @@ A setting's `targetFile` says *what artifact it becomes*:
 |---|---|
 | `[helm]` | a Helm chart value (`.Values.<path>`) for a helm asset |
 | `[env]` | an OS environment variable on the container |
-| `[footprint]` | container resource footprint (cpu/mem requests/limits) |
+| `[footprint]` | container CPU/memory footprint + replicas (key names below) |
 | `[label]` | a Kubernetes label |
 | `[annotation]` | a Kubernetes annotation |
 | `[filestore]` | a mounted file/volume value |
@@ -159,6 +159,12 @@ A setting's `targetFile` says *what artifact it becomes*:
 Choosing the wrong `targetFile` is a common error — e.g. putting a helm chart value under `[env]`
 (where Codiac builds Deployments for *service* assets) instead of `[helm]`.
 
+**`[footprint]` key names.** The canonical keys are the *flat* `cpuRequest`, `cpuLimit`,
+`memRequest`, `memLimit`, and `replicas` — this is what the interactive `cod config add -t footprint`
+prompt offers. The k8s-native *nested* shape (`requests.cpu`, `requests.memory`, `limits.cpu`,
+`limits.memory`) is also accepted and mapped onto the flat keys automatically, so either works.
+Confirm with `cod config view -t footprint`, which shows the resolved doc.
+
 ### Literal value vs sourced reference
 A setting's value is either:
 - a **literal** `value` (stored directly), or