@flamingo-stack/openframe-frontend-core 0.0.578 → 0.0.579-1952.5335.1

package/src/components/chat/utils/message-segment-accumulator.ts

@@ -155,22 +155,6 @@ export class MessageSegmentAccumulator {
     return this.getSegments();
   }
 
-  /**
-   * Append guide text to the current message.
-   * If the last segment is guide, append to it; otherwise start a new guide segment.
-   */
-  appendGuide(text: string): MessageSegment[] {
-    const lastSegment = this.segments[this.segments.length - 1];
-
-    if (lastSegment && lastSegment.type === 'guide') {
-      this.segments[this.segments.length - 1] = { type: 'guide', text: lastSegment.text + text };
-    } else {
-      this.segments.push({ type: 'guide', text });
-    }
-
-    return this.getSegments();
-  }
-
   /**
    * Add a clarification (ask) card. Unlike the three delta streams an ask
    * arrives whole in one chunk, so it is always a NEW segment — never merged
@@ -325,15 +309,11 @@ export class MessageSegmentAccumulator {
     status: ChatApprovalStatus = 'pending',
     /** Structured label/value rows. The card prefers them over `explanation`
      *  (see `ApprovalRequestData.fields`). Optional because the agent's own
-     *  approvals carry prose; a Product Guide card is almost entirely fields —
-     *  dropping them here left it as a bare title. */
+     *  approvals carry prose. */
     fields?: ApprovalRequestField[],
-    /** Where the card came from; `'guide'` keeps it inline (see
-     *  `ApprovalRequestData.origin`). */
-    origin?: 'guide',
   ): MessageSegment[] {
     this.segments.push(
-      this.buildApprovalRequestSegment(requestId, { command, explanation, approvalType, fields, origin }, status),
+      this.buildApprovalRequestSegment(requestId, { command, explanation, approvalType, fields }, status),
     );
     return this.getSegments();
   }
@@ -344,7 +324,7 @@ export class MessageSegmentAccumulator {
    * Three paths produce these: `addApprovalRequest` (live stream and replay),
    * `flushPendingApprovals` (tracked-but-unresolved after a history replay) and
    * `processApprovalResult` (a result arriving for a tracked request). They used
-   * to hand-write the object each, which is how `fields` and `origin` reached
+   * to hand-write the object each, which is how `fields` reached
    * the card down one path and not the others — the same proposal rendering as a
    * bare title, or losing the marker that routes its buttons to the hub.
    */
@@ -361,7 +341,6 @@ export class MessageSegmentAccumulator {
         requestId,
         approvalType: approval.approvalType,
         ...(approval.fields && approval.fields.length > 0 ? { fields: approval.fields } : {}),
-        ...(approval.origin ? { origin: approval.origin } : {}),
       },
       status,
       onApprove: this.callbacks.onApprove,
@@ -389,9 +368,6 @@ export class MessageSegmentAccumulator {
     status: ChatApprovalStatus = 'pending',
     executions?: Record<string, ApprovalBatchExecutionState>,
     resolvedByName?: string | null,
-    /** Where the batch came from; `'guide'` keeps it inline and routes it to
-     *  the hub, exactly as for a single card (see `ApprovalBatchData.origin`). */
-    origin?: 'guide',
   ): MessageSegment[] {
     const existingIndex = this.segments.findIndex(
       (s): s is ApprovalBatchSegment => s.type === 'approval_batch' && s.data.approvalRequestId === approvalRequestId,
@@ -400,9 +376,6 @@ export class MessageSegmentAccumulator {
     if (existingIndex !== -1) {
       const existing = this.segments[existingIndex] as ApprovalBatchSegment;
       const mergedExecutions = executions ?? existing.data.executions;
-      // An upsert must not strip the marker: the flip to `approved` comes from
-      // a later event that carries no origin of its own.
-      const mergedOrigin = origin ?? existing.data.origin;
       this.segments[existingIndex] = {
         ...existing,
         data: {
@@ -410,7 +383,6 @@ export class MessageSegmentAccumulator {
           approvalType,
           toolCalls,
           ...(mergedExecutions ? { executions: mergedExecutions } : {}),
-          ...(mergedOrigin ? { origin: mergedOrigin } : {}),
         },
         status,
         resolvedByName: resolvedByName ?? existing.resolvedByName,
@@ -427,7 +399,6 @@ export class MessageSegmentAccumulator {
         approvalType,
         toolCalls,
         ...(executions ? { executions } : {}),
-        ...(origin ? { origin } : {}),
       },
       status,
       resolvedByName,
@@ -685,9 +656,6 @@ export class MessageSegmentAccumulator {
         case 'thinking':
           if (segment.text) this.appendThinking(segment.text);
           break;
-        case 'guide':
-          if (segment.text) this.appendGuide(segment.text);
-          break;
         case 'ask':
           this.addAsk(segment.question, segment.options);
           break;
@@ -703,7 +671,6 @@ export class MessageSegmentAccumulator {
             data.approvalType || '',
             status,
             data.fields,
-            data.origin,
           );
           break;
         }
@@ -716,7 +683,6 @@ export class MessageSegmentAccumulator {
             status,
             data.executions,
             resolvedByName,
-            data.origin,
           );
           break;
         }

package/src/components/chat/utils/process-historical-messages.ts

@@ -33,7 +33,7 @@ import {
 } from '../../../chat-protocol/events';
 // One normalizer for ask rows, shared with the live decoder — history and the
 // stream must agree on which options are usable.
-import { guideFrameEvent, normalizeAskOptions } from '../../../chat-protocol/nats-decoder';
+import { normalizeAskOptions } from '../../../chat-protocol/nats-decoder';
 import { applyApprovalStatusToSegment } from '../stream/message-mutations';
 import {
   MESSAGE_TYPE,
@@ -47,7 +47,7 @@ import {
   type MessageData,
   type MessageOwner,
 } from '../types';
-import { approvalDisplaysInline, guideApprovalOrigin } from './approval-display';
+import { approvalDisplaysInline } from './approval-display';
 import { type MessageSegmentAccumulator, createMessageSegmentAccumulator } from './message-segment-accumulator';
 import { getCommandText } from './tool-call-helpers';
 
@@ -121,22 +121,6 @@ export function decodeHistoricalMessageData(data: MessageData): ChatStreamEvent
       }
       return null;
 
-    // Two persisted shapes, mirroring the live `GUIDE` chunk: the answer body
-    // (`text`) and a Product Guide frame the agent re-streamed (`payload`,
-    // persisted so a card survives a reload). Decoded through the SAME
-    // `guideFrameEvent` the live path uses — a second mapping here would let
-    // history and realtime disagree about the same bytes.
-    case MESSAGE_TYPE.GUIDE: {
-      if ('text' in data && data.text) {
-        return { type: 'guide-delta', text: data.text };
-      }
-      const payload = 'payload' in data ? data.payload : undefined;
-      if (payload && typeof payload === 'object' && !Array.isArray(payload)) {
-        return guideFrameEvent(payload);
-      }
-      return null;
-    }
-
     // Same completeness gate as the live decoder (`decodeNatsChunk`): a
     // persisted row without a question or without options is not a card the
     // user can answer, so it replays as nothing rather than as empty chrome.
@@ -397,10 +381,6 @@ function applyHistoryEvent(
       accumulator.appendThinking(event.text);
       break;
 
-    case 'guide-delta':
-      accumulator.appendGuide(event.text);
-      break;
-
     // Mirror of the live path: the intro sentence replays as answer text in
     // front of the card, so a reloaded thread reads exactly like the stream did.
     case 'ask':
@@ -417,23 +397,13 @@ function applyHistoryEvent(
       const toolCalls = event.toolCalls;
       const isBatch = !!toolCalls && toolCalls.length > 0;
       // Same rule the live kernels use — a card must not change where it
-      // renders (or which backend its buttons hit) just because the page was
-      // reloaded and it came back through history instead of the stream.
-      const guideOrigin = guideApprovalOrigin(event);
-
-      if (approvalDisplaysInline(event, approvalType, displayApprovalTypes)) {
+      // renders just because the page was reloaded and it came back through
+      // history instead of the stream.
+      if (approvalDisplaysInline(approvalType, displayApprovalTypes)) {
         if (isBatch) {
           const status = (approvalStatuses[event.requestId] as ChatApprovalStatus) || 'pending';
           if (batchApprovalsEnabled) {
-            accumulator.addApprovalBatch(
-              event.requestId,
-              approvalType,
-              toolCalls,
-              status,
-              undefined,
-              undefined,
-              guideOrigin,
-            );
+            accumulator.addApprovalBatch(event.requestId, approvalType, toolCalls, status, undefined, undefined);
           } else {
             // Flag OFF — unfold batch into N legacy approval cards (same id).
             for (const call of toolCalls) {
@@ -445,7 +415,6 @@ function applyHistoryEvent(
                 approvalType,
                 status,
                 undefined,
-                guideOrigin,
               );
             }
           }
@@ -459,12 +428,7 @@ function applyHistoryEvent(
           // and honor `approvalStatuses`.
           const resolvedStatus = approvalStatuses[event.requestId] as ChatApprovalStatus | undefined;
           const isResolved = resolvedStatus === 'approved' || resolvedStatus === 'rejected';
-          // A guide card is added inline even while pending. The tracked path
-          // below ends in `flushPendingApprovals`, whose segments the consumer
-          // lifts into a sticky footer — that is the treatment for the
-          // consumer's OWN approvals, and it is not how the hub's chat renders
-          // a proposal (nor where its preamble expects it).
-          if (guideOrigin || isResolved) {
+          if (isResolved) {
             accumulator.addApprovalRequest(
               event.requestId,
               event.command || '',
@@ -472,7 +436,6 @@ function applyHistoryEvent(
               approvalType,
               resolvedStatus ?? 'pending',
               event.fields,
-              guideOrigin,
             );
           } else {
             accumulator.trackApprovalRequest(event.requestId, {

package/src/components/chat/utils/resolve-fetched-card-href.ts

@@ -11,7 +11,7 @@
  *     (`title` / `url` / `targetPlatform` / `sourceRepo`). `resolveSourceRowCTA`
  *     then routes that `externalUrl` through the host's `composeContentUrl`
  *     seam and the card is clickable.
- *   - **Mingo / NATS transport** (`messageData: [{ type: 'GUIDE' | 'TEXT', text }]`)
+ *   - **Mingo / NATS transport** (`messageData: [{ type: 'TEXT', text }]`)
  *     — the body carries bare `[card://type:id]` markers and NOTHING else.
  *     `chat-message-enhanced.tsx` synthesizes a minimal `{ type, id, title: id,
  *     url: null }` ref so fetch-mode cards can still self-fetch their row, but

package/src/stories/ChatMessageEnhanced.stories.tsx

@@ -210,18 +210,18 @@ export const GuideWithEntityCards: Story = {
       ) : null,
     content: [
       {
-        type: 'guide',
+        type: 'text',
         text: "Here's how to create a monitoring policy (check) in OpenFrame:\n\n[card://onboarding_guide:first-check]\n\nStep-by-step:\n\n1. Go to Monitoring → Policies → Add Policy\n2. Write your osquery SQL query\n3. Save the policy",
       },
       {
         type: 'text',
-        text: 'A plain text segment renders its own marker identically:\n\n[card://onboarding_guide:add-devices]',
+        text: 'A second text segment renders its own marker identically:\n\n[card://onboarding_guide:add-devices]',
       },
     ] satisfies MessageSegment[],
   },
 };
 
-/** Every remaining segment type in one message — thinking, guide, tool execution, context compaction, error. */
+/** Every remaining segment type in one message — thinking, tool execution, context compaction, error. */
 export const AllSegmentTypes: Story = {
   args: {
     role: 'assistant',
@@ -233,10 +233,6 @@ export const AllSegmentTypes: Story = {
         text: 'The user wants Slack installed. Homebrew is present on the endpoint, so `brew install --cask slack` is the cleanest path.',
       },
       { type: 'text', text: 'Installing Slack now.' },
-      {
-        type: 'guide',
-        text: "Here's how to create a monitoring policy (check) in OpenFrame:\n\nStep-by-step:\n\n1. Go to Monitoring → Policies → Add Policy\n2. Give it a Name (something descriptive)\n3. Write your osquery SQL query — the query should return rows for devices that fail the check\n4. Set the interval — how often each device runs the check\n5. Save the policy",
-      },
       {
         type: 'tool_execution',
         data: {