docs(spec): application-profile: clean env for the outer pre/post-exec, reserved XCE_ prefix

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

.kiro/specs/application-profile/brief.md

@@ -339,6 +339,27 @@ How each profile attribute combines with the job's own value (owned by
   whose resreq sets terms is rejected until PR-15 named parts define
   per-part merging (leaning; requirements decide).
 
+### Environment of the outer layer and reserved names
+Decided 2026-10-12 (user), replacing the idea of an env denylist:
+- **A. The profile's pre/post-exec runs in a clean environment**: system
+  values (`XCE_*`, `HOME`, a fixed `PATH`) plus the profile's own env, never
+  the job's. The job's env applies after it, to the job's pre-exec, the job
+  and the job's post-exec. An admin script that needs job facts reads
+  `XCE_*`. Today the job env is applied first (`apply_env_vars()`,
+  `worker/src/xcecd_worker.c:835`, then `queue_pre_exec()` :843), so a job's
+  `PATH` or `BASH_ENV` can subvert the admin's script. Worker change in this
+  spec: the outer layer gets an explicitly built env (`uv_proc_pre_exec`
+  takes none today). It also fixes today's queue pre/post-exec.
+- **B. The `XCE_` prefix is reserved**: neither a job nor a profile may set
+  `XCE_*` variables (rejected at submit by apiserver and controller, and by
+  `xceadmin` for profiles).
+- Why no denylist: the whole job unit runs as the execution user
+  (`User=` on the transient unit, `worker/src/xcecd_cgroups.c:299-312`), in
+  sandbox mode inside the sandbox, so `LD_PRELOAD` and similar are not an
+  escalation; the real risks were the admin's outer layer and XCE's own
+  variables, which A and B close at the source. Sandbox-specific env
+  exposure stays with `job-sandbox-execution`.
+
 ### Presets (client side, `xcecli-presets`)
 Not part of this spec, recorded here because they replace profile defaults:
 - A preset is a set of job options (`--app`, `--queue`, `-R`, `-n`, env,
@@ -500,14 +521,13 @@ with the reason "application profile X is not defined".
   - `jobmod --app` for a pending job: who may, and the bulk form (leaning:
     the owner with `app:use` on the new profile; admins in bulk).
   - Raised 2026-10-12, not yet decided:
-    - A denylist of env variables a sandbox profile forbids jobs to add
-      (e.g. `LD_PRELOAD`)?
     - Job labels (`--label key=value`, e.g. the preset name) and a summary
       grouped by label, to compare tuning variants: here,
       `job-status-detail-display`, or `xcecli-presets`?
   - Settled 2026-10-12: scheduling and execution values frozen at
     dispatch, re-read on requeue ("Dispatch record"); a removed profile
-    makes its jobs pend ("Profile removed while jobs use it"); override granularity (no markers; additive rule),
+    makes its jobs pend ("Profile removed while jobs use it"); clean env for
+    the outer layer and reserved `XCE_` instead of an env denylist; override granularity (no markers; additive rule),
     limits a job may lower (profile limits are maximums), personal presets
     (client side), `app:override` and inheritance (deferred).
     - Splitting the spec: execution mode, I/O directories, capability