docs(specs): discovery for layered job configuration (queue/app/project)

New briefs: job-config-merge (one live merge of job, application profile,
queue policy and project into effective values; simplified rules: job
overrides profile, select ANDed, queue hard/task limits reject; queue is
policy only, res_req deprecated), project-config (project quotas v1) and
project-guarantee (backlog).

application-profile: the profile carries the job's resreq (incl. span) and
task limits; "frozen at submit" replaced by the live merge.
parjob-placement: span constraints live in the fixed-N planner and the
range search bisects over the planner's allowed counts; LSF 10.1 block,
ptile, stripe and HOSTLIMIT_PER_JOB findings recorded.
Roadmap: new specs, existing-spec updates, lsf-config-migration backlog.

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

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

@@ -5,6 +5,27 @@ mode is an attribute of the job, determined by the **application** the user runs
 so it is carried by a named application profile rather than by a bare mode
 option.)
 
+**Update 2026-10-09 (`/kiro-discovery`, configuration layering; user
+decisions):**
+- Configuration is layered LSF-style: **queue** = scheduling policy only (no
+  resreq; queue `res_req` is deprecated), **application profile** =
+  application execution constraints *including the job's resource
+  requirement* (select / rusage / `span[...]` / same) and task limits
+  (min / default / max, LSF TASKLIMIT), **project** = resource ownership
+  (`project-config`).
+- How the levels combine is owned by **`job-config-merge`**: job overrides
+  profile section by section, `select` is ANDed, queue hard and task limits
+  are ceilings that reject. This answers the open question "how resource
+  defaults combine with a job's own resreq" below.
+- **Replaces "Resolution at submit time"** below: the merge is *live*. The WAL
+  keeps the job's own values plus the profile name; the controller and
+  apiserver validate at submit, and the scheduler computes effective values
+  and recomputes them when a profile changes (a pending job that no longer
+  satisfies its profile pends with a reason; running jobs are unaffected).
+  Execution-side values (mode, options, launch type, env, pre/post-exec) are
+  still taken from the profile at dispatch time; requirements decide whether
+  dispatch freezes them on the job record.
+
 ## Problem
 XCE users run many kinds of applications: trusted in-house codes, untrusted
 scripts, vendor binaries, MPI solvers. Each needs a different way of running:
@@ -175,8 +196,8 @@ fits XCE's LSF-style job model.
   - Which extra attributes go into v1 beyond the four ("maybe others"). Examples:
     requeue exit values, runtime estimate, job starter or wrapper, output path
     template, checkpoint settings.
-  - How resource defaults combine with a job's own resreq (replace, or fill in
-    what's missing).
+  - ~~How resource defaults combine with a job's own resreq~~ — settled
+    2026-10-09, owned by `job-config-merge`.
   - Profile versioning and audit.
   - Whether the profile can be changed for a pending job.
 - **Out**:
@@ -215,6 +236,8 @@ fits XCE's LSF-style job model.
 
 ## Existing Spec Touchpoints
 - **Extends**: none directly.
+- **Depends on**: `job-config-merge` (merge rules and live re-evaluation).
+- **Feeds**: `parjob-placement` (the profile's `span[...]`).
 - **Adjacent**:
   - `job-status-detail-display`
   - `controller-job-cleanup`