kairos-chain 3.42.1 → 3.42.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 7d6b5abadc2727f37c441c8d0442da6470438537ad47f387e6c4021769c678dd
-  data.tar.gz: f5c625947d73fb41251829cf638b397308294daa4fed7ed94cae945ad6086b72
+  metadata.gz: 45fd1079aa951da3ac40d0dcd9763e02c2a15413753d5452dab4fc07e928a3cb
+  data.tar.gz: 93e3969307c08b26782c81804c9b5b10c475407e4770962a04ec29ab227a7951
 SHA512:
-  metadata.gz: 4948c9a12280c2ccc7e0083e056d0ad99d457fcb11d86761f060a891d2033924395521364b5f867ca30eec2cc806f5d539ccc22282657c31e31a0695a5270f55
-  data.tar.gz: 789de8f265c7d1dbbde4969643e26f3359887b3417ddd76fe5567348b41c9dc8c37b2f062f6e77d382abc49becd4a2703ac4de29cf8d2f63b62c9fef272a5db1
+  metadata.gz: e0d95027c4457cb89a1dee063b3637dc568fce57735e2be211119ace92d684b42451b03b176887202bc2eb797d71cb49af9e3ca49f0e0e9e00689c88ff74c177
+  data.tar.gz: fd1ac48f63e671ce7df974bab3efd35e2f3af8b626aeba655f56d3bffa933903d269f3d5775ae877203f9ef3050c66c5a3d5cbf69811ec113b9f5235b35d6574

data/CHANGELOG.md

@@ -4,6 +4,29 @@ All notable changes to the `kairos-chain` gem will be documented in this file.
 
 This project follows [Semantic Versioning](https://semver.org/).
 
+## [3.42.2] - 2026-07-14
+
+### Knowledge — loop_engineering_patterns §B: Model/Effort budget allocation
+
+Extended the `loop_engineering_patterns` L1 entry (0.3 → 0.4) with a §B
+design-craft note distilled from Anthropic's *Model and Effort in Claude Code*
+post:
+
+- Model (intelligence ceiling) and effort (per-request thoroughness) are
+  distinct levers; raise model when logic/knowledge is the wall, raise effort
+  when the loop skips steps.
+- Because a loop compounds turns, uniform high effort multiplies latency —
+  concentrate high effort on the verify/judgment/decision gates, keep mechanical
+  dispatch turns low.
+- The lever is the *orchestrator's*; a worker in a separate process (hermes body
+  subprocess, `agent`-skillset step) carries its own config and is unaffected.
+- KairosChain delta: the non-bypassable gates (Prop 10 consent/audit floor,
+  INV-5 layer guard, verdict track) are where effort must not be cut — a stop
+  there is an irreversible Kairos moment (Prop 5), not a throughput step.
+
+Added the `effort-allocation` tag and a "high/low effort for a long run?"
+entry-point line. No code or behavior change.
+
 ## [3.42.1] - 2026-07-14
 
 ### Fixed — SectionWriter auto-chunk completeness & duplicate tail

data/lib/kairos_mcp/version.rb

@@ -1,4 +1,4 @@
 module KairosMcp
-  VERSION = "3.42.1"
+  VERSION = "3.42.2"
   CHANGELOG_URL = "https://github.com/masaomi/KairosChain_2026/blob/main/CHANGELOG.md"
 end

data/templates/knowledge/loop_engineering_patterns/loop_engineering_patterns.md

@@ -1,8 +1,8 @@
 ---
 name: loop_engineering_patterns
 description: Use before designing or classifying an agent loop in KairosChain — to pick a loop type, apply loop-design craft, and place each loop at the right layer under the Prop 10 floor. Claude Code's four loop types + design principles, extended with the governance constraint Anthropic omits.
-version: "0.3"
-tags: [loops, agent, autonomy, taxonomy, layer-placement, provenance]
+version: "0.4"
+tags: [loops, agent, autonomy, taxonomy, layer-placement, provenance, effort-allocation]
 ---
 
 # Loop Engineering Patterns
@@ -14,6 +14,7 @@ Open *before* designing or classifying an agent loop — not a runtime tool:
 - New agent loop / autonomous cycle → pick a §A type, apply §B craft, then place it via §C.
 - "Which layer owns this loop?" (harness vs gem/SkillSet, plus the cross-cutting L0 governance floor) → §C table + the L0 note below it.
 - Strengthening the `agent` OODA loop (self-verification, semantic stop) → §B + §C evaluator/verifier notes.
+- "High/low effort for a long run?" → §B budget-allocation note (concentrate effort on §C's non-bypassable gates).
 - Explaining why KairosChain's autonomous mode keeps human checkpoints → §C Prop 10 floor.
 - Not for: skill lifecycle/maturation → [[agent_skill_evolution_guide]]; general layer rules → [[layer_placement_guide]].
 
@@ -29,6 +30,8 @@ Micro (small) and macro (broad) loops compose; match loop complexity to problem
 ## B. Design craft (universal — adopt as-is)
 Output quality tracks the surrounding harness, not the model alone. Keep the codebase clean so the loop follows existing patterns. **Encode verification as a skill with quantitative checks** so the loop measures its own work. Keep docs accessible/current. **Use a second, independent agent for review** (fresh context, separate session/model). Set explicit success/stop criteria and max-turn caps to bound cost; script deterministic steps instead of re-reasoning them; monitor token spend.
 
+**Allocate reasoning budget by phase, not uniformly.** Model and effort are distinct levers ([Model and Effort in Claude Code](https://claude.com/blog/claude-model-and-effort-level-in-claude-code), Anthropic, 2026): model sets the intelligence ceiling — raise it when logic or knowledge is the wall; effort sets per-request thoroughness (files read, tests run, verification passes) — raise it when the loop skips steps, not when it lacks intelligence. Because a loop compounds turns, uniform high effort multiplies latency across every cycle: concentrate high effort on the verify / judgment / decision gates and keep mechanical dispatch turns low. Note this is the *orchestrator's* lever — it governs how carefully the loop monitors, verifies, and decides; it does not raise the quality of a worker running in a separate process (e.g. a hermes body subprocess or an `agent`-skillset step), which carries its own model/effort config. In KairosChain the non-bypassable gates — the Prop 10 consent/audit floor, the INV-5 layer guard, the verdict track — are exactly where effort must not be cut, since a stop there is an irreversible Kairos moment (§C, Prop 5), not a throughput step.
+
 ## C. KairosChain reading (layer placement + the floor Anthropic omits)
 The four types are harness-framed (`/goal`, `/loop`, `/schedule`, `/usage`, auto mode are Claude Code mechanisms). KairosChain already implements most of the substance across layers — so the work is mostly *placement*, not adoption; one item is still design-stage (flagged in the table):
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: kairos-chain
 version: !ruby/object:Gem::Version
-  version: 3.42.1
+  version: 3.42.2
 platform: ruby
 authors:
 - Masaomi Hatakeyama