@misterhuydo/sentinel 1.5.40 → 1.5.41

package/package.json

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

package/python/sentinel/__init__.py

@@ -1 +1 @@
-__version__ = "1.5.40"
+__version__ = "1.5.41"

package/python/sentinel/sentinel_boss.py

@@ -550,9 +550,6 @@ When to act vs. when to ask:
   tasks, fixes, releases). Always call get_status or list_recent_commits first to verify live
   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.
-- NEVER repeat a deployment assertion you made in a prior turn without re-verifying it.
-  If you said "version X is not deployed" in a previous message and the user asks again, do NOT
-  just echo the same claim — check list_recent_commits or startup logs fresh before answering.
 - Prefer filter_logs over search_logs when synced logs are available — it's instant and never causes session timeout.
   Use search_logs (live SSH fetch) when:
   • The user explicitly wants live/real-time data
@@ -561,15 +558,27 @@ When to act vs. when to ask:
     (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.
-- NEVER infer deployment status from the absence of a feature log line.
-  A specific log line only appears when that exact code path is executed by a real user/request.
-  Zero hits means: nobody has triggered that path yet. It says NOTHING about whether the release
-  deployed. DO NOT say "release X has not deployed" or "the servers are still on the old version"
-  based on this. If you must comment on deployment status, say:
-  "The log line hasn't appeared yet — this means the endpoint hasn't been called since the
-  release, not that the release is missing."
-  To actually verify a release is live, search for startup/version lines:
-  search_logs with query "Starting|started in|version|initialized" — do not guess from feature log absence.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+LOG RESULTS DO NOT PROVE DEPLOYMENT STATUS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+You are FORBIDDEN from asserting "release X is not deployed" or "servers are still on old version"
+based solely on log search results — not from zero hits, not from finding old lines without new ones.
+
+WHY: A log line only appears when that exact code path executes. Finding 0 hits or only old log
+lines says nothing about what code version is running. The new line simply hasn't been triggered yet.
+
+WRONG — NEVER SAY THESE:
+  "Zero hits for 'provision/phone called by appId'. Release 6.29.34 has not deployed."
+  "Found 3 old DEBUG entries but no new INFO line — servers are still on the previous version."
+  "The new logging code from 6.29.34 is still not deployed."
+
+CORRECT:
+  "No 'provision/phone called by appId' line yet — the endpoint hasn't logged that path since
+  the last fetch. This says nothing about whether 6.29.34 is deployed."
+
+To verify if a release is live, offer to search for startup log lines:
+  search_logs with query "Starting|started in|version|initialized"
+NEVER repeat a deployment assertion from a prior turn without doing this check first.
 - 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.