@misterhuydo/sentinel 1.4.53 → 1.4.54

package/.cairn/session.json

@@ -1,6 +1,6 @@
 {
-  "message": "Auto-checkpoint at 2026-03-25T11:57:04.683Z",
-  "checkpoint_at": "2026-03-25T11:57:04.684Z",
+  "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.53",
+  "version": "1.4.54",
   "description": "Sentinel — Autonomous DevOps Agent installer and manager",
   "bin": {
     "sentinel": "./bin/sentinel.js"

package/python/sentinel/sentinel_boss.py

@@ -296,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.
@@ -348,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",