fix(selfhost): mirror the engine's JSON->YAML retry in private-config parsing

[bitfathers94]

fix(selfhost): mirror the engine's JSON->YAML retry in private-config parsing

parseConfigMapping and validateConfigWriteContent detected JSON vs YAML the
same way parseFocusManifestContent does but never got its retry: a leading
{/[ document that's valid YAML flow-mapping syntax but invalid strict
JSON was treated as unparseable, silently dropping a per-repo config layer
from the merge (or, with only one layer mounted, applying it correctly while
still firing a false "malformed" warning and metric increment). The write
validator had the identical gap, rejecting documents the read path already
merges. Both now retry as YAML on a JSON parse failure before giving up,
matching the engine parser byte-for-byte.

Closes #10057

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-31 08:02:10 UTC}

2 files · 1 AI reviewer · no blockers · readiness 70/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds the #9065 JSON→YAML retry (already used in focus-manifest.ts and config-lint.ts) to parseConfigMapping and validateConfigWriteContent, closing a real gap where a `{`/`[`-leading YAML flow mapping was silently dropped from the private-config merge or falsely flagged as malformed. The change is a faithful, minimal mirror of the existing pattern (see packages/loopover-engine/src/config-lint.ts's parseManifestTopLevelObject, which does the identical retry), and the accompanying tests exercise the real merge/warning/single-layer paths rather than fabricated states. The write-path error-message behavior on a genuine double-failure (reporting the original JSON error) is a reasonable, tested design choice.

Nits — 6 non-blocking

• src/selfhost/private-config.ts:150 — the JSDoc cites 'focus-manifest.ts:4556' as a line-number pointer to the original retry; line references like this drift silently as the file changes and are a fragile form of documentation.
• The duplicated try/catch nesting in parseConfigMapping and validateConfigWriteContent (now depth 5) could be flattened into a small shared helper (e.g. `parseYamlOrJson(text, looksLikeJson)`) to avoid two near-identical retry blocks living in one file — nit: consider extracting per the DRY concern, or explain why keeping them separate/inline is preferred.
• The new vi.mock("yaml", ...) at the top of test/unit/private-config.test.ts wraps the real parser for the whole file; worth confirming this doesn't subtly affect timing/behavior of the many other unrelated tests in this file that also call parseYaml indirectly (they appear to still use actual.parse via the spy wrapper, which looks safe, but it's a file-wide side effect for two tests' benefit).
• Consider extracting the shared JSON→YAML-retry-with-fallback logic (looksLikeJson → JSON.parse → catch → parseYaml → catch → fallback) into one small helper reused by parseConfigMapping, validateConfigWriteContent, and ideally parseManifestTopLevelObject in config-lint.ts, since duplicating this exact three-way branch across three files is the kind of drift orb(config): no unknown-key validation at runtime — a typo silently disables a safety control with zero warning #9065 itself was about.
• Given the linked issue's coverage note ('partial'), double check whether selfhost(private-config): parseConfigMapping never got #9065's JSON→YAML retry, so a valid layer is silently dropped from the merge #10057 also expected the shared_config/review-block extraction path or config-lint.ts's parseManifestTopLevelObject to be touched — if so, call that out in the PR description so reviewers know the scope boundary is intentional.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#10057
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	⚠️ 12/25	Preflight needs author follow-up before maintainer review.
Contributor workload	✅ 10/10	Author activity: 98 registered-repo PR(s), 67 merged, 3 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bitfathers94; Gittensor profile; 98 PR(s), 3 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds the exact JSON→YAML retry to both parseConfigMapping and validateConfigWriteContent, matching the engine's #9065 fallback shape, updates both JSDoc blocks to reference #9065 explicitly, and preserves the byte ceiling, plain-mapping rejection, and error-naming requirements while adding tests covering merge, single-layer, and double-failure cases.

Review context

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 98 PR(s), 3 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 3 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.86%. Comparing base (e199bb2) to head (26bed77).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10120      +/-   ##
==========================================
+ Coverage   79.79%   79.86%   +0.06%     
==========================================
  Files         282      283       +1     
  Lines       58690    58907     +217     
  Branches     6892     6960      +68     
==========================================
+ Hits        46832    47046     +214     
  Misses      11570    11570              
- Partials      288      291       +3     

Flag	Coverage Δ
backend	98.61% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/selfhost/private-config.ts	98.61% <100.00%> (ø)

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.