Feedback: hook system too thin to host a workflow framework (e.g. GSD) — request a first-class lifecycle-hook API

First — jcode is genuinely impressive. The RAM efficiency, ~14ms startup, the flicker-free renderer, swarm, and the fact that it imported my Claude Max login and my skills on first run are all excellent. The shipping iOS app is a real edge.

I evaluated adopting jcode as the runtime behind a self-hosted multi-agent control plane and decided not to, for one narrow, actionable reason: the hook system is too thin to host a workflow framework.

My setup runs a planning/enforcement system (GSD) built as ~19 lifecycle hooks — roughly the Claude Code set: PreToolUse / PostToolUse / SessionStart / UserPromptSubmit / Stop / PreCompact — that guard edits, monitor context, validate commits, and enforce phase boundaries. jcode happily imported all 67 of my skills into ~/.jcode/skills/, but [hooks] only exposes a pre_tool_timeout_ms; there's no documented lifecycle-hook API with typed event payloads that a third-party workflow tool can subscribe to. So the commands came over, but the rails couldn't.

Request: a first-class, documented hook/plugin API with parity to Claude Code's lifecycle events (pre/post tool, session start, prompt submit, stop, compact) and typed payloads — similar in spirit to OpenCode's plugin event system. The moment that exists, frameworks like GSD become portable to jcode, and you inherit much of the Claude Code extension ecosystem.

Happy to share my hook manifest as a concrete target if useful. Thanks for building this.

Start by locating the existing [hooks] configuration and the pre_tool_timeout_ms handling, then trace how tool and session lifecycle events are represented. Compare the available events with the requested PreToolUse, PostToolUse, SessionStart, UserPromptSubmit, Stop, and PreCompact set. Done means a documented, typed hook/plugin API covers the requested lifecycle events and can support third-party workflow frameworks.