docs(steering): N24 decided: gang-groups demoted to backlog as a co-start group

LLM training is one parallel job with topology requirements (PR-10).
gang-groups moves from the spec list to the roadmap backlog, re-scoped as
a co-start group of separately managed jobs and services (RL
post-training, disaggregated serving, streaming pipelines). resource-model
phases and the brief updated; job-resize no longer resizes gang groups.

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

.kiro/specs/gang-groups/brief.md

@@ -1,54 +1,93 @@
 # Brief: gang-groups
 
-(Resource-model discovery, 2026-10-11. Phase 5 of `.kiro/steering/resource-model.md`, driven by the LLM training/serving platform direction.)
+(Resource-model discovery, 2026-10-11. **Demoted to the backlog 2026-10-12**
+by user decision N24 in `.kiro/steering/resource-questions.md`. LLM training
+is one parallel job with topology requirements (PR-10 there), not a gang.
+This spec is re-scoped as a **co-start group** of separately managed jobs
+and services, to revisit when RL post-training or disaggregated serving
+reaches the roadmap.)
 
 ## Problem
-Distributed training is often several cooperating jobs that must start together or not at all, and with their storage ready:
-- a launcher plus worker groups;
-- a parameter server plus trainers;
-- heterogeneous roles with different resource requests (a Kubernetes JobSet, or a Volcano/Kueue gang).
+Some workloads are several cooperating parts that must start together, yet
+each part needs its own identity: application profile or container, owner,
+lifecycle, or independent scaling. One parallel job cannot express that.
+Starting only some parts wastes accelerators, and can deadlock the cluster
+when parts wait on each other.
 
-Starting part of a gang wastes accelerators and can deadlock the cluster. XCE places one parallel job all-or-nothing, but has no all-or-nothing group of jobs.
+**Use cases** (review 2026-10-11, "Gang use cases" in `resource-questions.md`):
+- **RL post-training** (RLHF, GRPO): a training job, rollout engines (e.g.
+  vLLM), and reward and reference models. Each is a different app;
+  rollouts restart and scale on their own.
+- **Disaggregated LLM serving:** prefill pool, decode pool and router. They
+  come up together and are placed close for KV-cache transfer, then scale
+  independently as long-running services.
+- **Streaming pipelines:** a live producer feeding a consumer (preprocessing
+  into training, online evaluation) with different profiles or owners.
+
+**Not this spec:**
+- data-, tensor- or pipeline-parallel training; MPMD codes; coordinator plus
+  workers: one parallel job with a compound resreq and topology
+  requirements (PR-10, `resource-instances`, `parjob-placement`);
+- a multi-host replica of a served model: one parallel job per replica in
+  `service-replica-set`;
+- jobs that only need to be placed near each other: placement groups
+  (PR-11), which give co-placement without a co-start.
 
 ## Current State
-- **One parallel job is already a gang:** all its tasks are placed together under `span[]` (`parjob-placement`).
-- **Heterogeneous single jobs:** compound resreqs (`N*{...}+M*{...}`, `lib/xce_resreq.peg:60-83`) express different task shapes within one job.
-- **Missing:** a group of separate jobs scheduled atomically, topology packing across a gang (`resource-instances`), and readiness of the gang's claims (`resource-claims`).
+- One parallel job is already a gang: all its tasks are placed together
+  (`parjob-placement`), and compound resreqs (`lib/xce_resreq.peg:60-83`)
+  mix task shapes within it.
+- There is no all-or-nothing start for a group of separate jobs or services.
 
 ## Desired Outcome
-- **Gang group:** the jobs of a group are scheduled all-or-nothing in one session decision (or by a reservation that accumulates until complete, with a timeout and release).
-- **Placement:** packed by topology (switch block, NVLink domain) when requested.
-- **Start:** no member starts until every member is placed and all their claims are READY.
-- **Group policy:** if a member fails, the group policy decides: fail all, restart all, or tolerate.
-- **Interactions:** with `job-resize`, preemption and backfill.
-- **Surfaces:** visible in xcecli/REST (group state, member states, pend reason).
+- **Co-start group:** a named group whose members are batch jobs and/or
+  service replica sets.
+- **Placement:** all members are placed all-or-nothing, in one session
+  decision or through a reservation that accumulates until complete, with a
+  timeout and release. Placement is packed by topology when requested,
+  reusing PR-11 placement groups.
+- **Start barrier:** no member starts until every member is placed and all
+  their claims are READY.
+- **Failure policy:** after the start, members keep their own lifecycles
+  (restart, scale). When a member fails, the group policy decides: fail the
+  group, restart the member, or tolerate.
+- **Display:** in xcecli/REST, with the group state, member states and the
+  pend reason.
 
 ## Approach
-- A group object, or a job-array-like construct, in the controller.
-- A scheduler gang step on top of the allocator framework, possibly reusing the parallel-job planner.
-- A group-level start barrier in the dispatch path.
+A group object in the controller; a scheduler co-placement step on top of
+the allocator framework and placement groups; a group start barrier in the
+dispatch path.
 
 ## Scope
-- **In:** group definition and submission, atomic placement, start barrier, failure policy, display, simulator support.
-- **Out:** elastic training frameworks themselves; claim and instance mechanics (other specs).
+- **In:** group definition, mixing jobs and service replica sets; atomic
+  placement; start barrier; failure policy; display; simulator support.
+- **Out:** RL and serving frameworks themselves; single-job training
+  (PR-10); claim and instance mechanics.
 
 ## Boundary Candidates
 - Group object.
-- Scheduler gang step.
+- Scheduler co-placement step.
 - Dispatch barrier.
 - Failure policy.
 
 ## Out of Boundary
-- Application-level rendezvous (torchrun etc.).
+- Application-level rendezvous (torchrun, Ray).
 
 ## Upstream / Downstream
-- **Upstream:** `resource-instances`, `resource-claims`, `parjob-placement`, `scheduler-framework`.
-- **Downstream:** LLM training workflows, `job-resize` (group resize).
+- **Upstream:** `resource-instances`, `resource-claims`,
+  `service-replica-set`, placement groups (PR-11), `scheduler-framework`.
+- **Downstream:** RL post-training and disaggregated-serving workflows.
 
 ## Existing Spec Touchpoints
-- **Adjacent:** `job-dependency` (ordering, not co-scheduling), `scheduler-preemption`, `service-replica-set` (replicas are independent, not a gang).
+- **Adjacent:**
+  - `job-dependency`: ordering, not co-start;
+  - `scheduler-preemption`;
+  - `service-replica-set`: replicas are independent; a co-start group can
+    contain replica sets;
+  - `job-resize`.
 
 ## Constraints
-- **Scheduler:** deterministic for sim/replay.
-- **Persistence:** group state is durable and field-complete in snapshots.
-- **HA/persistence:** full 3-phase spec workflow.
+- Deterministic for sim/replay.
+- Group state durable and field-complete in snapshots.
+- Full 3-phase spec workflow (HA/persistence).