kairos-chain 3.92.0 → 3.94.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3cea3a83409113bb9513f6da35f8e202ed84762f726997b55d4c0807e3764565
-  data.tar.gz: e88354debd6836834ffcf28b905f361b4e9d0d154d22d68f6112a20076fc45c1
+  metadata.gz: 05055bfa3f7c4377e2e88011754c85d8d87c690e07f19837c4dca5a0c1cd033c
+  data.tar.gz: 48b9c8a70d27304e21293440f121ec069cb0c7ec47ed41b01573cdd2e3c80505
 SHA512:
-  metadata.gz: 811debe565ba6b2815b24860edc7d43a1cec1f3c0da9a8b4d4aed0c52d88052ddbd8f53b544575b253860da2ad669d197f9c5a105ffdc08a8d8e9fb002aade2b
-  data.tar.gz: 9682dc5d58a0264960323374db889ad4074e0c063685a0062866e811ec04eb1c91a94fef720a4260b58f69d26f12f9640087213c713dc8c9c1438fb0f836089f
+  metadata.gz: '08ee4ff5f61407bdcc390eb8c4cda6c286472672a6549ded81d5d0b1c7cf29f8203a472f9cfa5d4cfc811b1b8d923d4ee77ee6746decad1893a33c01187ecc1e'
+  data.tar.gz: 0b94dde53ddce2444defb9933515dda0d4e754bb0e6053129927d82032bdb9b73383b5d67234a9b57f3e003e82e1b004c17c94f6e551a45ba2fc5dca412bd340

data/CHANGELOG.md

@@ -4,6 +4,105 @@ All notable changes to the `kairos-chain` gem will be documented in this file.
 
 This project follows [Semantic Versioning](https://semver.org/).
 
+## [Unreleased]
+
+## [3.94.0] - 2026-10-20
+
+### Added — L0 changes proposed for later approval, L0 restores on the record, L1 body history
+
+- **L0 proposals.** `skills_evolve` keeps a pending L0 change as (base, result,
+  content) without evaluating it; `command: "pending"` lists the proposals and
+  `apply` takes a `proposal_id`. Applying writes exactly the stored bytes under
+  an exclusive lock, only while the base is still the L0 in force and the
+  content hashes to its result. A failed load, an interrupt or a killed thread
+  never leaves an unrecorded L0 on disk.
+- **L0 restore on the record.** `skills_rollback` restores a snapshot only if
+  its hash appears in a transition recorded on the chain. Without
+  `approved: true` it writes nothing and returns a pending proposal; with
+  `proposal_id` the approval applies exactly the proposal that was shown.
+- **L1 body history.** `knowledge_update` gains `history`, `restore` and
+  `erase_body` (the last is irreversible and needs `approved: true`). Bodies
+  are kept by content address from a recorded activation point, and restore and
+  erasure decide from the chain whether their record landed.
+
+### Changed — read before upgrading
+
+- `VersionManager.rollback` is removed; nothing shipped calls it. Code that
+  called it should use `skills_rollback` with a `proposal_id`.
+- `chain_import` never overwrites an existing chain: it is refused when the
+  target already holds chain data. Import into a new data directory instead.
+
+## [3.93.0] - 2026-10-19
+
+### Added — `proactive_tutorial`, an opt-in mode that suggests KairosChain's own workflow
+
+Claude Code passes only the head of an MCP server's instructions to the model
+(4,096 characters by default, 2,048 in older builds). Until a mode is projected
+into CLAUDE.md, the `tutorial` mode's "Proactive Tool Usage" section (line 82 of
+309) never reaches the model.
+
+- New shipped mode `proactive_tutorial`. Its first section, which fits inside
+  the 2,048-character cap after the first-run hint, has the model offer to save
+  L2 contexts, promote L1 knowledge, tidy up (`dream_scan`, `skills_audit`),
+  run multi-LLM review on hard-to-undo changes, point at installed skills, and
+  draft a project mode once L1 shows a theme (or, in the first session, the
+  project has docs). Writes happen only after the user says yes. Switch with
+  `instructions_update(command: "set_mode", mode_name: "proactive_tutorial")`;
+  the default stays `tutorial`. Existing instances receive the file on the next
+  `system_upgrade`.
+- `instructions_update set_mode` now warns when CLAUDE.md still imports a mode
+  body projected for a different mode, and names the command that fixes it
+  (`kairos-chain mode project`, or `kairos-chain mode remove` for `none`).
+
+### Fixed — projected hooks run against the data directory they were projected from
+
+A project whose `.mcp.json` starts kairos-chain with another project's data
+directory (`--data-dir /…/KairosChain_2026/.kairos` in GenomicsChain_2025; 16
+projects on the reporting machine point at that one directory) got the shared
+directory's SkillSet hooks projected into its own `.claude/settings.json`. Each
+hook resolved its script as `${KAIROS_DATA_DIR:-$CLAUDE_PROJECT_DIR/.kairos}/…`
+with `KAIROS_DATA_DIR` unset, so it looked in the wrong project:
+model_provenance failed with `LoadError` on every Stop, SubagentStop and model
+switch (46 times across two sessions, 2026-10-06 and 10-18) and observed
+nothing; project_manager's session-start report failed the same way. A harness
+tells a hook where the project is, never where the data directory is.
+
+- When the data directory is not `<project root>/.kairos`, PluginProjector now
+  prefixes every projected hook command with the pair it projected from:
+  `export KAIROS_DATA_DIR=<dir> KAIROS_PROJECT_ROOT=<root>;`, shell-escaped.
+  The project root goes with it because `kairos-plugin-project` otherwise falls
+  back to the data dir's parent — the other project — when the hook's working
+  directory is not a plausible root. The two are always set together: the
+  agent SkillSet hands children both as a pair, and half a pair cross-wires a
+  re-projection. The default layout is projected exactly as before, and
+  hand-written hooks are never touched.
+- Plugin mode is left as declared: `hooks/hooks.json` is distributable, and a
+  data directory on the projecting machine means nothing on the consumer's.
+- `system_upgrade` and `kairos-chain upgrade` re-projected without `data_dir:`,
+  so in a project sharing a data directory they wrote the hooks as if it were
+  local and dropped the fix until the next server start; both now pass it.
+- The Codex host's `--host` rewrite now applies only to what follows the pinned
+  prefix, so a data-directory or project path containing `kairos-plugin-project`
+  or `--host` is never rewritten.
+- No SkillSet changes: model_provenance and project_manager keep their bare
+  `ruby` commands, which run under whatever Ruby the project selects. A gem
+  executable would not: under rbenv a project pinned to another Ruby (two of the
+  16 above run 3.3.7 / 3.3.10) cannot find it.
+
+To pick this up, install this gem under the Ruby each project's MCP server runs
+on — for most projects the usual one; for a project whose `.ruby-version` or
+`.mcp.json` command selects another Ruby, that Ruby too — then restart the
+project's session so projection runs again.
+
+### Added — llm_client 0.2.2: `llm_call` reports the model ID it asked for
+
+The success payload gains `requested_model` (the per-call `model` override, else
+the configured `model`) beside `model` (what the provider answered with). On
+Bedrock the two differ — `eu.anthropic.claude-sonnet-5-5` is sent and
+`claude-sonnet-5-5` comes back — and only the first names the inference profile,
+and with it the region. gc_tier1_assess records it in a report's
+`assessor_stack.llm.model_requested`. Additive; no field changed or removed.
+
 ## [3.92.0] - 2026-10-13
 
 ### Added — agent: judgment precedents the shadow judge reads, distilled from your answers

data/bin/kairos-chain

@@ -187,7 +187,9 @@ when 'skillset'
           require 'kairos_mcp/plugin_projector'
           project_root = KairosMcp.project_root
           mode = KairosMcp.projection_mode
-          projector = KairosMcp::PluginProjector.new(project_root, mode: mode)
+          # data_dir: see system_upgrade.rb — the projector must know where the
+          # SkillSets live, or a shared data dir is projected as if it were local.
+          projector = KairosMcp::PluginProjector.new(project_root, mode: mode, data_dir: KairosMcp.data_dir)
           enabled = manager.enabled_skillsets
           knowledge = KairosMcp.collect_knowledge_entries
           if projector.project_if_changed!(enabled, knowledge_entries: knowledge)

data/lib/kairos_mcp/kairos_chain/landed_probe.rb

@@ -0,0 +1,62 @@
+# frozen_string_literal: true
+
+require 'json'
+require_relative 'chain'
+
+module KairosMcp
+  module KairosChain
+    # Answers "did this exact entry reach the ledger?" after an append did not
+    # return normally.
+    #
+    # Chain#add_block raises Storage::Error when it cannot tell whether the
+    # write landed, and a thread can be interrupted after the write but before
+    # add_block returns. Either way the caller holds a change it must keep
+    # (the record is on the chain) or undo (it is not). Looking only at the last
+    # block answers wrongly once anything else has been appended since, so the
+    # caller takes a mark before appending and the probe scans every block after
+    # that mark for an entry equal to the one the caller tried to append.
+    module LandedProbe
+      # The ledger length now, i.e. the index from which the caller's block can
+      # appear. nil when the ledger cannot be read; every later status is then
+      # :unknown.
+      def self.mark(storage_backend: nil)
+        chain = Chain.new(storage_backend: storage_backend)
+        case chain.load_state
+        when :readable then chain.chain.length
+        when :absent then 0
+        end
+      rescue StandardError
+        nil
+      end
+
+      # :landed  -- a block after the mark carries an entry equal to entry_json
+      # :absent  -- the ledger is readable (or absent) and no such entry is there
+      # :unknown -- the mark or the ledger could not be read
+      #
+      # Equality is on the parsed entry, so a backend that re-serialises the JSON
+      # still matches. Only StandardError is absorbed: an interrupt during the
+      # probe propagates, and callers run their undo in an ensure for that case.
+      def self.status(mark, entry_json, storage_backend: nil)
+        return :unknown if mark.nil?
+
+        expected = JSON.parse(entry_json)
+        chain = Chain.new(storage_backend: storage_backend)
+        return :absent if chain.load_state == :absent
+        return :unknown unless chain.load_state == :readable
+
+        found = chain.chain.drop(mark).any? do |block|
+          Array(block.data).any? do |raw|
+            begin
+              JSON.parse(raw.to_s) == expected
+            rescue JSON::ParserError
+              false
+            end
+          end
+        end
+        found ? :landed : :absent
+      rescue StandardError
+        :unknown
+      end
+    end
+  end
+end