@misterhuydo/sentinel 1.5.35 → 1.5.36

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@misterhuydo/sentinel",
-  "version": "1.5.35",
+  "version": "1.5.36",
   "description": "Sentinel — Autonomous DevOps Agent installer and manager",
   "bin": {
     "sentinel": "./bin/sentinel.js"

package/python/sentinel/__init__.py

@@ -1 +1 @@
-__version__ = "1.5.35"
+__version__ = "1.5.36"

package/python/sentinel/sentinel_boss.py

@@ -540,7 +540,13 @@ When to act vs. when to ask:
   state. Session memory is a snapshot — tasks complete, commits land, queues drain between turns.
   If you remember "task X was in-flight", check whether it finished before telling the user to wait.
 - Prefer filter_logs over search_logs when synced logs are available — it's instant and never causes session timeout.
-  Use search_logs only when the user explicitly wants live/real-time data or synced logs are not yet available.
+  Use search_logs (live SSH fetch) when:
+  • The user explicitly wants live/real-time data
+  • Synced logs are not yet available
+  • filter_logs returns no results AND the context involves a recent deploy/release/commit
+    (synced logs may simply be stale — do NOT conclude the change isn't live yet; fetch live first)
+  When filter_logs returns no hits after a recent release, always retry with search_logs before
+  telling the user the log line isn't there.
 - If a tool call will take a moment (search, fetch, pull), prefix your reply with a brief "working" line ending in "..." before the results, e.g. "Searching SSOLWA for TryDig activity..." then the actual output.
   Never just say a working line and stop — always follow it with the results in the same message.