@specverse/engines 5.1.0 → 6.0.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

@@ -1,5 +1,5 @@
 name: behavior
-version: "9.1.0"
+version: "9.2.0"
 description: Generate pure TypeScript function bodies for SpecVerse behavior steps that don't match convention patterns
 author: SpecVerse Team
 tags: [behavior, code-generation, pure-function, typescript, realize]
@@ -10,58 +10,65 @@ system:
     function bodies for behavior steps that couldn't be matched by the realize
     engine's convention patterns.
 
+  minimalContext: |
     PURE FUNCTION RULES (critical — violating these breaks the architecture):
     1. NO database access (no prisma, no queries)
     2. NO event publishing (no eventBus)
     3. NO external services (no fetch, no email providers, no payment gateways)
     4. NO imports, no require, no fs, no process
-    5. All data you need comes in via the `input` object parameter
+    5. All data you need comes in via the `input` object parameter (already destructured — you have the fields directly)
     6. Return a plain result value (object, number, string) — the caller uses it
 
-    The controller (deterministic, convention-matched code) fetches all data,
-    calls your function, and then applies the result via convention code. Your
-    function is the PURE calculation or transformation in the middle.
+    OUTPUT RULES:
+    1. Output ONLY the function body code (between { and })
+    2. First line: short comment summarising what the function does
+    3. No markdown fences, no explanation before or after
+    4. Throw Error('...') for failure cases with descriptive messages
+    5. If a step fundamentally requires external side effects, throw an error indicating that — do not fake it
+
+  fullContext: |
+    # SpecVerse context (for LLMs that don't have the SpecVerse skill loaded)
+
+    SpecVerse is a declarative specification language. You describe WHAT a
+    system does in a .specly file, and the engines generate HOW — backend
+    (Fastify/Prisma), frontend (React/Tailwind), CLI, tools, diagrams. The
+    behavior-generation step you're being asked to perform plugs a
+    specific gap: the realize engine matches most spec behavior steps
+    against convention patterns ("Find {Model}", "Set {field}",
+    "Send {event}") and emits them directly; for the rest, you fill in
+    the pure-function body.
+
+    Where your function fits:
 
-    Example flow:
     ```
-    // Controller (convention code)
+    // Controller (convention-generated code — NOT your job)
     const order = await prisma.order.findUniqueOrThrow(...);
     const customer = await prisma.customer.findUniqueOrThrow(...);
 
-    // Your function (pure)
+    // Your function — PURE calculation or transformation
     const discount = await applyDiscountBasedOnLoyaltyTier({ order, customer });
     // discount = { amount: 42, rate: 0.10 }
 
-    // Controller (convention code)
+    // Controller (convention-generated code — NOT your job)
     await prisma.order.update({ where: { id }, data: { total: order.total - discount.amount } });
     await eventBus.publish('OrderDiscounted', { orderId, discount });
     ```
 
-    Convention patterns that are ALREADY auto-generated (you don't handle these):
+    Convention patterns ALREADY auto-generated (don't re-implement these):
     - "Find {Model} by {field}", "Create {Model}", "Update {Model}..."
     - "Delete {Model}", "Transition {Model} to {state}"
     - "Set/Increment/Decrement {field}", "Send {event} event"
 
-    You handle domain-specific logic: calculations, transformations, rules,
-    scoring, categorisation, validation.
+    You handle: domain-specific calculations, transformations, rules,
+    scoring, categorisation, validation logic. Anything where the behavior
+    step text doesn't match a convention pattern.
 
-  context: |
-    OUTPUT RULES:
-    1. Output ONLY the function body code (between { and })
-    2. Destructure `input` at the top: `const { order, customer } = input;`
-       (actually this is done for you — skip the destructure)
-    3. Perform the calculation/transformation
-    4. Return a meaningful result object
-    5. Throw Error('...') for failure cases with descriptive messages
-    6. NO await prisma.*, NO await eventBus.*, NO fetch, NO external calls
-    7. If the step fundamentally requires external side effects, throw an
-       error indicating that — do not fake it
-
-    OUTPUT FORMAT:
-    - No markdown fences
-    - No explanation before or after
-    - Just the function body code
-    - First line should be a comment summarizing what the function does
+    SpecVerse uses CURVED operations (Create, Update, Retrieve, Validate,
+    Evolve, Delete) on controllers. Validate is dry-run; Evolve handles
+    lifecycle state transitions. Models declare attributes, relationships,
+    and lifecycles. Full reference lives in the SpecVerse canonical guide
+    (`specverse://guide` resource, or `~/.claude/skills/specverse/reference/guide.md`
+    if the skill is installed).
 
   examples:
     - step: "Apply discount based on loyalty tier"
@@ -107,7 +114,7 @@ user:
 
     The function MUST return {{returnType}}. If that's `any`, return a
     reasonable result object describing what was computed. If it's a specific
-    type (e.g., { cost: number; days: number }), return an object matching
+    type (e.g., "{ cost: number; days: number }"), return an object matching
     that shape exactly — the caller depends on those field names.
 
     Output ONLY the function body (the code that goes between { and }).
@@ -115,12 +122,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