/**
 * @fileoverview Chat panel HTML — extracted v2.5.1 for cross-page reuse.
 *
 * ## Why this module exists (v2.5.1 REQ-2 fix + v2.5 REQ-3 extension)
 *
 * v2.5.0 introduced the home-page chat panel via `renderChatPanel()`
 * defined inside `src/server.ts`. Only `renderIndexPage` (the legacy
 * home page, hit when no `TaskSessionStore` is configured) actually
 * called it. The plugin always wires a `TaskSessionStore`, so the
 * production home page (`renderSessionForestPage` in
 * `src/task-session-store.ts`) shipped **without** the chat panel.
 *
 * The pre-existing `home-chat-v25.test.ts` constructed a server
 * WITHOUT `sessionStore`, so the green test exercised the legacy
 * path and the v2.5.0 bug slipped through.
 *
 * The v2.5.1 fix:
 *   1. Extract `renderChatPanel()` into this shared module.
 *   2. Have BOTH `renderIndexPage` (legacy) AND
 *      `_renderSessionForestPageImpl` (production home) import it.
 *   3. Both pages also need `<script src="/static/chat-panel.js"
 *      defer></script>` for the JS to actually wire up the form.
 *
 * v2.5 REQ-3 extends `renderChatPanel()` to accept an `opts` bag
 * with `scope` ("home" | "task") and `taskId` (when scope=task).
 * The HTML carries `data-chat-scope` and `data-task-id` hooks that
 * the chat-panel.js factory picks up to route to `/api/chat/...`
 * vs `/api/task-chat/...` and to select the right localStorage key.
 *
 * Extracting to a dedicated module avoids a circular import between
 * `server.ts` ↔ `task-session-store.ts` (server already imports from
 * task-session-store, and task-session-store previously imported
 * nothing from server, but future plugin evolution may want
 * session-store to depend on other server-side types — keeping
 * chat-panel-html a leaf module is a safer contract).
 *
 * The asset contract pinned by `test/home-chat-v25.test.ts`,
 * `test/chat-panel-session-forest-v251.test.ts` and
 * `test/task-chat-v25.test.ts`:
 *   • `data-chat-shell` — the section root
 *   • `data-chat-scope` — "home" | "task" (read by the JS factory)
 *   • `data-task-id`   — task id when scope=task
 *   • `data-chat-input` — the text input
 *   • `data-chat-send`  — the submit button
 *   • `data-chat-form`  — the `<form>` (used by the JS to bind Enter)
 *   • `data-chat-messages` — the message log container
 *   • `<script src="/static/chat-panel.js" defer></script>` — must
 *     follow the markup on the same page (defer is fine because the
 *     JS module polls for the DOM on load).
 *
 * Disabled gracefully: when the host didn't pass
 * `chatOptions.enabled` we render the empty section so SSR layout
 * stays predictable; the JS short-circuits and the `/api/chat/*`
 * endpoints return 503.
 */
/**
 * Render the home-page chat panel markup.
 *
 * Markup is intentionally minimal — the heavy lifting (EventSource
 * handling, message rendering, sessionId persistence) lives in
 * `public/chat-panel.js`. The HTML below carries `data-*` hooks that
 * the JS module targets; the contracts are pinned by
 * `test/home-chat-v25.test.ts`,
 * `test/chat-panel-session-forest-v251.test.ts` and
 * `test/task-chat-v25.test.ts`.
 *
 * @param opts.scope    "home" (default) | "task" — controls the
 *                      API endpoint the JS targets and the UI badge.
 * @param opts.taskId   Required when scope === "task". Used to label
 *                      the panel and bind `data-task-id`.
 */
export declare function renderChatPanel(opts?: {
    scope?: "home" | "task";
    taskId?: number;
}): string;
//# sourceMappingURL=chat-panel-html.d.ts.map