docs(spec): application-profile: convenience purpose, advisory recommendations, resreq tuning questions

- profiles exist mainly so users need not repeat resreq and other settings;
  most values are defaults, only what the application needs is fixed
- usage-based recommendations are advisory (user decision); new backlog
  item profile-usage-insight
- open questions: per-term resreq markers with ranges, app:override,
  inheritance, presets, job labels, compound resreqs

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

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

@@ -56,6 +56,20 @@ consumed by `service-supervision` (worker probes and restarts),
 - **This spec owns the profile's attribute schema**: which attributes exist
   and how each is marked *default* or *fixed*. `job-config-merge` consumes
   that schema and owns only the merge and live re-evaluation.
+- **Purpose: convenience first, enforcement where needed** (user, 2026-10-12).
+  A profile saves users from repeating the same resreq and other settings on
+  every job; most values are defaults the job may change. Only what the
+  application cannot run without is fixed. Consequences:
+  - Profile defaults will sometimes not fit, and users will tune them
+    (sizing, placement). The profile gives room to try: default terms, with
+    admin-set ranges for numeric values.
+  - **Recommendations are advisory** (user decision): usage-based
+    suggestions for a profile's defaults (requested vs. used, OOM kills,
+    runtime by variant) are reported to the admin, who changes
+    `applications.yaml`; a profile never tunes itself. Backlog:
+    `profile-usage-insight`.
+  - Job details show the effective resreq with each term's origin (profile
+    or job), so users see what they are tuning.
 - **Later sections are added by their consumers**: `service:`
   (`service-supervision`), I/O claims (resource-model PR-6), relationship
   and compound templates (PR-14/15), `container:` (R6). This spec only makes
@@ -342,6 +356,29 @@ fits XCE's LSF-style job model.
       rule of `job-config-layering.md`, which should then say so).
     - Env merge: per-variable default/fixed, plus a denylist for sandbox
       profiles (e.g. `LD_PRELOAD`)?
+    - Resreq override granularity (leaning, follows from the convenience
+      purpose): markers per term instead of per section. `select` has
+      *required* terms (always ANDed) and *default* terms (the job's select
+      replaces only these); `rusage` is per resource (fixed, or default with
+      optional min/max); `span`/`same`/`order` default unless marked. An
+      unmarked term is *default*. Amends `job-config-layering.md` once
+      decided. Also settles per-resource `rusage` merging and the "limits a
+      job may lower" question (default with a range is still only a check).
+    - Privileged override for one-off exceptions: an `app:override`
+      permission per profile (fixed terms treated as default for that job),
+      recorded on the job (WAL/snapshot) and shown in job details; queue
+      ceilings and project quotas still apply. v1 or later?
+    - Profile inheritance (`base: <profile>`) for recurring variants such as
+      "openfoam, large memory": v1 or later (leaning later).
+    - Personal presets for a user's tuned settings: xcecli only (leaning),
+      or server-side for the portal (a per-user layer, which conflicts with
+      one owner per attribute)?
+    - Job labels (`--label key=value`) and a summary grouped by label, to
+      compare tuning variants: here, `job-status-detail-display`, or its own
+      spec?
+    - Compound or alternative resreqs: reject a compound job resreq under a
+      profile with fixed resreq terms until PR-15 named parts define
+      per-part merging (leaning).
     - Splitting the spec: execution mode, I/O directories, capability
       advertisement and placement as a separate spec (or folded into
       `job-sandbox-execution`), leaving this spec the profile core.

.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.
+- [ ] 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 defaults, e.g. "rusage mem default 4000, p95 peak 1600 → suggest 2000" (Kubernetes VPA recommender precedent). **Advisory only** (user decision): the admin applies changes through `applications.yaml`; a profile never 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.
 
 - [ ] **xce-harness-component** — **PROMOTED to spec 2026-09-13** (`/kiro-discovery`; brief at `.kiro/specs/xce-harness-component/brief.md`). Elevate `xce_test` (the REPL-driven wire-protocol test client used by HA soak / multi-host / resource-value verification) out of `src/controller/testsuite/` into its own first-class `src/harness/` component — own `meson.build`, `CLAUDE.md`, and unit-test binary (carved out of `controller_unit_test`, which today recompiles ~14 of xce_test's own files a second time paired with white-box tests) — fully decoupled from `/xce-build controller` (today's implicit "controller always builds xce_test" coupling, `build-deployment.md:24`). Verified finding: none of xce_test's 15 source files include any controller-private header — only libxce public headers + generated capnp schema — so this is a pure relocation + build-graph split, not a dependency untangling problem, and no xce_test behavior changes. Touches `/xce-test-ha`, `/xce-deploy-ha`, `/xce-test-multihost`, `/xce-test-resources` (each must build `harness` explicitly once decoupled) and is adjacent to (not overlapping) the three existing behavior specs `xce-test-cli-ux`/`xce-test-e2e-primitives`/`xce-test-rc-file`, whose file-path references go stale after the move. Next: `/kiro-spec-init xce-harness-component`.