docs(spec): application-profile: profile aliases; moving pending jobs deferred to job-modify

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

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

@@ -454,9 +454,33 @@ with the reason "application profile X is not defined".
     details is a hash comparison; job details show it short
     (`openfoam@3f2a9c`). Admins never set it.
   - Base for the open "profile versioning and audit" item.
-- Leaning, for requirements: `jobmod --app <new>` moves a pending job to
-  another profile (the owner, with `app:use` on the new one; admins in bulk,
-  e.g. `--app-from <old>`); the scheduler re-evaluates.
+- **Moving pending jobs to another profile is not in this spec**
+  (decided 2026-10-12, user). XCE has no job modification today
+  (`JOB_MODIFY` is only an enum, `include/xce/types.h:620`; the apiserver's
+  `"modify"` action is commented out, `controllers/jobs.go:2446`). A general
+  modify path (apiserver action, controller opcode, WAL fact, scheduler
+  re-merge) is its own backlog spec, `job-modify` (LSF `bmod`), with `--app`
+  among its first attributes. Until then: restore the profile, use an
+  alias, or kill and resubmit.
+
+### Profile aliases
+Decided 2026-10-12 (user), so a rename never strands jobs:
+- A profile may list `aliases: [old-name, ...]`. An alias resolves to the
+  profile everywhere: merge, dispatch record, content hash (the target's),
+  RBAC (`app:use` is checked against the target profile's name).
+- Jobs keep the name they recorded; the scheduler and controller resolve it
+  through the alias. New submits that name an alias are accepted and record
+  the **target's** name, so the alias can be removed once old jobs drain.
+- Job details show the resolution, e.g. `openfoam (recorded as
+  openfoam-old)`.
+- `xceadmin` rejects an alias that clashes with a profile name or another
+  alias, and alias chains (an alias naming an alias). `default_application`
+  must name a real profile, not an alias.
+- Removing an alias while jobs still name it is the same as removing a
+  profile: they pend, and the live-upgrade warning lists them.
+- Rename workflow: rename the profile and add the old name as an alias;
+  drop the alias when no pending job uses it (the upgrade warning shows
+  when that is).
 - Why: for sandboxed jobs the mode and mounts a job actually ran with is a
   security/audit fact, and `job-sandbox-execution`'s mandatory cleanup
   depends on it; `persistence.md` does not allow memory-only state without a
@@ -497,8 +521,8 @@ with the reason "application profile X is not defined".
 
 ## Scope
 - **In**:
-  - The profile schema (essentials, additive rule) and `applications.yaml`,
-    and the default profile (`default_application`).
+  - The profile schema (essentials, additive rule, aliases) and
+    `applications.yaml`, and the default profile (`default_application`).
   - Submit-time validation of the profile and the additive rule.
   - RBAC permission for profile use.
   - Submit surfaces: REST, `xcecli --app`, harness, libxce.
@@ -518,8 +542,6 @@ with the reason "application profile X is not defined".
   - ~~How resource defaults combine with a job's own resreq~~ — settled
     2026-10-09, owned by `job-config-merge`.
   - Profile versioning and audit.
-  - `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:
     - Job labels (`--label key=value`, e.g. the preset name) and a summary
       grouped by label, to compare tuning variants: here,
@@ -527,7 +549,8 @@ with the reason "application profile X is not defined".
   - 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"); clean env for
-    the outer layer and reserved `XCE_` instead of an env denylist; override granularity (no markers; additive rule),
+    the outer layer and reserved `XCE_` instead of an env denylist; moving
+    pending jobs deferred to `job-modify`, profile aliases in v1; 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