blocker: define the supported remote Hermes launch/session contract explicitly for stable release

[richard950825-sys]

Summary

Hermes Gate is now explicitly positioned as a temporary local client for reconnecting to durable remote tmux/Hermes sessions.

Under that product model, it is acceptable for Hermes Gate to support a narrower remote workflow contract than a general-purpose remote workspace manager. However, that supported contract must be explicit and stable enough for release.

Right now the implementation already assumes a narrow remote session model, but the product/docs boundary is still not explicit enough about what is and is not supported.

Current behavior

The current code effectively defines a remote session contract like this:

• create a tmux session named gate-N
• launch Hermes via bash -l -c hermes
• later reattach to the entire tmux session
• treat the Gate-created tmux session as the unit of management

This is a real contract in implementation terms, but it is not yet formalized clearly enough for release.

Why this matters

This is a release blocker because users need to know what Hermes Gate actually supports.

Without an explicit contract, users may reasonably assume Hermes Gate supports broader remote Hermes workflows than it really does, for example:

• launch from arbitrary working directories
• wrapper scripts or aliases instead of plain hermes
• environment preloading before launch
• richer tmux session layouts beyond the Gate-managed model
• arbitrary native Hermes start conventions that happen to work manually on the server

A temporary local client is allowed to be opinionated, but it is not allowed to hide that opinionated contract behind broader expectations.

Evidence

Observed in:

• hermes_gate/session.py
• especially create_session() and attach_cmd()

Current implementation includes behavior equivalent to:

• tmux new-session -d -s gate-N "bash -l -c hermes"
• tmux attach -d -t gate-N

Expected behavior

Hermes Gate should clearly define the supported remote session model it manages.

That definition should make it easy to answer questions like:

• what is a managed session in Hermes Gate?
• what launch environment is assumed?
• what remote shell/runtime assumptions are required?
• what is intentionally unsupported?

Suggested direction

One acceptable direction is to explicitly narrow scope and document it.

For example, the project could state that stable support currently means:

• Gate-managed tmux sessions only
• one specific remote launch model
• one clearly defined attach model

Another acceptable direction is to broaden support. But for release, the minimum requirement is clarity, not maximal feature scope.

Acceptance criteria

• the supported remote Hermes launch/session model is documented explicitly
• docs distinguish supported Gate-managed sessions from broader native remote workflows
• startup/attach semantics are described in a way consistent with the actual implementation
• release docs no longer imply broader support than the implementation provides

Testing requirements

Automated tests

• regression tests for any code paths changed while formalizing the session contract
• doc regression tests if product-facing wording is updated

Manual / integration validation

• verify the documented supported launch/session model works end-to-end on a real remote server
• verify at least one intentionally unsupported workflow is either rejected clearly or documented clearly

Non-goals

• supporting every possible native Hermes remote workflow in this issue
• turning Hermes Gate into a persistent local workspace manager