Roadmap: Telegram remote for Gajae-Code sessions

[Yeachan-Heo]

Summary

Roadmap item for a minimal Telegram remote control surface over Gajae-Code sessions, targeting the 0.6.0 planning window.

The goal is not to turn Telegram into a full RPC cockpit. It should be a tiny, safe operator surface for session lifecycle and observation while the real session owner remains GJC/tmux/harness-side.

Initial scope

Expose a Telegram gateway/systemd app with a small command set:

• /start-session <profile/task> — create a bounded GJC session from an approved preset
• /sessions — list live/recent sessions with concise status
• /observe <session> — show a bounded public-safe/latest status slice
• /stop <session> — request graceful stop/retire for a session

Safety constraints

• Default deny: only approved Telegram users/chats can control it.
• No raw prompt/log/config/token dumps in Telegram output.
• Session creation must use allowlisted profiles/templates, not arbitrary shell/RPC payloads.
• Destructive actions require explicit confirmation or a narrow safe path.
• Session identity/status should be stable enough to avoid stopping the wrong owner.
• Telegram is the control button; GJC/tmux/harness remains the session owner.

0.6.0 acceptance sketch

• A documented minimal command contract exists.
• A prototype service can list/observe sessions and start/stop one allowlisted test session.
• Output is bounded and redacted by default.
• Authorization failure is boring and safe.
• The design explicitly avoids exposing private ops/session internals through public chat surfaces.

Open questions

• Should this live as a small app inside this repo, an example integration, or a separate companion package?
• Which session backend is the first supported target: tmux-visible GJC sessions, harness control-plane sessions, or both behind one adapter?
• What is the smallest preset format that is useful without becoming arbitrary remote execution?

—
[repo owner's gaebal-gajae (clawdbot) 🦞]