kairos-chain 3.84.0 → 3.87.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1ebfc6fe1ff6c901c620512c56c698f6dca7bd058143e611547864a0a5460e29
-  data.tar.gz: caa3229fcb55a9f057a88be84a7a7694e514aff6e9b31ec5a8796d5e1ca93138
+  metadata.gz: eac563609de17554382bdd2a4c2a42b21040fd60f43c4702eea153eeb5d5806b
+  data.tar.gz: 0cbb9994501dc8bdf9333e13f15bd25bc5c45e68f83abf1066e860606bc1c18a
 SHA512:
-  metadata.gz: 91588bb7de5f9f211409c77e90ba688432415dae81a142341481201ea412d2769d597ed1d10382a726b7ef301fbfdda77439bfa7f27e870102a296f520957656
-  data.tar.gz: a7a9bd001776163b148e690508f6aa6f44639f01974f00da552f5264676f37f4a25a286c9acb6e502edd6c77f07f9c5de2afd963a6053a89a8d0999721bf55a4
+  metadata.gz: 4f41031abdbec48d77ed711a114a8be271321b4afee36e4a7b081550437afbf82b8a0a2aa91eba23fa3422873f8e5032202a00dc51a4cbb5758b72370a60d1dc
+  data.tar.gz: f0d09276a3259622de795ec1f7522e2b78af9c80c6934aa809195755f3fa8938d53996fbd1ab226e0884a5348383b92baf320a3c6c94e9d82ad94689d35cba87

data/CHANGELOG.md

@@ -4,6 +4,191 @@ All notable changes to the `kairos-chain` gem will be documented in this file.
 
 This project follows [Semantic Versioning](https://semver.org/).
 
+## [3.87.0] - 2026-09-24
+
+### Added — `model_provenance` SkillSet: which model actually answered
+
+Claude Code re-runs a request on another model when a safety classifier flags it
+(from Opus 5.5 and the Fable models: biology → Opus 5, cyber → Opus 4.8) and the
+session then stays on that model. The operator is told once in the main session and
+not at all for subagents, and the model that took over reads the same system prompt
+naming the model it replaced, so its account of itself cannot be trusted. Observed
+on 2026-09-24: an audit subagent answered 90 of 102 records on `claude-opus-5`, with
+nothing in its output saying so.
+
+`model_provenance` is hooks only (no MCP tools, no core change). It derives the
+answering model from what the harness recorded — per-response `message.model` and
+the transcript's `fallback` marker — never from what a model says:
+
+- **PostModelSwitch** records every model change; on `source: "auto"` it tells the
+  model which model it now is.
+- **SubagentStop** records the subagent's latest run. A run starts only at a message
+  from the coordinator or a peer; Skill bodies (`turnCompanion` records) and the
+  agent's own task notifications are not resumes.
+- **Stop** reads every finished response not yet reported — main transcript and every
+  subagent transcript, recursively — and shows one `[model_provenance] …` line per
+  affected transcript, including transcripts it could not read and subagents still
+  running. All observer state commits in one rename after the report is composed.
+
+The transcript reader lives in `hooks/`; `lib/` exposes only the append-only
+observation store. The projected command guards itself when neither
+`KAIROS_DATA_DIR` nor `CLAUDE_PROJECT_DIR` is set (silent under Codex, a visible
+non-blocking error elsewhere). Install: `kairos-chain skillset install
+<gem>/templates/skillsets/model_provenance`, then re-project. Design:
+`docs/model_provenance/`.
+
+### Changed — `multi_llm_review` 0.11.0: persona seats can record the observed model
+
+`orchestrator_reviews[]` entries take an optional `agent_id` (the id the Agent tool
+returned for that persona's subagent). When any persona carries one, collect
+resolves it through `model_provenance`'s store and the seat records
+`model_source`, `model_observed`, `model_divergence` and `binding:
+caller_declared`, with each persona's observation in its `persona_rows` entry. A
+persona is divergent when any observed response came from a model other than the
+declared persona model; the seat is observed only when every persona's observation
+is complete. Without any `agent_id` the record is exactly as before.
+
+### Changed — review roster: Opus 5 → Opus 5.5, Fable 5 → Fable 5.1
+
+The rotating frontier slot is `claude-opus-5-5` (label `claude_cli_opus5.5`) and
+the reserve slot `claude-fable-5-1`. Opus 5.5 is the one model that runs at medium
+when effort is omitted, so the explicit `high` in `effort_map` is what keeps it at
+high. L1 `multi_llm_review_workflow` 3.14.0 → 3.15.0: prescriptive text only;
+measurements and history that name Opus 5 or Fable 5 stay as written.
+
+## [3.86.0] - 2026-09-21
+
+### Changed — multi-LLM review: a per-round check for which review you are in
+
+Templates only: L1 `multi_llm_review_workflow` 3.13.0 → 3.14.0. No library code,
+no config.
+
+**The rule.** § Step -1 gains rule 7: classify each round's findings by CATEGORY,
+not only by the (a)/(b)/(c) severity that rule 1 and § Convergence Rules already
+require. Structural gaps ("this cannot work") and fix correctness ("the fix is
+wrong") are design-review categories; missing wiring ("this does not work") is an
+implementation-review category. When a design loop's findings have moved to the
+implementation category, the design review is over — freeze, hand the rest to the
+implementation queue, and do not dispatch another round.
+
+**Why it is new.** The content is not new; the *step* is. `multi_llm_reviewer_
+evaluation` § Bug Category Differentiation Across Rounds and this document's
+§ Convergence Curve have both described the progression for months, as
+observations. Nothing told an orchestrator to perform the check each round, so a
+loop could run eight rounds without anyone asking which review it was in.
+
+**The loop that paid for it.** GenomicsChain service (2.5) provenance anchoring,
+2026-09-20/21, 8 rounds, orchestrator Opus 5. Rounds 1–4 exhausted the
+design-category findings — the record contract, the verifier's readability, the
+proof TTL, the packaging. Rounds 5–8 then spent four rounds on a single
+implementation-category class (a malformed bundle outgrading an honest one, in
+the adapter's reading of broken input) and produced +102 lines of design against
++271 of code and +397 of tests, while the reviewed artifact grew 56 KB → 180 KB.
+
+Two things about that are worth keeping. First, the orchestrator's (a)/(b)/(c)
+trend table looked healthy the whole time — blocking rows 15 → 12 → 8 → 7 → 7 →
+9 → 10 → 6, density 26.7 → 3.3 per 100 KB — because the findings *were*
+narrowing. Severity and category are different axes, and only one of them was
+being read. Second, the surface grew because rule 2 was being broken: the code
+sat under an `APPENDIX (advisory only — findings against these never block)`
+header, the seats honoured it (round 8's codex labelled two of its three findings
+"Advisory under the appendix rule") and the orchestrator treated them as blocking
+anyway. Rule 2 exists to collapse the claim surface; a surface that grows every
+round is the tell that it is not being kept.
+
+The loop ended on the operator's observation, not on any recorded signal: *the
+adapter is an implementation problem, and a design review that runs tests has
+stopped being a design review.*
+
+**Also recorded in § Experimental Data**, because the same loop dropped them: the
+≤5 fixes-per-round cap (rule 3) ran at 7/6/6/6, the pre-flight falsifier (rule 4)
+was skipped for three consecutive rounds, the per-round
+`reviewer_evaluation_observation_<reviewer>_<date>` records (§ L2 Save Points)
+were never written, and no seat was asked for a closure verdict on its own
+prior-round P0s (§ Convergence Rules). A loop that drops five of this document's
+rules at once is not a loop that ran out of rules to follow.
+
+Records (GenomicsChain_SkillSets): L2 `decision_design_frozen_prov_anchoring_20260921`,
+`reviewer_evaluation_observation_prov_anchoring_loop_20260921`, and the round
+records `review_r5_…` through `review_r8_prov_anchoring_v0_1_9_20260921`.
+
+## [3.85.0] - 2026-09-06
+
+### Changed — multi-LLM review: high effort by default, gpt-6-astra seats, gpt-5.5 retires
+
+Templates only: `multi_llm_review/config/multi_llm_review.yml`, L1
+`multi_llm_review_workflow` 3.12.0 → 3.13.0. No library code.
+
+**Effort.** Every seat that has an effort control now runs at `high`, at every
+complexity level, so `effort_map` is a constant rather than a function of complexity.
+Claude CLI takes `--effort high`, codex takes `-c model_reasoning_effort=high`, Cursor
+takes nothing — `cursor_adapter` builds no effort flag, so a value set for a cursor
+entry would be recorded and never sent. Both the roster defaults and `effort_map` are
+set, because `effort_map` overrides the roster per dispatch and an entry left at
+`medium` would be silently raised. `high` rather than `xhigh`/`max` because it is the
+ceiling the two providers share (Claude CLI accepts low/medium/high/xhigh/max, codex
+accepts minimal/low/medium/high), and a roster split across incomparable settings is
+worth less than a lower common one.
+
+This supersedes the 2026-04-29 default-effort policy. That policy rested on one
+low-vs-high measurement — 8.35 vs 8.16 — taken on the Opus 4.6 / 4.7 generation, on
+none of the models now in the roster. It was not re-measured, so the supersession is a
+judgement and a later measurement could reverse it. Cost is measured and rises:
+gpt-6-astra spent 8,274 tokens at high against 3,150 at its default on one identical
+one-line prompt.
+
+**Roster.** `codex_gpt6-astra` replaces `codex_gpt5.6-sol`, verified before the swap
+through the flags `codex_adapter` actually builds. `codex_gpt5.5` retires in the same
+edit and is not replaced: it had been commented out of the instance roster since
+2026-07-30 "for round R10 only" and never restored, so the calibrated
+cross-generation anchor role had already lapsed for five weeks. Codex now holds one
+slot and it is uncalibrated. Roster 5 → 4, so `convergence_rule` moves 3/5 → 3/4 and
+`convergence_rule_after_exclusion` 3/4 → 2/3, both on the same ceil(N × 0.6) basis and
+both reference figures rather than gates. Three calibration warnings are recorded in
+the L1: the 138-run seat profile is gpt-5.6-sol's and does not transfer; that corpus
+was gathered at medium effort; and it was gathered on a 5-seat roster.
+
+### Fixed — three documents called the APPROVE ratio the closing condition
+
+A round closes on the exhaustion of (a)+(b) findings, declared by the operator, with
+new (a)+(b) P0 = 0 as the machine-side signal. The tooling has said so since v0.7
+INV-R2 named the field `reference_verdict` and v0.10.1 renamed `convergence` to
+`vote_tally`. Three documents had not caught up, and they are the ones actually read.
+
+L1 `multi_llm_reviewer_evaluation` 1.5 → 1.6. § Convergence Rule (Updated) stated
+`3/4 APPROVE = proceed to next step` and `4/4 APPROVE = merge-ready` with no note that
+the ratio is a reference value — while L1 `multi_llm_review_workflow` names this very
+section as the normative detail it defers to. The document saying "the ratio is not
+the primary close" pointed at a document saying it was. The closing condition is now
+stated first, the one blocking rule (any (a)/(b) REJECT) is separated from the
+reference figures, and the two facts that make the ratio unusable as a criterion sit
+in the section: Codex went 24 of 24 reviews without APPROVE on one design loop, and
+both 2026-08 threads closed by (a)+(b) exhaustion without reaching their ratio.
+
+L1 `design_to_implementation_workflow` 1.1 → 1.2. `merge gate: 3/3 APPROVE =
+merge-ready` and `Merge criteria: 3/3 APPROVE with 0 FAIL` replaced by the closing
+condition; the anti-pattern list gains reading an APPROVE count as the closing
+condition, naming this document as having carried it. The reviewer lineup written here
+("3 reviewers: Opus 4.6 + Codex GPT-5.4 + Composer-2") is deleted rather than
+corrected — it had been wrong since 2026-04-19, and a roster copied into a second
+document goes stale silently.
+
+`agent` SkillSet: the bundle handed to reviewers opened "aggregate per the convergence
+rule below" followed by the bare ratio. The heading no longer calls it a convergence
+rule, a Closing condition section states what actually closes a round, and the ratio
+is labelled "Reference ratio (recorded, never sufficient on its own)".
+
+Surviving uses of "merge gate" name the stage and its reviewer lineup, not a ratio,
+and stay.
+
+**Not reviewed by multi-LLM review**, at the operator's explicit instruction — the
+change is a seat swap plus wording, and a round would have cost hours. Verification is
+this agent's own and is not an independent judgement: YAML load of both configs, the
+three CLI invocations run for real (gpt-6-astra and both Claude models answered at
+high, with the model echoed back), `ruby -c` on `agent_step.rb`, multi_llm_review 556
+runs / 1,809 assertions and agent 21 checks, all passing. No test asserts the reviewer
+prompt wording, so that one line is unguarded.
+
 ## [3.84.0] - 2026-09-03
 
 ### Fixed — agent: second field-defect bundle (D5-b, D6, exit-record housekeeping), real-process worker tests

data/lib/kairos_mcp/version.rb

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

data/templates/knowledge/design_to_implementation_workflow/design_to_implementation_workflow.md

@@ -1,7 +1,7 @@
 ---
 name: design_to_implementation_workflow
 description: "Full-lifecycle workflow for complex features: design review, self-review, implementation review, and final merge gate. Derived from Service Grant + Attestation Nudge experiments."
-version: "1.1"
+version: "1.2"
 tags:
   - workflow
   - implementation
@@ -31,7 +31,8 @@ different bugs.
 │  v0.2 ──→ Multi-LLM Review R2 ──→ Fix ──→ v0.3            │
 │            (fix correctness)                                │
 │                                                             │
-│  Convergence: 0 FAIL, 2/3+ APPROVE                         │
+│  Closes on: new (a)+(b) P0 = 0, operator declares freeze    │
+│  (APPROVE ratio is a reference figure, not the gate)        │
 ├─────────────────────────────────────────────────────────────┤
 │ IMPLEMENTATION PHASE                                        │
 │                                                             │
@@ -48,7 +49,7 @@ different bugs.
 │  (missing wiring, fail-open, integration gaps)              │
 │                                                             │
 │  Final Multi-LLM Review + Persona Assembly                  │
-│  (merge gate: 3/3 APPROVE = merge-ready)                   │
+│  (closes the same way; ratio stays a reference figure)      │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -76,8 +77,15 @@ different bugs.
 - Output: Complete design document with pseudocode
 
 #### Multi-LLM Review Rounds
-- **3 reviewers**: Claude Opus 4.6 + Codex GPT-5.4 + Composer-2
-- **Convergence criteria**: 0 FAIL, 2/3+ APPROVE
+- **Reviewers**: the roster in `multi_llm_review/config/multi_llm_review.yml`,
+  which is where the count and the models live. The "3 reviewers: Opus 4.6 +
+  Codex GPT-5.4 + Composer-2" written here until 2026-09-06 had been wrong since
+  2026-04-19 and is not restated, because a roster copied into a second document
+  goes stale silently
+- **Closing condition**: new (a)+(b) P0 = 0, carryover P0s counted separately
+  with a closure verdict on each, and the freeze declared by the operator. The
+  APPROVE ratio the tool reports is a recorded reference value — see L1
+  `multi_llm_review_workflow` § Convergence Rules
 - **Typical rounds**: 2-3 for Tier 3 complexity
 - **Convergence curve**:
   - R1: Structural gaps — "this is missing" (existence)
@@ -148,7 +156,11 @@ Claude Persona Assembly (4 personas):
 - Safety-critical components
 - NOT for intermediate rounds (diminishing returns)
 
-**Merge criteria**: 3/3 APPROVE with 0 FAIL. Codex APPROVE is the strongest signal (see `multi_llm_reviewer_evaluation`).
+**Merge criteria**: new (a)+(b) P0 = 0, with the freeze declared by the operator.
+A Codex APPROVE is the strongest *reference* signal (see
+`multi_llm_reviewer_evaluation`), and it is not a gate: Codex went 24 of 24
+reviews without reaching APPROVE on one design loop, so a merge waiting on it
+would never have merged.
 
 ## Effort Level Selection
 
@@ -192,6 +204,9 @@ Reviewer 側 (Opus 4.7) は effort-independent なので high が天井。xhigh/
 
 ## Convergence Data
 
+Observed outcomes of past loops, not criteria. The APPROVE counts below record
+what those particular rounds happened to reach; they are not what closed them.
+
 ### Service Grant (Tier 3, 2026-03-18)
 - Design: v1.0 → v1.4, 3 review rounds, 3 LLMs
 - Design review findings: R1: 8 P0/P1, R2: 2 FAIL + 28 CONCERN, R3: 0 FAIL
@@ -207,6 +222,10 @@ Reviewer 側 (Opus 4.7) は effort-independent なので high が天井。xhigh/
 
 ## Anti-Patterns
 
+- **Reading an APPROVE count as the closing condition.** It is a recorded
+  reference value; a round closes on new (a)+(b) P0 = 0 with the freeze declared
+  by the operator. This document itself carried the mistake until v1.2, in the
+  strongest available wording ("merge gate: 3/3 APPROVE = merge-ready")
 - Implementing Phase 2+ when Phase 1 prerequisites aren't met
 - Using agent team for implementation (context fragmentation)
 - Skipping self-review (misses cheap P0 fixes)