okf-mcp 1.2.1 → 1.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 44ae2c50c714bc127ac861756a46e998d20f4310c77165ddcb616f7600c75517
-  data.tar.gz: 9fec8976e46b7bbe983bd0261eba453a4b25c700dcde8085df36f7a0df3f924a
+  metadata.gz: e3ca85c635fb0dda3d4fc64a1b0b88aa112ea2e246502c79642c31e21b1921bb
+  data.tar.gz: 6a142dfd2a4de4a91691433d42f20b7cbe64bcd98007f96a1c9a371e57612ad9
 SHA512:
-  metadata.gz: 7989702891ac272f637306102cadbd68f9e14f458b5cf81b373b681e3f9a8970fc248526f65038c449d498508820e143a2c9795b074ce456e3372882fd51889a
-  data.tar.gz: 0a9f01ba82b4bf10592c23666051617f9be55f80848925cbd029a8ad7e42753d3f597491ea71e45f2a97c817c6d8acbf9203890d4b7afd28a17a6dd4c526207a
+  metadata.gz: cfecb3ac8b7238c6b3f331d0fc8edfcc43d9331339361c4c3f854213e0b2c8731a69471beeac2180b0f5966ea3503876c9d85cc493cc6b28a834c9128f65dd05
+  data.tar.gz: 2bd9dcfccb2039033342258f4a733cc8de081b5338680f1d9501c1095577651c49813b9139a8042e8c19235ebe9d6c26945385e37fb071a13b85ca87aa37a9ed

data/.okf/design/the-tool-set.md

@@ -119,6 +119,24 @@ widen. A file that cannot be read or parsed keeps the last good set *without*
 latching its stamp, so a transient truncation is survived rather than made
 permanent until restart.
 
+**The stamp watches every file the registry reads, not just its own.** okf's
+registry can `link` another registry file, and that file's bundles resolve into
+the served set — so a stamp over one path meant an `okf registry set` in the
+linked file was never seen, and this server kept answering about the set it
+booted with. That is the same silent wrong answer the rule above exists to
+refuse, arriving through a second door. The link list comes from the kernel, so
+adding or dropping a link moves the first path's stamp and the next pass watches
+the new set; nothing has to be registered here.
+
+The two kinds of file are watched under **different rules**, and the asymmetry is
+the whole of it. This server's own registry going unreadable answers `nil`, which
+holds the last good set — the paragraph above. A linked file is a pointer's
+target, and okf already treats a missing one as *resolves to nothing, reported*;
+following that here means a vanished target drops its bundles rather than
+freezing them. Riding out an error and following a state change are different
+jobs, and one stamp had to do both.
+<!-- rule:okf-mcp-stamp-watches-links -->
+
 Four consequences of that rule had to be chased down after it landed. Two are
 the same mistake in different clothes — **something else was still a boot
 snapshot** — and two are what a *movable* served set costs a cache that was

data/.okf/log.md

@@ -1,5 +1,27 @@
 # Update Log
 
+## 2026-08-21
+
+* **The freshness stamp watches every file the registry reads** —
+  [the tool set](design/the-tool-set.md). okf's registry can now `link` another
+  registry file, and that file's bundles resolve into the served set; the stamp
+  still stat'd this server's own file alone, so an `okf registry set` over there
+  moved nothing it watched and a long-running server kept answering about the
+  set it booted with. That is the silent wrong answer the stamp exists to
+  prevent, arriving through a second door. The two kinds of file keep **different
+  rules**: this server's own registry going unreadable holds the last good set,
+  because a file caught mid-write must not empty what is being served, while a
+  linked target that vanishes drops its bundles — okf already reports a missing
+  one as resolving to nothing, and following that beats freezing it. Riding out
+  an error and following a state change are different jobs, and one stamp had to
+  do both.
+
+* **`list_bundles` names the linked groups too.** They were resolvable as a
+  `bundle` argument and absent from the listing, because okf split them into a
+  second method — an agent could open `@brain` and never learn it existed. The
+  kernel folded them back into `groups_listing`, so this needed no change here
+  beyond the `link` key now on each row.
+
 ## 2026-08-19
 * **Addition**: **okf-mcp has a knowledge bundle, and `AGENTS.md` now relies on
   it** — [structure](structure/), [capabilities](capabilities/),

data/CHANGELOG.md

@@ -5,6 +5,42 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.3.0] - 2026-08-22
+
+### Fixed
+
+- **A long-running server now sees writes inside a *linked* registry.** okf gained
+  `okf registry link`, which folds another registry file's bundles into the served
+  set; the freshness stamp still watched only this server's own registry file, so
+  an `okf registry set` in the linked file never moved it and the server kept
+  answering about the set it booted with. The stamp now covers every file the
+  registry reads. The link list comes from the kernel, so adding or dropping a
+  link moves the first path's stamp and the next pass watches the new set.
+
+  The two kinds of file keep different rules. This server's own registry going
+  unreadable still answers `nil` and holds the last good set — a file caught
+  mid-write must not empty what is being served. A linked file is a pointer's
+  target, and okf already reports a missing one as resolving to nothing, so a
+  vanished target drops its bundles instead of freezing them.
+
+### Changed
+
+- **The `mcp` floor moves to `~> 1.3`.** `Gemfile.lock` is not committed, so the
+  suite resolves the newest SDK the requirement admits and proves itself against
+  that one; the floor tracks what the suite proves, and 1.3.0 shipped. Nothing in
+  this gem changed for it — all 324 tests pass against 1.3.0 — but a floor that
+  admits an SDK the suite never ran against is the claim the floor test exists to
+  refuse.
+
+- **The `okf` floor moves to 2.2.0**, the kernel that ships `registry link` and
+  `Registry#links_listing`. The stamp reads that method, and against 2.1.1 every
+  refresh would raise NoMethodError straight past the SystemCallError rescue.
+  `rake verify_okf_floor` gates `release` on exactly this and now passes.
+
+- `list_bundles` groups now carry a `link` key — `null` for a group this registry
+  owns, the link's name for one that arrived through a link (okf ≥ 2.2). Linked
+  groups were already resolvable as a `bundle` argument and are now listed too.
+
 ## [1.2.1] - 2026-08-20
 
 ### Fixed

data/README.md

@@ -77,8 +77,9 @@ bundles only when the registry itself is what is being served.
 
 With no arguments the registry *is* what is served, so it is followed rather
 than snapshotted: `okf registry set`, `rename` or `del` in another terminal
-shows up on the next tool call, without a restart. The file is re-read only
-when its fingerprint moves, so the cost is a `stat`. Bundle contents are never
+shows up on the next tool call, without a restart. A write inside a registry the
+first one *links* counts too. The files are re-read only when a fingerprint
+moves, so the cost is a `stat` each. Bundle contents are never
 snapshotted either — bodies are read live, and a bundle is re-parsed whenever
 one of its files changes.
 

data/lib/okf/mcp/registry.rb

@@ -15,7 +15,7 @@ module OKF
     # names a registered bundle or group, whose slug is reserved before any
     # plain-dir basename is deduped — the server verb's rule). No argv means
     # the active kernel registry, resolved exactly as the CLI resolves it:
-    # a project-local .okf-registry.json discovered from cwd, else
+    # a project-local .okf.json discovered from cwd, else
     # $OKF_HOME/registry.json, OKF_NO_DISCOVERY=1 forcing global.
     class Registry
       # One served bundle: the +slug+ tools name it by, its absolute +root+ on
@@ -297,10 +297,34 @@ module OKF
       # mtime *and* size, the pair the residency layer already uses: a second
       # write inside one filesystem timestamp tick moves the size when it does
       # not move the clock.
+      #
+      # Every file the registry reads, not just its own. A link puts bundles in a
+      # second file, and watching only the first meant a `registry set` over there
+      # was never seen: this server would keep answering about the set it booted
+      # with, which is the one failure a stamp exists to prevent. The link list
+      # itself comes from the kernel, so adding or dropping a link moves the first
+      # entry and the next pass watches the new set.
+      # The two files are watched under different rules, and the asymmetry is the
+      # point. This server's *own* registry going unreadable answers nil, which
+      # holds the last good set — a file caught mid-write must not empty what is
+      # being served. A *linked* file is only a pointer's target, and the kernel
+      # already treats a missing one as "resolves to nothing, reported", so its
+      # absence is a state change to follow rather than an error to ride out.
       def registry_stamp
         return nil if @kernel.nil?
 
-        stat = ::File.stat(@kernel.path)
+        own = file_stamp(@kernel.path)
+        return nil if own.nil?
+
+        [ own ] + @kernel.links_listing.map { |row| file_stamp(row[:registry]) }
+      rescue OKF::Error, SystemCallError
+        nil
+      end
+
+      # nil for a file that is not there — a state in its own right for a link, so
+      # a target appearing or vanishing moves the stamp exactly as an edit does.
+      def file_stamp(path)
+        stat = ::File.stat(path)
         [ stat.mtime.to_f, stat.size ]
       rescue SystemCallError
         nil

data/lib/okf/mcp/version.rb

@@ -2,6 +2,6 @@
 
 module OKF
   module MCP
-    VERSION = "1.2.1"
+    VERSION = "1.3.0"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: okf-mcp
 version: !ruby/object:Gem::Version
-  version: 1.2.1
+  version: 1.3.0
 platform: ruby
 authors:
 - Rodrigo Serradura
@@ -15,21 +15,21 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.2'
+        version: '1.3'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.2'
+        version: '1.3'
 - !ruby/object:Gem::Dependency
   name: okf
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 2.1.1
+        version: 2.2.0
     - - "<"
       - !ruby/object:Gem::Version
         version: '3'
@@ -39,7 +39,7 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 2.1.1
+        version: 2.2.0
     - - "<"
       - !ruby/object:Gem::Version
         version: '3'