kairos-chain 3.85.0 → 3.87.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bb60c9f0163eaf405fdad217697364791fd3bc3d40fe15a77ef57458950c1163
-  data.tar.gz: f5e9dd8b9bfc9ccc36472ada9bdc0d0b00104ef06398c198c6d9963369f82d39
+  metadata.gz: eac563609de17554382bdd2a4c2a42b21040fd60f43c4702eea153eeb5d5806b
+  data.tar.gz: 0cbb9994501dc8bdf9333e13f15bd25bc5c45e68f83abf1066e860606bc1c18a
 SHA512:
-  metadata.gz: 28cb26af2e39d33a5f39e4157c5c2e74f7ff63af77384a73aadb6fe4c03e7c7a8e6c445f7deaff9fdc0b05daf47ad69fdb5a6dee3bdeecd6f40a64f146f7196d
-  data.tar.gz: ac81db0e9cb2ab019f2944113de79e7b4c19be5389dead92398f86dcc6b4a82f38491bfad13de2a98d68eefe0ee7ddf94d23289d131662fbff2c1ccfe6dab9cc
+  metadata.gz: 4f41031abdbec48d77ed711a114a8be271321b4afee36e4a7b081550437afbf82b8a0a2aa91eba23fa3422873f8e5032202a00dc51a4cbb5758b72370a60d1dc
+  data.tar.gz: f0d09276a3259622de795ec1f7522e2b78af9c80c6934aa809195755f3fa8938d53996fbd1ab226e0884a5348383b92baf320a3c6c94e9d82ad94689d35cba87

data/CHANGELOG.md

@@ -4,6 +4,114 @@ 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

data/lib/kairos_mcp/version.rb

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

data/templates/knowledge/multi_llm_review_workflow/multi_llm_review_workflow.md

@@ -1,7 +1,7 @@
 ---
 name: multi_llm_review_workflow
 description: "Multi-LLM review methodology and execution — workflow pattern, CLI tooling, consensus analysis, Persona Assembly. Applicable to design, implementation, documentation, or any artifact."
-version: "3.13.0"
+version: "3.15.0"
 tags:
   - workflow
   - review
@@ -69,6 +69,42 @@ write a review spec and declare it frozen for the round:
 6. **Reference originals by path + sha256; do not transcribe.** Reviewers
    read the repository; the artifact carries the manifest. Transcription
    errors are undetectable and 100KB+ pastes rot.
+7. **Check which review you are in, every round — category, not severity.**
+   Classify each round's findings by CATEGORY against
+   `multi_llm_reviewer_evaluation` § Bug Category Differentiation Across
+   Rounds, in addition to the (a)/(b)/(c) severity classification 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 the design, hand the
+   remaining findings to the implementation queue, and do not dispatch
+   another round. Severity and category are different axes — a trend of
+   narrowing (a)/(b) findings says the loop is healthy, and says nothing
+   about whether it is still reviewing the design.
+
+   Two cheap tells that a design loop has crossed over, both readable
+   without any new instrumentation: the round's output is mostly code and
+   tests rather than design text, and the claim surface is growing instead
+   of collapsing (rule 2 exists to collapse it; if it is growing, rule 2 is
+   being broken somewhere).
+
+   Evidence — GenomicsChain service (2.5) provenance anchoring, 2026-09-20/21,
+   8 rounds, orchestrator Opus 5. Rounds 5–8 found exactly one class, a
+   malformed bundle outgrading an honest one, entirely in the adapter's
+   reading of broken input: the implementation category. Those four rounds
+   produced +102 lines of design against +271 of code and +397 of tests, and
+   the artifact grew 56 KB → 180 KB. Rule 2 was broken throughout — the code
+   sat under an APPENDIX header reading "advisory only, never block", the
+   seats obeyed it (round 8's codex marked two of its three findings
+   "Advisory under the appendix rule") and the orchestrator treated those
+   findings as blocking anyway. The orchestrator ran the (a)/(b)/(c) trend
+   table every round and it looked healthy, because the findings WERE
+   narrowing; what it never asked was which review the categories described.
+   The operator stopped the loop by naming the category shift directly — the
+   adapter is an implementation problem, and a design review that runs tests
+   has stopped being a design review. Records: L2
+   `decision_design_frozen_prov_anchoring_20260921`.
 
 Corollaries observed in the same loop: fix the *class*, and fix every copy —
 a corrected lib comment whose refuted twin survives in a test file costs a
@@ -461,9 +497,9 @@ they disagree, the config is right and this section is stale.
 - [ ] Agent Team Personas model: = orchestrator model (NOT a different model),
       unless you are running personas on a different model on purpose — then
       it is whatever you declare as persona_model (see § Persona execution model)
-- [ ] Subprocess CLI model: Opus 4.6. The other Claude roster slot is Opus 5,
+- [ ] Subprocess CLI model: Opus 4.6. The other Claude roster slot is Opus 5.5,
       which under the default "delegate" strategy is taken by your persona team
-      rather than spawned — so when you are Opus 5, Opus 4.6 is the only Claude
+      rather than spawned — so when you are Opus 5.5, Opus 4.6 is the only Claude
       CLI subprocess
 - [ ] Codex model: gpt-6-astra, with -m. One codex slot since gpt-5.5 was
       retired 2026-09-05 — do not add a second codex entry expecting the old
@@ -818,16 +854,17 @@ outside this repository — see the incident recorded in § Pre-flight checklist
 | **Cursor Agent** | `agent -p --model composer-2.5` | File reference (stdin NOT supported) | stdout redirect: `> output.md` | composer-2.5, passed explicitly — never relying on the CLI default |
 | **Claude Code** | Agent tool (internal) | Direct prompt string | Write to workspace file | Orchestrator model, or the declared `persona_model` when personas run elsewhere |
 | **Claude CLI (4.6)** | `claude -p --model claude-opus-4-6` | stdin pipe: `cat prompt.md \| claude -p --model claude-opus-4-6` | stdout redirect: `> output.md` | Opus 4.6 — the calibrated anchor, deliberately not a frontier model |
-| **Claude CLI (frontier)** | `claude -p --model claude-opus-5` | stdin pipe: `cat prompt.md \| claude -p --model claude-opus-5` | stdout redirect: `> output.md` | Runs only when Opus 5 is *not* the orchestrator; when it is, that slot is taken by the persona team |
+| **Claude CLI (frontier)** | `claude -p --model claude-opus-5-5` | stdin pipe: `cat prompt.md \| claude -p --model claude-opus-5-5` | stdout redirect: `> output.md` | Runs only when Opus 5.5 is *not* the orchestrator; when it is, that slot is taken by the persona team |
 
 `--bare` must NOT be passed (established 2026-07-23): it skips credential
 loading and the subprocess fails with "Not logged in". The project-instruction
 bias it was meant to suppress is handled by `review_context: independent`
 instead.
 
-Fable 5 appears in no row above. It was retired from the roster on 2026-07-26
-after five consecutive non-substantive returns, and now sits in the reserve
-container — see § Reserve observers (escalation).
+Fable appears in no row above. Fable 5 was retired from the roster on 2026-07-26
+after five consecutive non-substantive returns; the reserve container now holds
+its successor, Fable 5.1 (since 2026-09-24) — see § Reserve observers
+(escalation).
 
 ### Thinking Effort Configuration (validated 2026-04-20)
 
@@ -835,11 +872,11 @@ Based on cross-evaluation experiment (7 models × 4 tasks + Nomic, 518 CLI calls
 
 | Role | Model | Effort Flag | Rationale |
 |------|-------|-------------|-----------|
-| **Primary (orchestrator)** | session default | (default) | Sufficient for integration, dialogue, judgment |
-| **Reviewer: Agent Team** | = orchestrator, or the declared `persona_model` | (default) | Personas inherit whichever model actually runs them |
+| **Primary (orchestrator)** | session default | Claude Code's own setting | Not set by this config — record the level actually in effect (see the 2026-09-24 note) |
+| **Reviewer: Agent Team** | = orchestrator, or the declared `persona_model` | the session's level, unless the persona's agent file sets `effort:` | Personas inherit whichever model — and effort — actually runs them |
 | **Reviewer: Claude CLI** | Opus 4.6, plus any frontier roster slot the orchestrator is not | `--effort high` (config `effort: high`) | Operator instruction 2026-09-05; supersedes the 2026-04-29 default-effort policy — see the note below the table |
-| **Coding sub-agent** | Opus 5 | `--effort xhigh` | Published starting point for coding/agentic work; not measured here (see note) |
-| **Design sub-agent** | Opus 5 | `--effort high` | Published starting point for intelligence-sensitive work; not measured here (see note) |
+| **Coding sub-agent** | Opus 5.5 | `--effort high` | Operator default for KairosChain (2026-09-24); not measured here (see note) |
+| **Design sub-agent** | Opus 5.5 | `--effort high` | Operator default for KairosChain (2026-09-24); not measured here (see note) |
 | **Codex** | GPT-6-astra / GPT-5.5 | `-c model_reasoning_effort=high` | Same operator instruction. The earlier "(no flag) / fixed effort" entry was wrong: codex_adapter has always emitted this flag when the roster set `effort` |
 | **Cursor Agent** | Composer-2.5 | (no flag) | Genuinely has no effort control — cursor_adapter builds no such flag, so an `effort:` key on a cursor roster entry is recorded and never sent |
 
@@ -871,6 +908,20 @@ a starting point to sweep down from, not a validated setting. Separately, the
 for its ambiguity-preserving bias, not for capability, so a frontier successor
 does not replace it.
 
+Note (2026-09-24): the frontier rows moved from Opus 5 to Opus 5.5 (operator
+instruction — 5.5 is now Claude Code's default orchestrator and takes over
+every seat Opus 5 held), and both sub-agent rows are set to `high`, the
+operator's default effort for KairosChain. Two facts about 5.5 matter when
+reading any effort in this document. It is the one model that runs at
+**medium** when effort is omitted (every other model defaults to high), so
+every seat that should run at high has to say so. And level names do not mean
+the same amount of thinking across models — Anthropic reports 5.5 at medium
+matching Opus 5 at high — so equal settings across seats are not equal
+thinking. The orchestrator and a persona team run at the Claude Code session's
+level (the Agent tool has no effort parameter; an agent file's `effort:` line
+overrides it), so a session at xhigh puts the persona seat at xhigh while the
+CLI seats run at high. Record both levels in the round.
+
 Key findings:
 - **Opus 4.6** high effort improves Evaluator/Strategy (+0.43/+0.200 Nomic), not Response
 - **Opus 4.7** high effort improves Response/Thinking (+0.81 code, +0.53 philosophy), not Evaluator
@@ -908,11 +959,11 @@ record no longer claims a model that did not answer.
 **Rule**: When invoking `multi_llm_review` (or running this workflow manually), the
 orchestrating LLM MUST pass its own model identifier as `orchestrator_model`.
 
-**Rationale**: The reviewer roster contains more than one Claude entry (Opus 5
-and Opus 4.6 as of 2026-07-26). A frontier slot sits in the roster on purpose:
+**Rationale**: The reviewer roster contains more than one Claude entry (Opus 5.5
+and Opus 4.6 as of 2026-09-24; Opus 5 held the frontier entry from 2026-07-26). A frontier slot sits in the roster on purpose:
 when it is the current session model it matches `orchestrator_model` and becomes
 the persona-team slot; when it is not, it is dispatched as a `claude -p`
-subprocess. With the current two-entry Claude side, an Opus 5 orchestrator leaves
+subprocess. With the current two-entry Claude side, an Opus 5.5 orchestrator leaves
 Opus 4.6 as the only Claude CLI subprocess. No per-orchestrator config branch is
 needed either way.
 To avoid the orchestrator reviewing its
@@ -924,7 +975,7 @@ composition adapts automatically.
 
 **Why "argument-passing" not "file-introspection"**:
 - The orchestrator's model identity lives in *its own context* (system prompt
-  declares e.g. "You are powered by Fable 5"). No external file or env var is
+  declares e.g. "You are powered by Fable 5.1"). No external file or env var is
   authoritative — `/model` switches change context immediately.
 - MCP protocol does not transmit caller-model info; only the orchestrator can
   truthfully report its own identity. This is genuine self-reference: the system
@@ -936,8 +987,8 @@ composition adapts automatically.
 **How orchestrator obtains its model ID**:
 - Claude Code sessions: read the system prompt line "You are powered by the
   model named ... The exact model ID is ...". Use the exact ID as stated,
-  whatever its form (e.g. `claude-opus-5`, `claude-fable-5`). Strip any context
-  suffix — `claude-opus-5[1m]` is passed as `claude-opus-5`, since the roster
+  whatever its form (e.g. `claude-opus-5-5`, `claude-fable-5-1`). Strip any context
+  suffix — `claude-opus-5-5[1m]` is passed as `claude-opus-5-5`, since the roster
   matches on the bare model ID.
 - Other hosts: use whatever introspection the host provides; if none, pass
   `null` and accept that no exclusion happens.
@@ -947,7 +998,7 @@ composition adapts automatically.
 multi_llm_review(
   artifact_path: "log/design.md",
   review_type: "design",
-  orchestrator_model: "claude-opus-5"    # MUST be set by caller; bare ID, no [1m] suffix
+  orchestrator_model: "claude-opus-5-5"  # MUST be set by caller; bare ID, no [1m] suffix
 )
 ```
 
@@ -966,7 +1017,7 @@ multi_llm_review(
   model: the first is taken over by the persona team, the second leaves as the
   caller's own, and any beyond that run — as fresh external processes on that
   model, which is what the "subprocess" strategy buys deliberately. On the
-  current roster (one Opus 5 entry) the question does not arise. Settled
+  current roster (one Opus 5.5 entry) the question does not arise. Settled
   2026-07-27: the invariant fixes a count for the persona clause and states none
   for this one, and the shipped behaviour follows the text rather than widening
   it. A caller who wants a same-model slot to run anyway asks for it with
@@ -1009,6 +1060,18 @@ cross-model subprocess reviewers give epistemic diversity. The two are complemen
   performance/api-design; doc → ontologist/skeptic/integration)
 - Collect persona results: each as `{persona, verdict (APPROVE|REVISE|REJECT),
   reasoning, findings: [{severity, issue}, ...]}`
+- Bind each persona to its subagent: add `agent_id` — the id the Agent tool
+  returned for that persona's subagent — to its entry. With the model_provenance
+  SkillSet installed, the seat then records the model the harness observed
+  answering, not only the declared one: a safety-classifier fallback inside a
+  persona (Opus 5.5 → Opus 5 on biology, → Opus 4.8 on cyber) otherwise leaves
+  one model's findings recorded under another's name. The binding is your
+  declaration and is recorded as such; a persona without one, or whose id
+  resolves to no record, is recorded as unobserved with its cause.
+- Call collect after the personas' task-notifications, not on their
+  hand-backs: the hand-back reaches you 1.2–13.6 s before the subagent's final
+  record (10 of 10 observed, 2026-09-24), and a persona collected before its
+  record exists is recorded as unobserved.
 
 **Call 2**: `multi_llm_review_collect(collect_token, orchestrator_reviews: [...])`
 - Persona Assembly: any REJECT → REJECT; else any REVISE → REVISE; else APPROVE
@@ -1043,8 +1106,8 @@ the caller.
 
 ```
 multi_llm_review(
-  orchestrator_model: "claude-fable-5",   # who is calling
-  persona_model:      "claude-opus-5",    # who the personas actually run on
+  orchestrator_model: "claude-fable-5-1", # who is calling
+  persona_model:      "claude-opus-5-5",  # who the personas actually run on
   ...
 )
 ```
@@ -1087,8 +1150,9 @@ Points worth knowing before using it:
 - Reserve entries obey INV-E5 exactly like roster entries: they name their
   provider and model, and inherit no CLI default.
 
-As of 2026-07-26 the container holds Fable 5, which was retired from the roster
-after five consecutive non-substantive returns.
+As of 2026-09-24 the container holds Fable 5.1. Its predecessor Fable 5 held it
+from 2026-07-26, after being retired from the roster for five consecutive
+non-substantive returns; Fable 5.1 has not yet run in this slot.
 
 ### Substance and the denominator
 
@@ -1285,7 +1349,7 @@ readable until GC. Read them directly and synthesize manually, then re-run
   before, silently swapping the model behind an unchanged role label
 - **Codex workspace**: `-C /path/to/workspace` to set working directory
 - **Claude Agent paths**: Write within workspace (e.g., `log/`), not `/tmp`
-- **Claude CLI (Opus 4.6 / any non-orchestrator frontier slot)**: `claude -p --model claude-opus-4-6` (likewise `claude-opus-5`) runs as external process. Uses stdin pipe (like Codex). Do NOT pass `--bare` — it skips credential loading and the subprocess dies with "Not logged in" (established 2026-07-23). Project-instruction bias is suppressed via `review_context: independent`, not via `--bare`
+- **Claude CLI (Opus 4.6 / any non-orchestrator frontier slot)**: `claude -p --model claude-opus-4-6` (likewise `claude-opus-5-5`) runs as external process. Uses stdin pipe (like Codex). Do NOT pass `--bare` — it skips credential loading and the subprocess dies with "Not logged in" (established 2026-07-23). Project-instruction bias is suppressed via `review_context: independent`, not via `--bare`
 - **Claude CLI parallelism**: Agent tool (internal, orchestrator model) + Bash `claude -p` (external, Opus 4.6 and any other Claude roster slot the orchestrator is not) run truly in parallel as separate processes
 - **Claude CLI file access**: a plain `claude -p` review subprocess should not need file access. Ensure the review prompt includes all artifact content inline (rule #6). Use `--add-dir` + `--allowedTools "Read,Glob,Grep"` if file access is genuinely needed, and accept that CLAUDE.md is loaded (the old `--bare` workaround is unusable — see above)
 
@@ -1437,10 +1501,10 @@ Step 3: Execute the configured roster in parallel (currently 4 slots, one of
   - Bash(background): cat prompt.md | codex exec -m gpt-6-astra -c model_reasoning_effort=high -C workspace -o log/review_codex_gpt6-astra.md -
   - Bash(background): agent -p --trust --model composer-2.5 "Read prompt and review..." > log/review_cursor.md
     (no effort flag — Cursor has no effort control)
-  - Agent(background): Claude Team (orchestrator model, e.g. Opus 5) → write to log/review_claude_team_opus5.md
+  - Agent(background): Claude Team (orchestrator model, e.g. Opus 5.5) → write to log/review_claude_team_opus5.5.md
   - Bash(background): cat prompt.md | claude -p --model claude-opus-4-6 --effort high > log/review_claude_opus4.6.md 2>log/review_claude_opus4.6.stderr.log
-    (add a line per further Claude roster slot you are not; with the 2026-07-26
-     roster an Opus 5 orchestrator has none, so opus-4.6 is the only one)
+    (add a line per further Claude roster slot you are not; with the 2026-09-24
+     roster an Opus 5.5 orchestrator has none, so opus-4.6 is the only one)
 
 Step 4: Collect and validate
   - Wait for all to complete (background task notifications)
@@ -1477,10 +1541,10 @@ log/{artifact}_review{N}_{llm_id}_{date}.md       # Individual reviews
 log/{artifact}_review{N}_consensus_{date}.md       # Consensus analysis
 ```
 
-LLM identifiers: `claude_cli_opus5`, `claude_cli_opus4.6`,
+LLM identifiers: `claude_cli_opus5.5`, `claude_cli_opus4.6`,
 `codex_gpt6-astra`, `cursor_composer2.5`, `cursor_gpt5.4`,
 `cursor_premium`. The delegated slot is reported as `claude_team_<model>`
-(e.g. `claude_team_claude-opus-5`), assembled at collect time — the roster's
+(e.g. `claude_team_claude-opus-5-5`), assembled at collect time — the roster's
 own labels stay CLI-neutral because either frontier entry can take either path.
 (legacy, pre-2026-06-10: `claude_opus4.6`, `claude_team_opus4.6`, `claude_team_opus4.7`,
 `claude_cli_opus4.7`, `cursor_composer2`; retired 2026-07-23: `codex_gpt5.4`;
@@ -1488,7 +1552,8 @@ retired 2026-07-25: `claude_cli_opus4.8`, `claude_team_fable5`;
 retired 2026-07-26: `claude_cli_fable5` — five consecutive non-substantive
 returns, 85-128 characters in 5-7 seconds, no findings and no verdict text;
 retired 2026-09-05: `codex_gpt5.6-sol`, replaced by `codex_gpt6-astra`, and
-`codex_gpt5.5`, not replaced. Runs recorded under a retired identifier keep it —
+`codex_gpt5.5`, not replaced; retired 2026-09-24: `claude_cli_opus5`, succeeded in
+the same slot by `claude_cli_opus5.5`. Runs recorded under a retired identifier keep it —
 the label names the model that answered, so renaming old records would attribute
 one model's findings to another)
 
@@ -1825,5 +1890,65 @@ Compression ratio: parallel agent raw → Assembly ≈ 2:1
   by (a)+(b) exhaustion without ever reaching it. Every ratio in this document
   is a reference figure.
 
+- Step -1 rule 7 added, the per-round category check (v3.14.0, 2026-09-21,
+  operator instruction). The rule the loop below needed already existed as an
+  observation — `multi_llm_reviewer_evaluation` § Bug Category Differentiation
+  and this document's § Convergence Curve both describe the progression — but
+  neither was a step anyone was told to perform each round, so eight rounds ran
+  without it. GenomicsChain service (2.5) provenance anchoring: R1–R4 exhausted
+  the design-category findings (record contract, verifier readability, proof
+  TTL, packaging); R5–R8 then spent four rounds on one implementation-category
+  class, produced +102 design lines against +271 code and +397 test lines, and
+  grew the artifact 56 KB → 180 KB while rule 2 was being broken. The
+  orchestrator's own trend table showed healthy narrowing the whole time, which
+  is the point: severity narrowed while the category had already changed.
+  The loop closed on the operator's observation, not on any recorded signal.
+  Also recorded, because the same loop dropped them: the ≤5 fixes-per-round cap
+  (rule 3) went to 7/6/6/6, the pre-flight falsifier (rule 4) was skipped for
+  three consecutive rounds, 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: L2 `decision_design_frozen_prov_anchoring_20260921`,
+  `review_r5_prov_anchoring_v0_1_5_20260921` .. `review_r8_prov_anchoring_v0_1_9_20260921`,
+  report `docs/reports/prov_anchoring_mlr_status_20260921/report.html` (GenomicsChain_SkillSets)
+
+- Persona seats can record the observed model (v3.15.0, 2026-09-24, operator
+  instruction). `orchestrator_reviews[]` entries take an optional `agent_id`;
+  when any is supplied, collect resolves each through the model_provenance
+  SkillSet's observation store and the seat carries `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 takes the most severe state (divergent >
+  unobserved > matching) and is observed only when every persona's observation
+  is complete. Without any `agent_id` the record is exactly as before. Why:
+  Claude Code re-runs a flagged request on a fallback model and stays there,
+  silently for subagents — observed twice on 2026-09-24 (62 and 208 responses,
+  56 and 148 of them on Opus 5 after the switch). Design:
+  `docs/model_provenance/design_v0.3.md`.
+
+- Opus 5 → Opus 5.5 and Fable 5 → Fable 5.1 (v3.14.1, 2026-09-24, operator
+  instruction). Opus 5.5 is now Claude Code's default orchestrator, so it takes
+  over every seat Opus 5 held and nothing else about the roster changes: still
+  4 seats (Opus 5.5 as orchestrator and persona team, Opus 4.6 CLI, codex
+  gpt-6-astra, cursor composer-2.5), still `high` on every seat with an effort
+  control. The frontier slot's label becomes `claude_cli_opus5.5`; the reserve
+  container's occupant becomes Fable 5.1 (`claude_cli_fable5.1`). Only text
+  that prescribes current behaviour was changed. Measurements, seat profiles and
+  history that name Opus 5 or Fable 5 stay as written, because they are facts
+  about those models — in particular the `claude_team_opus-5` persona row in
+  § Step 0.1 is Opus 5's record, not a profile for 5.5. Why the
+  config's orchestrator slot had to move and not merely be documented: the slot
+  is matched to `orchestrator_model` by exact string, so a 5.5 orchestrator
+  against a `claude-opus-5` slot took over nothing — its persona team joined as
+  a fifth observer and the Opus 5 slot still ran as a CLI subprocess (found in
+  the 2026-09-24 Opus 5.5 guidance audit). Effort: see the 2026-09-24 note under
+  § Thinking Effort Configuration, including that the persona seat follows the
+  session's level while CLI seats follow the config.
+
 **Key insight**: Design reviews and implementation reviews find
-**categorically different bugs**. Both phases are necessary.
+**categorically different bugs**. Both phases are necessary. The corollary that
+cost eight rounds to learn: **which of the two you are in is readable from the
+findings' category, and has to be read every round** (§ Step -1 rule 7).

data/templates/skillsets/llm_client/lib/llm_client/bedrock_adapter.rb

@@ -82,7 +82,23 @@ module KairosMcp
           region = @config['aws_region'] || @config[:aws_region] ||
                    ENV.fetch('AWS_REGION', 'us-east-1')
 
-          Aws::BedrockRuntime::Client.new(region: region)
+          Aws::BedrockRuntime::Client.new(region: region, **client_options)
+        end
+
+        # The SDK's defaults are a 60 s read timeout and 3 retries, and a retry
+        # re-sends the whole prompt. A long generation (a Tier-1 assessment over
+        # a full paper) therefore failed after exactly 4 x 60 s with
+        # Net::ReadTimeout, having been billed four times (measured 2026-09-12,
+        # 243 s). The read timeout follows the same `timeout_seconds` the other
+        # adapters honour, and there is no retry: a timed-out generation is not
+        # made shorter by sending it again, and the caller decides whether to
+        # retry.
+        def client_options
+          {
+            http_open_timeout: 10,
+            http_read_timeout: timeout_seconds,
+            retry_limit: 0
+          }
         end
 
         def resolve_model(override)

data/templates/skillsets/llm_client/skillset.json

@@ -1,6 +1,6 @@
 {
   "name": "llm_client",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Pure LLM provider abstraction. One API call, returns response. No loop, no retry, no fallback.",
   "author": "Masaomi Hatakeyama",
   "layer": "L1",

data/templates/skillsets/llm_client/test/test_bedrock_adapter_timeout.rb

@@ -0,0 +1,57 @@
+# frozen_string_literal: true
+# The Bedrock client must carry the configured timeout and no SDK retries.
+# Before 2026-09-12 it was built with the SDK defaults (60 s read timeout,
+# 3 retries): a Tier-1 assessment over a full paper timed out after exactly
+# 4 x 60 s and was billed four times. No AWS gem is needed here: the client
+# constructor is stubbed and its options captured.
+
+require 'minitest/autorun'
+require_relative '../lib/llm_client/adapter'
+require_relative '../lib/llm_client/bedrock_adapter'
+
+module KairosMcp
+  module SkillSets
+    module LlmClient
+      class TestBedrockAdapterTimeout < Minitest::Test
+        def with_stubbed_client
+          captured = nil
+          fake = Class.new do
+            define_singleton_method(:new) { |**opts| captured = opts; :client }
+          end
+          had_aws = Object.const_defined?(:Aws)
+          Object.const_set(:Aws, Module.new) unless had_aws
+          had_ns = Aws.const_defined?(:BedrockRuntime)
+          Aws.const_set(:BedrockRuntime, Module.new) unless had_ns
+          had_client = Aws::BedrockRuntime.const_defined?(:Client)
+          orig = had_client ? Aws::BedrockRuntime.send(:remove_const, :Client) : nil
+          Aws::BedrockRuntime.const_set(:Client, fake)
+          # `require 'aws-sdk-bedrockruntime'` must not fail when the gem is absent.
+          $LOADED_FEATURES << 'aws-sdk-bedrockruntime.rb' unless $LOADED_FEATURES.include?('aws-sdk-bedrockruntime.rb')
+          yield
+          captured
+        ensure
+          Aws::BedrockRuntime.send(:remove_const, :Client)
+          Aws::BedrockRuntime.const_set(:Client, orig) if orig
+          Aws.send(:remove_const, :BedrockRuntime) unless had_ns
+          Object.send(:remove_const, :Aws) unless had_aws
+        end
+
+        def test_configured_timeout_reaches_the_client_and_retries_are_off
+          adapter = BedrockAdapter.new({ 'aws_region' => 'eu-central-1', 'timeout_seconds' => 600 })
+          opts = with_stubbed_client { adapter.send(:bedrock_client) }
+
+          assert_equal 'eu-central-1', opts[:region]
+          assert_equal 600, opts[:http_read_timeout]
+          assert_equal 10, opts[:http_open_timeout]
+          assert_equal 0, opts[:retry_limit]
+        end
+
+        def test_default_timeout_when_none_configured
+          adapter = BedrockAdapter.new({ 'aws_region' => 'eu-central-1' })
+          opts = with_stubbed_client { adapter.send(:bedrock_client) }
+          assert_equal 120, opts[:http_read_timeout], 'falls back to Adapter#timeout_seconds default'
+        end
+      end
+    end
+  end
+end