Skip to content

fix(windows): refresh stale Hermes persona fallback - #3346

Open
tang-vu wants to merge 1 commit into
Osmantic:mainfrom
tang-vu:fix/windows-refresh-stale-hermes-soul
Open

fix(windows): refresh stale Hermes persona fallback#3346
tang-vu wants to merge 1 commit into
Osmantic:mainfrom
tang-vu:fix/windows-refresh-stale-hermes-soul

Conversation

@tang-vu

@tang-vu tang-vu commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Summary

  • replace an existing generated data/persona/SOUL.md when Python rendering is unavailable
  • keep the install phase and the Windows maintenance CLI behavior identical
  • exercise both real PowerShell functions against a stale-file sandbox

Why this matters

Windows install and refresh paths regenerate Hermes' install-owned persona after configuration/template changes. When every Python renderer candidate is unavailable, both paths only removed directories and silently retained an old regular file. The invariant is that a refresh always produces content from the current template, whether dynamic rendering succeeds or the fallback is used.

Closes #3334.
Closes #3343.

Overlap check

Searched open and closed PRs for Windows SOUL.md, Repair-HermesSoulMd, Invoke-HermesSoulRefresh, and both issue numbers. No PR covers either production entry point. The two reports are intentionally combined because they implement the same refresh contract in the phase and maintenance CLI copies.

Test plan

  • powershell.exe -NoProfile -ExecutionPolicy Bypass -File ods/tests/test-windows-hermes-soul-refresh.ps1 (both entry points passed)
  • PowerShell AST parsing occurs inside the regression test for both source files
  • git diff --check

Tradeoffs and rollback

SOUL.md is installer-generated state, not a user-owned source template; fallback refresh now overwrites it just as successful dynamic rendering already does. No migration is needed. Reverting restores stale-file preservation when Python is unavailable.

Generated with Codex

Follow-up overlap audit (2026-08-31)

#3489 opened later and fixes the same Test-Path -PathType Container mistake, but only in installers/windows/ods.ps1; it leaves the duplicated installer-phase implementation in phases/06-directories.ps1 stale and provides no executable regression test.

#3346 remains the stronger canonical fix because it keeps both Windows production entry points behaviorally identical and runs each real function against a pre-existing stale SOUL.md with Python rendering unavailable. #3489's narrower -PathType Leaf check offers no independent advantage over #3346's removal of whatever conflicting node exists at the installer-owned output path, so no code was ported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant