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

.kiro/steering/roadmap.md

@@ -122,6 +122,7 @@ Direction: `.kiro/steering/resource-model.md`. Decisions, proposals (PR-1 generi
 - [ ] project-guarantee — NEW 2026-10-09 (configuration layering, backlog). Project-owned guarantees (resource amount or host pool), borrowing of idle guaranteed capacity, reclaim through preemption. Brief: `.kiro/specs/project-guarantee/brief.md`. Dependencies: project-config, scheduler-preemption.
 - [ ] job-resize — NEW 2026-10-10 (from long-running services discovery; not on the services path). Grow/shrink a running parallel job's allocation (LSF resizable jobs, `bresize`) for elastic applications. Brief: `.kiro/specs/job-resize/brief.md`. Dependencies: parjob-placement, host-failure-job-recovery.
 - [ ] project-delegated-membership — NEW 2026-10-10 (from project-config requirements, user decision: future). Project managers edit their project's (and subtree's) members at runtime without an admin config push; needs a durable store that coexists with `xceadmin` config pushes (e.g. a separate delegated member list) and audit. Dependencies: project-config, rbac-persistence.
+- [ ] job-modify — NEW 2026-10-12 (from application-profile discussion, user decision; backlog, no brief yet). Modify a pending job (LSF `bmod`): apiserver action (today `"modify"` is commented out, `controllers/jobs.go:2446`; `JOB_MODIFY` only an enum), controller opcode, WAL fact with snapshot field-completeness, scheduler re-merge, xcecli. First attributes: `--app` (owner with `app:use` on the new profile; admins in bulk, e.g. `--app-from <old>`), `-R`, `-n`, queue; later begin/end time (`job-time-window`), dependencies. Dependencies: application-profile, job-config-merge.
 - [ ] xcecli-presets — NEW 2026-10-12 (from application-profile discussion, user decisions). Client-side presets replace convenience defaults in profiles: a preset is a set of job options (`--app`, `--queue`, `-R`, `-n`, env, limits) expanded by the client, a flag replacing the preset's value for that option; one file per preset (`~/.config/xce/presets/<ns>/<name>.yaml`, same layout in the apiserver's presets dir), env capture by name (`pass:`; `XCE_*` and secret-looking names excluded); the apiserver only shares admin-deployed presets read-only (`GET /api/v1/presets[/{name}]`), and `preset pull` copies one locally so server-side removal never affects users (`preset diff`, `pull --force` user-initiated); user-to-user sharing by `preset export`/`import`; presets carry no privilege and are not a configuration level; optional preset-name job label; the portal does the same expansion. Brief: `.kiro/specs/xcecli-presets/brief.md`. Dependencies: application-profile.
 - [ ] profile-usage-insight — NEW 2026-10-12 (from application-profile discussion, backlog; no brief yet). Per-profile report over recent jobs comparing the profile's defaults with actual use (requested vs. peak memory, CPU efficiency, OOM kills, pend time, runtime by variant) and suggesting better values for site presets (or a profile essential), e.g. "preset openfoam rusage mem 4000, p95 peak 1600 → suggest 2000" (Kubernetes VPA recommender precedent). **Advisory only** (user decision): the admin applies changes to site presets or `applications.yaml`; nothing tunes itself. Optional user hint ("used 1.4G of 4G requested"). Dependencies: application-profile, run usage in job records.
 - [ ] lsf-config-migration — NEW 2026-10-09 (user idea, backlog; no brief yet). A tool (likely an `xceadmin` subcommand) that converts LSF configuration (`lsb.queues`, `lsb.applications`, `lsb.resources` Limit sections, `lsb.users`/`lsb.hosts` groups, `lsb.params` defaults, project settings) into XCE `configs/*.yaml`, with a report of what does not map: queue `RES_REQ` (XCE queues are policy only; move into a profile or drop), LSF's full per-section merge rules vs XCE's simplified ones, compound/alternative resreqs, unsupported parameters. Dependencies: job-config-merge, application-profile, project-config, parjob-placement (span), admin-config-tool. Promote via `/kiro-discovery` when those land.