hermes - 💡(How to fix) Fix Feature Request: explicit local patch reapply workflow for upstream updates [1 participants]

Problem

Hermes updates are straightforward if you stay fully upstream or fully forked. The painful middle ground is users who keep a mostly-upstream install but carry a small set of local source changes.

Today, those users effectively have to rebase and manually re-apply their local patches after upstream updates. That works, but it is brittle, repetitive, and easy to get wrong when the same local customizations need to survive multiple upstream releases.

This is similar in spirit to #8302 (preserving local skill customizations while still benefiting from upstream changes), but for local source-code patches / customizations, not just skill files.

Motivation

There seems to be a real class of Hermes users who:

• want to stay close to upstream,
• want upstream bug fixes and new features,
• but also need a few local-only customizations.

Right now the practical options are all bad:

• keep a long-lived fork and manually rebase forever,
• repeatedly re-apply the same local edits by hand,
• or avoid updating because local customizations are annoying to preserve.

For users who intentionally run Hermes as a customizable local agent, this creates friction around updating and experimentation.

Narrow Proposal

A scoped v1 could focus on explicit, auditable patch reapplication, not autonomous "self-healing" behavior.

Examples of what that might look like:

• a tracked patch-manifest file describing local patches to re-apply after update,
• a command to check whether each patch still applies cleanly,
• a command to re-apply patches after update and fail loudly on conflicts,
• status output showing which patches applied, failed, or need manual intervention.

Non-Goals

To keep scope sane, this would not mean:

• silently rewriting code,
• AI-driven automatic conflict resolution,
• hidden mutation of local files without an explicit user action,
• trying to preserve arbitrary changes with no traceable patch source.

Why this might fit Hermes

Hermes already has users who customize local behavior and workflows. A lightweight patch-preservation workflow could make local customization less fragile without forcing users into a full permanent fork.

The key point is to keep it boring:

• explicit,
• local-first,
• fail-closed,
• inspectable,
• easy to ignore if you do not need it.

Questions for maintainers

1. Is this kind of explicit local patch-reapply workflow in scope at all?
2. If yes, would maintainers prefer:
   • a source-control-oriented workflow helper,
   • a Hermes-native patch manifest / status command,
   • or something narrower than either of those?
3. Is there enough user pain here to justify a small v1, or is this too niche for core Hermes?

If this seems directionally acceptable, I’m happy to turn it into a tighter proposal or a small PR with a deliberately limited first version.