HARUMI
戻る

2026-07 — 2026-08 / 06

Harumi Platform — 運用ループを閉じる

Personal production system個人開発・運用

成果リポジトリ、デプロイ済みリビジョン、実行時の証拠、ロードマップ、永続的な知識が一致するまで本番変更を完了としない、閉じた運用ループを構築しました。

概要

計画、ローカルモデルのチャット、ライブヘルス、文書は既に存在していましたが、互いに隣接するだけのツールでした。ルールはコードからずれ、文書は退役済みワークロードを現役として記し、緑のパイプラインだけでは対象の変更が配信中だと証明できませんでした。

背景

計画、文書、チャット、本番ヘルスは存在していましたが、作業完了時にそれらの一致を強制する仕組みがありませんでした。

システム

Input to System to Evidence to DecisionInputSystemEvidenceDecision

課題

問題は情報不足ではなく、閉ループの欠如でした。同じ事実が manifest・文書・memory・UI に現れても、単一の正本やコピー間の検証がありませんでした。セキュリティ方針は散文にある一方で、追跡対象ファイルには実際の認証情報が残っていました。検索品質も、失敗できる再現可能な質問群なしに語られていました。

調査

最初の仮説

既存 Markdown を Obsidian に入れれば、有用な知識システムになると考えました。

Observe → Frame → Change → Prove → Retain → Re-observe を実行可能な状態機械として定義。正本 Markdown と永続 memory は読み取り専用の Obsidian プロジェクションへ再構築され、リンク識別・出所・鮮度・検索質問がゲートになります。共有 CI scanner は新しい認証情報リテラルを拒否。デプロイ証明は「latest」や「Synced」だけを信じず、Git commit・image・稼働 Pod・実経路を結び付けます。

証拠

Observe → Frame → Change → Prove → Retain → Re-observe
13/13 top-3 retrieval · 0 unresolved · 0 ambiguous

最初の検索 benchmark は 12 問中 8 問しか正本へ到達しませんでした。正本 node と intent を修復後、受入対象 13 問すべてが top 3 以内に到達。2026-08-06 時点の graph は 63 notes、99 native edges、identity defect 0 でした。

退けた修正

Obsidian UI を別の執筆面として扱う案。各事実の第三のコピーを作り、それを守る gate が存在しないため退けました。

判断

正本 Markdown と durable memory だけを source とし、読み取り専用 projection を再構築。graph identity、鮮度、検索、認証情報 scan を実行可能な gate にしました。

結果

2026-08-06 の受入確認はすべてのゲートを通過しました。プロジェクションはリンクと別名をすべて解決し、検索 13 件すべてが top 3 以内で正本に到達。ただし重要なのはその数字ではなく、それが一度きりの計測ではないことです。未解決リンクや曖昧な別名が 1 件でもあれば graph gate が build を止め、稼働中のプロジェクションにはアラートが出るため、この性質は同期のたびに再証明されます。その後プロジェクションは 3 倍以上に成長しましたが、性質は保たれています。意図的に置いた認証情報で CI が失敗し、削除後に緑へ戻ることも実証。同じ runbook で Redis と Kafka の全 identity を本番輪換し、データ復旧、quorum、MakeUp consumer 経路、旧認証拒否まで確認しました。

次に変えること

現在の制約: 3 repository に過去の credential finding が baseline として残っています。gate は増加を防ぎますが、残存 debt の削除はまだ必要です。

次の一手: credential baseline を 0 まで減らし、その後も no-secrets 境界を維持できる、証拠に基づく diagnostic tool だけを追加します。

次のプロジェクト

サーバー前面パネルディスプレイのリバースエンジニアリング