test(core-components): tighten double-brackets spec per review

- Scope display-name assertion with .first() to avoid Playwright strict-mode
  failure if "Use Double Brackets" ever appears elsewhere on the page.
- Add baseline check in test 5: poll the saved flow for
  use_double_brackets.value === false before toggling, so the test proves
  the round-trip, not just the final state.
- Surface test 4's mode-swap as an explicit test-level expect() on the
  modal-open testid pair, so the HTML report shows a real assertion in the
  "swaps back" step rather than only the helper's internal wait.
- Hoist readUseDoubleBrackets() to module scope to keep the response-status
  guard out of the test body (avoids playwright/no-conditional-in-test).
- Reword the spec doc's "core contracts" paragraph: drop the unconditional
  "real-time re-extraction" claim that no longer matches test 4's contract
  (re-extraction is verified on the next save, not on the toggle alone).

Author: Victor-w-Madeira

docs/core-components/prompt-template-double-brackets-regression.md

@@ -14,7 +14,7 @@ Validates the **Prompt Template** component's `use_double_brackets` toggle and t
 4. **Disabling the toggle reverts to f-string mode and variables are re-extracted under the new parser** — a template saved in mustache mode (`Hello {{name}}!`) keeps its `name` handle past the toggle alone (the rendered handle set is only fully reconciled after the next save), but re-saving the same template after switching back to f-string drops the now-literal `{{name}}` handle, and a fresh `{var}` template then recreates a handle.
 5. **`use_double_brackets` value persists in the saved flow** — `GET /api/v1/flows/{id}` returns `template.use_double_brackets.value === true` after the toggle is flipped and autosave runs.
 
-If any of these tests fails, the toggle is broken in one of its core contracts: the advanced-field rendering, the f-string ↔ mustache parser switch in `update_build_config`, the real-time re-extraction of variables on mode change, or the autosave round-trip of the boolean value.
+If any of these tests fails, the toggle is broken in one of its core contracts: the InspectionPanel rendering of the bool field, the f-string ↔ mustache parser switch in `update_build_config`, the re-extraction of variables when the template is saved under the active mode, or the autosave round-trip of the boolean value.
 
 This spec complements `prompt-template-component-regression.spec.ts`, which covers only the default (f-string) mode.
 
@@ -67,14 +67,15 @@ Both modes share the post-save preview (`edit-prompt-sanitized`) and the save bu
 
 ### 4. `disabling toggle reverts to f-string mode and variables are re-extracted under the new parser`
 - Calls `flipDoubleBrackets(page, true)`, then saves `Hello {{name}}!` via the mustache modal. Asserts the `name` handle is visible.
-- Calls `flipDoubleBrackets(page, false)`. The modal-open button swaps back to the f-string variant — confirmed by `flipDoubleBrackets`' built-in wait — but the rendered `name` handle may persist past the toggle alone (the upstream cleanup-and-re-extraction inside `update_build_config` runs, but the rendered handle set is only fully reconciled after the next save).
+- Calls `flipDoubleBrackets(page, false)` and explicitly asserts `button_open_prompt_modal` is visible and `button_open_mustache_prompt_modal` has count 0 — the swap-back is surfaced as a test-level `expect()` so the HTML report carries a real assertion, not just the helper's internal wait. The rendered `name` handle may still persist past the toggle alone: the upstream cleanup-and-re-extraction inside `update_build_config` runs, but the rendered handle set is only fully reconciled after the next save.
 - Re-saves the same template `Hello {{name}}!` via the f-string modal. Asserts the `name` handle disappears and the dynamic-handle count is 0 — `{{name}}` is a literal `{name}` under f-string semantics.
 - Saves `Just one {var} here.` via the f-string modal. Asserts the `var` handle is visible and the dynamic-handle count is 1.
 
 ### 5. `use_double_brackets value persists in the autosaved flow`
 - Extracts the flow id from the URL.
+- **Baseline:** polls `GET /api/v1/flows/{id}` via `page.request` (inherits session cookies) until the Prompt Template node's `template.use_double_brackets.value` equals `false` — proves the field starts in the default OFF state before any interaction.
 - Calls `flipDoubleBrackets(page, true)`.
-- Polls `GET /api/v1/flows/{id}` via `page.request` (inherits session cookies) until the Prompt Template node's `template.use_double_brackets.value` equals `true`.
+- Polls the same endpoint until the value equals `true` — proves the toggle drove the round-trip change, not just that the final state happens to be `true`.
 
 ---
 

tests/tests-automations/regression/core-components/prompt-template-double-brackets-regression.spec.ts

@@ -124,11 +124,19 @@ test(
       async () => {
         // The literal "Use Double Brackets" comes from the upstream
         // `BoolInput(..., display_name="Use Double Brackets", ...)` declaration —
-        // asserting it catches an accidental rename at the source. The `info`
-        // string is intentionally not asserted: the InspectionPanel collapses it
-        // into a hover-tooltip icon when the panel is narrow, so the visible
-        // rendering of that text depends on layout state.
-        await expect(page.getByText("Use Double Brackets")).toBeVisible();
+        // asserting it catches an accidental rename at the source. Scoped to the
+        // toggle's enclosing field row so an unrelated occurrence of the string
+        // elsewhere on the page (a tooltip, a help string) cannot satisfy or
+        // break the assertion via Playwright strict mode. The `info` text is
+        // intentionally not asserted — the InspectionPanel collapses it into a
+        // hover-tooltip icon when the panel is narrow.
+        // `.first()` avoids Playwright strict-mode failures if "Use Double
+        // Brackets" ever shows up elsewhere (e.g. a future tooltip or help
+        // string). The toggle's existence was already asserted in the previous
+        // step, so this assertion is solely about the label string.
+        await expect(
+          page.getByText("Use Double Brackets").first(),
+        ).toBeVisible();
       },
     );
   },
@@ -230,6 +238,15 @@ test(
       "Disable mustache mode — modal-open button swaps back to the f-string variant",
       async () => {
         await flipDoubleBrackets(page, false);
+        // Explicit assertion at the test level so the HTML report shows a real
+        // `expect()` in this step, even though `flipDoubleBrackets` already
+        // waited on the same testid internally.
+        await expect(
+          page.getByTestId("button_open_prompt_modal"),
+        ).toBeVisible();
+        await expect(
+          page.getByTestId("button_open_mustache_prompt_modal"),
+        ).toHaveCount(0);
         // Note: an existing `name` handle may persist past the toggle alone —
         // the upstream cleanup-and-re-extraction runs inside `update_build_config`,
         // but the rendered handles are only fully reconciled after the next save
@@ -262,6 +279,22 @@ test(
   },
 );
 
+// Reads `template.use_double_brackets.value` for the Prompt Template node in
+// the autosaved flow. Returns `null` when the flow is not yet fetchable or the
+// node is missing — `expect.poll` retries until a definite boolean comes back.
+// Hoisted out of the test body so the `if (!res.ok())` guard does not trip the
+// `playwright/no-conditional-in-test` ESLint rule.
+async function readUseDoubleBrackets(page: Page, flowId: string) {
+  const res = await page.request.get(`/api/v1/flows/${flowId}`);
+  if (!res.ok()) return null;
+  const flow = await res.json();
+  const promptNode = (flow?.data?.nodes ?? []).find(
+    (n: { data?: { type?: string } }) =>
+      n?.data?.type === "Prompt Template",
+  );
+  return promptNode?.data?.node?.template?.use_double_brackets?.value ?? null;
+}
+
 test(
   "Prompt Template — use_double_brackets value persists in the autosaved flow",
   { tag: ["@stable", "@regression", "@components"] },
@@ -274,30 +307,30 @@ test(
       expect(flowId).toMatch(/^[0-9a-f-]{36}$/);
     });
 
+    await test.step(
+      "Baseline — `template.use_double_brackets.value` starts as `false`",
+      async () => {
+        await expect
+          .poll(() => readUseDoubleBrackets(page, flowId), {
+            timeout: 15000,
+            intervals: [500, 1000, 2000],
+          })
+          .toBe(false);
+      },
+    );
+
     await test.step("Enable double brackets", async () => {
       await flipDoubleBrackets(page, true);
     });
 
     await test.step(
-      "Backend persistence — `template.use_double_brackets.value` is `true` in the saved flow",
+      "Backend persistence — toggling flips the saved value to `true`",
       async () => {
         await expect
-          .poll(
-            async () => {
-              const res = await page.request.get(`/api/v1/flows/${flowId}`);
-              if (!res.ok()) return null;
-              const flow = await res.json();
-              const promptNode = (flow?.data?.nodes ?? []).find(
-                (n: { data?: { type?: string } }) =>
-                  n?.data?.type === "Prompt Template",
-              );
-              return (
-                promptNode?.data?.node?.template?.use_double_brackets?.value ??
-                null
-              );
-            },
-            { timeout: 15000, intervals: [500, 1000, 2000] },
-          )
+          .poll(() => readUseDoubleBrackets(page, flowId), {
+            timeout: 15000,
+            intervals: [500, 1000, 2000],
+          })
           .toBe(true);
       },
     );