@flamingo-stack/openframe-frontend-core 0.0.532-snapshot.20260811155109 → 0.0.532

package/dist/chat-protocol/confirm-tool.d.ts

@@ -1,50 +0,0 @@
-/**
- * The hub's confirm-tool contract — request shape and error envelope.
- *
- * Resolving a Product Guide proposal is a POST to `endpoints.approvalToolUrl`
- * whose response is an ordinary guide stream (a `decision_resolved` frame, then
- * the hub's auto-continuation). Two callers make that call today: the SSE chat
- * adapter, and any host replaying the same route into a different transport's
- * conversation (the product app resolves guide cards inside a NATS Mingo
- * dialog). They MUST send byte-identical bodies — a proposal is single-use, so a
- * caller that drifts on a field name does not degrade, it fails the write — and
- * they must surface the same server copy, because the hub's errors are written
- * for the end user ("This approval expired — ask again to get a fresh one").
- *
- * Hence both live here rather than at either call site.
- *
- * Server-safe: no React, no browser APIs.
- */
-/** What the user did with the card. */
-export type ApprovalToolAction = 'approve' | 'reject';
-/** Client-side shape of a confirm; `buildConfirmToolBody` renames it to the
- *  wire's own casing so no caller hand-writes `proposal_id`. */
-export interface ConfirmToolRequest {
-    /** The hub-minted proposal id carried by the card. */
-    proposalId: string;
-    action: ApprovalToolAction;
-    /**
-     * The hub's conversation id, quoted back verbatim. The hub rejects a confirm
-     * without it: a proposal only means something inside the conversation that
-     * minted it.
-     */
-    conversationId: string | null | undefined;
-}
-/** Build the confirm-tool request body. The ONE place that knows the wire
- *  spells the id `proposal_id` while everything else is camelCase. */
-export declare function buildConfirmToolBody(request: ConfirmToolRequest): Record<string, unknown>;
-/**
- * Pull the user-facing copy out of a failed chat/confirm response.
- *
- * The route-base envelope is `{error, code}`; `error` is written for the end
- * user, so it beats any status-code copy the client could invent. Returns null
- * when the body is not that envelope (HTML error page, empty body, gateway
- * response) — the caller then supplies its own generic line.
- *
- * Consumes the body: call it once, on a response you have already decided is a
- * failure.
- */
-export declare function readServerErrorMessage(response: {
-    json: () => Promise<unknown>;
-}): Promise<string | null>;
-//# sourceMappingURL=confirm-tool.d.ts.map

package/dist/chat-protocol/confirm-tool.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"confirm-tool.d.ts","sourceRoot":"","sources":["../../src/chat-protocol/confirm-tool.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,uCAAuC;AACvC,MAAM,MAAM,kBAAkB,GAAG,SAAS,GAAG,QAAQ,CAAA;AAErD;gEACgE;AAChE,MAAM,WAAW,kBAAkB;IACjC,sDAAsD;IACtD,UAAU,EAAE,MAAM,CAAA;IAClB,MAAM,EAAE,kBAAkB,CAAA;IAC1B;;;;OAIG;IACH,cAAc,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,CAAA;CAC1C;AAED;sEACsE;AACtE,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,kBAAkB,GAAG,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAMzF;AAED;;;;;;;;;;GAUG;AACH,wBAAsB,sBAAsB,CAAC,QAAQ,EAAE;IACrD,IAAI,EAAE,MAAM,OAAO,CAAC,OAAO,CAAC,CAAA;CAC7B,GAAG,OAAO,CAAC,MAAM,GAAG,IAAI,CAAC,CAQzB"}

package/dist/chat-protocol/leading-frames.d.ts

@@ -1,38 +0,0 @@
-/**
- * Leading-frame → `ChatStreamEvent` table — the ONE mapping both transports read.
- *
- * The SSE decoder (`./decode.ts`) reaches it while walking the hub's byte
- * framing. The NATS decoder (`./nats-decoder.ts`) reaches it for `GUIDE` chunks
- * carrying a `payload`: the saas-ai-agent re-streams the Product Guide's hub
- * frames VERBATIM into the Mingo chunk stream (`GuideStreamingService`), so the
- * bytes a guide answer is made of are the same frames on both transports — only
- * the envelope differs. Decoding them twice would drift the moment the hub adds
- * a frame kind, which is why this table lives outside either decoder.
- *
- * The NATS side does NOT take every event this table can produce; see
- * `guideFrameEvent` in `./nats-decoder.ts` for which ones cross over and why.
- *
- * Server-safe: no React, no browser APIs.
- */
-import type { ChatStreamEvent } from './events';
-/**
- * Escape `<` so markdown renderers that pass HTML through (rehypeRaw)
- * don't treat XML-like tokens in Claude's thinking output as elements.
- * `<` → `&lt;` preserves the visible character without breaking
- * blockquote `>` markers. Per-character, so it distributes over
- * concatenation: escape(a + b) === escape(a) + escape(b) — callers may
- * apply it per-delta or on the accumulated string interchangeably.
- */
-export declare function escapeThinkingTags(text: string): string;
-/**
- * Map one parsed leading frame to normalized events, replicating the
- * legacy parser's else-if chain ORDER and its exact truthiness/typeof
- * gates. Frames that matched a branch but failed its inner validation
- * (e.g. `routing` without a string `routedComplexity`) produce NO event,
- * exactly like the legacy no-op.
- *
- * Every branch pushes AT MOST ONE event — `guideFrameEvent` relies on that
- * to hand a single event back to `decodeNatsChunk`'s per-chunk contract.
- */
-export declare function mapLeadingFrame(meta: any, out: ChatStreamEvent[]): void;
-//# sourceMappingURL=leading-frames.d.ts.map

package/dist/chat-protocol/leading-frames.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"leading-frames.d.ts","sourceRoot":"","sources":["../../src/chat-protocol/leading-frames.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,UAAU,CAAA;AAE/C;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAEvD;AAED;;;;;;;;;GASG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,GAAG,EAAE,GAAG,EAAE,eAAe,EAAE,GAAG,IAAI,CAqIvE"}