silas 0.3.0 → 0.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 187a0730a1a84463f6207060d446c6960946513c0884d708fc0d16c011493a26
-  data.tar.gz: ed9a09b617c7dde80deaf6fe2c460e254cc96487b43eac52f56c6aa7dedecbaa
+  metadata.gz: 36bc01dd259d8950ae57b75a3eb94f91065aed62d2b149d705959695bc8f323f
+  data.tar.gz: f2aa37ea2d83373d2252b594aaef87894f1da03adda08edfa746baa6e76c2dea
 SHA512:
-  metadata.gz: a38278a7020a9282b1ff9aaac7b18da60bd017a001bcc421c6e316d0033b1a4b468cd86c0d4bcdcd869940f7d9c4b953318e84dd626087bef4fee1ee8ea8b87c
-  data.tar.gz: 6f42e1a81bf935ebdbb39c678e46662ab85b9f45bd8293c0e83f4467e7db922e2102087ab62ea7eb8e8b1b3b1d323eba1a5772e997028b3e5838882bda9cfeb3
+  metadata.gz: 43ba5370306adecd0c53f818d655a367748e5b3162559abca5e8eb2a5687410c8d145f8f8b545f98ca265961344378e1c0a474826b46853357f2bce4192aa12b
+  data.tar.gz: 3cf07dea2adbe6eb33ec3bf65401c96127c1a066fbb104ea2e945d42f5526e8272aebbf9561a5777d1c6278674b3bc386036d1aa2b01bcb37d99366822ac431b

data/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## 0.3.1
+
+- **Fixed: only the first scenario in a `silas:eval` run was really tested.**
+  `Silas.configure` never invalidated the memoized resolved engine, so a
+  second `configure` in the same process kept serving the first one — every
+  eval scenario after the first silently ran the *first* scenario's script
+  while still reporting pass/fail as though it hadn't. Reconfiguring now
+  re-resolves both the engine and the sandbox. The gem's own specs missed this
+  because the spec helper resets config between examples; a real multi-scenario
+  eval suite — the production path — does not. Found by building
+  `examples/playground`.
+- **Automatic approvals are now recorded.** A graded gate that clears a call
+  (a lambda under its threshold, an `:once` rule already satisfied) sets
+  `approval_state: "approved"` with **no** `approved_by` — so the audit trail
+  distinguishes "gate ran and passed automatically" (which the inbox now
+  renders as *auto-approved by policy*) from "no gate at all", which stays
+  `nil`. Previously both were indistinguishable on a money-moving tool.
+- The generated `ruby_llm.rb` initializer opts into `use_new_acts_as`, silencing
+  RubyLLM's legacy-API deprecation warning on every boot — Silas never uses
+  `acts_as_*`, so the warning was pure noise. Existing initializers are still
+  never touched.
+
 ## 0.3.0
 
 - **`bin/rails silas:doctor`** — every known first-run failure mode as one

data/app/views/silas/inbox/invocations/_invocation.html.erb

@@ -3,8 +3,8 @@
     <code><%= invocation.tool_name %></code>
     <%= status_pill(invocation.awaiting_approval? ? "required" : invocation.status) %>
     <%# The audit line — who held the lever, and why it moved. %>
-    <% if invocation.approval_state == "approved" && invocation.approved_by.present? %>
-      <span class="muted">approved by <%= invocation.approved_by %></span>
+    <% if invocation.approval_state == "approved" %>
+      <span class="muted"><%= invocation.approved_by.present? ? "approved by #{invocation.approved_by}" : "auto-approved by policy" %></span>
     <% elsif invocation.approval_state == "declined" %>
       <span class="muted">declined<%= " by #{invocation.approved_by}" if invocation.approved_by.present? %><%= " — “#{invocation.decline_reason}”" if invocation.decline_reason.present? %></span>
     <% elsif invocation.approval_state == "expired" %>

data/lib/generators/silas/install/templates/ruby_llm.rb

@@ -5,6 +5,12 @@
 #
 # Any provider RubyLLM supports works the same way (openai_api_key, etc.).
 RubyLLM.configure do |c|
+  # Silas never uses RubyLLM's acts_as_* ActiveRecord mixins (it owns its own
+  # durable schema), so opt into the new API to silence the legacy deprecation
+  # warning on every boot. Remove this line if THIS app uses acts_as_chat and
+  # hasn't migrated yet — see https://rubyllm.com/upgrading-to-1-7/
+  c.use_new_acts_as = true if c.respond_to?(:use_new_acts_as=)
+
   c.anthropic_api_key = ENV["ANTHROPIC_API_KEY"]
   # The per-request timeout (seconds; RubyLLM default 300). Under streaming
   # this is an idle-between-chunks timeout — the hang protection for a stuck

data/lib/silas/ledger.rb

@@ -92,8 +92,15 @@ module Silas
           when Hash # {denied: "reason"} — eve's shape
             invocation.update!(status: "failed", result: { "denied" => verdict[:denied] })
             return :done
+          when :approved
+            # A gate ran and CLEARED it (a lambda under its threshold, or an
+            # :once rule already satisfied). Record that, so the audit trail
+            # can tell "gate evaluated, passed automatically" apart from "no
+            # gate at all" (which stays nil). approved_by is left nil — that
+            # absence is what marks it automatic rather than human.
+            invocation.update!(approval_state: "approved")
           end
-          # :not_applicable / :approved / :once-satisfied fall through
+          # :not_applicable falls through ungated
         end
 
         execute!(invocation, tool)

data/lib/silas/version.rb

@@ -1,3 +1,3 @@
 module Silas
-  VERSION = "0.3.0"
+  VERSION = "0.3.1"
 end

data/lib/silas.rb

@@ -51,9 +51,17 @@ module Silas
       @config ||= Configuration.new
     end
 
+    # Reconfiguring re-resolves the engine and sandbox. Without this the
+    # memos below outlive the config that produced them: a second
+    # `Silas.configure { |c| c.engine = ... }` in one process kept serving the
+    # FIRST engine. That silently broke multi-scenario `silas:eval` runs —
+    # every scenario after the first ran the first one's script and still
+    # reported pass/fail as if it hadn't. Re-resolution is cheap (one `.new`).
     def configure
       yield config
       config.validate!
+      @resolved_engine = nil
+      @resolved_sandbox = nil
       config
     end
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: silas
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.3.1
 platform: ruby
 authors:
 - Daniel St Paul
@@ -103,7 +103,7 @@ description: 'An agent framework where your Rails app is the chassis: app/agent/
   convention, durable runs on Active Job Continuations, exactly-once tool execution
   via a transactional ledger, approvals that park at zero compute.'
 email:
-- daniel@zerogravity.co.uk
+- danielstpaul@hotmail.com
 executables: []
 extensions: []
 extra_rdoc_files: []