Added value: +{
+  "description": "STANDALONE MODE (workflow mode inherits the workflow proxy instead): Proxy for runs. {source:\"WebRun\", country?} or {source:\"custom\", type:\"http\"|\"socks\", host, port, username?, password?}. Custom passwords are encrypted at rest and never returned. Social/messaging workflows (WhatsApp, Telegram, Instagram, Facebook, X, LinkedIn, TikTok): set country to the country the user is in right now — recommend it and confirm the country with them first; a mismatch is the usual cause of refused logins and sessions that log out repeatedly, and a scheduled workflow re-hits it every run, so keep the country stable once set.",
+  "properties": {
+    "country": {
+      "description": "2-letter ISO code or \"random\" (WebRun).",
+      "type": "string"
+    },
+    "host": {
+      "type": "string"
+    },
+    "level": {
+      "enum": [
+        "system",
+        "chrome"
+      ],
+      "type": "string"
+    },
+    "password": {
+      "type": "string"
+    },
+    "port": {
+      "type": "number"
+    },
+    "source": {
+      "enum": [
+        "WebRun",
+        "custom"
+      ],
+      "type": "string"
+    },
+    "type": {
+      "enum": [
+        "http",
+        "socks"
+      ],
+      "type": "string"
+    },
+    "username": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Previous value: -"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."New value: +"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract and WebRun applies it to every run automatically."

Previous value: -"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."New value: +"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."

Previous value: -"STANDALONE MODE: environment to run in. Omit to use the connection-bound environment (or your only one). Workflow mode always uses the workflow's deployed environment."New value: +"STANDALONE MODE, rarely needed — OMIT it: the connection-bound environment (or your only one) is applied automatically; never ask the user to choose. Workflow mode always uses the workflow's deployed environment."

Previous value: -"STANDALONE MODE: seed for the agent's persistent memory (carried across runs)."New value: +"STANDALONE MODE: the agent's private notebook, shown to it every run and updated automatically after each run. Seed ONLY durable facts the next run must know (target descriptions, preferences, known state) — one short line each. Task steps belong in prompt, not here. Usually best left empty."

Previous value: -"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Use {{variables}} for per-run values. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never put memory/dedup instructions here; those belong in memoryContract (the policy channel)."New value: +"STANDALONE MODE (required there): The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."

Previous value: -"WORKFLOW MODE: values for the workflow's {{variables}}, BAKED IN at deploy and reused every run (stored variableValues defaults fill gaps). Every template variable must be covered — an unattended agent cannot ask later."New value: +"WORKFLOW MODE, and only when the workflow's prompt actually contains {{variables}}: values for them, BAKED IN at deploy and reused every run (stored variableValues defaults fill gaps). Every template variable must be covered — an unattended agent cannot ask later. Workflows with concrete prompts need nothing here."