@@ -22,8 +22,9 @@ backend:
   (allreduce / allgather / reduce_scatter / alltoall / broadcast / gather / scatter / reduce /
   send / recv / barrier, …). Each override converts privateuseone tensors into the device view
   the inner backend needs (`_C._flagos_to_cuda_view`), delegates to `self._inner`, and returns
-  the inner backend's Work. Inner backend priority: FlagCX → HCCL (ascend) → NCCL
-  (nvidia/metax).
+  the inner backend's Work. Inner backend priority: FlagCX → the vendor's native backend
+  (HCCL for ascend, NCCL for nvidia/metax, MCCL for MUSA) → host-staged gloo, the last tier
+  and the only one that needs no vendor library (§0.4).
 
 - **Registration**: `import torch_fl` calls `register_flagos_backend()`, which runs
   `Backend.register_backend("flagos", creator, devices=["privateuseone"])` and sets
@@ -80,6 +81,58 @@ Integrate against this contract; do not guess:
 
 The manual suite does not yet exercise point-to-point operations, gather/scatter roots, all-to-all, multi-node rendezvous, process failure recovery, or more than two devices. Those paths remain unvalidated on Enflame hardware.
 
+### 0.4 Host-staged gloo and gloo redirection (measured on MUSA MTT S5000)
+
+A host with no FlagCX, no vendor torch and no vendor communication library used to have no
+working collective at all: `ProcessGroupFlagOS` raised "no suitable inner backend" from
+`backend="flagos"`, and `backend="gloo"` — what torchrun and the transformers FSDP2 tests ask
+for — built a `ProcessGroupGloo` whose C++ collectives reject flagos tensors with
+`ProcessGroupGloo::allreduce: unsupported device type flagos` (issue
+[#263](https://github.com/flagos-ai/Torch-FL/issues/263)).
+
+Two additions close that gap. Both are in `torch_fl/comm/process_group.py` and both are gated
+by a runtime switch:
+
+- **`_try_build_staged_gloo` — the last tier of `_build_inner`.** gloo ships inside c10d, so it
+  is always present; this tier builds a real `ProcessGroupGloo` and wraps it in
+  `_HostStagedGloo`, a `ProcessGroup` facade that moves every flagos operand through host memory
+  (device → host → collective → device) and synthesises the two virtuals gloo does not implement
+  (`allgather_into_tensor_coalesced`, `reduce_scatter_tensor_coalesced`) from gloo's own
+  `_allgather_base` / `_reduce_scatter_base`. It costs a copy per collective, so it runs only
+  after FlagCX and the vendor-native backend have declined, and it warns once when it is used.
+  `FLAGOS_DIST_STAGED_GLOO=0` declines the tier so the failure is explicit instead.
+- **`redirect_gloo_requests` — answered on the requested side.** gloo cannot be repaired from
+  the gloo side: gloo's own `BackendConfig` expansion is what registers a `ProcessGroupGloo`
+  under the flagos device type (`pg._device_types` reads `[('flagos', 'flagos'), ('cpu',
+  'cpu')]` on a plain gloo group), its creator branch asserts `isinstance(backend_class,
+  ProcessGroupGloo)`, and `c10d.Backend` cannot be subclassed from Python at all. So the request
+  is answered with the `flagos` backend *before* the backend config is built: `import torch_fl`
+  interposes on `torch.distributed.init_process_group` and `torch.distributed.new_group` and
+  rewrites a `"gloo"` backend argument to `"flagos"`, but only when the process accelerator is
+  the flagos device (`torch._C._get_accelerator().type`), because gloo is a legitimate choice on
+  a cpu/cuda host. `FLAGOS_DIST_REDIRECT_GLOO=0` keeps the requested backend verbatim while
+  debugging a distributed problem.
+
+**Measured** (two ranks, no FlagCX / no `torch_musa.distributed` / no NCCL, i.e. the worst case;
+`torch_fl/comm/process_group.py` as landed):
+
+| Request | Result |
+| --- | --- |
+| `init_process_group(backend="flagos")` | `ProcessGroupFlagOS` over `_HostStagedGloo`; `all_reduce` → `[3.0, 3.0]` on both ranks |
+| `init_process_group(backend="gloo")` | redirected to `flagos`; `all_reduce`, `all_gather_into_tensor`, `reduce_scatter_tensor`, cpu `all_reduce`, `barrier`, and `torch.ops._c10d_functional.all_gather_into_tensor` all correct on both ranks |
+| `new_group([0, 1], backend="gloo")` | redirected to `flagos`; subgroup `all_reduce` → `[3.0, 3.0]` on both ranks |
+| `FLAGOS_DIST_REDIRECT_GLOO=0` | both ranks get a plain `ProcessGroupGloo` again and fail on the flagos tensor — the switch is load-bearing |
+
+**Partially validated on the FSDP2 suite.** Of the six `Qwen3ModelTest::test_fsdp2_*` nodeids
+that #263 counted, three now pass (`test_fsdp2_save_load`, `test_fsdp2_sharding_structure_0_untied`,
+`test_fsdp2_sharding_structure_1_tied`); the other three get past the collectives and then fail in
+FSDP2's stream setup on a **separate** defect — `torch_fl.flagos.Stream.__init__` routes every
+non-GCU platform without a CUDA runtime to the Ascend ACL stream, so on MUSA it raises
+`RuntimeError: libascendcl.so not found. ACL runtime is required` at
+`_fsdp_param_group.py::FSDPCommContext.lazy_init`. MUSA has no Python-side stream/event
+implementation (`torch_fl/accelerator/` has `ascend`, `gcu`, `metax`, `dcu`, `cuda`, `bpu`,
+`ppu`), so those three remain blocked on that work, not on the collective path.
+
 ---
 
 ## 1. Background and prior state
 
@@ -112,6 +112,18 @@ Logging and tracing. None of these changes routing.
 | `FLAGOS_TRACE` | Runtime | `0` (off) | Verbose logging in the device profiler shim compiled into this build. One switch covers every accelerator: exactly one device tracer is compiled per build, so the name is never ambiguous |
 | `FLAGOS_TRACER_LIBRARY` | Runtime | Auto-discovered | Override the tracer library the profiler shim `dlopen`s, when the default path does not match the installed driver |
 
+### Distributed
+
+How `torch.distributed` picks a backend for the flagos device. The `"flagos"`
+backend is registered at import; these switches cover the two cases where a
+caller does *not* ask for it by name. See
+[distributed over FlagCX](../architecture/distributed-flagcx.md).
+
+| Variable | Scope | Default | Purpose |
+|----------|-------|---------|---------|
+| `FLAGOS_DIST_REDIRECT_GLOO` | Runtime | `1` (on) | Answer a plain `init_process_group(backend="gloo")` or `new_group` request with the flagos backend when the process accelerator is the flagos device. `torch.distributed` routes any device type it does not recognise to gloo, and a `ProcessGroupGloo` rejects flagos tensors with `unsupported device type flagos` ([#263](https://github.com/flagos-ai/Torch-FL/issues/263)). Set `0` to keep the requested backend |
+| `FLAGOS_DIST_STAGED_GLOO` | Runtime | `1` (on) | Allow the host-staged gloo inner backend: the last fallback tier of the `"flagos"` backend when no vendor communicator (FlagCX/NCCL/HCCL/MCCL) is available. It needs no vendor library at all but copies every flagos operand device->host->device per collective. Set `0` to fail loudly instead of staging. One warning is emitted the first time a group is built on this tier |
+
 ### Vendor compatibility
 
 Import-time shims that adapt a vendor's torch or driver to the flagos device.
 
@@ -83,8 +83,10 @@ root-cause filing. Raw JSON remains outside the repository at
 
 ### What has changed since this baseline
 
-Four of the five causes have a fix; the fifth is the only reason this baseline is
-not fully resolved.
+All five causes have a fix. For one of them (#263) that is not the same thing as
+all of its nodeids passing: the collective failure the row names is gone, and the
+three nodeids that used to be blocked behind it now reach a separate defect in
+FSDP2's stream setup instead.
 
 - **#250, #265** (device context poisoning, and its `test_model_parallelism`
   trigger) — closed 2026-09-15, the same day PR #280 (`6b2af4b`, "stage
@@ -108,18 +110,30 @@ not fully resolved.
   MUSA integer division through mudnn and promote true division").
 - **#264** (TorchInductor/Triton requires CUDA libraries) — PR #419 (`48829b8`,
   "ask torch, not the redirected probe, before aliasing cuda to flagos").
-- **#263** (ProcessGroupGloo rejects `flagos` tensors) — still open. Its six
-  FSDP2 nodeids are the remaining known failures of this baseline, and the failure
-  reproduces today: `RuntimeError: ProcessGroupGloo::allreduce: unsupported device
-  type flagos`.
+- **#263** (ProcessGroupGloo rejects `flagos` tensors) — PR #435 (2026-09-27, "answer gloo
+  requests with the flagos backend and stage collectives over host memory"). gloo cannot be
+  repaired from the gloo side, so the request is answered with the `flagos` backend before the
+  backend config is built, and `ProcessGroupFlagOS` grew a last tier that stages
+  collectives through host memory over a real gloo group
+  (`docs/architecture/distributed-flagcx.md` §0.4 has the mechanism and the
+  measurements). Re-measured with the same harness on this change over `05be850`:
+  `{"PASS": 3, "FAIL": 3}` of the six FSDP2 nodeids, against six failures at
+  baseline. The three that pass are `test_fsdp2_save_load`,
+  `test_fsdp2_sharding_structure_0_untied` and `test_fsdp2_sharding_structure_1_tied`.
+  The three that fail are `test_fsdp2_plan_vs_ddp_0_untied`, `test_fsdp2_plan_vs_ddp_1_tied`
+  and `test_fsdp2_save_load_dcp`, and they fail *after* the collectives, in
+  `_fsdp_param_group.py::FSDPCommContext.lazy_init`, with `RuntimeError: libascendcl.so
+  not found. ACL runtime is required` — `torch_fl.flagos.Stream` sends every non-GCU
+  platform without a CUDA runtime to the Ascend ACL stream. That is a MUSA gap with no
+  issue of its own yet, not the collective path this row tracks.
 
 Because `Affected tests` and the baseline header above describe `64e60dd`, the
 whole table is a dated snapshot and not a statement about the current tree.
 Re-running the baseline is what refreshes it — and is also what fills in the
 `Fingerprint` column, per the note above. The closures above are recorded from the
-issues and the commits that landed; only the #268 re-measurement re-ran any of
-this baseline's tests, and it covers eight nodeids out of twenty, so the other
-four causes are **not revalidated** here.
+issues and the commits that landed; two re-measurements have re-run any of this
+baseline's tests since — #268's eight borrowed nodeids and #263's six — so the rows
+for #250/#265, #264 and #266 are **not revalidated** here.
 
 ### Failed test inventory