Lattice 0.79.2

MCP起動例外の発生版が常に0.0.0として記録されていた問題を修正した。配布packageの版と、内蔵serverの読込・生成・起動のどこで例外が起きたかを既存の診断分類へ記録する。

既存の未解決記録とfingerprint式は保持する。過去のMCP起動失敗の原因や復旧は、この診断改善だけで確定しない。

通常CIはmacOS・Linux・Windowsの全gateが成功。公開tarballの整合性とsource一致を照合し、隔離導入した公開版でMCP初期化、8ツールの一覧、索引検索、正常終了を確認した。

Lattice 0.78.1

修正: projectごとのページが、記録された端末名をそのまま出していた（ADR 0198）

• 0.78.0は、これから書く記録とhubの公開一覧からOSのhost名を外したが、projectごとのページの作業記録の欄
  （「来歴…記録者 端末名/agent」）は、過去の記録に書かれた端末名をそのまま出していた。ページはhubを通って
  誰にでも配信される。
• ページは、端末の公開label（terminal- と16進12桁）の形の名前だけをそのまま出す。それ以外の名前は、
  OSのhost名も席が付けた名前も、同じ名前に同じ番号を振った「端末1」「端末2」に置き換える。
• 手元のdashboardと静的な todo gantt の出力も同じ表示になる。元の名前は記録そのもので読める。
• 記録の本体は変えない。agent はそのまま出す。作業記録の本文は対象外。

Lattice 0.78.0

OSのhost名をjournalと公開landingへ出さない（ADR 0197）

• LATTICE_TODO_ACTOR_HOST の無いTodo操作は、OSのhost名を actor.host へ書いていた。journalは
  repositoryへcommitされるので、公開repositoryでは持ち主の名前を含むhost名が誰でも読めた。
• 端末がhubへ送る display_name もOSのhost名で、hubは公開landing（HTMLとJSON）へそのまま出していた。
• どちらも、端末ごとの乱数の識別子から一方向に導いたlabel（terminal- と16進12桁）に替える。同じ端末は
  journalでも公開landingでも同じlabelになり、端末の区別は残る。識別子は
  ~/.lattice/bridge-hub-terminal.json（bridge-hubの識別子と同じfile）で、無ければ最初の操作が作る。
  読めず作れない端末のhostは host になる。
• hubは、端末の自己申告の名前を公開一覧へ出さない。公開の名前は、public-visibility.json の新しい任意の
  キー terminal_display_names（labelをキーにした対応表）に書いた名前、無ければlabelになる。古い版の
  端末がhost名を送ってきても、公開landingには出ない。
• 明示の LATTICE_TODO_ACTOR_HOST は今までどおり優先する。過去のjournalは変わらない。
• 注意: 旧い既定のhostで行った todo start を、新しい既定のhostでは todo retract できない
  （start_actor_mismatch）。retractする時だけ LATTICE_TODO_ACTOR_HOST に旧い値を渡す。
• 名乗りの無い操作の agent は、今もOSの利用者名から作る（今回の対象外）。

Lattice 0.77.0

漏れた通信の失敗を内部故障と分け、重大度を落ちた面で決める（ADR 0196）

• CLIのtyped契約の外へ漏れた例外は、原因を見ずに LATTICE.CLI_INTERNAL_FAILED・high で記録していた。
  通信の失敗（接続の切断、時間切れ）が漏れた時も、内部故障の high になっていた。
• 漏れた通信の失敗は、LATTICE.CLI_TRANSPORT_UNHANDLED として別に記録する。製品が通信の失敗を型つきで
  返せなかった、という対処不良の記録である。観測したcodeは safe_context.cause_code に載る
  （fetch failed のように、codeを cause の側に持つ例外からも拾う）。
• その重大度は落ちた面で決める。何も書き換えないと確かめた面（run.list・todo.status・todo.verify）は
  warn、書き換える面と確かめていない面は high。
• 取消（AbortError）は記録しない。
• todo は、漏れた fetch failed を CONTRACT_VIOLATION（呼び出し側の契約違反）と答えていた。
  INTERNAL_FAILURE と答え、記録に乗せる。
• 処理している通信の失敗（hubへの配達、BugHubへの送信、heartbeat）と取消を記録しない動きは、変わらない。
• 通信でない内部故障とMCPの起動失敗は high のまま。送る項目は増えない。

Lattice 0.76.0

修正: 故障や解決の直後の送信が、受け口に断られていた（ADR 0195）

• 0.74.0・0.75.0では、報告の observed_at を秒へ切り捨てて作っていた。BugHubは、記録の時刻が
  observed_at より後の報告を断る。記録と同じ1秒の中で送ると observed_at が記録より前になり、
  422 invalid_report で断られた。自動送信は記録の直後に走るので、ほとんどの場合これに当たっていた。
• 断られた報告は、最大1時間遅れて送り直されていた。記録は失われていない。
• observed_at を、送る時刻と、載せる記録の時刻のうち最も後の時刻にした。直後の送信が最初の1回で届く。

送信の経路を確かめる reporting verify

• lattice runtime-errors reporting verify --json を足した。記録を載せない空の報告を1通送り、合鍵・署名・
  受け口までの経路・受領の署名を確かめる。確かめられた時だけ verified・exit 0。
• storeの記録と受領の印には触れない。受け口は受領を記録するだけで、issueも通知も動かさない。
• 送信を有効にしていない端末と、合鍵の無い端末では、networkへ触れない。
• 受け口は端末×製品ごとに1分に1回まで受ける。report と続けて打つ時は1分空ける。

v0.75.0

runtime errorの収集と送信がWindowsで動く（ADR 0194）

• Windowsでは、Latticeの故障を1件も記録できなかった（0.73.0からは collection: "unsupported" と答えていた）。
  storeを本人だけが触れる形で置けると確かめる方法が無かったためである。Windowsでも記録し、送れるようにした。
• 確かめ方: icacls でDACLを読み、本人・SYSTEM・Administratorsへの許可だけで出来ている時だけ使う。
  それ以外は、POSIXと同じく store_unsafe で止める。
• 置き場（Windows）:
  • store: %LOCALAPPDATA%\Lattice\runtime-errors\。このフォルダは継承を切って本人・SYSTEM・Administrators
    だけに絞る。他のaccountが触れる形で中身があるフォルダは、絞らずに止める。
  • 送信の設定: %LOCALAPPDATA%\Lattice\runtime-error-reporting.json
  • 合鍵: %LOCALAPPDATA%\bughub\product-credentials\lattice.json。他のaccountが読める形なら
    credential_unsafe（理由 acl_not_owner_only）で、送らない。
• Windowsで収集を有効にするのは lattice runtime-errors reporting enable --json である。有効にするまでは
  collection: "disabled" を返す。unsupported は、macOS・Linux・Windows以外のOSの答えとして残る。
• macOS・Linuxの動きは変わらない。
• 所有者は確かめない（icacls は所有者を返さない）。理由と範囲はADR 0194に書いた。

v0.74.0

runtime errorの送信をLattice自身が持つ（ADR 0193）

• Latticeが、未受領のruntime error記録をBugHubの製品報告の受け口へ自分で送る。これまでは工場
  （dotagents）のreportが運んでいた。
• 既定では通信しない。 送るのは、端末で lattice runtime-errors reporting enable --json を打ち、
  BugHubの持ち主が合鍵のfile（~/.config/bughub/product-credentials/lattice.json）を置いた端末だけ。
  どちらかが欠ければnetworkへ触れない。設定を変えていない端末の動きは今までと同じ。
• 新しいcommand:
  • lattice runtime-errors reporting <status|enable|disable> --json
  • lattice runtime-errors report --json（未受領の分を今送る。受領まで済むか、送るものが無ければexit 0）
• 秘密は通信に載せず、送るバイト列と時刻へのHMAC-SHA256署名だけを付ける。受領済みにするのは、
  署名つきの200が返った時だけ。届いたか分からない時は未受領のまま残し、後から送り直す。
• 送る時機: 故障を記録した直後と、以後のCLI実行（hooks を除く）の終わりに、切り離した子processで送る。
  CLIの応答は待たせない。1分に1回まで、同じ中身の送り直しは1時間に1回まで。
• 送信を有効にした端末では、工場の設定が無くても収集が有効になる。
• LATTICE_RUNTIME_ERROR_REPORTING=0 は、既定の置き場の送信設定を読まない（試験と自動化の口）。
• Windowsは収集に対応しないので、送信も unsupported と答える。

v0.73.0

runtime errorの収集: 対応しないOSは unsupported と答える

• Windowsでは、lattice runtime-errors snapshot／diagnostics が collection: "disabled" を返していた。
  設定が有効でも同じ答えで、「設定で止めている」のか「このOSでは収集できない」のかを区別できなかった。
  Windowsでは collection: "unsupported" を返す。status は not_applicable、cursor は0、記録は空、
  diagnostics のキーは今までと同じ。
• 収集そのものは変わらない。Windowsではstoreの所有者と権限をPOSIXの形で確かめられないので、記録を作らない。
• 受け側の前提: dotagents 49709de 以降（unsupported を受け入れる）。

v0.72.1

修正

• factory-reporter.json の host.profile が linux の端末で、runtime errorの収集が無効になっていた
  （lattice runtime-errors diagnostics が collection: disabled）。Latticeが受ける語の一覧に linux が無く、
  設定全体を無効とみなしていた。工場のLinux workstation（rabbit）では、故障が1件も記録されていなかった。
  dotagentsの契約と同じ5語（server・mac・linux・wsl・windows-native）を受ける。
• 変わらないこと: Windowsでは収集しない。storeの所有者と権限をPOSIXの形で確かめられないので、
  書き込みを store_unsafe で止めている。設定の置き場（%LOCALAPPDATA%\dotagents\factory-reporter\config.json）も
  読まない。windows-native の語は受けるが、記録は作られない。

v0.72.0

runtime error記録: 落ちた面と例外の分類（safe_context）

• BugHubの LATTICE.CLI_INTERNAL_FAILED（mac-kite、26回）は、どのcommandで落ちたかが記録に無く、
  原因を確定できないまま閉じた。新しい記録は固定語彙の分類 safe_context を持つ。
  • command_kind: 落ちたCLIの面（run.list・todo.start 等、Latticeが持つ一覧の語だけ。無ければ other）。
  • error_kind: 例外の種類（Error・TypeError・RangeError・SyntaxError・ReferenceError・
    AggregateError・SystemError、それ以外は other）。
  • cause_code: Nodeが付けるerror code（ENOENT・ERR_MODULE_NOT_FOUND 等。無ければ none）。
  • 3つは必ずそろえる。message本文・path・引数の値・stackは載せない。
• fingerprintは、分類つきの記録では
  sha256(product \0 component \0 error_code \0 message_template \0 command_kind \0 error_kind \0 cause_code)。
  原因が違えば別の記録（BugHubでは別のissue）になる。分類を持たない旧記録は前の式のまま残り、
  新しい発生は旧記録へ加算されない。
• todo のcommandがtyped契約の外で落ちた時（INTERNAL_FAILURE）も、run系と同じ
  LATTICE.CLI_INTERNAL_FAILED として記録する。これまでは記録されなかった。
• 受け側の前提: dotagents 898c6e1 以降（safe_context を受け入れ、同じ式でfingerprintを照合する）と、
  BugHubの lattice 許可キー（command_kind・error_kind・cause_code）。

0.71.2 — 2026-10-03

修正

• todo dashboard ensure が、登録簿のlock待ち切れ（DASHBOARD_REGISTRY_BUSY）やdaemonの無応答
  （DASHBOARD_DAEMON_UNRESPONSIVE）などを INTERNAL_FAILURE とstackの抜粋で返していた。
  登録簿とdaemonの故障はcodeと detail（reason・next_action）を持つtyped errorとして返す。
  再実行で解ける種類は next_action に lattice todo dashboard ensure --json を示す。
• 登録簿のJSONが壊れている時のmessageから、localの絶対pathを外した。