nexu-io/html-anything

Problem When Codex runs through the conversion route, its JSONL stream includes lifecycle events such as thread.started and turn.started. It can also emit a nonfatal model-catalog refresh diagnostic on stderr and then continue successfully. The current adapter ignores the lifecycle start events and forwards the full diagnostic response body. The browser also marks a conversion as done whenever the SSE stream ends, even when the agent has a non-zero or missing exit code or produced no HTML. Together, this makes a run look stalled or successful without a reliable terminal state. Reproduction Run pnpm -F @html-anything/next dev. Select Codex and start any conversion. Observe a lifecycle diagnostic before the assistant output. Observe that completion is not derived from both the process exit code and generated HTML. Redacted real-session event shape: thread.started turn.started item.completed (diagnostic) item.completed (agent message) turn.completed Expected behavior Surface the Codex

Topic and thanks.

概述 Pi agent 已经能被识别（/api/agents 返回 available: true），但调用时抛出 UnsupportedAgentProtocolError，因为 pi-rpc 协议尚未实现。 这是与 ACP 协议（Hermes/Kimi/Devin 等）同类的问题，但 Pi 使用的是独立的 pi-rpc 协议，需要单独实现。 当前状态 /api/agents 返回片段 { "id": "pi", "label": "Pi", "vendor": "Inflection", "protocol": "pi-rpc", "models": [ {"id": "default", "label": "Default (CLI config)"}, {"id": "anthropic/claude-sonnet-4-5", "label": "Claude Sonnet 4.5"}, {"id": "anthropic/claude-opus-4-5", "label": "Claude Opus 4.5"}, {"id": "openai/gpt-5", "label": "GPT-5"}, {"id": "google/gemini-2.5-pro", "label": "Gemini 2.5 Pro"} ], "unsupported": true, "available": true, "path": "/home/bewg/.local/share/fnm/node-versions/v24.18.0/installation/bin/pi", "resolvedBin": "pi" } 错误信息 调用 Pi 时返回： pi uses the pi-rpc protocol, which is not yet wired up in this build.

Parent #112 — PRD: macOS Desktop Client (Electron, Intel x64 v1) What to build When the Desktop Client starts the embedded server, merge environment variables from the user's login shell (especially PATH) into the server process so externally installed Coding Agents in paths like ~/.local/bin, Homebrew, nvm, and fnm are discoverable — matching browser parity when the user runs the dev server from a terminal. Preserve existing server-side agent scanning and Settings binary override; PATH injection is additive. End-to-end outcome: with a test or real agent CLI on a login-shell-visible PATH, the Desktop Client top bar lists that agent without manual bin override. Acceptance criteria Server process receives login-shell-enriched PATH on macOS when launched from Desktop Client /api/agents in the Desktop Client window lists agents found in typical user install locations Settings binary override still wins over PATH scan when set Automated smoke test: fake executable in a login-shell-

Parent #112 — PRD: macOS Desktop Client (Electron, Intel x64 v1) What to build Enable standalone production output for the Next application so a single Node process can serve the full editor without pnpm dev. Wire the e2e Capability Parity seam: Playwright runs against this production standalone server (same artifact the Desktop Client will bundle). End-to-end outcome: after next build, starting the standalone server on loopback serves the entry view, API routes, Skill templates, and existing e2e specs pass unchanged against that server. Include any copy/trace steps required so Skill template assets and static files needed at runtime are present in the standalone artifact. Acceptance criteria Next application builds with standalone output enabled Standalone server starts on a loopback port and serves the editor entry view /api/agents, /api/templates, and host-validation middleware behave as in dev e2e Playwright config uses the standalone production server (or documents an equiv