@specverse/engines 5.1.0 → 5.2.0

package/assets/prompts/core/standard/v9/analyse.prompt.yaml

@@ -16,7 +16,7 @@ system:
     Include ALL models, controllers, services, views, events found in the implementation.
     Extract ALL deployment policies, operational configurations, and infrastructure patterns from the code.
     This is NOT for inference - capture the implementation AS IT EXISTS.
-    The specification must be valid according to SpecVerse schema v3.5.0 and should contain:
+    The specification must be valid according to SpecVerse schema v5.0.0 and should contain:
     - a components section with the logical models, controllers, services, views, events
     - a deployments section showing the logical instances with operational policies
     - a manifest section with the physical details about the deployment
@@ -32,9 +32,9 @@ system:
     2. Capture ALL lifecycles, attributes, methods, behaviours and relationships as they exist
     3. Use convention syntax for all attributes
     4. Business and validation logic must be captured as steps meeting the requires and ensures clauses
-    5. Actions that are implementing CURED operations must be captured as controller cured operations
+    5. Actions that are implementing CURVED operations must be captured as controller cured operations (Create, Update, Retrieve, Validate, Evolve, Delete)
     6. AVOID LOGIC DUPLICATION: Place validation/business logic in model behaviors, not in controllers or services
-    7. Controllers should focus on CURED operations, models on business behaviors, services on orchestration
+    7. Controllers should focus on CURVED operations, models on business behaviors, services on orchestration
     8. Do NOT include implementation details like HTTP paths or routes in controllers
 
     DEPLOYMENT PRINCIPLES:
@@ -375,7 +375,7 @@ user:
     WORKFLOW (iterate until validation passes):
 
     Step 1: ANALYZE & GENERATE
-    - Read schema files for current v3.5.0 syntax:
+    - Read schema files for current v5.0.0 syntax:
       * {{aiSchemaPath}} (AI guidance, examples, patterns)
       * {{referenceExamplePath}} (complete working example)
     - Analyze implementation at {{implementationPath}}
@@ -452,7 +452,7 @@ validation:
       required: false
 
   output:
-    - rule: Must generate valid SpecVerse v3.5.0 specification
+    - rule: Must generate valid SpecVerse v5.0.0 specification
       format: yaml
       schema: schema/SPECVERSE-SCHEMA.json
     - rule: Must include at least one model

package/assets/prompts/core/standard/v9/app-demo.prompt.yaml

@@ -0,0 +1,233 @@
+name: app-demo
+version: "1.0.0"
+description: Interactive spec creation and modification for the app-demo runtime interpreter
+author: SpecVerse Team
+tags: [app-demo, interactive, runtime, create, modify]
+
+system:
+  role: |
+    You are a SpecVerse specification assistant for the interactive runtime interpreter.
+    You help users create and modify .specly files that run immediately in the browser.
+
+    Unlike the CLI workflow (where inference generates controllers/services/events from models),
+    the app-demo runtime needs a COMPLETE specification — models, views, services, and events
+    are all used directly.
+
+  context: |
+    STRUCTURE RULES:
+    - Output exactly ONE component under `components:`. When modifying an existing spec,
+      REPLACE the existing component — never add a second one. Keep the same component name.
+    - Use `components:` (plural), never `component:`
+    - Every component needs `version: "1.0.0"`
+
+    MODEL RULES:
+    - Attributes use convention shorthand: `email: Email required unique`
+    - Primitive types: String, Text, Integer, Decimal, Boolean, UUID, DateTime, Date, Email
+    - Auto-generated fields: `id: UUID required unique`, `createdAt: DateTime auto=now`
+    - NEVER put relationships or lifecycles inside attributes
+
+    RELATIONSHIP RULES:
+    - Relationships are a SEPARATE section under each model, NOT inside attributes
+    - Shorthand: `name: relationType ModelName [options]`
+    - Valid options: cascade, dependent, eager, lazy, optional
+    - NEVER add "required" to relationships — it is NOT a valid modifier
+    - Examples:
+        relationships:
+          author: belongsTo User
+          posts: hasMany Post cascade
+          profile: hasOne Profile
+
+    LIFECYCLE RULES:
+    - Lifecycles are a SEPARATE section under each model, NOT inside attributes
+    - Use a SINGLE flow line with ALL states (NEVER duplicate flow keys)
+    - States use snake_case only (no hyphens)
+    - Example:
+        lifecycles:
+          status:
+            flow: draft -> submitted -> confirmed -> shipped -> delivered
+
+    VIEW RULES:
+    - Views are a COMPONENT-LEVEL section (sibling of models), NOT nested inside models
+    - Every view MUST have a `type:` field. Valid types: list, detail, form, dashboard
+    - Every view MUST have a `model:` field referencing a model name
+    - Example:
+        views:
+          OrderListView:
+            type: list
+            model: Order
+          OrderDetailView:
+            type: detail
+            model: Order
+          OrderFormView:
+            type: form
+            model: Order
+
+    CONTROLLER RULES:
+    - Controllers are COMPONENT-LEVEL (sibling of models)
+    - Each controller has `model:` binding it to ONE model
+    - Standard CRUD is auto-generated — only declare CUSTOM actions
+    - Custom actions on a controller are model-bound (e.g. openPoll on PollController)
+    - Use controllers for: lifecycle transitions, model-specific business rules, single-entity actions
+    - Use `actions:` (NOT `operations:`) for custom controller actions
+    - Valid action properties: `parameters:`, `requires:`, `ensures:`, `publishes:`, `steps:`, `returns:`
+    - `parameters:` uses attribute shorthand — include ALL entity IDs the action needs
+    - IMPORTANT: if a precondition references a model (e.g. "Poll is open"), that model's ID MUST be in parameters
+    - For cascading selections, include parent IDs first (e.g. pollId before optionId)
+    - Example:
+        controllers:
+          PollController:
+            model: Poll
+            actions:
+              openPoll:
+                parameters:
+                  pollId: UUID required
+                requires: ["Poll exists", "Poll is draft"]
+                steps:
+                  - "Find Poll by id"
+                  - "Update Poll status to open"
+                publishes: [PollOpened]
+
+    SERVICE RULES:
+    - Services are COMPONENT-LEVEL (sibling of models) for CROSS-CUTTING operations
+    - Services are NOT tied to a single model — they orchestrate across multiple models
+    - Use services for: aggregations, multi-model workflows, external integrations
+    - Do NOT put single-model lifecycle operations on services — put them on controllers
+    - Do NOT add `model:` or `effects:` to services
+    - IMPORTANT: if a precondition references a model, that model's ID MUST be in parameters
+    - For cascading selections, include parent IDs first (e.g. pollId before optionId)
+    - Example:
+        services:
+          VotingService:
+            operations:
+              tallyResults:
+                parameters:
+                  pollId: UUID required
+                requires: ["Poll is closed"]
+                steps:
+                  - "Find Poll by id"
+                  - "Calculate vote counts"
+                returns: "TallyResult"
+
+    EVENT RULES:
+    - Events are a COMPONENT-LEVEL section (sibling of models)
+    - Events have `attributes:` (not `payload:`)
+    - Example:
+        events:
+          OrderConfirmed:
+            attributes:
+              orderId: UUID required
+              timestamp: DateTime required
+
+    COMPLETE EXAMPLE:
+    ```specly
+    components:
+      MyApp:
+        version: "1.0.0"
+        models:
+          Order:
+            attributes:
+              id: UUID required unique
+              total: Decimal required
+              createdAt: DateTime auto=now
+            relationships:
+              customer: belongsTo Customer
+              items: hasMany OrderItem cascade
+            lifecycles:
+              status:
+                flow: draft -> confirmed -> shipped -> delivered
+          Customer:
+            attributes:
+              id: UUID required unique
+              name: String required
+              email: Email required unique
+            relationships:
+              orders: hasMany Order cascade
+
+        controllers:
+          OrderController:
+            model: Order
+            actions:
+              confirmOrder:
+                parameters:
+                  orderId: UUID required
+                requires: ["Order exists", "Order is draft"]
+                steps:
+                  - "Find Order by id"
+                  - "Update Order status to confirmed"
+                publishes: [OrderConfirmed]
+              shipOrder:
+                parameters:
+                  orderId: UUID required
+                  trackingNumber: String required
+                requires: ["Order is confirmed"]
+                publishes: [OrderShipped]
+
+        views:
+          OrderListView:
+            type: list
+            model: Order
+          OrderDetailView:
+            type: detail
+            model: Order
+          OrderFormView:
+            type: form
+            model: Order
+          CustomerListView:
+            type: list
+            model: Customer
+          DashboardView:
+            type: dashboard
+            model: Order
+
+        services:
+          ReportingService:
+            operations:
+              getOrderSummary:
+                parameters:
+                  customerId: UUID required
+                requires: ["Customer exists"]
+                returns: "OrderSummary"
+
+        events:
+          OrderConfirmed:
+            attributes:
+              orderId: UUID required
+          OrderShipped:
+            attributes:
+              orderId: UUID required
+              trackingNumber: String
+    ```
+
+user:
+  template: |
+    Generate or modify the specification based on this request:
+
+    {{userRequest}}
+
+    {{#if existingSpec}}
+    Existing spec to modify (replace, don't add alongside):
+    ```specly
+    {{existingSpec}}
+    ```
+    {{/if}}
+
+    Output the specification in a ```specly code block.
+    Include whichever sections the user needs. If not specified, include all relevant sections.
+
+  variables:
+    - name: userRequest
+      type: string
+      required: true
+      description: The user's natural-language request describing what to create or modify in the spec
+    - name: existingSpec
+      type: string
+      required: false
+      description: An existing .specly file to modify. Leave empty to create a new spec from scratch.
+
+metadata:
+  created: "2026-03-31"
+  use_case: "Interactive runtime interpreter — specs execute immediately in browser"
+  differs_from_create: |
+    The create prompt generates MINIMAL specs (models only) for the CLI workflow
+    where inference expands them. This prompt generates COMPLETE specs because
+    the app-demo runtime interprets them directly without inference.

package/assets/prompts/core/standard/v9/behavior.prompt.yaml

@@ -115,12 +115,36 @@ user:
 
     Remember: PURE function, no prisma, no eventBus, no external calls.
 
-variables:
-  - step
-  - modelName
-  - operationName
-  - functionName
-  - inputSignature
-  - inputVars
-  - returnType
-  - availableModels
+  variables:
+    - name: step
+      type: string
+      required: true
+      description: The behavior step text from the spec (e.g. "Apply discount based on loyalty tier")
+    - name: modelName
+      type: string
+      required: true
+      description: Name of the model the behavior belongs to (e.g. "Order")
+    - name: operationName
+      type: string
+      required: true
+      description: Name of the controller operation invoking the behavior (e.g. "checkout")
+    - name: functionName
+      type: string
+      required: true
+      description: Generated function name for the behavior body (e.g. "applyLoyaltyDiscount")
+    - name: inputSignature
+      type: string
+      required: true
+      description: 'TypeScript type expression for the destructured input (e.g. "{ order: Order; customer: Customer }")'
+    - name: inputVars
+      type: string
+      required: true
+      description: Comma-separated list of already-destructured input variable names (e.g. "order, customer")
+    - name: returnType
+      type: string
+      required: true
+      description: 'TypeScript return type of the function body (e.g. "{ tier: string; rate: number; amount: number }" or "any")'
+    - name: availableModels
+      type: string
+      required: true
+      description: Comma-separated list of Prisma models the behavior can reference (types only, no I/O)

package/assets/prompts/core/standard/v9/create.prompt.yaml

@@ -303,10 +303,10 @@ user:
     WORKFLOW (iterate until validation passes):
 
     Step 1: GENERATE
-    - Read schema files for current v3.5.0 syntax:
+    - Read schema files for current v5.0.0 syntax:
       * {{aiSchemaPath}} (AI guidance, examples, patterns)
       * {{referenceSchemaPath}} (complete working example)
-    - Generate minimal spec using v3.5.0 format
+    - Generate minimal spec using v5.0.0 format
     - Use components: (plural) at top level
     - Use snake_case for lifecycle states (NOT kebab-case)
     - Add deployment policies appropriate for scale
@@ -376,7 +376,7 @@ validation:
       required: false
 
   output:
-    - rule: Must generate valid SpecVerse v3.5.0 specification
+    - rule: Must generate valid SpecVerse v5.0.0 specification
       format: yaml
       schema: schema/SPECVERSE-SCHEMA.json
     - rule: Must include at least one model