@autonoma-ai/planner 0.1.14-canary.9e91c81 → 0.1.14

package/dist/index.js

@@ -4841,10 +4841,10 @@ var init_rubrics = __esm({
           "Are all step verbs valid (click/type/scroll/assert/hover/drag/read/refresh)? Are asserts visual-only (no URLs, network, console)? No code selectors? No login steps?"
         ),
         intentQuality: dimensionResultSchema.describe(
-          "Is the intent a specific, falsifiable behavioral claim \u2014 not just 'verify X is visible'?"
+          "Is the intent (the `description` frontmatter field) a specific, falsifiable behavioral claim \u2014 not just 'verify X is visible'?"
         ),
         missionAlignment: dimensionResultSchema.describe(
-          "Does the test's intent + steps verify the feature's core purpose? Not just UI appearance."
+          "Does the test's intent (the `description` field) + steps verify the feature's core purpose? Not just UI appearance."
         )
       }),
       systemPrompt: `You are a structural reviewer for E2E test plans. Each test will be executed by a VISUAL agent that sees the screen like a human user \u2014 it cannot inspect code, network, URLs, or any non-visual state.
@@ -4863,13 +4863,13 @@ Your job is to EVALUATE tests against a rubric, NOT to rewrite them. You have to
 - Assertions must reference specific visible text, not vague descriptions ("success indicator", "results are displayed")
 
 ### 2. Intent quality
-Is the intent a specific, falsifiable behavioral claim?
+Is the intent \u2014 the \`description\` frontmatter field \u2014 a specific, falsifiable behavioral claim?
 FAIL: "When a user clicks the clock icon, the Wait modal should open" (just UI mechanics)
 PASS: "Adding a 5-second wait step should insert a Wait action into the step list with the configured duration"
 
 ### 3. Mission alignment
-Does the test's intent + steps actually verify the feature's core purpose?
-FAIL if the intent just describes UI appearance when the feature is about functionality.
+Does the test's intent (the \`description\` field) + steps actually verify the feature's core purpose?
+FAIL if the description just describes UI appearance when the feature is about functionality.
 
 When done reviewing, call finish with your structured evaluation.`
     };
@@ -5479,6 +5479,9 @@ function validateTestContent(content) {
   } else {
     try {
       const { data } = matter4(content);
+      if (!data.description || typeof data.description !== "string" || data.description.length < 20) {
+        errors.push("Missing or insufficient 'description' field in frontmatter \u2014 must state the test's intent as a specific, falsifiable behavioral claim (min 20 chars)");
+      }
       if (!data.verification || typeof data.verification !== "string" || data.verification.length < 20) {
         errors.push("Missing or insufficient 'verification' field in frontmatter \u2014 must describe WHERE to navigate and WHAT to assert at the source of truth");
       }
@@ -5486,9 +5489,6 @@ function validateTestContent(content) {
       errors.push("Failed to parse frontmatter");
     }
   }
-  if (!/\*\*Intent\*\*:/.test(content)) {
-    errors.push("Missing **Intent**: section");
-  }
   const stepMatches = content.match(
     /^\d+\.\s+(click|type|scroll|assert|hover|drag|read|refresh):/gm
   ) || [];
@@ -5573,9 +5573,6 @@ function buildWriteTestTool(state, outputDir) {
           error: `Invalid frontmatter: ${parsed.error.issues.map((i) => i.message).join(", ")}`
         };
       }
-      if (!/\*\*Intent\*\*:/.test(input.content)) {
-        return { error: "Test must include an **Intent**: section between Setup and Steps describing what behavior is being tested" };
-      }
       const allSteps = input.content.match(/^\d+\.\s+(\w+):/gm) || [];
       for (const step of allSteps) {
         const verbMatch = step.match(/^\d+\.\s+(\w+):/);
@@ -5741,8 +5738,7 @@ var init_tools2 = __esm({
     init_validation();
     testFrontmatterSchema = z21.object({
       title: z21.string().min(1),
-      description: z21.string().min(1),
-      intent: z21.string().min(30, "Intent must be at least 30 characters \u2014 describe the BEHAVIOR being tested, not the steps"),
+      description: z21.string().min(20, "Description must state the test's intent \u2014 a specific, falsifiable behavioral claim (what the user does, what the feature produces, why it matters), not the steps. At least 20 characters."),
       criticality: z21.enum(["critical", "high", "mid", "low"]),
       scenario: z21.string().min(1),
       flow: z21.string().min(1),
@@ -5894,8 +5890,7 @@ Every test file must start with YAML frontmatter:
 \`\`\`yaml
 ---
 title: "Toggle recording stops active session"
-description: "Verify toggling recording OFF stops the session"
-intent: "When the recording toggle is ON (default), clicking it should stop recording and show a confirmation toast"
+description: "When the recording toggle is ON (default), clicking it should stop recording and show a confirmation toast"
 criticality: critical
 scenario: standard
 flow: "User Settings"
@@ -5905,12 +5900,17 @@ verification: "Refresh the Settings page, assert the recording toggle is in the
 
 ### Frontmatter rules
 - title: Short, descriptive test name
-- description: One sentence explaining what the test verifies
-- intent: A specific, falsifiable claim derived from the feature's MISSION \u2014 what the user does, what the feature produces, and why it matters. Focus on OUTCOMES, not UI mechanics.
+- description: (REQUIRED \u2014 write tool rejects without it, min 20 chars) The test's INTENT \u2014 a specific, falsifiable claim derived from the feature's MISSION. States what the user does, what should happen, and WHY it matters. This is the test's immutable "what it does" anchor and the "north star" the execution agent uses to adapt if steps don't match reality. Write it BEFORE the steps; if your steps conflict with the description, fix the STEPS. Focus on OUTCOMES, not UI mechanics.
+  The description is NOT "what UI appears" \u2014 it's "what the feature DOES".
+  Include in the description:
+  - The expected INITIAL STATE of relevant elements
+  - The ACTION the user takes
+  - The EXPECTED OUTCOME (what the feature produces, not what UI appears)
+  - Why this matters to the user
   GOOD: "Toggling recording from ON to OFF stops the active session and shows a confirmation toast"
   BAD: "Click the recording toggle" (that's a step, not an intent)
   BAD: "Verify the page displays correctly" (visibility check, not a behavior)
-  Derive from the mission: if the mission is "Generate valid config files", every test's intent must be about generating, previewing, or copying config \u2014 not about UI elements appearing.
+  Derive from the mission: if the mission is "Generate valid config files", every test's description must be about generating, previewing, or copying config \u2014 not about UI elements appearing.
 - criticality: One of: critical, high, mid, low
 - scenario: Which scenario this test uses (usually "standard")
 - flow: Which feature/flow this belongs to (must match a feature from AUTONOMA.md)
@@ -5928,17 +5928,7 @@ After frontmatter:
 NEVER write "Login as..." or "Log in" in Setup. The user is ALWAYS already authenticated. Setup only describes WHERE the user is, not authentication.
 NEVER write tests that require navigating to invalid URLs, 404 pages, or error states.
 
-**Intent**: A specific, falsifiable claim derived from the feature's MISSION. States what the user does, what should happen, and WHY it matters. Write this BEFORE writing steps \u2014 it's the "north star" that the execution agent uses to adapt if steps don't match reality.
-
-The intent is NOT "what UI appears" \u2014 it's "what the feature DOES".
-
-Include in your intent:
-- The expected INITIAL STATE of relevant elements
-- The ACTION the user takes
-- The EXPECTED OUTCOME (what the feature produces, not what UI appears)
-- Why this matters to the user
-
-The intent is the source of truth. If your steps conflict with the intent, fix the STEPS.
+The test's intent lives ONLY in the \`description\` frontmatter field (see Frontmatter rules above) \u2014 write it FIRST as your north star, and do NOT repeat it as an "Intent" section in the body. The body contains only Setup, Steps, Verification, and Expected Result.
 
 **Steps**: Numbered list using ONLY these actions (any other verb is INVALID):
 - click: Click a button, link, or element
@@ -6647,7 +6637,7 @@ Each journey test:
 - Uses EXACT data values from scenarios.md \u2014 NEVER use "Dynamic:", "{variable}", or "e.g."
 - Has criticality: critical
 - Has scenario: standard
-- Includes an **Intent**: section explaining the cross-feature flow being tested
+- Has a \`description\` frontmatter field stating the cross-feature flow being tested as a specific, falsifiable behavioral claim
 - Verifies that the OUTPUT of one feature is correctly consumed by the NEXT feature
 - Goes in the "journeys" folder