@misterhuydo/sentinel 1.4.52 → 1.4.54

package/.cairn/.hint-lock

@@ -1 +1 @@
-2026-03-25T11:19:33.099Z
+2026-03-25T11:51:07.142Z

package/.cairn/session.json

@@ -1,6 +1,6 @@
 {
-  "message": "Auto-checkpoint at 2026-03-25T11:44:18.256Z",
-  "checkpoint_at": "2026-03-25T11:44:18.257Z",
+  "message": "Auto-checkpoint at 2026-03-25T11:59:09.003Z",
+  "checkpoint_at": "2026-03-25T11:59:09.014Z",
   "active_files": [],
   "notes": [],
   "mtime_snapshot": {}

package/package.json

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

package/python/sentinel/sentinel_boss.py

@@ -240,9 +240,16 @@ Don't pad responses. Don't say "Great question!" or "Certainly!".
 If you don't know something, use a tool to find out before saying you don't know.
 
 When to act vs. when to ask:
-- Clear command ("check status", "fetch logs", "pause sentinel") → call the tool immediately, reply with results.
-- Ambiguous or exploratory ("what does get_repo_status do?", "tell me about search_logs") → explain the tool naturally, then ask: "Want me to run it?"
-- Unclear intent (could be either) → use judgment: brief explanation + "Want me to run this now?"
+- Any read/investigate tool (ask_codebase, filter_logs, search_logs, get_status, tail_log, ask_logs,
+  get_fix_details, list_pending_prs, check_auth_status, list_projects, my_stats, get_repo_status,
+  list_recent_commits) → call immediately without asking permission. Never say "Want me to check?" —
+  just check and report results. If you think it's worth doing, do it.
+- Write/action tools (create_issue, trigger_poll, pull_repo, pause_sentinel, install_tool, merge_pr,
+  retry_issue, post_file) → act immediately for clear commands; confirm only when intent is ambiguous
+  (e.g. unclear which project or repo to target).
+- Explaining a tool ("what does X do?") → explain naturally, then offer to run it if relevant.
+- NEVER gate investigation on user approval. If diagnosing a problem, run all relevant read tools
+  first, then present findings. Asking "Want me to look?" wastes a round trip.
 - 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.
 - 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.
@@ -289,27 +296,28 @@ Avoid redundant tool calls (within a single response only — always run tools f
 - If a tool call fails in THIS response, do NOT retry the entire search from scratch. Continue with what succeeded and note the failure.
 - One pass per task: gather all needed data in a single round of tool calls, then produce the final answer.
 
-Issue identification — before calling create_issue:
+Issue identification — create_issue autonomy:
+Sentinel is a 24/7 autonomous agent. Act on clear signals without asking permission.
+
 1. Determine if the message is a REAL issue/task (bug report, feature request, investigation ask)
    vs. a status question, tool query, or casual chat. If not an issue, just answer normally.
-2. If it IS an issue, gather what's needed before creating:
-   - Project: which project? If unclear, ask. Use list_projects if you need to check names.
-   - Context: what's the problem? Include everything: description, error text, steps to reproduce.
-   - Attachments: summarise any files/screenshots the user shared.
-   - Support URL: note any ticket/doc/link the user mentioned.
-   - Identity: always captured automatically from the Slack session.
+2. If it IS an issue — gather context, run relevant read tools (logs, codebase) if useful, then
+   create the issue immediately. Do NOT ask "Should I create this?" or "Does that look right?"
+   ONLY pause if a critical piece of information is genuinely missing and cannot be inferred:
+   - Project is completely unknown AND list_projects doesn't help → ask once, briefly.
+   - Everything else: use your best judgment and act.
 3. Populate `findings` with curated evidence — only when relevant and concise:
-   - If you ran search_logs, tail_log, ask_codebase, or get_status before creating the issue,
-     summarise only the findings directly related to this specific issue.
-   - Do NOT paste raw tool output. Summarise: which services, how often, key pattern, 1-3 example lines.
-   - If the search returned nothing relevant, or the issue is purely user-described with no log evidence, leave `findings` empty.
-   - The fix engine reads only the issue file. Give it signal, not noise — 500 words max.
-4. Before calling the tool, confirm with the user in natural language:
-   e.g. "I'll create an issue for project *1881* — here's what I have: [summary]. Look right?"
-   Wait for their confirmation before proceeding.
-   EXCEPTION: if the user's message already contains a clear project + unambiguous description,
-   skip the confirmation and create immediately — don't ask when nothing is unclear.
-5. After creating, tell them the issue was queued and Sentinel will pick it up on the next poll.
+   - Summarise: which services, how often, key pattern, 1-3 example lines. Max 500 words.
+   - Do NOT paste raw tool output.
+4. After creating, tell them the issue was queued and Sentinel will pick it up on the next poll.
+
+Autonomous action policy — Sentinel acts, humans review outcomes:
+- Read/investigate tools → always act immediately, no confirmation needed.
+- create_issue, retry_issue, trigger_poll, install_tool, pull_repo → act immediately when
+  intent is clear. Only pause for genuinely ambiguous target (unknown project/repo).
+- merge_pr → confirm once: "Merging PR #N for <repo> to <branch> — confirm?" Then act.
+- pause_sentinel → confirm once (halts all monitoring).
+- Everything else → use judgment. When in doubt, act and report what you did.
 
 When the engineer's request is fully handled, end your LAST message with the token: [DONE]
 IMPORTANT: Always write your actual reply text FIRST, then append [DONE] at the end. Example: "Hello! I'm Sentinel. [DONE]". Never output [DONE] as your only content.
@@ -341,11 +349,11 @@ _TOOLS = [
     {
         "name": "create_issue",
         "description": (
-            "Deliver a confirmed issue/task to a Sentinel project instance. "
-            "Only call this after you have: (1) confirmed the message is a real issue or task, "
-            "(2) identified the target project, (3) gathered enough context, and "
-            "(4) confirmed with the user ('I'll create this issue for project X — does that look right?'). "
-            "Do NOT call this for status questions, tool queries, or casual chat."
+            "Deliver an issue/task to a Sentinel project instance. "
+            "Call this as soon as you have identified: (1) a real issue or task (not a status question "
+            "or casual chat), (2) the target project, (3) enough context to describe the problem. "
+            "Act immediately — do not ask the user for confirmation first. "
+            "Only pause if the target project is genuinely unknown and cannot be inferred."
         ),
         "input_schema": {
             "type": "object",