@salsita-ai/sdk 0.50.0-develop.db8514eccf → 0.50.0-develop.dede205ab0

package/dist/phoenix/application-spec/generate-assistant-prompt.d.ts

@@ -1,13 +0,0 @@
-import type { AssistantSpec } from '#package/application-spec';
-/**
- * The part of the assistant's system prompt that explains how to read the generated GraphQL schema.
- * It is generated here, by the SDK that also runs in the browser, and stored with the deployment,
- * because the conventions it describes belong to this SDK version and not to the server. The part
- * about changes is left out when the schema has no `Mutation` type, the part about adding
- * entities when it has no `addChild` mutation, the part about replacing them when it has no
- * `replaceEntity` mutation, the part about the choices of a field when it has
- * no options edge, and the part about custom changes when the manifest exposes no action. The last two sections explain the
- * `query` and `apply` tools, which every run registers whatever the schema holds, and the change
- * record the `AssistantSystem` attaches to every user message.
- */
-export declare const generateAssistantPrompt: (assistant: NonNullable<AssistantSpec>) => string;

package/dist/phoenix/application-spec/generate-assistant-prompt.js

@@ -1 +0,0 @@
-let e=["How to read the GraphQL schema of this configurator:","- A configuration is a set of entities. `root` is the root entity, `entities` lists every entity or the ones with the given ids, and `selectedEntity` is the entity the user has selected, or the root entity when nothing is selected.","- Every entity has an `id` of the form `<Type>-<number>`, for example `Table-1`, and a `type` with its entity type name. Ids are assigned by the configurator: read them from the configuration and never make one up.","- A field whose name starts with `_` is computed by the configurator from other values. It can be read like any other field and never written.","- Numbers are in the units the configuration stores them in. A field description names the unit when the product defines one.",'- A text field that only takes fixed values lists them in its description as "One of: ...". Use exactly those values.',"- A field typed as another entity type or as a list of one is a relation: select fields on it to read the related entities.","- Field and type descriptions come from the team that built the configurator and say what a value means for the product."],t=["How changes work:","- Every field of the `Mutation` type is one change. Its description says what it changes and what it returns.","- The configurator checks the whole configuration after each change. A change that would leave it invalid fails with an error that names the entities at fault, and it is not applied. Later changes of the same request are then not run.","- The configurator may adjust other values in response to a change, so read what a mutation returns instead of assuming the values you sent."],a=["How to add entities:","- Entities are added from recipes, the same ones the configurator offers the user. An entity type that can take children has a `meta` field; `meta { childRecipes }` lists its recipe groups and their recipes.","- List the recipes of the group first, pick one by its `key`, then call `addChild` with the id of the parent, the `groupId` and the `key`. Keys change with the configuration and the language, so never reuse one from memory.","- `dryRun` on a recipe shows what adding it would do without adding it: whether it is `ok`, the `changedEntities` it would add or modify, the `deletedEntityIds` it would remove, the `sideEffects` the configurator says it would have, and the `errors` when it cannot be added. An entity whose id the configuration does not have yet is new. It is costly, so select it only on the recipes you are deciding between.","- Put each `addChild` in its own operation. The recipes of a group and what they add depend on the configuration before them, so after adding something, list the group again before adding from it once more."],n=["How to replace entities:","- An entity is replaced from recipes, the same ones the configurator offers the user. An entity type that can be replaced has a `meta` field; `meta { replaceRecipes }` lists its replace recipe groups and what the entity can be replaced with.","- List the recipes of the group first, pick one by its `key`, then call `replaceEntity` with the id of the entity, the `groupId` and the `key`. `dryRun` on a replace recipe shows what replacing would do without doing it: the replacement and everything else that changes are under `changedEntities`, and the replaced entity is among the `deletedEntityIds`.","- The replacement is a new entity with a new id, and its field values come from the recipe, so they can differ from those of the entity it replaces. Read the ids and values `replaceEntity` returns, and never use the old id again.","- Put each `replaceEntity` in its own operation. The recipes of a group and what they do depend on the configuration before them, so after replacing something, list the group of the replacement again before replacing once more."],o=["How to find the values a field can take:","- Some fields store a key whose choices the configurator holds elsewhere. Such a field has an edge under `meta` named after it: `meta { <field>Options }` lists its choices, each with the `value` to write and the `name` the user sees.","- Read the choices before you write such a field or name a choice to the user, and write the `value`, not the `name`. A value outside the list is rejected unless the edge description says the field is not checked.","- `dryRun` on an option shows what writing its value would do without writing it: whether it is `ok`, the `changedEntities` it would add or modify, the `deletedEntityIds` it would remove, the `sideEffects` the configurator says it would have, and the `errors` when the value cannot be written. It is costly, so select it only on the options you are deciding between. It is null when the edge description says the options cannot be dry-run.","- The choices can depend on the entity and on its current state. Read them again after a change, unless the edge description says they are the same for all instances or do not change."],i=["How the custom changes of this configurator work:","- Besides the generic changes, the `Mutation` type has fields the team built for this product. Each runs one domain operation the configurator itself uses, so prefer it over composing the same change from generic mutations. Its description says what it does and what its arguments mean.","- Its arguments are checked against what the operation declares; an argument that does not fit, or a change the product does not allow, fails the field with a message that says what to send instead.","- It returns an object whose fields the description names; a field typed as an entity reads that entity after the change."],s=["How to use the `query` and `apply` tools:","- Both take `operations`, a list of GraphQL documents that run in order. Each document holds exactly one operation. To do several things, send several items in one call instead of several calls.","- Write values into the document as literals. Use `variables` only for a value that cannot be written as a literal.","- Select only the fields you need: results are returned whole.","- The result has one GraphQL result per operation, in the order sent. When an operation fails, its `errors` say why and the operations after it are not run.","- `query` reads the configuration the user has open and never changes it. Call it before you say anything about the configuration."],h=["- This configurator exposes no changes, so there is nothing for `apply` to run. Say so when the user asks you to change the configuration."],r=['- Mutations inside `query` answer "what if" questions. Each operation sees the changes of the ones before it, so a mutation followed by a query shows the configuration as it would be. Nothing is kept and the user sees no change.',"- `apply` makes the changes the user asked for. It is all or nothing: when any operation fails, nothing is changed; when all succeed, the user gets them as one undo step.","- `committed` in the result says whether the changes were kept. When it is false although no operation failed, `message` says why: the changes may be waiting for the approval of the user, the user may have changed the configuration meanwhile, or this session may not change the configuration at all. Without a `message`, the operations changed nothing. Never tell the user a change was made unless `committed` is true.","- `sideEffects` in the result lists what the configurator did beyond what the operations asked for, such as parts it added or replaced to keep the configuration valid, in its own words. Tell the user about them when the changes were kept. When they were not, or in `query`, it lists what the mutations that succeeded would do. `dryRun` has the same list for a single recipe or option."],d=["How to read the change record:","- Every user message starts with a change record of the configuration since your previous action. It is the complete list of the entities that were added or deleted, of the stored fields of this schema that changed, and of the selection and navigation changes, so update your picture from it and do not query those again when it does not mention them.","- Fields whose name starts with `_` are computed and are never listed. Read them again when the record lists a change they may depend on.","- `[changes: none]`: nothing changed. Do not query again what you already know.","- `[changes]` is followed by one line per change. `selected`, `navigationState`, `viewState` and `toolState` lines show `<old> -> <new>` of what `selectedEntity` and `navigation` return, with `none` for an empty value. `A <id>` is an added entity and `D <id>` a deleted one. `M <id>` is a modified entity, followed by one `<field>: <old> -> <new>` line per changed field, under the name the field has in this schema. A `reset: undo/redo` line says the user undid or redid changes.","- The `#` comment at the end of a line names the control, the transformer or the explanation of the last change to that line.","- `[changes: unavailable]`: the page was loaded since your previous action, so earlier values may be stale. `[changes: too many (n)]`: n entities changed and are not listed. In both cases query what you need."],c=["- Changes you applied are not in the record, except those that were waiting for the approval of the user: they appear in it once approved."];export const generateAssistantPrompt=l=>{let u=/^type Mutation\b/m.test(l.sdl);return[e,...u?[t]:[],.../^\s+addChild\(/m.test(l.sdl)?[a]:[],.../^\s+replaceEntity\(/m.test(l.sdl)?[n]:[],.../^type FieldOption\b/m.test(l.sdl)?[o]:[],...Object.keys(l.actions).length>0?[i]:[],[...s,...u?r:h],[...d,...u?c:[]]].map(e=>e.join("\n")).join("\n\n")};