mcptask-rails-runner 0.3.11-aarch64-linux → 0.3.12-aarch64-linux
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/CHANGELOG.md +51 -0
- data/lib/mcptask_rails_runner/version.rb +1 -1
- data/libexec/mcptask_runner +0 -0
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 9bf7f3f10628428ab5584bba14821cab58162fec31e19b4ade4b37bb401ea376
|
|
4
|
+
data.tar.gz: '08f94cde2bc019035ba01d61416431f864c0b8dc345a8fe825641924c196a395'
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: ab5c73e793fdcbfa37dcaa55c9c3bbc292d0b9e9fdbfd3be69659995ff24898d977469db06aa4a5e345f7550adfc5f8cd99604402d7c44c86847445b107aa3c9
|
|
7
|
+
data.tar.gz: d424ccb262b5b1dc1ea82d3bd965f43b99f627d179bcd50ebd0dde8d9b6c497786fcfe2763315299d4100f950b4103cbd1fe3d4b0a4c94036ea82fd2f5bc37b5
|
data/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,57 @@ entries below describe wrapper changes only. Binary changes are listed in the
|
|
|
5
5
|
[mcptask-releases](https://github.com/jchsoft/mcptask-releases/releases)
|
|
6
6
|
release notes for the same tag.
|
|
7
7
|
|
|
8
|
+
## 0.3.12
|
|
9
|
+
|
|
10
|
+
No wrapper changes. Full notes in
|
|
11
|
+
[mcptask-releases v0.3.12](https://github.com/jchsoft/mcptask-releases/releases/tag/v0.3.12).
|
|
12
|
+
|
|
13
|
+
**Upgrading:** run `mcptask_runner update` in each project after the binary
|
|
14
|
+
upgrade. Nothing does it for you, so without that step the fixes below stay
|
|
15
|
+
installed nowhere — the helpers in `~/.claude/bin` and the skills in each
|
|
16
|
+
project's `.claude/skills/` keep whatever version they already had. No `--force`
|
|
17
|
+
is needed, including on hosts whose skills carry a rewritten model name.
|
|
18
|
+
|
|
19
|
+
- **The guard against running the test suite directly had stopped guarding.**
|
|
20
|
+
`check_test_lock` refuses a direct `bin/ci` while another agent's suite holds
|
|
21
|
+
the global lock. It looked for pidfiles in a flat directory that nothing has
|
|
22
|
+
written in a long time, so its "pidfile missing and the lock is over ten
|
|
23
|
+
seconds old" check matched every lock there has ever been: each one read as
|
|
24
|
+
stale and the command went through. The guard worked for the first ten seconds
|
|
25
|
+
of a lock's life and never again. The path is now rebuilt from the lock's own
|
|
26
|
+
project, the way the shell helper beside it already did it. A lock that names
|
|
27
|
+
no project is no longer guessed to be dead either — a holder that cannot be
|
|
28
|
+
located is not a holder that can be verified.
|
|
29
|
+
|
|
30
|
+
- **The refusal now says what to do instead.** Declining to touch a lock owned
|
|
31
|
+
by another working directory was correct for a live one and a dead end for a
|
|
32
|
+
dead one, and a prohibition with nowhere to go is what got the lock bypassed
|
|
33
|
+
in the first place: an agent told not to interfere ran the suite unlocked.
|
|
34
|
+
It now names the way out — a stale lock is reaped by `acquire` itself,
|
|
35
|
+
whatever directory owns it. Ownership also compares normalised paths, so the
|
|
36
|
+
same checkout reached through a symlink, a trailing slash or a subdirectory
|
|
37
|
+
stops looking foreign, while a linked worktree stays correctly distinct.
|
|
38
|
+
|
|
39
|
+
- **Two failures in taking the lock, both silent.** The directory that
|
|
40
|
+
serialises the moment of acquiring had no staleness handling, so an acquire
|
|
41
|
+
killed midway left it behind for good and wedged every later run behind a lock
|
|
42
|
+
reported as `unknown` — which the orchestrator cannot wait on, so it spun to
|
|
43
|
+
its retry cap and called the lock stuck while naming nothing to delete. And a
|
|
44
|
+
lockfile missing its `PID=` line killed `acquire` outright before the staleness
|
|
45
|
+
check could reap it, leaving a blank error and a malformed lock that every
|
|
46
|
+
retry hit again.
|
|
47
|
+
|
|
48
|
+
- **Bundled skills no longer declare a `model:`.** A model name written into
|
|
49
|
+
`.claude/skills/` can only be right for one backend, and that directory is
|
|
50
|
+
read by two: the runner's child process and whoever opens the same project in
|
|
51
|
+
a session of their own. Whichever way it was written it was wrong for one of
|
|
52
|
+
them, and wrong silently, because the CLI returns its model error as the
|
|
53
|
+
skill's own result and the agent above reads that as the answer. Each fork now
|
|
54
|
+
runs on its session's own model; `context: fork` is untouched, and that is
|
|
55
|
+
what actually keeps a fork's output out of the parent's context.
|
|
56
|
+
|
|
57
|
+
- **A SIGTERM is not a failed attempt, so the runner announces no retry.**
|
|
58
|
+
|
|
8
59
|
## 0.3.11
|
|
9
60
|
|
|
10
61
|
No wrapper changes. Full notes in
|
|
@@ -10,5 +10,5 @@ module McptaskRailsRunner
|
|
|
10
10
|
# Binary::INSTALL_DIR. So the pin is per project and per foreground rake
|
|
11
11
|
# invocation; the installed copy is per machine, and the newest binary any of
|
|
12
12
|
# those projects offers is the one that stays.
|
|
13
|
-
VERSION = "0.3.
|
|
13
|
+
VERSION = "0.3.12"
|
|
14
14
|
end
|
data/libexec/mcptask_runner
CHANGED
|
Binary file
|