Files
neuron-tai/.scratch/distributed-gguf-runtime/evidence/MAINTENANCE-HANDOFF.md

2.7 KiB

Maintenance review handoff — distributed GGUF runtime

Date: 2026-07-14 Scope: close the maintenance review, preserve the hard blockers, and hand off the remaining implementation work to the next model.

What is complete

  • Completed stories are now recorded in docs/issues/distributed-gguf-runtime/.
  • The PRD and milestone docs were updated to reflect the closed set and the blocked set.
  • The DGR-018 preflight scripts were preserved at commit a0f28b5.
  • The current feature line has delivered DGR-001 through DGR-006 and DGR-017.

Hard / unsolved issues for later

1) DGR-018 requires hardware we do not have

DGR-018 is blocked because the whole-model GLM-5.2 UD-IQ1_S oracle requires:

  • a 256-GiB-class host,
  • at least 224 GiB runtime-accessible memory,
  • at least 250 GB free storage on one filesystem outside /home.

The current development host reports only 124.9 GiB MemTotal and has no eligible filesystem with 250 GB free. The authoritative blocker evidence is in evidence/DGR-018/BLOCKED.md and evidence/DGR-018/preflight.json.

2) DGR-019 and DGR-020 are transitively blocked

  • DGR-019 needs the DGR-018 oracle for parity certification.
  • DGR-020 needs DGR-018 and DGR-019, plus enough physical consumer nodes that no single node can admit the whole recipe.

No smaller model may be substituted for these stories.

3) The remainder of the graph stays blocked unless replanned

The current graph makes DGR-007 depend on DGR-019, which means:

  • DGR-007 through DGR-016 are also blocked transitively.
  • Unblocking the dense pipeline without the 256-GiB host would require an explicit replanning decision to relax the DGR-007 → DGR-019 dependency.
  • That replanning decision has not been made.

4) Maintenance-only tasks should stay separate from feature implementation

The review uncovered that the codebase now has a clean closed-story split, but further work should avoid mixing:

  • maintenance cleanup,
  • blocked-hardware preparation,
  • and actual distributed GLM implementation.

The next model should treat the maintenance pass as closed and only pick up real implementation work that is not hardware-blocked.

Use the next model to continue on the non-blocked implementation queue only. Priority candidates are whatever is still actionable without the GLM oracle host; if a story depends on DGR-018, keep it deferred.

Reference files

  • docs/issues/distributed-gguf-runtime/README.md
  • .scratch/distributed-gguf-runtime/PRD.md
  • .scratch/distributed-gguf-runtime/milestones.md
  • .scratch/distributed-gguf-runtime/evidence/DGR-018/BLOCKED.md
  • .scratch/distributed-gguf-runtime/evidence/DGR-018/preflight.json