codeloop-mcp-server 0.1.64 → 0.1.66
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/auth/critical_floors.d.ts.map +1 -1
- package/dist/auth/critical_floors.js +8 -0
- package/dist/auth/critical_floors.js.map +1 -1
- package/dist/index.js +6 -1
- package/dist/index.js.map +1 -1
- package/dist/runners/base.d.ts.map +1 -1
- package/dist/runners/base.js +86 -14
- package/dist/runners/base.js.map +1 -1
- package/dist/runners/flutter.d.ts.map +1 -1
- package/dist/runners/flutter.js +73 -3
- package/dist/runners/flutter.js.map +1 -1
- package/dist/runners/modal_detector.d.ts +27 -7
- package/dist/runners/modal_detector.d.ts.map +1 -1
- package/dist/runners/modal_detector.js +124 -31
- package/dist/runners/modal_detector.js.map +1 -1
- package/package.json +1 -1
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"critical_floors.d.ts","sourceRoot":"","sources":["../../src/auth/critical_floors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH,MAAM,WAAW,aAAa;IAC5B,4DAA4D;IAC5D,WAAW,EAAE,MAAM,CAAC;IACpB,wDAAwD;IACxD,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,eAAe,EAAE,aAAa,
|
|
1
|
+
{"version":3,"file":"critical_floors.d.ts","sourceRoot":"","sources":["../../src/auth/critical_floors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH,MAAM,WAAW,aAAa;IAC5B,4DAA4D;IAC5D,WAAW,EAAE,MAAM,CAAC;IACpB,wDAAwD;IACxD,MAAM,EAAE,MAAM,CAAC;CAChB;AAED;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,eAAe,EAAE,aAAa,EA8F1C,CAAC"}
|
|
@@ -108,5 +108,13 @@ export const CRITICAL_FLOORS = [
|
|
|
108
108
|
min_version: "0.1.63",
|
|
109
109
|
reason: "Out-of-app confirm/alert modal was NEVER detected (recurrence) — 0.1.54/0.1.55/0.1.57 only hardened FILE dialogs; a plain Yes/No confirmation MessageBox raised by clicking a button (e.g. Photometry-DB 'Delete TEMP PCB Test Range') stayed invisible to the detector and blocked the journey. detectWindowsModal only flagged a window when UIA reported IsModal=true AND the dialog TITLE contained the app name, OR the title matched a file-dialog pattern — but a WPF/WinForms MessageBox is a SEPARATE top-level #32770 window whose caption is 'Confirm'/'Delete'/the app name and whose UIA IsModal flag is frequently FALSE, so it slipped through every pass (is_modal_present:false). No F4 directive fired and the agent kept clicking the now-blocked button beneath it, then mis-read 'click missed' and looped. A second bug compounded it: win_ui_inspect / win_ui_automate located the app window with an EXACT NameProperty match, so app_name 'Photometry DB' never matched the live title 'PhotometryDB - Professional…' (no space) and every inspect returned 'App window not found', forcing coordinate guessing. 0.1.63 ships H12: (1) the Windows modal probe now collects each window's ProcessId and resolves the app's own pid(s) + main-window handle(s), and flags any app-OWNED secondary top-level window carrying a dialog signal (modal flag / #32770 or dialog class / confirm-or-alert title) as the modal regardless of its caption — the title- and IsModal-independent ownership signal that finally catches in-process MessageBox confirms; (2) classifyModalKind now treats an ambiguous #32770 as `confirm` (routes to codeloop_handle_modal for an agent decision) instead of `file_dialog` (auto-Escape), while a file-TITLED #32770 stays file_dialog; (3) codeloop_handle_modal with decision confirm/cancel now INVOKES the matching Yes/OK/Save/Delete or No/Cancel button on the dialog directly via UIA and re-detects to confirm it cleared, so a destructive Yes/No box no longer depends on which button is the Enter/Escape default; (4) buildUiaAppElementLookup + a whitespace-insensitive process-lookup fallback make win_ui_inspect / win_ui_automate / screenshot / window-bounds resolve the app window even when app_name differs from the live title by spaces or a suffix, or doesn't embed it at all (owning-process match).",
|
|
110
110
|
},
|
|
111
|
+
{
|
|
112
|
+
min_version: "0.1.65",
|
|
113
|
+
reason: "Out-of-app confirm modal STILL missed (recurrence #4, now on 0.1.64) — the 0.1.63 ownership fix could only flag a dialog that was actually IN the window list, but on the next Photometry-DB delete-confirm the list came back with ONLY the main window ('Only the main window exists'), so every pass was starved of data and the agent mis-read it as 'the click missed the Delete button' and looped. ROOT CAUSE, distinct from all prior fixes: every modal fix 0.1.54→0.1.63 enumerated windows via UIA — RootElement.FindAll(TreeScope.Children, ControlType::Window). A native Win32/WPF MessageBox(hwndOwner,…) is an OWNED top-level window, and UIA's control view does NOT reliably expose owned dialogs as direct children of the root element (they nest under the owner), and a strict ControlType::Window filter drops anything UIA surfaces as Pane/Custom — so the dialog never even appeared in the enumeration. No ownership / title / IsModal tweak can rescue a window that isn't in the list. A compounding factor: a window-scoped screenshot (PrintWindow on the app HWND) renders ONLY the app window, so the overlaid native dialog was invisible in the capture too, reinforcing the agent's wrong 'no modal' conclusion. 0.1.65 ships H13: (1) the Windows modal probe is rewritten from the UIA control-view walk to a Win32 EnumWindows enumeration that lists EVERY visible top-level window and, per window, reads the owner handle (GW_OWNER), enabled state (IsWindowEnabled), pid, class and title, plus the current foreground window (GetForegroundWindow); (2) selectWindowsModal gains title- and IsModal-INDEPENDENT passes — OWNER-CHAIN (a visible non-main window whose GW_OWNER is the app's main window is the MessageBox, full stop), OWNER-DISABLED (Windows disables a modal's owner, so a visible-but-disabled app main window means a modal is blocking it), and FOREGROUND (after a click that pops a dialog, the dialog is the foreground window — caught even when app-title resolution fails, the exact Photometry-DB 'PhotometryDB' vs 'Photometry DB' case); (3) the post-interact H11 directive now warns that a window-scoped screenshot does NOT render a separate native dialog, so a clean app-window shot is not proof there is no modal, and the agent must trust the F4 directive / codeloop_handle_modal instead of re-clicking the blocked control. The whole detection→F4-directive→handle_modal (UIA button-invoke)→kill-window chain now fires on the first detection.",
|
|
114
|
+
},
|
|
115
|
+
{
|
|
116
|
+
min_version: "0.1.66",
|
|
117
|
+
reason: "codeloop_verify could HANG FOREVER on Flutter projects — the three primary Flutter runners (flutter analyze, flutter test, flutter test integration_test/) all called runCommand WITHOUT a timeout, so any one of them could block the whole verify (and the MCP response, which only returns when the entire sequential pipeline finishes) indefinitely. The dominant trigger: `flutter test integration_test/` is launched with NO `-d` device flag and NO device probe, so when no emulator/simulator/device is booted the Flutter CLI waits forever for one — the user saw verify 'hang at here for 10 mins' on a fresh Flutter project with no device. `flutter analyze` could likewise stall on an implicit `pub get` over a slow/blocked network, and a brand-new machine could even block on Flutter's first-run analytics consent prompt. (The later deep-internal duplicates static_analysis `flutter analyze` and coverage `flutter test --coverage` already had 4-/5-min caps, but they never ran because the un-timed primary trio came first.) 0.1.66 fixes it: every primary Flutter runner now passes a wall-clock timeout (analyze 4 min, test 5 min, integration_test 6 min) — on expiry runCommand SIGKILLs and returns exit_code 124, which the runner surfaces as an explicit FAILED result with a clear note ('killed after N min … waiting on a cold emulator/device or a stalled pub get — boot a device or run flutter pub get, then re-verify') instead of a silent freeze — and all three now run with CI=true so Flutter never blocks on its first-run analytics/consent prompt. CRUCIALLY, 0.1.66 also fixes the runCommand watchdog itself: commands were spawned via `shell: true`, so killing the direct child only reaped the `/bin/sh -c …` wrapper, NOT the grandchild it forked (flutter is a bash script that spawns dart) — the grandchild kept the stdout pipe open so the `close` event never fired and the promise hung forever, defeating the timeout. The watchdog now makes the timed child a process-group leader (detached on POSIX) and SIGKILLs the ENTIRE group via process.kill(-pid) (taskkill /T /F on Windows), with a 1.5s safety net that force-settles the promise even if `close` is somehow withheld. Without this, every timeout added above would have been silently ineffective on real Flutter (and any shell-wrapped) commands.",
|
|
118
|
+
},
|
|
111
119
|
];
|
|
112
120
|
//# sourceMappingURL=critical_floors.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"critical_floors.js","sourceRoot":"","sources":["../../src/auth/critical_floors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AASH;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,eAAe,GAAoB;IAC9C;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,ufAAuf;KAC1f;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EAAE,4hBAA4hB;KACriB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EAAE,yvBAAyvB;KAClwB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,kxBAAkxB;KACrxB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,0/BAA0/B;KAC7/B;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,0iCAA0iC;KAC7iC;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,gqDAAgqD;KACnqD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,uqDAAuqD;KAC1qD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,w+EAAw+E;KAC3+E;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,88EAA88E;KACj9E;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,uiEAAuiE;KAC1iE;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,u/DAAu/D;KAC1/D;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,k3DAAk3D;KACr3D;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,oiDAAoiD;KACviD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,g3CAAg3C;KACn3C;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,srFAAsrF;KACzrF;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,gwEAAgwE;KACnwE;CACF,CAAC"}
|
|
1
|
+
{"version":3,"file":"critical_floors.js","sourceRoot":"","sources":["../../src/auth/critical_floors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AASH;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,eAAe,GAAoB;IAC9C;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,ufAAuf;KAC1f;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EAAE,4hBAA4hB;KACriB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EAAE,yvBAAyvB;KAClwB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,kxBAAkxB;KACrxB;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,0/BAA0/B;KAC7/B;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,0iCAA0iC;KAC7iC;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,gqDAAgqD;KACnqD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,uqDAAuqD;KAC1qD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,w+EAAw+E;KAC3+E;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,88EAA88E;KACj9E;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,uiEAAuiE;KAC1iE;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,u/DAAu/D;KAC1/D;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,k3DAAk3D;KACr3D;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,oiDAAoiD;KACviD;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,g3CAAg3C;KACn3C;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,srFAAsrF;KACzrF;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,gwEAAgwE;KACnwE;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,84EAA84E;KACj5E;IACD;QACE,WAAW,EAAE,QAAQ;QACrB,MAAM,EACJ,gwEAAgwE;KACnwE;CACF,CAAC"}
|
package/dist/index.js
CHANGED
|
@@ -3968,7 +3968,12 @@ Wait 1-2 seconds between interactions so video frames capture state changes.`, {
|
|
|
3968
3968
|
"(3) if one is present call codeloop_handle_modal with the appropriate `decision` " +
|
|
3969
3969
|
"(\"confirm\" to proceed / \"cancel\" to abort / \"dismiss\" to close), and " +
|
|
3970
3970
|
"(4) only then continue the planned journey. " +
|
|
3971
|
-
"Do NOT skip modals \"to keep moving\" — an unhandled modal will block every subsequent click and the user_journey_evidence gate will block ready_for_review."
|
|
3971
|
+
"Do NOT skip modals \"to keep moving\" — an unhandled modal will block every subsequent click and the user_journey_evidence gate will block ready_for_review. " +
|
|
3972
|
+
// 0.1.65 H13 — a window-scoped capture (method "powershell (window: …)") renders ONLY
|
|
3973
|
+
// the named app window via PrintWindow, so a SEPARATE native dialog drawn on top of it
|
|
3974
|
+
// is invisible in that shot. A clean app-window screenshot is NOT proof there is no modal.
|
|
3975
|
+
"NOTE (desktop): a window-scoped screenshot does NOT render a separate native dialog (Win32/WPF MessageBox, OS file picker) drawn over the app — a clean app-window shot is NOT proof there is no modal. " +
|
|
3976
|
+
"If CodeLoop emits a [CodeLoop F4] modal directive below, or your click did not produce the expected effect, TRUST that and call codeloop_handle_modal (which detects via the Win32 owner-chain and clicks the dialog's button directly) rather than re-clicking the now-blocked control beneath the dialog.";
|
|
3972
3977
|
// 0.1.55 F4 — when desktop click-effect verification detected a
|
|
3973
3978
|
// modal that has now persisted across one or more interactions, the
|
|
3974
3979
|
// F4 directive is stronger than the soft H11 reminder. Append it
|