@praxisui/ai 8.0.0-beta.2 → 8.0.0-beta.21
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +47 -4
- package/fesm2022/praxisui-ai.mjs +1290 -83
- package/index.d.ts +475 -19
- package/package.json +7 -2
package/README.md
CHANGED
|
@@ -61,7 +61,7 @@ Peer dependencies (Angular v20):
|
|
|
61
61
|
## What this package is responsible for
|
|
62
62
|
|
|
63
63
|
- assistant UX surfaces and interaction flow
|
|
64
|
-
- reusable assistant shell primitives such as conversation messages, quick replies, prompt composer,
|
|
64
|
+
- reusable assistant shell primitives such as conversation messages, quick replies, prompt composer, governed actions, viewport-level drag/resize chrome, layout restore and minimized-session dock
|
|
65
65
|
- backend API orchestration for provider catalog, suggestions, and patch generation
|
|
66
66
|
- local lightweight session history with tenant/env/user scoping
|
|
67
67
|
- confirmation and risk policy integration for sensitive changes
|
|
@@ -72,13 +72,36 @@ Peer dependencies (Angular v20):
|
|
|
72
72
|
|
|
73
73
|
`PraxisAiAssistantShellComponent` is the canonical chrome for Praxis assistant experiences that need a conversational surface. Hosts should prefer it for new specialized flows instead of creating component-local assistant UI.
|
|
74
74
|
|
|
75
|
+
`PraxisAiAssistantComponent` remains exported only as a compatibility surface for older configuration-assistant integrations. New Praxis components, demos and cockpit flows should use `PraxisAiAssistantShellComponent` with `PraxisAssistantTurnOrchestratorService` and, when the assistant can be minimized or resumed, `PraxisAssistantSessionRegistryService`.
|
|
76
|
+
|
|
75
77
|
The shell owns the shared UX primitives:
|
|
76
78
|
- conversation messages and message actions such as edit/resend/custom actions
|
|
77
79
|
- prompt composer, Enter-to-submit behavior, pasted or selected file attachments, submit/apply actions and attach/remove attachment events
|
|
78
80
|
- active context chips for component, schema, selection, route, tenant or custom context
|
|
81
|
+
- rich quick reply chips with optional description, icon, tone and structured context hints
|
|
79
82
|
- attached context metadata for files, images, JSON, schema and text payloads
|
|
80
83
|
- mode and state labels for `config`, `agentic-authoring`, `chat`, `diagnostic`, `review` and `inline-help`
|
|
81
|
-
- draggable/resizable panel layout and accessibility labels
|
|
84
|
+
- viewport-level draggable/resizable panel layout, pointer-only resize handles, layout restore, minimize affordance and accessibility labels
|
|
85
|
+
|
|
86
|
+
The shell is a viewport-level assistant surface, not a component-bounded popover. A component trigger opens the assistant with local semantic context, but the panel can move across the page, resize from any edge or corner, and be restored to its initial safe layout through the shared "Restaurar posição do assistente" affordance. The default close affordance is "Minimizar assistente" because specialized hosts usually preserve the governed session through `PraxisAssistantSessionRegistryService`; hosts that truly close/discard the session may override the label.
|
|
87
|
+
|
|
88
|
+
The assistant chrome belongs to the platform, not to the component that opened it. Hosts should provide contextual labels, mode, state and context chips, while `PraxisAiAssistantShellComponent` keeps the shared visual hierarchy: assistant identity first, contextual title/subtitle second, and operational mode/state as compact metadata. Component-specific styling should not make the shell look owned by Page Builder, Table, Dynamic Form or any other individual runtime.
|
|
89
|
+
|
|
90
|
+
Composer actions are state-aware. The primary action changes from "Interpretar pedido" to clarification, review, applying, success or error labels according to the current turn state. Secondary recovery actions such as retry and cancel are surfaced by the shell when the active turn can be recovered, while hosts still own the flow-specific semantics.
|
|
91
|
+
|
|
92
|
+
Hosts can render the primary action as icon-only with `iconOnly=true` when that matches modern LLM chat composer conventions. The action must still provide a semantic `label` or `ariaLabel`; the shell uses it for accessibility and tooltip text while omitting the visible label.
|
|
93
|
+
|
|
94
|
+
Message-level actions can also be rendered as icon-only controls by setting `icon` or `iconOnly=true` on `PraxisAssistantShellMessageAction`. Built-in `edit`, `resend` and `copy` actions use `edit`, `replay` and `content_copy` icons by default, with the visible label moved to tooltip and `aria-label`.
|
|
95
|
+
|
|
96
|
+
`PraxisAiAssistantDockComponent` is the companion minimized-session surface for the same assistant identity. Hosts use it when a specialized assistant session remains active but the full shell is minimized. The dock owns the shared visual language for assistant presence, state badges and reopen affordance; hosts still provide the semantic session summary and decide what reopening means.
|
|
97
|
+
|
|
98
|
+
`PraxisAssistantSessionRegistryService` is the canonical in-memory registry for assistant sessions opened by different Praxis components in the same application shell. Component hosts register their active or minimized sessions with stable `ownerId`/`ownerType` metadata so a global assistant host can present one shared experience while preserving each component's semantic context. The registry accepts an optional `PraxisAssistantContextSnapshot`, normalizes it before storage and rejects snapshots whose `identity.sessionId`, `identity.ownerId` or `identity.ownerType` do not match the session descriptor. Components that already have a canonical context snapshot should prefer the context helpers: `upsertContextSession`, `openContextSession`, `minimizeContextSession`, `getContextSession` and `removeContextSession`.
|
|
99
|
+
|
|
100
|
+
`PraxisAiAssistantSessionHostComponent` is the canonical presence host for minimized assistant sessions in an application or page shell. It reads `PraxisAssistantSessionRegistryService`, renders the shared dock for each minimized session, and emits the opened session snapshot after promoting that session to active in the registry. Specialized components still own the full shell events until their authoring action contracts are promoted to shared platform contracts.
|
|
101
|
+
|
|
102
|
+
`PraxisAssistantContextSnapshot` is the canonical, UI-agnostic context contract for intelligent Praxis components. It represents safe assistant context: stable identity, current target, context chips, manifest reference, resource/schema hints, digests, governance hints, attachment summaries and declarative action contracts. It is intentionally not a raw component payload. Hosts should normalize snapshots with `normalizePraxisAssistantContextSnapshot` before storing them in a registry, passing them between components or using them as a handoff boundary.
|
|
103
|
+
|
|
104
|
+
Context snapshots must not contain full configs, form values, table rows, `currentState`, `runtimeState`, `pendingPatch`, arbitrary diagnostics, `File`, bytes, base64 or local `blob:` preview URLs. Use `dataProfileDigest`, `runtimeStateDigest`, `schemaFields` and `PraxisAssistantAttachmentSummary` instead. `@praxisui/ai` can declare handoff actions such as `shared-rule-handoff`, `governed-publication-handoff`, `materialization-handoff` and `enforcement-validation-handoff`, but the executable semantics of approving, publishing, materializing or enforcing domain rules belong to Praxis Config/domain-rules contracts.
|
|
82
105
|
|
|
83
106
|
The shell intentionally does not own component semantics. Specialized flows still own their adapter/service contract:
|
|
84
107
|
- configuration assistants continue to use `AiConfigAdapter`, capabilities, suggestions and patch review
|
|
@@ -93,7 +116,7 @@ By default, the prompt composer submits with `Enter` and keeps `Shift+Enter` for
|
|
|
93
116
|
|
|
94
117
|
When a user pastes an image into the prompt composer, the shell emits `attachmentsPasted` with `PraxisAssistantShellAttachment` items containing the original `File`, image metadata, `source: 'paste'` and a local preview URL.
|
|
95
118
|
|
|
96
|
-
Hosts can also enable button-based file selection with `enableFileAttachments`, `attachmentAccept` and `attachmentMultiple`. In that mode, the attach button opens the native file picker and emits `attachmentsSelected` with `source: 'file-picker'`. When file selection is disabled, the legacy `attach` event remains available for host-defined context actions. The shell does not upload or persist files; the host owns storage, redaction and backend forwarding.
|
|
119
|
+
Hosts can also enable button-based file selection with `enableFileAttachments`, `attachmentAccept` and `attachmentMultiple`. In that mode, the attach button opens the native file picker and emits `attachmentsSelected` with `source: 'file-picker'`. When file selection is disabled, the legacy `attach` event remains available for host-defined context actions. Hosts that do not support attachment semantics should set `showAttachAction=false`; hosts that do not support pasted image context should set `enablePastedAttachments=false`. The shell does not upload or persist files; the host owns storage, redaction and backend forwarding.
|
|
97
120
|
|
|
98
121
|
Flows that forward attachments to backend authoring endpoints should send only serializable attachment summaries, such as `id`, `name`, `kind`, `mimeType`, `sizeBytes`, `source` and `hasPreview`. Do not send `File`, bytes, base64 payloads or local `blob:` URLs to the assistant contract. When a backend clarification needs to keep attachment context for the next turn, the flow can return those summaries inside `pendingClarification.diagnostics.attachmentSummaries`; the turn orchestrator preserves that pending clarification state and sends it back with the next `clarify` action.
|
|
99
122
|
|
|
@@ -106,7 +129,7 @@ The orchestrator owns the turn lifecycle:
|
|
|
106
129
|
- stable `sessionId` creation per controller when the host does not provide one
|
|
107
130
|
- fresh `clientTurnId` creation for each executable submit/apply/retry/cancel turn
|
|
108
131
|
- LLM-assisted clarification as a first-class `clarification` state
|
|
109
|
-
- structured clarification questions and quick replies
|
|
132
|
+
- structured clarification questions and quick replies, including rich chip metadata from backend flows
|
|
110
133
|
- edit/resend actions for user messages, including conversation fork semantics
|
|
111
134
|
- attached context add/remove state
|
|
112
135
|
- apply/retry/cancel dispatch when the active flow supports it
|
|
@@ -118,6 +141,8 @@ When a flow asks for clarification, direct user input while the controller is in
|
|
|
118
141
|
|
|
119
142
|
`pendingClarification.diagnostics` is opaque flow state. It is preserved across the next clarification answer so backend-owned semantics can keep metadata-only context, including attachment summaries, without the shell understanding the domain or retaining local file payloads.
|
|
120
143
|
|
|
144
|
+
Backend-owned flows may return quick replies as clickable chips for candidate resources, catalog follow-ups or clarification options. Hosts should keep the full quick reply object: `description`, `icon` and `tone` are presentation hints, while `contextHints` carries structured values such as `resourcePath`, `submitUrl`, `operation` and `schemaUrl` for the next turn. Do not downcast these replies to label/prompt pairs or recompute the options in the UI.
|
|
145
|
+
|
|
121
146
|
When a user edits or resends an earlier user message, the controller forks the conversation from that message before invoking the flow again. Downstream assistant/user messages, quick replies, pending clarification and preview state are cleared so the backend receives the revised conversation branch instead of stale follow-up context. Hosts that expose an edit composer should call `submitEditedMessage(messageId, text)` when the revised prompt is submitted.
|
|
122
147
|
|
|
123
148
|
## What this package does not own
|
|
@@ -193,6 +218,24 @@ Notes:
|
|
|
193
218
|
- `currentState` must be the config root (not wrapped under `config`).
|
|
194
219
|
- Clarifications may return `{ type: "clarification", message, options }`.
|
|
195
220
|
|
|
221
|
+
### Agentic authoring manifest tools
|
|
222
|
+
- `GET /api/praxis/config/ai/authoring/manifests/{componentId}`
|
|
223
|
+
- `GET /api/praxis/config/ai/authoring/manifests/{componentId}/editable-targets`
|
|
224
|
+
- `GET /api/praxis/config/ai/authoring/manifests/{componentId}/operations`
|
|
225
|
+
- `POST /api/praxis/config/ai/authoring/manifests/{componentId}/resolve-target`
|
|
226
|
+
- `POST /api/praxis/config/ai/authoring/manifests/{componentId}/validate-plan`
|
|
227
|
+
- `POST /api/praxis/config/ai/authoring/manifests/{componentId}/compile-patch`
|
|
228
|
+
|
|
229
|
+
`AiBackendApiService` exposes these endpoints through typed methods so hosts can inspect the executable manifest, resolve targets, validate a component edit plan and compile a backend-owned patch without routing by local keywords.
|
|
230
|
+
|
|
231
|
+
### Agentic authoring turn streaming
|
|
232
|
+
- `POST /api/praxis/config/ai/authoring/turn/stream/start`
|
|
233
|
+
- `GET /api/praxis/config/ai/authoring/turn/stream/{streamId}`
|
|
234
|
+
- `GET /api/praxis/config/ai/authoring/turn/stream/{streamId}/probe`
|
|
235
|
+
- `POST /api/praxis/config/ai/authoring/turn/stream/{streamId}/cancel`
|
|
236
|
+
|
|
237
|
+
`AiBackendApiService.startAgenticAuthoringTurnStream`, `connectAgenticAuthoringTurnStream` and `cancelAgenticAuthoringTurnStream` use the same SSE envelope contract as patch streaming. Browser `EventSource` cannot send custom headers, so signed stream tokens returned by the backend should be passed to `connectAgenticAuthoringTurnStream` and `cancelAgenticAuthoringTurnStream` when the backend uses signed-url stream auth.
|
|
238
|
+
|
|
196
239
|
## Assistant local history (UI)
|
|
197
240
|
|
|
198
241
|
The assistant stores a lightweight local history in the browser using `localStorage`. It is scoped by
|