[Wave 4] Low/info — Docs: docs/usermanuals/en/deployment/ #786

Wave 4 · 10 finding(s) in 10 fix package(s). Documents with fewer than five findings each in this wave, grouped by directory.

Findings

• DOC-BLEGAL-225 (docs, Low) — docs/usermanuals/en/deployment/gguf-export.md: wrong detail — Drop the .gguf file into LM Studio's models directory; it appears in the picker.
  severity Low
  Where. docs/usermanuals/en/deployment/gguf-export.md:99 (Turkish mirror: docs/usermanuals/tr/deployment/gguf-export.md:100) · type: wrong detail
  The document says. Drop the .gguf file into LM Studio's models directory; it appears in the picker.
  What the code does. LM Studio expects ~/.lmstudio/models///.gguf, or lms import <path> (experimental). A bare file at the models root does not match the documented layout. This was not tested in LM Studio.
  Proposed correction. 'Place it at ~/.lmstudio/models///model.gguf, or run lms import model.gguf.' TR: aynı yol.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-BLEGAL-226 (docs, Low) — docs/usermanuals/en/deployment/gguf-export.md: stale — [IS-T08-20] '$ ./main -m model.q4_k_m.gguf -p "Hello, how are you?" -n 256'
  severity Low
  Where. docs/usermanuals/en/deployment/gguf-export.md:104 (Turkish mirror: docs/usermanuals/tr/deployment/gguf-export.md:105) · type: stale
  The document says. [IS-T08-20] '$ ./main -m model.q4_k_m.gguf -p "Hello, how are you?" -n 256'
  What the code does. llama.cpp renamed main to llama-cli on 2024-06-12 (PR #​7809). The main deprecation stub prints 'The binary main is deprecated. Please use llama-cli instead' and returns EXIT_FAILURE. The CLI target is llama-cli (tools/cli/CMakeLists.txt), or the unified llama cli.
  Proposed correction. $ llama-cli -m model.q4_k_m.gguf -p "Hello, how are you?" -n 256
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B01-044 (docs, Low) — docs/usermanuals/en/deployment/verify-gguf.md: misleading — Recompute the layers to detect drift between what they sent and what they signed.
  severity Low
  Where. docs/usermanuals/en/deployment/verify-gguf.md:14 (Turkish mirror: docs/usermanuals/tr/deployment/verify-gguf.md:14) · type: misleading
  The document says. Recompute the layers to detect drift between what they sent and what they signed.
  What the code does. A .sha256 sidecar is an unkeyed digest, not a signature. Whoever sends or relays the file can regenerate it (the page itself says so at :164).
  Code references. forgelm/verify/_gguf.py:103-151
  Proposed correction. "...detect drift from the digest they published — obtain that digest out of band (signed release notes, detached signature); a sidecar shipped with the file proves nothing about the sender."
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B01-045 (docs, Low) — docs/usermanuals/en/deployment/verify-gguf.md: broken example — Text and JSON output examples list magic_ok, metadata_parsed, sidecar_present, sidecar_match, tensor_count, sha256_* (the no-gguf examp…
  severity Low
  Where. docs/usermanuals/en/deployment/verify-gguf.md:57-66,74-91,121-130 (Turkish mirror: docs/usermanuals/tr/deployment/verify-gguf.md:57-66,74-91,121-130) · type: broken example
  The document says. Text and JSON output examples list magic_ok, metadata_parsed, sidecar_present, sidecar_match, tensor_count, sha256_* (the no-gguf example omits the sha lines).
  What the code does. checks always contains metadata_error (null when there is no error), and text mode prints every checks key, so a metadata_error: None line appears. With a sidecar present, the no-gguf case also prints sha256_actual and sha256_expected. Observed output: magic_ok, metadata_parsed, metadata_error, sidecar_present, sidecar_match.
  Code references. forgelm/verify/_gguf.py:75-81, forgelm/verify/_gguf.py:95, forgelm/cli/subcommands/_verify_gguf.py:119-123
  Proposed correction. Add metadata_error (null / None) to the examples, and the sha256 lines to the no-gguf example.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B01-046 (docs, Low) — docs/usermanuals/en/deployment/verify-gguf.md: wrong detail — checks dict has magic_ok, metadata_parsed, sidecar_present, sidecar_match, tensor_count, sha256_*
  severity Low
  Where. docs/usermanuals/en/deployment/verify-gguf.md:58-67,76-91 ; docs/reference/verify_gguf_subcommand.md:22,56-90 · type: wrong detail
  The document says. checks dict has magic_ok, metadata_parsed, sidecar_present, sidecar_match, tensor_count, sha256_*
  What the code does. checks always also contains metadata_error (None/null) and sidecar_match is None without a sidecar; text output prints those lines.
  Code references. forgelm/verify/_gguf.py:75-81, forgelm/cli/subcommands/_verify_gguf.py:122-123
  Proposed correction. Add metadata_error to the examples/flag table.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B01-049 (docs, Low) — docs/usermanuals/en/deployment/verify-gguf.md: wrong detail — Third-party GGUF: recompute layers "to detect drift between what they sent and what they signed."
  severity Low
  Where. docs/usermanuals/en/deployment/verify-gguf.md:14 (Turkish mirror: docs/usermanuals/tr/deployment/verify-gguf.md) · type: wrong detail
  The document says. Third-party GGUF: recompute layers "to detect drift between what they sent and what they signed."
  What the code does. The sidecar is an unsigned SHA-256 digest (verify/_gguf.py:104-151). No signature or key is verified, so the check detects mismatch with the digest file, not with anything "signed".
  Code references. forgelm/verify/_gguf.py:120-151
  Proposed correction. Replace "what they signed" with "the SHA-256 they published".
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B08-067 (docs, Low) — docs/usermanuals/en/deployment/deploy-targets.md: false claim — Generated configs include a comment with source run-id and timestamp
  severity Low · already tracked: KNOWN-OPEN CLI-10|CLI-14|CLI-15|CLI-16 docs/roadmap/phase-16-trust-surface-hardening.md:624-625
  Where. docs/usermanuals/en/deployment/deploy-targets.md:171 · type: false claim
  The document says. Generated configs include a comment with source run-id and timestamp
  What the code does. Only a static 'Generated by ForgeLM deploy' line; the JSON has _generated_by/_docs.
  Code references. forgelm/deploy.py:120-123, forgelm/deploy.py:207-208
  Proposed correction. Drop the claim or implement it.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B08-070 (docs, Low) — docs/usermanuals/en/deployment/model-merging.md: wrong detail — slerp 'Requires exactly two entries.'
  severity Low
  Where. docs/usermanuals/en/deployment/model-merging.md:77 (Turkish mirror: docs/usermanuals/tr/deployment/model-merging.md:77) · type: wrong detail
  The document says. slerp 'Requires exactly two entries.'
  What the code does. With a count other than 2, _slerp_merge logs a warning and silently falls back to a linear merge (merging.py:183-185). Nothing is rejected.
  Code references. forgelm/merging.py:181-185
  Proposed correction. "Uses exactly two entries; with any other count ForgeLM warns and falls back to linear."
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

• DOC-D3B08-071 (docs, Low) — docs/usermanuals/en/deployment/model-merging.md: wrong detail — ForgeLM rejects merges across different bases 'at merge time with a clear error'.
  severity Low
  Where. docs/usermanuals/en/deployment/model-merging.md:150 (Turkish mirror: docs/usermanuals/tr/deployment/model-merging.md:150) · type: wrong detail
  The document says. ForgeLM rejects merges across different bases 'at merge time with a clear error'.
  What the code does. There is no explicit base-compatibility check. The failure is whatever PeftModel.from_pretrained or torch raises (e.g. a size mismatch), caught generically and reported as MergeResult(error=str(e)), exit 2 (merging.py:110-112; _no_train_modes.py:175-176).
  Code references. forgelm/merging.py:72-112, forgelm/cli/_no_train_modes.py:175-176
  Proposed correction. "... the merge fails when PEFT cannot load an adapter onto the base (typically a tensor size-mismatch error) and exits 2."
  Turkish mirror. the Turkish page has no such statement

• DOC-D3B08-095 (docs, Low) — docs/usermanuals/en/deployment/model-merging.md: broken example — Link to docs/roadmap/completed-phases.md#phase-14-multi-stage-pipeline-chains-v070
  severity Low
  Where. docs/usermanuals/en/deployment/model-merging.md:162 (Turkish mirror: docs/usermanuals/tr/deployment/model-merging.md:162) · type: broken example
  The document says. Link to docs/roadmap/completed-phases.md#phase-14-multi-stage-pipeline-chains-v070
  What the code does. The heading at docs/roadmap/completed-phases.md:1435 is '## Phase 14 — Multi-Stage Pipeline Chains (v0.7.0)'. GitHub's slug keeps two hyphens around the removed em-dash (phase-14--multi-stage-pipeline-chains-v070), so the single-hyphen anchor does not resolve and the link opens at the top of the page. All other ~120 github.com/HodeTech/ForgeLM blob/tree/main links under docs/usermanuals point a…
  Code references. docs/roadmap/completed-phases.md:1435
  Proposed correction. Change the fragment to #phase-14--multi-stage-pipeline-chains-v070, in the TR mirror too.
  Turkish mirror. the Turkish page has the same error; fix both in the same PR

Done when

• Every finding above is fixed or closed with a reason (tick it here).
• Code fixes carry a test; doc fixes update the Turkish mirror in the same PR.

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}