kairos-chain 3.58.2 → 3.61.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 354e0a87d4c0ed3736972c2fde97cf1537b4054d6ab86ae3cdf593e2c6d08a76
-  data.tar.gz: 64237a0328caa2330bbebd4e188c017fc076bc773a9e0a4bcf05ea3fe8e9b118
+  metadata.gz: d38191ff3e513822d6183bf4fee4c92e497148978eda3bda064a01b81d0bf95b
+  data.tar.gz: 97999aa9377a086ea092237ad53605fec24b9e01c9691e7c92c24b6329bd565e
 SHA512:
-  metadata.gz: bde4d816b2a7610de034633ae467c1f6febda1b907b81fb156b356b5d86980f57c37c3e8903cdeb24a861323d16705a1d167e63390d9c1350d8bb880fb52f3da
-  data.tar.gz: 9e32311add613a1bbddffa704f0720622ca436be7a0bfc56b237d3ac650cf574cdb82ed3f12550e94782020c1b4c762baa6333db8b72a1ea04f32bf46a37cc8e
+  metadata.gz: eacfebd73445ea5e6a503bb34e8978a0a6c649d34a46810140a885f235e3933b01701d45921341b6771caa64c58f4dac61f51233d2741417e8b59be111196109
+  data.tar.gz: bffb450e4de67e1b3c179de5bd48b86d1d6d3c2bc8e69cd6878fd6d89b6e3346fae29b09cd5ef79ddbb12f16498e0f944da84af4a62b3a36eff0db05ea5b6d96

data/CHANGELOG.md

@@ -4,6 +4,177 @@ All notable changes to the `kairos-chain` gem will be documented in this file.
 
 This project follows [Semantic Versioning](https://semver.org/).
 
+## [3.61.0] - 2026-08-06
+
+### Fixed
+
+- **`multi_llm_review` (SkillSet 0.9.0) — a finding reaches the record whole, and the record
+  stops claiming what it cannot know.** A downstream instance measured, across four real rounds,
+  that 18 of 21 aggregated findings came back at exactly 201 bytes while `reviews[].raw_text` was
+  empty on every row and `raw_text_length` reported the real size. Three bounds were doing it: an
+  inclusive Range (`issue.strip[0..200]`, hence 201) in aggregation, the 500-character display
+  limit applied to the record as well as the prompt, and a serializer row that carried a reply's
+  length but never the reply. A fourth defect discarded a distinct finding on dedup collision
+  without saying so.
+
+  Findings are now bounded in **bytes** at `FINDING_RECORD_MAX_LEN = 8000` for the record, with
+  `DEFAULT_MAX_LEN = 500` still applied by every path taking a finding into a prompt. The dedup key
+  is unchanged at 80 characters — widening it would stop two reviewers describing one defect from
+  merging, which moves the finding count and the convergence denominator — but the surviving text
+  is no longer arbitrary: `issue` comes from a member whose severity equals the merged severity,
+  and distinct texts survive in `issue_variants` (capped at `MAX_ISSUE_VARIANTS = 8`, with
+  `issue_variants_omitted` naming what the cap dropped). Every row now carries `raw_text_excerpt`
+  unconditionally at 4096 bytes, and the reply itself in `raw_text` on request
+  (`include_raw_text`, 65536 bytes). Findings carried into a later round's prompt are sanitised and
+  folded to one line — a path that previously took reviewer text into a prompt with no sanitisation
+  at all.
+
+  **The two evidence fields are sanitised transcriptions, not verbatim records, and the tool
+  schemas now say so** rather than implying otherwise. The text is byte-clamped, NFKC-normalised,
+  stripped of invisible characters, tag-escaped, then byte-clamped again; normalisation rewrites
+  compatibility forms, the strip removes five of Unicode's eight mandatory line breaks, and the tag
+  escape collapses unbounded whitespace. No field states whether a stored text is the whole reply.
+  A completeness flag was implemented for exactly that purpose and then removed: three reviewers
+  measured it wrong in **both** directions — a 4,010-byte reply stored as 18 bytes reported
+  complete, and a reply whose every readable byte survived reported truncated. "Was anything
+  dropped" cannot be answered by byte counts taken around a pass that also rewrites, strips and
+  escapes. On delegated runs the pending-state record keeps each subprocess reply as it arrived; on
+  single-phase runs the returned payload is the only form there is, and the schema distinguishes
+  the two.
+
+  Six review rounds, four pre-flight falsifier passes and forty-plus mutations. Every defect in
+  this change was found by adversarial reading or by mutating the code in a copy outside the
+  repository; **none** by the test suite passing. Known and disclosed rather than closed: the
+  excerpt can store a word the reviewer did not write (normalisation cannot simply be dropped —
+  the delimiter pattern matches ASCII angle brackets, so a fullwidth `＜artifact＞` would pass
+  straight through an escape that no longer normalises, and the escape-without-normalise entry
+  point `stated_text` has been waiting on since R2 does not exist yet); the measured response
+  ceiling of 28.9 MB against a declared 14.4 MB; and thirteen sites that survive deletion with the
+  suite green.
+
+## [3.60.0] - 2026-08-05
+
+### Added
+
+- **`account_manager` (SkillSet 0.1.0) — a jurisdiction-neutral double-entry ledger for a
+  one-person business that is also a household cash book.** One person, two purses: the books must
+  separate for tax, but the money does not — the owner draws from the business and pays business
+  costs from a private card. Six tools (`am_entry`, `am_import`, `am_query`, `am_report`,
+  `am_receipt`, `am_close`), one ledger with two books, one currency, and a bookkeeper-persona
+  sub-agent that transcribes on the way in and reads figures on the way out but cannot post,
+  confirm, discard, close or bind evidence.
+
+  No country's rules appear in any code path. The chart of accounts, tax labels, fiscal year and
+  import profiles are configuration; adding a country means writing one YAML file. The loader has
+  one refusal with a closed list of causes, and a missing ledger configuration is refused rather
+  than substituted by the shipped example.
+
+  Three things carry the design. A **range** is one calendar month derived from the transaction
+  date, so ranges cannot overlap or leave a gap and the rules that would have policed that do not
+  exist. A **proposal** is not a figure: imported rows and transcriptions are visible, counted by
+  no report, and become postings only by an explicit operator call. The **annual close posts, then
+  seals** — it credits each book's own retained earnings dated the fiscal year's last day, then
+  seals every month of that year, and that entry is the one posting permitted into a
+  period-closed (never sealed) range, because refusing it would make the annual close unreachable
+  in ordinary month-by-month use.
+
+  Design review did not converge over three rounds, so the design was implemented rather than
+  argued further; two implementation review rounds followed. Round 1 found a ledger that lost
+  records — an acknowledged posting absent from disk, because each tool cached its own store and
+  saved a stale snapshot over it — plus a refusal idiom that never executed
+  (`def m(id) = h[id] or raise X` parses as `(def …) or raise`), a closing entry that credited the
+  wrong book, and a year sealed as year zero from `'abc'.to_i`. Twenty-seven of its twenty-eight
+  blocking findings are fixed, and three independent reviewers verified the fixes in round 2.
+  Round 2's own findings are recorded and open: twelve are missing test coverage rather than
+  defects, and the remainder sit at configuration edges. Known and unfixed: there is no locking,
+  so the store is safe for one operator on one machine and not beyond it.
+
+  Not auto-installed — `account_manager` is not in `CORE_SKILLSETS`, so it ships in the gem and is
+  installed explicitly, like `project_manager`.
+
+## [3.59.0] - 2026-08-05
+
+### Added
+
+- **`project_manager` names what no bucket covered (SkillSet 0.3.0).** `pm_digest`
+  sorted open items into four buckets and reported the remainder as a count called
+  `healthy_count`. Dormancy is computed at high salience only, so a normal- or
+  low-salience item with no deadline was counted but never named, however long it
+  sat. On the operator's own store that was 12 of 22 open items, the oldest
+  untouched for 98 days, and nothing in the digest would ever have raised them.
+
+  The digest now returns `uncovered_count` and `uncovered_stale`. The latter names
+  every uncovered item the store already calls dormant, in full and oldest first,
+  ties broken by id — in full rather than a top-N because untouched items advance
+  in lockstep, so a fixed cut omits the same work every day forever. The secretary
+  agent reads the list out after the buckets with no next step attached: it is a
+  list of what nothing raised, not a bucket to act on. `healthy_count` survives as
+  a deprecated alias, because the name is wrong — the number mixes work that is
+  fine with work nobody is watching. Bucket membership is otherwise unchanged.
+
+  Hardening found while reviewing it, all reachable through the tool surface.
+  `pm_item` writes `due` and `touched_at` through with no validation and every
+  reader assumed `Time.parse` would succeed, so one bad value replaced the whole
+  digest — or the whole deadline query — with an error object. Both now read
+  through `ProjectManager.parse_time`, which answers nil for a malformed string, a
+  non-string and an out-of-range field alike. The same discipline covers
+  caller-supplied numbers in `whole_number`, including the `pm.yml` thresholds and
+  the `digest:` mapping they sit in, so an operator typo in the one file
+  `skillset upgrade` never repairs falls back to defaults instead of disabling the
+  digest. `summarize` also carries the raw `touched_at` now, so a consumer can tell
+  a missing marker from an unreadable one — the secretary is required to word them
+  differently and previously had to guess.
+
+  Eight review rounds against a frozen target, closed by exhaustion rather than by
+  threshold: the last round's findings were pre-existing SkillSet defects outside
+  the target, not defects in this change. The recurring mistake worth recording is
+  that seven consecutive rounds each found the same shape — a guard placed one step
+  short of where the value enters — at the call site instead of the source, at two
+  of three exception classes, at a config hash's values instead of the hash, and at
+  the hash instead of the read that produces it.
+
+- **`project_orientation_report` L1 knowledge.** A fixed procedure for producing a
+  one-page HTML report that explains where a single thread of work stands, written
+  for a reader who has not followed it. Ten invariants, a fixed eight-section order,
+  three collapsed appendices, and SVG rules; the checkable part is enforced by
+  `scripts/check_report.py` (standard library only, exit 0 on pass).
+
+  The two invariants that carry the most weight are non-obvious. The writer must
+  not hold the session context that produced the work — a writer who knows
+  everything skips premises without noticing, so the report is written by a
+  context-blank process given only the artifacts. And a section that explains a
+  *change* must carry one worked example from start to finish, because a reader
+  forced to re-learn the setup at every section stops following at the first switch.
+
+  The design was not validated by a design review. It was validated by building
+  four prototypes on the same subject and having a human read each one: invariants
+  7, 8, 9, 10 and the SVG rules all came out of those judgments and none of them
+  came out of the design table. `references/worked_example.md` records which
+  prototype failed how.
+
+  The checker itself went through two rounds of multi-LLM review, neither of which
+  approved it, and the shape of what they found is why it ships as it does. The
+  first version matched tags with regular expressions, so every content check was
+  defeated by moving content into a region the pattern did not scan — wrapping the
+  failing example in `<details open>` turned it into a pass. It now builds a
+  document tree and measures rendered text, so relocating content no longer helps.
+  The second round found a further class: a report could declare every section
+  exempt and pass as a blank page, a one-argument `translate` silently moved
+  nothing, and a relative font unit was read as a tiny absolute size. Those are
+  closed, and each is now a fixture.
+
+  What is deliberately not closed is stated in the script and in the skill: this
+  is a lint over the ways an author gets a wrong answer while writing normally,
+  not a boundary against someone determined to pass an unreadable report. Text
+  drawn by a stylesheet, an `<iframe srcdoc>`, or a full-width spelling of a
+  forbidden label all get through, and closing that class needs a renderer rather
+  than a parser. A pass means a handful of known ways of being unreadable are
+  absent; whether the report can actually be understood in one pass stays a human
+  judgement. `test/` ships 22 fixtures and a runner so the boundary is checkable
+  rather than asserted — 18 that must fail, each naming the check that must catch
+  it, and 4 that must pass, because closing an evasion is trivial if the gate is
+  allowed to reject everything.
+
 ## [3.58.2] - 2026-08-03
 
 ### Fixed

data/lib/kairos_mcp/version.rb

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

data/templates/knowledge/project_orientation_report/assets/report_template.html

@@ -0,0 +1,214 @@
+<!DOCTYPE html>
+<html lang="ja">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<!-- Tokens that LOOK work-internal but are ordinary vocabulary (A4, Q3, gpt-5).
+     Declaring one is a decision; leaving this empty is the default. -->
+<meta name="orientation-allowed-tokens" content="">
+<title>作業名 — 現状レポート</title>
+<style>
+  :root {
+    --ink: #23262b;
+    --muted: #5f6672;
+    --line: #d5d9e0;
+    --panel: #f7f8fa;
+    --accent: #b3402f;
+  }
+  body {
+    font-family: "Hiragino Sans", "Noto Sans JP", "Yu Gothic", ui-sans-serif, sans-serif;
+    color: var(--ink);
+    background: #fff;
+    line-height: 1.9;
+    font-size: 16.5px;
+    max-width: 46rem;
+    margin: 0 auto;
+    padding: 2.5rem 1.2rem 5rem;
+  }
+  h1 { font-size: 1.5rem; line-height: 1.5; margin: 0 0 .4rem; }
+  h2 {
+    font-size: 1.13rem;
+    margin: 3rem 0 .9rem;
+    padding-bottom: .35rem;
+    border-bottom: 2px solid var(--line);
+  }
+  p { margin: .9rem 0; }
+  .stamp {
+    background: var(--panel);
+    border: 1px solid var(--line);
+    border-radius: 6px;
+    padding: .8rem 1rem;
+    font-size: .87rem;
+    color: var(--muted);
+    line-height: 1.8;
+  }
+  .stamp b { color: var(--ink); font-weight: 600; }
+  table { border-collapse: collapse; width: 100%; margin: 1.2rem 0; font-size: .93rem; }
+  th, td { border: 1px solid var(--line); padding: .5rem .7rem; text-align: left; vertical-align: top; }
+  th { background: var(--panel); font-weight: 600; }
+  figure { margin: 1.4rem 0; }
+  figcaption { font-size: .85rem; color: var(--muted); margin-top: .5rem; }
+  svg { display: block; margin: 0 auto; }
+  .mark { color: var(--accent); font-weight: 600; }
+  details {
+    margin-top: 3rem;
+    border-top: 1px solid var(--line);
+    padding-top: 1rem;
+  }
+  summary { cursor: pointer; font-weight: 600; }
+  @media print {
+    body { max-width: none; font-size: 11pt; }
+    details { page-break-before: always; }
+    details[open] summary { list-style: none; }
+  }
+</style>
+</head>
+<body>
+
+<!-- 節0 表紙。条件2 — 時点を名指しする。図表は不要、時点の枠がその代わり。
+     data-visual="none" が「この節に図表が無いのは意図的だ」という宣言。
+     宣言の無い節は図表を要求される -->
+<h1 data-visual="none">《作業名》 — 現状レポート</h1>
+<p>《この 1 枚は何の話か。1 文で》</p>
+<div class="stamp">
+  <b>生成</b> 《YYYY-MM-DD HH:MM》 ／
+  <b>git</b> 《short commit》 ／
+  <b>chain の高さ</b> 《length》<br>
+  <b>読んだ入力</b> 《n 件。一覧は付録 C》
+</div>
+
+<!-- 節1 登場人物。作業の内部ではなく、作業に入る前の前提だけ。SVG 必須 -->
+<h2>登場人物</h2>
+<p>《誰が誰に何を渡すのか。ここでは仕組みを書かない》</p>
+<figure>
+<!--
+  箱の幅の決め方。SVG の text は折り返さないので、書き手が計算する。
+
+      日本語 1 文字 ≈ font-size × 1.0     半角英数 1 文字 ≈ font-size × 0.55
+
+  font-size 14 なら日本語 1 文字が 14px。下の箱は幅 220px なので **15 文字**まで。
+  超えるときは、箱を広げるか、下のように <tspan> で行を分ける。
+  1 行に収める必要はない。収まらない行を 1 本の text に押し込むのが失敗の形。
+  検収スクリプトは、各行を親の <rect> と照合して溢れを落とす。
+-->
+<svg viewBox="0 0 760 210" style="width:100%;max-width:760px;height:auto" role="img">
+  <title>《図の内容を 1 文で。読み上げ用》</title>
+  <defs>
+    <marker id="arrow" viewBox="0 0 10 10" refX="9" refY="5"
+            markerWidth="7" markerHeight="7" orient="auto-start-reverse">
+      <path d="M 0 0 L 10 5 L 0 10 z" fill="#5f6672"/>
+    </marker>
+  </defs>
+  <rect x="10" y="60" width="220" height="76" rx="6" fill="#f7f8fa" stroke="#5f6672"/>
+  <text font-size="14" text-anchor="middle"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">
+    <tspan x="120" y="94">《登場人物 1 の名前》</tspan>
+    <tspan x="120" y="116">《長ければ 2 行目へ》</tspan>
+  </text>
+  <rect x="270" y="60" width="220" height="76" rx="6" fill="#f7f8fa" stroke="#5f6672"/>
+  <text font-size="14" text-anchor="middle"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">
+    <tspan x="380" y="94">《登場人物 2 の名前》</tspan>
+    <tspan x="380" y="116">《長ければ 2 行目へ》</tspan>
+  </text>
+  <rect x="530" y="60" width="220" height="76" rx="6" fill="#f7f8fa" stroke="#5f6672"/>
+  <text font-size="14" text-anchor="middle"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">
+    <tspan x="640" y="94">《登場人物 3 の名前》</tspan>
+    <tspan x="640" y="116">《長ければ 2 行目へ》</tspan>
+  </text>
+  <line x1="230" y1="98" x2="265" y2="98" stroke="#5f6672" marker-end="url(#arrow)"/>
+  <line x1="490" y1="98" x2="525" y2="98" stroke="#5f6672" marker-end="url(#arrow)"/>
+  <text x="248" y="46" text-anchor="middle" font-size="11"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#5f6672">《渡すもの》</text>
+  <text x="508" y="46" text-anchor="middle" font-size="11"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#5f6672">《渡すもの》</text>
+</svg>
+<figcaption>《図の説明。1 行》</figcaption>
+</figure>
+
+<!-- 節2 何が壊れていたか。条件8 — 実際の入力と出力の値を 1 組 -->
+<h2>何が壊れていたか</h2>
+<p>《具体的に何が起きたのか》</p>
+<table>
+  <tr><th>入力</th><th>出た結果</th></tr>
+  <tr><td>《実際に与えた値》</td><td>《実際に返った値》</td></tr>
+</table>
+
+<!-- 節3 直そうとして何が起きたか。条件10 — 追う例を決め、時点ごとの扱いを 1 枚の表に -->
+<h2>直そうとして何が起きたか</h2>
+<p>《経緯を 1 本の線で。以下は追いかける例》</p>
+<table>
+  <tr><th>時点</th><th>《追う例 その 1》</th><th>《追う例 その 2》</th></tr>
+  <tr><td>《最初》</td><td>《どうなったか》</td><td>《どうなったか》</td></tr>
+  <tr><td>《修正 1》</td><td>《どうなったか》</td><td><span class="mark">《ここで開いた穴》</span></td></tr>
+  <tr><td>《最終》</td><td>《どうなったか》</td><td>《どうなったか》</td></tr>
+</table>
+
+<!-- 節4 どう閉じたか。条件10 — 節3 と同じ例で、前と後を対比する -->
+<h2>どう閉じたか</h2>
+<p>《最後にとった手と、その一言の理由》</p>
+<figure>
+<svg viewBox="0 0 700 220" style="width:100%;max-width:700px;height:auto" role="img">
+  <title>《前と後で、追っている例の扱いがどう変わったか》</title>
+  <rect x="20" y="20" width="320" height="180" rx="6" fill="#f7f8fa" stroke="#5f6672"/>
+  <text x="40" y="50" font-size="13"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">《修正前》</text>
+  <text x="40" y="100" font-size="12"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">《追う例 その 1 の扱い》</text>
+  <text x="40" y="130" font-size="12"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#b3402f">《追う例 その 2 の扱い》</text>
+  <rect x="360" y="20" width="320" height="180" rx="6" fill="#f7f8fa" stroke="#5f6672"/>
+  <text x="380" y="50" font-size="13"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">《修正後》</text>
+  <text x="380" y="100" font-size="12"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">《追う例 その 1 の扱い》</text>
+  <text x="380" y="130" font-size="12"
+        font-family="Hiragino Sans, Noto Sans JP, sans-serif" fill="#23262b">《追う例 その 2 の扱い》</text>
+</svg>
+<figcaption>《なぜこれで閉じるのか。1 行》</figcaption>
+</figure>
+
+<!-- 節5 今どこ。数字は必ず分母つき -->
+<h2>今どこ</h2>
+<table>
+  <tr><th>項目</th><th>状態</th></tr>
+  <tr><td>《進んだところ》</td><td>《数字は分母つきで》</td></tr>
+  <tr><td>《止まっているところ》</td><td>《何待ちか》</td></tr>
+</table>
+
+<!-- 節6 決まっていないこと。条件6 — 作業側が未決と書き残したものだけ。提案を書かない -->
+<h2 data-visual="none">決まっていないこと</h2>
+<ul>
+  <li>《作業側が未決と書き残していること》</li>
+</ul>
+
+<!-- 節7 記録の食い違い。条件5 — どれかに寄せない。無ければ「食い違いなし」と明記 -->
+<h2>記録の食い違い</h2>
+<table>
+  <tr><th>記録が言っていること</th><th>実際</th></tr>
+  <tr><td>《どの記録が何と書いているか》</td><td>《確かめた結果》</td></tr>
+</table>
+
+<details>
+<summary>付録 A — 符牒の対応表</summary>
+<table>
+  <tr><th>元の記録の符牒</th><th>本体での呼び名</th></tr>
+  <tr><td>《符牒》</td><td>《日本語の呼び名》</td></tr>
+</table>
+</details>
+
+<details>
+<summary>付録 B — 網羅の記録</summary>
+<p>《変更ファイル一覧、テストの内訳、実測値の全部。引き継ぎ用》</p>
+</details>
+
+<details>
+<summary>付録 C — 読んだもの</summary>
+<ul>
+  <li><code>《パス》</code> — 《そこから取った内容を一言》</li>
+</ul>
+</details>
+
+</body>
+</html>