docs(spec): application-profile: Future Discussion section (design questions, deferred features, housekeeping)

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

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

@@ -955,3 +955,69 @@ Decided 2026-10-12 (user), so a rename never strands jobs:
 - Size: still large after the split (config, access and submit, job state,
   outer layer); one coherent feature, testable end to end with `direct`.
 - HA/persistence spec: use the full 3-phase workflow.
+
+## Future Discussion
+Everything left to discuss, collected 2026-10-12 at the end of the brief
+discussion. Nothing here blocks requirements.
+
+### For this spec's design phase
+1. **Serial job wrapping:** both starters wrap a single-task job's command;
+   confirm `job_starter` is outermost.
+2. **Today's queue pre/post-exec:** on which hosts it runs (in
+   `xcecd_worker`), so it maps to `*_job_exec` or `*_host_exec` without a
+   behaviour change.
+3. **Kill paths:** the unit's explicit stop timeout and a configurable
+   maximum hook duration (today post-exec is bounded only by systemd's
+   unset `TimeoutStopUSec`); how the worker survives an OOM kill inside its
+   own unit.
+4. **Declined dispatch:** confirm a dispatch declined for a missing or
+   changed profile counts neither as a run nor against requeue limits.
+5. **Field placement:** the profile env (a `start_info` field or an exdata
+   key), the task starter on each `xce_taskhost_t`, renaming the queue-named
+   `qPreExec` / `qPostExec`, and the dispatch-record payload layout.
+6. **Task starter reach:** which launch types start tasks through the
+   worker and which through the MPI runtime; inserting the starter into
+   `create_mpi_cmdline()` for `openmpi` and `mpich`.
+7. **Content hash:** canonical encoding, algorithm and length; which fields
+   besides `description` are excluded.
+8. **params and annotations:** pattern syntax, count and size limits, env
+   name conversion edge cases; an opt-out for exporting annotations only if
+   someone needs it.
+9. **Re-merge cost:** with the live merge, a profile change re-merges every
+   pending job of that profile in the scheduler; check the cost for large
+   pending queues and whether re-merging is batched or lazy.
+10. **Messages:** the live-upgrade warning format, the new pend reason
+    ("application profile X is not defined"), the `xceadmin` secret-name
+    patterns, and the warning when no host matches a profile's `select`.
+
+### Deferred features (roadmap backlog)
+| Item | What | Revisit when |
+|---|---|---|
+| `app-access-control` | per-profile `app:use` / `app:view` (design kept above) | profiles must be restricted to some users |
+| `job-modify` | modify pending jobs (`--app`, `-R`, `-n`, queue; bulk `--app-from`) | renames or profile moves become common |
+| `job-requeue` | requeue/success exit values (profile attributes), requeue on hook failure | an application needs automatic requeue |
+| checkpoint, warning-before-kill | their own specs, each adding its profile attribute | an application needs them |
+| output path template | PR-6/PR-7 I/O track | output options are supported |
+| `job-labels` | server-side labels, filtering, summaries; reuses REST `tags` (bug-1970) | team-wide comparison or services need labels |
+| `config-history-audit` | profile history, change audit, lookup by content hash | admins need to see past profiles |
+| `app-submit-hook` | `esub`-style submit hook; client or apiserver | params, annotations, starters and hooks are not enough |
+| `profile-usage-insight` | advisory suggestions for site presets and profile defaults | usage data is available per profile |
+| `xcecli-presets` | client-side presets (brief exists, no `spec.json`) | after this spec's requirements |
+| `app:override` | privileged one-off override of profile values | `job-modify` exists and admins still need it |
+| profile inheritance (`base:`) | variants of a profile | presets prove insufficient for variants |
+| counted-resource protection | a `min:` floor on a profile `rusage` entry, or a "counted" marker in `resources.yaml` | licence under-reservation is a real problem |
+| per-resource default per-type | a per-type field in `resources.yaml` | a resource is almost always per host or per job |
+| per-part profile terms | profile `rusage` / `span` / `same` / `order` for compound jobs | PR-15 named parts land |
+| per-host hooks for the job | the job's own per-host pre/post-exec | users ask for it |
+| writable server-side presets | publish presets from the portal | the portal needs it, after `rbac-persistence` |
+| portal | preset storage, submit forms from `params` | portal work starts |
+
+### Housekeeping
+- Regenerate `job-config-merge`'s `requirements.md` after this spec's
+  design (it predates the structured resreq, the `rusage` rule, `params`,
+  exdata handling, frozen dispatched jobs and the `min`/`max` task range).
+- Mirror bug-1970 to Gitea (`/gitea-sync`).
+- `spec.json` for `xcecli-presets` and the backlog items when they are
+  promoted (gitea-sync skips briefs without one).
+- Next step: `/kiro-spec-init application-profile`, then
+  `/kiro-spec-requirements application-profile`.