docs(spec): xcecli-presets: environment capture by name (XCE_ and secret exclusions)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.kiro/specs/xcecli-presets/brief.md

@@ -41,6 +41,29 @@ configuration level.
 - **Site presets complement profiles.** Admins typically publish a preset
   with the profile's name holding its usual tuning; clients may point to it
   ("server preset `openfoam` available") but never apply it automatically.
+- **Environment capture** (user, 2026-10-12). A preset may list env
+  variable *names or patterns* to copy from the submit shell; values are
+  read at submit, never stored in the preset (LSF `bsub -env "all, ~VAR"`,
+  Slurm `--export=VAR1,VAR2` precedent):
+
+  ```yaml
+  env:
+    pass: [OMP_NUM_THREADS, "MPI_*", "FOAM_*"]   # or: pass: all, exclude: ["SSH_*", DISPLAY]
+    set:  { OMP_PROC_BIND: close }
+  ```
+  - `XCE_*` is never captured (reserved; matters for submits from inside a
+    job, which today copy the parent's `XCE_JOBID` with `--env`).
+  - Secret-looking names (`*TOKEN*`, `*SECRET*`, `*PASSWORD*`, `*_KEY`) are
+    excluded by default with a warning, because captured values are stored
+    in the job record; an explicit `set:` overrides.
+  - A captured name the job's profile defines is dropped by the client with
+    a note; an explicit `set:` that conflicts is still rejected by the
+    server (additive rule). The client reads the profile (`app:view`).
+  - `pass: all` is opt-in; no capture is the default (today's behaviour).
+    CLI only: portal and REST have no shell env and use `set:` only.
+  - Today's `xcecli jobs submit --env` (whole `os.Environ()`,
+    `xcecli/common/utils/utils.go:279`) gets the same `XCE_*` and secret
+    exclusions, so the flag and presets behave alike.
 - **Safety and visibility:** a warning on export/import when env variable
   names look like secrets; `xcecli jobs submit --dry-run` shows the expanded
   options and the effective values after the profile merge