mcptask-rails-runner 0.3.18 → 0.3.20

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: be43b323d689bbb685fb366d755aa837dacb5a2184450ecb4192c051317d2ab1
-  data.tar.gz: 4101e1dd5bcd1704c9d198760b0bde3a9663d02650c3a00af5ac0e35da125596
+  metadata.gz: 49c22bb6614a5230f35bffc56475baae278dfe014d123608339d9d64605e23e3
+  data.tar.gz: c57fb535d1e21a9ef10009f52231540912784fa1fe5c8011a44ae4d058649618
 SHA512:
-  metadata.gz: 94032b0cb455e7d39f2f319b5e1983c391690c68def8788e22e16a60ee23092058ccfc4220ccac54cff6c2344d186c940b70426b99cbe7c23a352e520dc4e209
-  data.tar.gz: 4d04d2ecc72e2593e5dc33acf12a35991b2e3199ae2ae984b6287e37f771091eb6509f63ecc7393d7c1a2fcb34a5f13d97d4630e63281a3d86ae1b753c37a3ae
+  metadata.gz: e17a375731c475d4acf9b38c3892d92fba6caaa7e225f89be19421537aa78d0d33b03a356fe2f6d80dd1ba549323c39092090626d5b2d2d10ddbeb5db4a0903a
+  data.tar.gz: 5ac712a382f98e78dc0ba1b2befb3c2751158b35fdc471faefe422126f3cd745ecc7062c4cb7617530559c179545d83cf0f19564b68f202edb6c2b04e898eb6e

data/CHANGELOG.md

@@ -5,6 +5,125 @@ entries below describe wrapper changes only. Binary changes are listed in the
 [mcptask-releases](https://github.com/jchsoft/mcptask-releases/releases)
 release notes for the same tag.
 
+## Unreleased
+
+## 0.3.20
+
+No wrapper changes. Full notes in
+[mcptask-releases v0.3.20](https://github.com/jchsoft/mcptask-releases/releases/tag/v0.3.20).
+
+**Upgrading:** run `mcptask_runner update --self` on each host, and do it for
+this one rather than at leisure — the fix below can only reach a runner that is
+running the new binary, and the situation it fixes keeps happening until then. A
+daily process picks the new copy up at its night swap, but only once that copy
+is on disk. The project bump alone still changes nothing about what the 08:00
+job runs.
+
+Binary changes carried by this version:
+
+- A piece assigned to somebody else while this runner is working it now stops
+  the child, instead of being worked to the end by a runner it no longer belongs
+  to. The dashboard socket has always carried both halves of an assignment —
+  "given to you" cut an idle wait short, and "given to somebody else" reached
+  nothing — so a task moved between two agents was picked up by its new owner
+  while its old one carried on: two agents on one piece, the same branch name
+  pushed twice, two sets of efforts logged. The runner now abandons the piece,
+  says so, and goes back to the queue for one that is still its own. It is not a
+  reason to stop the day, and the piece is deliberately not set aside: the queue
+  has already stopped offering it, and it stays workable if it is handed back.
+- The run log is coloured as it is read, and the file itself stays plain. The
+  two lines that matter in a wall of uniform text — the ones `Warn` and `Error`
+  already mark with a glyph — are painted red and yellow, a child's stderr is
+  yellow, and the `[Component]` tags, cost lines and phase separators are dimmed
+  so the shape of a run is visible in a scroll. Only what the runner itself
+  marked is coloured; guessing a severity from the wording would be wrong on the
+  day it mattered. Nothing is written to the file, which is what bug reports
+  attach and what people grep. `runner-log --paint` is the same filter over
+  stdin, so `tail -f any.log | runner-log --paint` works for a log read some
+  other way.
+
+## 0.3.19
+
+**Upgrading:** `bundle update mcptask-rails-runner` in each project for the
+wrapper change, and `mcptask_runner update --self` on each host for the binary
+ones — the installed copy is per machine, so the project bump alone does not
+change what the 08:00 job runs. Both binary changes below are prompt text sent
+to the child, so they take effect on the next run the updated binary starts;
+there is nothing to migrate.
+
+- The line `Binary.install!` prints just before it hands over with `exec` is
+  coloured like everything the binary prints after it: green for a first
+  install and for the same version laid down again, yellow for replacing an
+  older copy, for keeping a newer one, and for `MCPTASK_RUNNER_BIN` diverting
+  the install. Until now it was the last grey line on the screen, sitting in
+  front of a coloured wall and looking like the least important thing there
+  while being the only line that reports a binary was replaced.
+
+  The palette is a deliberate copy of the binary's own rather than a second
+  opinion — `MCPTASK_RUNNER_COLOR` first and winning both ways, then
+  `NO_COLOR`, then `TERM=dumb`, then whether the stream is a terminal, and on
+  Windows the terminal has to advertise ANSI. Both halves of
+  `rake mcptask_runner:update` now answer that question the same way, and a
+  redirect or a pipe still gets exactly the bytes it got before.
+
+Binary changes carried by this version:
+
+- Every numbered workflow step that does real work now carries its own "LOG
+  PROGRESS NOW" line, and each one names the `TaskUpdate` that closes the same
+  step's todo item. A run on 2026-08-25 opened its pull request having logged
+  nothing at all, while its plan moved on the dashboard the whole time: three
+  anchors sat on the auto-squash spine, the seven steps between them said
+  nothing about logging, and the three manual workflows had no anchor anywhere
+  — only the block that sits past the last numbered step, which is the
+  arrangement already known not to get read. Hanging the log on the call the
+  child does make reliably is what ties the effort trail to the plan.
+- The child is told to search inside the project directory and never to run
+  `find /` or `find ~`. That walk enters macOS's protected folders, and the
+  permission dialog it raises names mcptask_runner and blocks the call until it
+  times out — at 08:02 there is nobody there to answer it. The instruction
+  names where to look instead: `bundle show` / `gem which` for Ruby, `go env
+  GOMODCACHE` for Go.
+
+## 0.3.18
+
+No wrapper changes. Full notes in
+[mcptask-releases v0.3.18](https://github.com/jchsoft/mcptask-releases/releases/tag/v0.3.18).
+
+**Upgrading:** run `mcptask_runner update --self` on each host. Both changes
+below are binary behaviour, and the first of them is visible in the output of
+the very command that installs it — so the run that replaces the binary is
+still grey, and every run after it is not.
+
+Binary changes carried by this version:
+
+- The install and update output is coloured, so the one row that needs a look
+  no longer reads exactly like the thirty that do not: green for up-to-date
+  and added, yellow for updated and force-updated, red for conflict-skipped,
+  dimmed section tags, and warnings in red on stderr. It is decided per stream
+  and only when the stream is really a terminal, so a pipe, a redirect and a
+  launchd log get the bytes they always got; `MCPTASK_RUNNER_COLOR` and
+  `NO_COLOR` override.
+- A child's process group is remembered when the child starts, so anything it
+  leaves behind is still reachable after it exits. A process group outlives
+  its leader, but the kernel can no longer name that group once the leader has
+  been reaped — and the kill path used to ask at kill time, get nothing, and
+  signal a bare pid that no longer resolved. Anything a child started and then
+  exited on went on running: a dev server, a backgrounded command, a watcher.
+  Nothing raised, so nothing ever reported it. This had shipped in every
+  version of the runner there has ever been.
+
+## 0.3.17
+
+No wrapper changes, and no entry was written here at the time. Full notes in
+[mcptask-releases v0.3.17](https://github.com/jchsoft/mcptask-releases/releases/tag/v0.3.17).
+
+Nothing an operator can observe changed in the binary either. The release
+carried one refactor — the event stream's assignment callback moved to a
+setter so that a caller supplying its own stream gets it too — which leaves
+production behaviour identical and exists so the path cannot break silently
+under test. Everything else in it was the chaos stress harness, which does not
+ship in the binary.
+
 ## 0.3.16
 
 No wrapper changes. Full notes in

data/README.md

@@ -91,6 +91,15 @@ Go binary as-is. The only legacy task without a counterpart is
 `verbose=true` and `ignore_quota=true` environment variables are honored by
 the binary itself, exactly as before.
 
+`install` and `update` print one line before handing the process over, and it
+is coloured the way the binary colours everything after it: green when the
+install left the machine where it already was, yellow when a binary the host
+was running has just been replaced or when the version on disk was kept
+instead. Only at a terminal — a pipe, a redirect and CI get the plain text
+they always got. `NO_COLOR` turns it off, and `MCPTASK_RUNNER_COLOR` (`1` /
+`0`) answers it either way, ahead of `NO_COLOR`. The binary reads the same two
+variables.
+
 ## Supported platforms
 
 Platform gems exist for `arm64-darwin`, `x86_64-darwin`, `aarch64-linux`,

data/lib/mcptask_rails_runner/binary.rb

@@ -86,10 +86,12 @@ module McptaskRailsRunner
     # versions and one installed binary, so a project pinning an older gem must
     # not quietly drag the machine's runner backwards.
     def install!(install_dir: INSTALL_DIR, gem_root: GEM_ROOT, out: $stdout)
+      paint = Palette.for(out)
+
       override = ENV["MCPTASK_RUNNER_BIN"]
       unless override.nil? || override.empty?
-        out.puts "[mcptask_runner] MCPTASK_RUNNER_BIN is set — running #{override} " \
-                 "and leaving #{installed_path(install_dir: install_dir)} alone."
+        out.puts paint.changed("[mcptask_runner] MCPTASK_RUNNER_BIN is set — running #{override} " \
+                               "and leaving #{installed_path(install_dir: install_dir)} alone.")
         return override
       end
 
@@ -98,14 +100,20 @@ module McptaskRailsRunner
 
       existing = installed_version(target)
       if existing && existing > Gem::Version.new(VERSION)
-        out.puts "[mcptask_runner] #{target} already holds #{existing}, which is newer than this " \
-                 "gem's #{VERSION} — keeping it. Delete that file to install this gem's binary instead."
+        out.puts paint.changed("[mcptask_runner] #{target} already holds #{existing}, which is newer than " \
+                               "this gem's #{VERSION} — keeping it. Delete that file to install this " \
+                               "gem's binary instead.")
         return target
       end
 
       copy(source, target)
-      out.puts "[mcptask_runner] installed mcptask_runner #{VERSION} into #{target}" \
-               "#{existing ? " (replacing #{existing})" : ''}."
+      # Green when this leaves the machine where it already was — a first
+      # install, or the same version laid down again. Yellow when a binary the
+      # host was running has just been replaced, which is the one line of this
+      # command worth stopping on.
+      line = "[mcptask_runner] installed mcptask_runner #{VERSION} into #{target}" \
+             "#{existing ? " (replacing #{existing})" : ''}."
+      out.puts(existing && existing < Gem::Version.new(VERSION) ? paint.changed(line) : paint.ok(line))
       target
     end
 

data/lib/mcptask_rails_runner/palette.rb

@@ -0,0 +1,80 @@
+# frozen_string_literal: true
+
+module McptaskRailsRunner
+  # Colour for the lines this gem prints before it hands the process over.
+  #
+  # `rake mcptask_runner:update` opens with Binary.install!'s line, and
+  # everything after it comes from the Go binary, which since 0.3.18 colours its
+  # own output by meaning: green when there was nothing to do, yellow when
+  # something moved, red when something is waiting on a decision. A grey first
+  # line in front of that wall reads as the least important thing on the screen,
+  # when it is in fact the only one that replaced a binary.
+  #
+  # The rules here are copied from internal/install/color.go in the Go repo
+  # rather than invented — same colours, same two environment levers, same "a
+  # terminal and nowhere else". Two halves of one command that disagreed about
+  # what NO_COLOR means would be a puzzle, not a feature.
+  class Palette
+    RESET  = "\e[0m"
+    GREEN  = "\e[32m"
+    YELLOW = "\e[33m"
+
+    # Values of MCPTASK_RUNNER_COLOR that settle the question, either way.
+    FORCE_ON  = %w[1 true always force].freeze
+    FORCE_OFF = %w[0 false never].freeze
+
+    # Terminals that turn escape codes on for themselves and say so. A Windows
+    # console renders them only once virtual-terminal processing is switched on
+    # for its handle, and this gem is not going to call into Win32 for a
+    # convenience — so anything not on this list gets plain text, and
+    # MCPTASK_RUNNER_COLOR=1 is the way in for a console the list has not heard
+    # of.
+    WINDOWS_ANSI_HINTS = %w[WT_SESSION ANSICON ConEmuANSI TERM].freeze
+
+    # for decides how one stream should be written to.
+    def self.for(out, env: ENV)
+      new(enabled: enabled?(out, env))
+    end
+
+    # MCPTASK_RUNNER_COLOR is asked first and wins both ways, because it is the
+    # specific answer: whoever set it knows where this output is going. NO_COLOR
+    # is the general convention (no-color.org) — present and non-empty means no
+    # colour, from anything.
+    def self.enabled?(out, env)
+      specific = env["MCPTASK_RUNNER_COLOR"].to_s.downcase
+      return true if FORCE_ON.include?(specific)
+      return false if FORCE_OFF.include?(specific)
+      return false unless env["NO_COLOR"].to_s.empty?
+      return false if env["TERM"] == "dumb"
+      return false unless out.respond_to?(:tty?) && out.tty?
+
+      Gem.win_platform? ? WINDOWS_ANSI_HINTS.any? { |name| !env[name].to_s.empty? } : true
+    end
+
+    def initialize(enabled:)
+      @enabled = enabled
+    end
+
+    def enabled?
+      @enabled
+    end
+
+    # ok — this is the state you wanted; nothing to read closely.
+    def ok(text)
+      wrap(GREEN, text)
+    end
+
+    # changed — something moved, or what you assumed would happen did not.
+    def changed(text)
+      wrap(YELLOW, text)
+    end
+
+    private
+
+    def wrap(code, text)
+      return text unless @enabled && !text.empty?
+
+      "#{code}#{text}#{RESET}"
+    end
+  end
+end

data/lib/mcptask_rails_runner/version.rb

@@ -10,5 +10,5 @@ module McptaskRailsRunner
   # Binary::INSTALL_DIR. So the pin is per project and per foreground rake
   # invocation; the installed copy is per machine, and the newest binary any of
   # those projects offers is the one that stays.
-  VERSION = "0.3.18"
+  VERSION = "0.3.20"
 end

data/lib/mcptask_rails_runner.rb

@@ -14,6 +14,7 @@ module McptaskRailsRunner
   end
 end
 
+require_relative "mcptask_rails_runner/palette"
 require_relative "mcptask_rails_runner/binary"
 
 # Only inside a booted Rails app — rails/railtie needs active_support loaded,

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: mcptask-rails-runner
 version: !ruby/object:Gem::Version
-  version: 0.3.18
+  version: 0.3.20
 platform: ruby
 authors:
 - Josef Chmel
@@ -38,6 +38,7 @@ files:
 - lib/mcptask/rails/runner.rb
 - lib/mcptask_rails_runner.rb
 - lib/mcptask_rails_runner/binary.rb
+- lib/mcptask_rails_runner/palette.rb
 - lib/mcptask_rails_runner/railtie.rb
 - lib/mcptask_rails_runner/version.rb
 - lib/tasks/mcptask_runner.rake