@kody-ade/kody-engine 0.4.166 → 0.4.168

package/dist/bin/kody.js

@@ -1061,7 +1061,7 @@ var init_loadPriorArt = __esm({
 // package.json
 var package_default = {
   name: "@kody-ade/kody-engine",
-  version: "0.4.166",
+  version: "0.4.168",
   description: "kody \u2014 autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   license: "MIT",
   type: "module",
@@ -9179,7 +9179,7 @@ function composeAuthBlock(authProfile, login, password) {
     return `Auth: a saved Playwright \`storageState.json\` is available at \`${authProfile}\`. Pass it to the browser via the \`storageState\` parameter so the session starts pre-authenticated.`;
   }
   if (login && password) {
-    return `Auth: log in once at the app's login page. Username: \`${login}\` \xB7 Password: \`${password}\`. Type each field key-by-key (Playwright \`locator.pressSequentially()\` / the MCP \`browser_type\` tool), NOT a one-shot \`fill()\` or value assignment: pasting a value in a single step often fails to fire the login form's framework onChange handler, so the form submits empty and you get a FALSE "invalid email or password". After typing, confirm the field shows the value before clicking submit; if the first attempt is rejected, re-type key-by-key before treating the credentials as wrong. Re-use the session afterwards.`;
+    return `Auth: log in once at the app's login page. Username: \`${login}\` \xB7 Password: \`${password}\`. Type each field key-by-key (Playwright \`locator.pressSequentially()\` / the MCP \`browser_type\` tool), NOT a one-shot \`fill()\` or value assignment: pasting a value in a single step often fails to fire the login form's framework onChange handler, so the form submits empty and you get a FALSE "invalid email or password". After typing, confirm the field shows the value before clicking submit; if the first attempt is rejected, re-type key-by-key before treating the credentials as wrong. If a login form's inputs don't respond to typing-by-label/placeholder, inspect the DOM and target them by their \`id\`/\`name\` attribute instead \u2014 e.g. a Payload CMS admin login at \`/admin\` uses \`#field-email\` and \`#field-password\`. The app may have TWO separate logins (a public/frontend one and a Payload \`/admin\` one); if a change you must verify lives behind the admin, log into that form too. Re-use the session afterwards.`;
   }
   if (login) {
     return `Auth: username \`${login}\` is configured but no \`LOGIN_PASSWORD\` secret was found. Note auth-gated surfaces as gaps.`;

package/dist/executables/ui-review/prompt.md

@@ -113,8 +113,8 @@ _UI review by kody — browsed {{previewUrl}}_
 
 - **Never write credentials anywhere.** The QA login is provided only so you can sign in — you MUST NOT put the password (or any token/secret) into the review, findings, steps, or any text posted to GitHub. PRs and issues are often public. When describing an authenticated step, write "log in as the QA account" — never quote the username or the password.
 - No commits. No `git` / `gh` invocations. No edits to files outside `.kody/ui-review/`.
-- Verdict **FAIL** only for clear visual regressions, broken flows, or correctness/accessibility issues that block merge.
-- Verdict **CONCERNS** for clarity/polish/edge-case gaps that shouldn't block.
-- Verdict **PASS** when the PR's UI changes work as intended and nothing obvious is broken.
-- If the preview URL is unreachable, PASS/FAIL should be based on the diff alone, and the "Gaps" section must call that out.
+- Verdict **FAIL** for clear visual regressions, broken flows, or correctness/accessibility issues that block merge. **Also FAIL when the PR claims to fix a specific user-visible symptom (named in the PR body or linked issue) and that symptom is STILL present in the browser** — report against the user-visible outcome, not just whether the diff is technically correct. A fix whose code path is right but whose reported symptom still reproduces is a FAIL.
+- Verdict **CONCERNS** for clarity/polish/edge-case gaps that shouldn't block — **and whenever you could NOT confirm a UI-affecting change in the browser** (couldn't reach the page, couldn't log in, couldn't trigger the state). Do not upgrade an unverified change to PASS on the strength of reading the diff: a reviewer must not bless what it did not see. List every such gap explicitly.
+- Verdict **PASS** only when you **confirmed in the browser** that the PR's changed behavior works as intended and nothing obvious is broken. PASS is a statement that you *saw it work*, not that the code looks correct.
+- If the preview URL is unreachable, the verdict is **CONCERNS** (not PASS) with the "Gaps" section calling out that nothing could be browser-verified; reserve FAIL for problems you can still prove from the diff alone.
 - Be specific: every finding gets a route + screenshot reference, or a file:line reference. No generic advice.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kody-ade/kody-engine",
-  "version": "0.4.166",
+  "version": "0.4.168",
   "description": "kody — autonomous development engine. Single-session Claude Code agent behind a generic executor + declarative executable profiles.",
   "license": "MIT",
   "type": "module",