kairos-chain 3.32.0 → 3.34.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c01be861d1c6a82ee12606f25c5526268351cd4353aa21cf00a0dcb28fc5ed30
-  data.tar.gz: 4f2cfd5edc74107aa944ba16a953d30935dca34141806bf3b3b71efe9ed84b51
+  metadata.gz: a393cfbac08011bdd6f7b8cd3129177f535c7507868215d6b85ef2af732e8521
+  data.tar.gz: 202af122d66197111412f5cdfc48287872713781602fe7f5f428ec40f3e111a9
 SHA512:
-  metadata.gz: a88518aa910493860251c66f0ecdc60ce2d39131626bf2b1e571a3d274560c5e2a876c3ccae6a165f73c1c706ca94022ee9f28369e88fea76e9010ad8f234e7d
-  data.tar.gz: 8fe7372a93fdbebe24b9bb6a57e9d2d464966840cfef2c35674319230a6ff05d66f27e6934484bf78b1c5a3fad55de7088639038126e95d1cece92ad1695b5ed
+  metadata.gz: 880c1f5206e0e84ab3b448abd25e5ec3a2fd012840a0f0f2b1d67bd8883fc54da27a945e451de3c2dfc96c36628658db625190b8a8ad8dd8796b1c5b7cbf2eb1
+  data.tar.gz: 4a2187976ddddc4e4a27ef51075f38ddeff13539f60c8928150bce1d3d97d607b6bb09aa327179569209ddcf440cae575b53b1460e5f9f350553d2760a6e4a7a

data/CHANGELOG.md

@@ -4,6 +4,51 @@ All notable changes to the `kairos-chain` gem will be documented in this file.
 
 This project follows [Semantic Versioning](https://semver.org/).
 
+## [3.34.0] - 2026-07-03
+
+### Added — L1 knowledge (dev repo): loop_validation
+
+New L1 knowledge entry `loop_validation` (v0.4), the mechanical loop-verdict
+methodology distilled from the Autonomous Growth Loop governance design
+(FROZEN v0.3.1, 3-round multi-LLM review) and its slice-1 implementation.
+Body-agnostic reference engine (`scripts/kairos_verdict.py`, fail-closed, no
+LLM), example spec, and an instance-local hermes body adapter appendix.
+Realizes candidate A of the loop-engineering keystone analysis. Frozen at
+v0.4 after 3 multi-LLM review rounds (6/6 unanimous R3); R1 caught a real
+engine crash on malformed specs (execution-verified), R2 caught a wrapper
+constant-key breach and a reason-taxonomy desync.
+
+Scoped to `knowledge/` (dev repo) only this release — NOT promoted to
+`templates/` (user distribution) because the hermes adapter appendix carries
+instance-local absolute paths. Promotion to `templates/` awaits proven use
+and path placeholder-izing.
+
+### Design (docs, not gem): Autonomous Growth Loop governance v0.3.1 FROZEN
+
+10 governance invariants for an unattended growth loop (evidence-grounded
+fail-closed verdict, dual stop floor, norm-change asymmetry, human-authored
+run mandate grounded at the human per Prop 9, execution-events-as-attestation
+vs Meta-Ledger-for-capability-changes). Design artifact under `docs/drafts/`.
+
+## [3.33.0] - 2026-07-03
+
+### Added — L1 knowledge: loop_engineering_patterns
+
+New gem-bundled L1 knowledge entry `loop_engineering_patterns` (v0.3), sibling
+of `skill_authoring_patterns` (same distill-an-Anthropic-post-through-layers
+method). Distills Claude Code's "Getting Started with Loops" into: §A four loop
+types (two axes: trigger × human presence), §B universal loop-design craft,
+§C KairosChain layer placement (harness vs gem/SkillSet) plus the cross-cutting
+Prop 10 procedural-floor reading that the source omits. Source text is not
+redistributed; a facts-only provenance pointer lives in `references/`.
+
+- Shipped to both `knowledge/` and `templates/knowledge/` (mirrors sibling).
+- `skill_authoring_patterns` Related gains a reciprocal sibling link.
+- Frozen after 2 multi-LLM review rounds (6-reviewer roster, delegate strategy).
+  R1 caught one genuine (a) factual error (`confidence_exit_threshold` wrongly
+  described as unwired — it is wired at agent_step.rb Gate 7) and one overstated
+  mechanism status; R2 narrowed to wording-precision findings, resolved in v0.3.
+
 ## [3.32.0] - 2026-07-03
 
 ### Added — multi-host SkillSet projection (Codex + OpenCode)

data/lib/kairos_mcp/version.rb

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

data/templates/knowledge/loop_engineering_patterns/loop_engineering_patterns.md

@@ -0,0 +1,49 @@
+---
+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]
+---
+
+# Loop Engineering Patterns
+
+Distilled from Claude Code's post [Getting Started with Loops](https://claude.com/blog/getting-started-with-loops) (Anthropic, 2026). Local provenance / facts index: `references/claude_code_loops_2026.md` (pointer; canonical text is the URL, not redistributed here). Sibling method: [[skill_authoring_patterns]] — same distill-an-Anthropic-post-through-KairosChain-layers move.
+
+## When to reference this entry
+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.
+- 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]].
+
+## A. Four loop types (base-level classification)
+Two axes generate the four types: **trigger** (user prompt / goal spec / schedule-or-event) and **human presence** (present / absent). The autonomous type is the no-human variant of the schedule/event trigger, not a fourth independent trigger — kept as a peer type here to mirror the source taxonomy.
+1. **Turn-driven** — trigger: user prompt; stop: task done or needs context; for short exploratory work.
+2. **Goal-driven** — trigger: goal spec (`/goal`); stop: goal met OR max turns; a separate evaluator checking exit criteria raises reliability; for tasks with verifiable exit.
+3. **Time-driven** — trigger: schedule/interval (`/loop`, `/schedule`); stop: user cancels or work done; for recurring work / external monitoring.
+4. **Autonomous** — trigger: events/schedule, no human present; stop: each task exits on goal, routine runs until disabled; for well-defined recurring streams (triage, migrations).
+
+Micro (small) and macro (broad) loops compose; match loop complexity to problem abstraction.
+
+## 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.
+
+## 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):
+
+| Type | KairosChain home | Existing mechanism (status) |
+|---|---|---|
+| Turn-driven | harness (Claude Code) | interactive session (shipped) |
+| Goal-driven | gem / SkillSet | `agent` OODA loop with explicit goal + max-step cap; goal-satisfaction judged from reflect-phase confidence/remaining, human-mediated stop (shipped). The *wired* auto-exit on confidence is the Autonomous row's Gate 7, not this path. |
+| Time-driven | harness / gem | harness: `/loop`, `/schedule`, ScheduleWakeup/Cron (shipped, harness-layer); gem: routines × autonomous-growth (design, not yet shipped) |
+| Autonomous | gem | `autonomos_cycle`/`loop`, `autoexec`, and the `agent` autonomous path — whose Gate 7 confidence early-exit (`confidence_exit_threshold`, wired in `agent_step.rb`) terminates on goal satisfaction (shipped) |
+
+**L0 (cross-cutting, not a per-type home):** the Prop 10 procedural floor binds every row — it is a governance constraint over all four types, not a home for any one. See the paragraph below.
+
+The article's craft maps onto existing mechanisms (illustratively, not as strict 1:1 equivalences): its "separate evaluator" for goal-driven ≈ the agent's reflect-phase confidence evaluation (Observe/Reflect), not `multi_llm_review`; "verification as skill" ≈ `introspection_check` / `definition_verify`; "second agent for review" ≈ `multi_llm_review` (independent session). These pre-exist; they are not new imports.
+
+**The governance floor Anthropic omits.** Every article loop optimizes for completion/throughput; none carries a consent/audit constraint. KairosChain adds a cross-cutting axis: **every loop, whatever its type, is bound by the Prop 10 procedural floor** — no loop may bypass consent, harm protection, or audit, and any autonomous norm must stay recordable and contestable. (Prop 10 is currently provisional/inline in masa mode, not yet promoted to L0; the floor it names is nonetheless the intended binding.) Concretely, the autonomous type's "run until disabled, no human present" cannot be adopted verbatim: KairosChain's autonomous loop carries human checkpoints and safety gates (the `agent` skill), and a stop is not a bare exit but a constitutively recorded Kairos moment (Prop 5). This floor is the KairosChain-specific delta — the article has no place for it because a weight-hosted assistant has no revisable governance surface. Consistent with (not proof of) masa mode's harness-as-cultivation-surface bet in [[skill_authoring_patterns]] §C.
+
+## Related
+[[skill_authoring_patterns]] · [[layer_placement_guide]] · [[agent_skill_evolution_guide]] (instance-local, not gem-bundled) · [[kairoschain_self_development]] · kairoschain_meta_philosophy (Prop 5 constitutive recording). Prop 10 procedural floor: current authoritative home is masa mode § Proposition 10 (inline, provisional); migration into L1/L0 is pending.

data/templates/knowledge/loop_engineering_patterns/references/claude_code_loops_2026.md

@@ -0,0 +1,23 @@
+# [Source pointer] Getting Started with Loops
+
+> **Provenance / 来歴**
+> - **Source (official):** https://claude.com/blog/getting-started-with-loops
+> - **Publisher:** Anthropic / Claude Code
+> - **Retrieved:** 2026-07-03
+> - **Companion:** JP video walkthrough ("【神記事】Claude Code 公式が遂に『ループエンジニアリング』を解説") — user-supplied summary; canonical URL not recorded.
+>
+> **This is a pointer, not a copy.** The article's text is Anthropic's
+> copyrighted content and is **not redistributed in this gem**. The canonical
+> source is the URL above.
+
+## What the source covers (facts, for indexing)
+
+**Four loop types:** turn-driven (trigger: user prompt; stop: task done or needs context) · goal-driven (`/goal`; stop: goal met OR max turns; a separate evaluator model checks exit criteria) · time-driven (`/loop`, `/schedule`; stop: user cancels or work done) · autonomous/proactive (events/schedule, no human present; each task exits on goal, routine runs until disabled).
+
+**Design principles:** maintain clean codebases; encode verification as skills with quantitative checks; keep documentation accessible/current; deploy a second independent agent for review. Micro/macro loops compose — match loop complexity to problem abstraction.
+
+**Operational notes:** bound cost with explicit success criteria + max-turn caps; script deterministic work rather than re-reasoning it; monitor spend (`/usage`, `/goal` metrics, `/workflows`); match scheduling interval to actual change frequency; auto mode removes manual permission for routine execution.
+
+**Slash examples:** `/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries` · `/loop 5m check my PR, address review comments, and fix failing CI` · `/schedule every hour: check #project-feedback for bug reports`.
+
+For the KairosChain reading through layers, see `loop_engineering_patterns.md` §A/§B/§C. For full prose, open the URL above.

data/templates/knowledge/skill_authoring_patterns/skill_authoring_patterns.md

@@ -44,4 +44,4 @@ The real difference is *where philosophy lives*: closed in the core (Anthropic)
 **Why this bet (operational vs decorative).** Harness-hosted norms are readable/recorded/revisable where weight-baked norms are opaque (Prop 10, provisional in masa.md) — arguably the right home even post-fine-tuning. Hiring a model ≠ cultivating one; the harness is the weight-less user's only cultivation surface. Norms must stay operational (hooks, introspection_check), not decorative (philosophy theater). Full dialogue: `references/why_harness_norms_bet.md`.
 
 ## Related
-[[agent_skill_evolution_guide]] · skillset_implementation_quality_guide · kairoschain_meta_philosophy (Prop 1; Prop 10 provisional in masa.md).
+[[agent_skill_evolution_guide]] · [[loop_engineering_patterns]] (sibling: same distill-an-Anthropic-post-through-layers method) · skillset_implementation_quality_guide · kairoschain_meta_philosophy (Prop 1; Prop 10 provisional in masa.md).

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: kairos-chain
 version: !ruby/object:Gem::Version
-  version: 3.32.0
+  version: 3.34.0
 platform: ruby
 authors:
 - Masaomi Hatakeyama
@@ -275,6 +275,8 @@ files:
 - templates/knowledge/llm_cross_evaluation/scripts/test_calibration_v23.rb
 - templates/knowledge/llm_cross_evaluation/scripts/test_intra_family_v23.rb
 - templates/knowledge/llm_cross_evaluation/scripts/test_layer_d_v23.rb
+- templates/knowledge/loop_engineering_patterns/loop_engineering_patterns.md
+- templates/knowledge/loop_engineering_patterns/references/claude_code_loops_2026.md
 - templates/knowledge/mcp_to_saas_development_workflow/mcp_to_saas_development_workflow.md
 - templates/knowledge/multi_agent_design_workflow/multi_agent_design_workflow.md
 - templates/knowledge/multi_agent_design_workflow_jp/multi_agent_design_workflow_jp.md