hermes - 💡(How to fix) Fix Cross-bot user-level ephemeral status (device mode, AFK, focus project, quiet hours) [1 pull requests]

Problem

Hermes provides two surfaces for non-conversational context:

• USER.md for durable user facts (cached as part of the system prompt)
• _plugin_turn_context in run_conversation() for per-turn dynamic content

There's a gap between them: frequently-flipping user state that should be visible to every profile — things like:

• Device/form-factor mode (e.g. mobile vs desktop, where reply length and attachment behavior should differ)
• Availability state (available / short break / long break)
• Current focus project (so unrelated profiles can defer proactive nudges)
• Quiet hours
• Travel/location-dependent defaults

Storing these in USER.md per-profile creates three issues:

1. Every profile needs updating when the flag changes (N writes per flip)
2. Each profile pays a system-prompt cache invalidation per edit
3. Profiles can drift out of sync if any one write fails or lags

The architectural pattern in software-development/hermes-ephemeral-turn-context already covers the right shape (inject per-turn, don't bake into the cached prefix). This issue proposes a small concrete implementation of that pattern for cross-profile user state.

Proposed approach

Single shared status file + per-turn ephemeral injection.

Storage

A JSON file under ~/.hermes/state/ containing the active flags, last-updated timestamps per field, and an attribution field for the last writer. Atomic read-modify-write so concurrent profiles don't clobber each other.

Injection

A helper on AIAgent invoked from the run_conversation() ephemeral path that:

• Reads the file
• Applies per-field staleness rules
• Returns a short status line for the active fields
• Appends to _plugin_turn_context only — never to _cached_system_prompt

Mutation

A small tool (e.g. user_status) registered in the gateway toolset with get / set operations, available to any profile that wants to update the shared state in response to a user signal.

Optional

Slash commands for fast manual switching (/status family).

Why not extend user memory

User memory is in the cached prefix. Any edit invalidates the cache for the rest of the session, which is the wrong cost profile for state that may flip several times a day.

Why a single shared file vs per-profile state

A shared file scales to N profiles at the cost of one write and one read per turn. Per-profile copies require either a broadcast mechanism on every change or accept eventual-consistency drift — neither is ideal for state the user expects to be globally true.

Sketch of acceptance criteria

• ~/.hermes/state/ created on first use
• Status JSON schema with atomic-write helper
• AIAgent helper called from the ephemeral turn-context path (not the cached system prompt builder)
• Per-field staleness handling
• Tool exposed via the gateway toolset for cross-profile updates
• Tests for: missing file, present file, stale fields, concurrent writes
• Optional follow-up: slash command surface

Happy to take this on if it's a direction the project wants to go — wanted to file the design first to check fit before submitting a PR.