DavidHLPL · RHINE LAB
DavidHLPL 的个人 AI 知识库，使用 LLM 持续整理可追溯的技术与工程知识
后端工程
- Database Schema Drift: Locating with the history, schema, and query Views — Explains why Flyway validate cannot replace an actual Schema check, and uses the three views of migration history, actual schema, and application query to distinguish checksum drift, external DDL, Unknown column, and residue from a failed migration.
- Dubbo + Nacos: Verify the Registration Name and group/version First, Then Run a Real Smoke Test — Based on Apache Dubbo 3.3.6 and official Nacos materials, describes the minimal boundaries of interface-level/application-level registration names, metadata, group/version matching, startup checks, and a real Nacos smoke test.
- Frontend and Miscellaneous Essays: Vue, MyBatis, UniApp, Cache Annotations, and Environment Troubleshooting (archived) — Archived collection of frontend, MyBatis and environment troubleshooting notes. Original evidence remains in immutable raw snapshots.
- AtomicBoolean: Atomic Boolean State and CAS Boundaries — Explains when an atomic boolean state is needed, how compareAndSet combines checking with transition, and where CAS stops helping with multi-field invariants, contention, and coordination.
- AutoCloseable: Resource Ownership and Close-Exception Semantics — Explains AutoCloseable and try-with-resources through resource ownership, reverse close order, primary and suppressed exceptions, and the boundaries of idempotent cleanup.
- Java Concurrency Deep Dive: JUC, CAS, Atomics, Locks, and Threading — Centers on CAS to connect atomics, locks, thread coordination, and reference types with cost boundaries.
- NullValue: The Cache-Null Placeholder and Serialization Boundary — Explains why a cache must distinguish a missing key from a business null, how NullValue prevents repeated negative lookups, and where singleton and serialization semantics stop.
- Java Production Performance Troubleshooting: A Minimal Symptom-to-Evidence Decision Tree — Compresses Java production incidents into a minimal decision tree from symptom and evidence to thread, GC, or code localization, followed by reversible mitigation and recovery.
- JJWT 0.13.0: Explicitly Fixing the Signature Algorithm, Verifying by Key Type — Explains the recommended algorithm heuristic of signWith(Key), the two-argument explicit-algorithm API, the SecretKey/PublicKey type boundaries of verifyWith, and the migration path for the audience builder in JJWT 0.13.0.
- KB Session Ingestion Pipeline Contract: Incremental Reuse, Redaction v19, and Immutable Raw — Pins the minimal contract of the KB session ingestion pipeline at commit c0ae74e: identity/content-hash-driven incremental reuse, no reuse of failed records, redaction v19, internal control-plane filtering, partial checkpoint resume, and immutable raw manifest validation, and clarifies placeholder semantics and redaction boundaries.
- Microservice Data Ownership: Establish the Domain Owner First, Then Talk About Database Splitting and Migration — Establishes an order for determining data ownership with service-private data, bounded context, saga, transactional outbox, and expand-migrate-contract, so a shared physical database, a shared schema, and service autonomy are not conflated.
- MySQL Performance Triage: Symptom → Metric → Layer → Safe Mitigation — Map MySQL slowness, stalls, connection piles, and replication alerts to symptoms, metrics, layers, and safe mitigations across connections, locks, indexes, transactions, Buffer Pool, and I/O—without copying a full SOP.
- MySQL Storage Engines and Deadlock Detection — Distinguishes engine capabilities from deadlock log paths with minimal checks.
- Redis Business Patterns: Caching, Distributed Locks, Message Queues, Feed Streams, and Flash Sales — Anchors on consistency, mutual exclusion, and messaging semantics to distill reusable business patterns.
- Redis Heima Practice: Distributed Cache, Multi-Level Cache, and Best Practices — Condenses 200+ pages of course material into a checklist, flagging version and experimental gaps.
- Redisson/Jackson's Default Serialization Behavior for LocalDateTime and the Write-Read Asymmetry Boundary — Explains why the default JsonJacksonCodec and GenericJackson2JsonRedisSerializer fail at write time for LocalDateTime, that the Redisson default codec is actually Kryo5Codec, and the three-layer decision path for troubleshooting write-read asymmetry.
- Redis Persistence and Internals: RDB/AOF, Data Structures, and Advanced Mechanisms — Distinguishes snapshot vs append-only recovery and performance boundaries.
- Spring Boot and Spring Cloud: Auto-Configuration, Transactions, Service Discovery, Gateway, and Observability — Anchors on service discovery to distill call-chain contracts.
- データベース Schema ドリフト：history、schema、query の三ビューで特定する — Flyway validate が実際の Schema チェックの代わりにならない理由と、migration history、実際の schema、アプリ query の三ビューで checksum ドリフト、外部 DDL、Unknown column、失敗した migration の残骸を区別する方法を説明する。
- Dubbo + Nacos：登録名と group/version を先に確認してから、本物の smoke test を実行する — Apache Dubbo 3.3.6 と Nacos 公式資料に基づき、インターフェースレベル/アプリケーションレベルの登録名、metadata、group/version のマッチング、起動チェック、本物の Nacos smoke test の最小境界を説明する。
- フロントエンドと随筆集：Vue、MyBatis、UniApp、キャッシュ注釈と環境トラブルシューティング（アーカイブ） — フロントエンド、MyBatis、環境調査のノートをまとめたアーカイブです。元の証拠は不変のrawスナップショットに保持されています。
- AtomicBoolean：原子ブール状態と CAS の境界 — 原子ブール状態が必要な条件、compareAndSet が検査と遷移をまとめる仕組み、複数フィールドの整合性や高競合での CAS の限界を整理します。
- AutoCloseable：リソース所有権と close 例外の意味 — リソース所有権を起点に、AutoCloseable と try-with-resources の逆順 close、主例外と suppressed 例外、冪等な後片付けの境界を説明します。
- Java 並行処理の深掘り：JUC、CAS、アトミック、ロックとスレッド機構 — CAS を核にアトミック・ロック・スレッド協調と参照型をコスト境界付きで接続。
- NullValue：キャッシュ null のプレースホルダーとシリアライズ境界 — キャッシュで key 不在と業務上の null を区別する理由、NullValue が負の結果を保持して存在しないデータへの反復問い合わせを抑える仕組み、singleton とシリアライズの境界を整理します。
- Java 本番性能トラブルシューティング：症状から証拠への最小判断木 — Java 本番性能障害を、症状・証拠・スレッド/GC/コード特定・可逆的な止血と復旧の最小判断木に圧縮し、再起動やコマンド一覧を根因分析の代わりにしない方法を示します。
- JJWT 0.13.0：署名アルゴリズムを明示固定し、key 型で検証する — JJWT 0.13.0 における signWith(Key) の推奨アルゴリズムのヒューリスティック、二引数の明示アルゴリズム API、verifyWith の SecretKey/PublicKey 型境界、audience builder の移行方法を説明する。
- KB セッション摂取パイプライン契約：インクリメンタル再利用、redaction v19、不変 raw — 固定コミット c0ae74e における KB セッション摂取パイプラインの最小契約を固定する。ID/コンテンツハッシュ駆動のインクリメンタル再利用、失敗記録の再利用不可、redaction v19、内部コントロールプレーンフィルタ、partial checkpoint からの再開、raw manifest の不変検証を定め、プレースホルダの意味論と機密情報除去境界を明確にする。
- マイクロサービスデータ所有権：領域 owner を先に決めてから、DB 分割と移行を考える — サービス私有データ、bounded context、saga、transactional outbox、expand-migrate-contract でデータ所有権の判定順序を確立し、共有物理データベース、共有 schema、サービス自律を混同しないようにする。
- MySQL パフォーマンス切り分け：現象 → 指標 → 層 → 安全な緩和 — MySQL の遅延、停止、接続滞留、レプリケーション警告を、接続・ロック・インデックス・トランザクション・Buffer Pool・I/O の現象、指標、層、安全な緩和へ対応付ける。完全な SOP は複製しない。
- MySQL ストレージエンジンとデッドロック検出 — エンジン能力とデッドロックログの経路を最小検証で区別。
- Redis ビジネスパターン：キャッシュ、分散ロック、メッセージキュー、Feed と数量限定・時間限定販売 — 一貫性・排他・メッセージ意味を軸に再利用可能なビジネスパターンを蒸留。
- Redis 黒馬実践：分散キャッシュ、マルチレベルキャッシュとベストプラクティス — 200ページ超の教材をチェックリストに圧縮し、バージョンと検証の欠落を明示。
- Redisson/Jackson による LocalDateTime のデフォルト直列化挙動と書き込み・読み出し非対称の境界 — デフォルトの JsonJacksonCodec と GenericJackson2JsonRedisSerializer が LocalDateTime に対して書き込み時に失敗する理由、Redisson のデフォルト codec が実は Kryo5Codec であること、そして三層の設定で書き込み・読み出し非対称を調べる判断経路を説明する。
- Redis 永続化と原理：RDB/AOF、データ構造と高度な仕組み — スナップショットと追記ログの回復と性能境界を区別。
- Spring Boot と Spring Cloud：自動構成、トランザクション、サービス検出、ゲートウェイと可観測性 — サービス検出を起点に呼び出しチェーンの契約を蒸留。
- 数据库 Schema 漂移：用 history、schema 与 query 三视图定位 — 说明 Flyway validate 为什么不能替代实际 Schema 检查，并用 migration history、实际 schema 与应用 query 三个视图区分 checksum 漂移、外部 DDL、Unknown column 和失败迁移残留。
- Dubbo + Nacos：先核对注册名、group/version，再做真实 smoke test — 基于 Apache Dubbo 3.3.6 与 Nacos 官方资料，说明接口级/应用级注册名、metadata、group/version 匹配、启动检查和真实 Nacos smoke test 的最小边界。
- 前端与综合随笔：Vue、MyBatis、UniApp、缓存注解与环境排障（已溶解归档） — 历史随笔收纳袋已溶解。零散前端、MyBatis 与环境排障内容保留在不可变 raw 快照中，主知识库不再维护此综合页。
- AtomicBoolean：原子布尔状态与 CAS 边界 — 说明何时需要原子布尔状态，compareAndSet 如何把检查与切换合并，以及 CAS 在多变量一致性、高竞争和复杂协作中的边界。
- AutoCloseable：资源所有权与关闭异常语义 — 从资源所有权出发解释 AutoCloseable 与 try-with-resources 的关闭顺序、主异常和 suppressed 异常语义，并划定 close 幂等与失败处理边界。
- Java 并发深度：JUC、CAS、原子类、锁与线程机制 — 以 CAS 为内核，串联原子类、锁、线程协作与引用类型，明确无锁与有锁的适用成本。
- NullValue：缓存 null 的占位对象与序列化边界 — 说明缓存层为什么需要区分 key 不存在与业务 null，NullValue 如何作为占位对象防御缓存穿透，以及单例和序列化在边界上的限制。
- Java 线上性能排障：从症状到证据的最小决策树 — 把 Java 线上性能事故压缩为症状、证据、线程/GC/代码定位、止损与恢复的最小决策树，避免用重启或命令清单替代根因分析。
- JJWT 0.13.0：显式固定签名算法，按 key 类型验签 — 说明 JJWT 0.13.0 中 signWith(Key) 的推荐算法启发式、双参数显式算法 API、verifyWith 的 SecretKey/PublicKey 类型边界，以及 audience builder 的迁移方式。
- KB 会话摄入管道契约：增量复用、redaction v19 与不可变 raw — 固定提交 c0ae74e 中 KB 会话摄入管道的最小契约：身份/内容哈希驱动增量复用、失败记录不复用、redaction v19、内部控制面过滤、partial checkpoint 断点续跑与 raw manifest 不可变校验，并澄清占位符语义与脱敏边界。
- 微服务数据所有权：先定领域 owner，再谈拆库与迁移 — 用服务私有数据、bounded context、saga、transactional outbox 和 expand-migrate-contract 建立数据所有权判定顺序，避免把共享物理数据库、共享 schema 和服务自治混为一谈。
- MySQL 性能排查：现象→指标→定位层→安全缓解 — 把 MySQL 慢、卡、连接堆积和复制告警映射为现象、指标、定位层与安全缓解，覆盖连接、锁、索引、事务、Buffer Pool 和 IO，但不替代现场 SOP。
- MySQL 存储引擎与死锁检测 — 区分存储引擎能力与死锁检测路径，提供存储选型与排障的最小判断。
- Redis 业务模式：缓存、分布式锁、消息队列、Feed 流与秒杀 — 以缓存一致性、锁正确性、消息语义为锚，收敛 Redis 在业务场景中的模式与反模式。
- Redis 黑马实战与进阶：分布式缓存、多级缓存与最佳实践 — 把黑马 Redis 实战提炼为分布式缓存、多级缓存与最佳实践的最小可用清单，标注版本与实验缺口。
- Redisson/Jackson 对 LocalDateTime 的默认序列化行为与写读不对称边界 — 说明默认 JsonJacksonCodec 与 GenericJackson2JsonRedisSerializer 为什么对 LocalDateTime 写入即失败、Redisson 默认 codec 实为 Kryo5Codec，以及按三层配置排查写读不对称的决策路径。
- Redis 持久化与原理：RDB/AOF、数据结构与高级机制 — 区分 RDB/AOF 持久化、底层数据结构与过期淘汰，明确持久化选择的可用性与性能边界。
- Spring Boot 与 Spring Cloud：自动装配、事务、注册发现、网关与可观测性 — 以服务注册发现为起点，归纳自动装配、事务、熔断限流与可观测性的配置与运行边界。
系统运维
- containerd TLS: Choosing a Trusted Chain or Temporary Verification Bypass — A layer-by-layer decision model for private-registry pull failures: separate certificate trust, containerd configuration, Kubernetes credentials, and node cache, then choose a production CA or a temporary skip_verify probe.
- Database Written-Test Review: From SQL Semantics to Batch Data Processing — A database written-test review as a verifiable chain of judgments: separate SQL semantics from dialects, handle NULLs, duplicates, and empty results, then bring Kettle and very large table operations down to sharding, recovery, reconciliation, and risk control.
- HBase Fundamentals, Architecture, and Operations: Data Model, Table Design, Shell, and Java API — Converges logical/physical models, architecture, table design, and operational tooling; clarifies trade-offs vs RDBMS.
- SSH Intranet Access: Connection Direction, Exposure, and Recovery — A five-axis comparison of Cloudflare Tunnel, Tailscale, and FRP—connection direction, exposure, control plane, data plane, and recovery—with evidence-backed boundaries for mobile clients, ports, and systemd/linger.
- Java Backend Interview Retrospective: Project Truth, Engineering Mechanisms, and Production Evidence — Synthesizes a capability model that moves from proving project ownership, through cache and asynchronous mechanisms, to production evidence for diagnosis, mitigation, and recovery.
- Spark and Big Data Ecosystem: Hadoop, HBase, Spark Runtime Modes, and Clusters — Compares batch/stream engines and Spark runtime modes.
- Testcontainers 1.20.6: Rule Out the Docker API Version First, Then Judge the daemon Unavailable — Explains how Testcontainers 1.20.6 falls back to 1.32 for an unknown Docker API version, why DOCKER_API_VERSION should not borrow Docker CLI experience, and how to distinguish version incompatibility from a missing Docker environment starting from the earliest 400 error.
- containerd TLS：信頼チェーンと一時的な検証スキップの判断 — プライベートレジストリの pull 失敗を、証明書信頼・containerd 設定・Kubernetes の認証情報・ノードキャッシュに分解し、本番 CA と一時的な skip_verify の境界を判断するためのモデル。
- データベース筆記試験の復盤：SQL セマンティクスからバッチ処理まで — データベース筆記試験を検証可能な判断の連鎖として振り返る。SQL の意味と方言を分け、NULL・重複・空結果を扱い、最後に Kettle と巨大テーブルの操作を分割・復旧・照合・リスク管理へ落とし込む。
- HBase 基礎・アーキテクチャと運用：データモデル、テーブル設計、Shell と Java API — 論理/物理モデル、アーキテクチャ、テーブル設計と運用を収束し、RDBMS とのトレードオフを明確化。
- SSH 内網アクセス：接続方向・公開面・障害復旧 — Cloudflare Tunnel、Tailscale、FRP を接続方向・公開面・コントロールプレーン・データプレーン・復旧の 5 軸で比較し、モバイルクライアント、ポート、systemd/linger の根拠付き境界を整理する。
- Java バックエンド面接の振り返り：プロジェクトの真正性、設計機構、実運用の証拠 — プロジェクトの ownership の証明、cache/非同期の機構、本番での診断・止血・復旧の証拠を一つの能力モデルに統合します。
- Spark とビッグデータエコシステム：Hadoop、HBase、Spark 実行モードとクラスタ — バッチ/ストリームエンジンと Spark 実行モードを比較。
- Testcontainers 1.20.6：Docker API バージョンを先に切り分けてから、daemon の利用不可を判断する — Testcontainers 1.20.6 が未知の Docker API バージョンを 1.32 にフォールバックする仕組み、DOCKER_API_VERSION に Docker CLI の経験を当てはめるべきでない理由、そして最も早い 400 エラーからバージョン非互換と Docker 環境の欠落を区別する方法を説明する。
- containerd TLS：证书信任链与临时跳过验证的决策 — 用一条可验证的链路判断私有镜像拉取失败属于证书信任、Kubernetes 凭证还是节点缓存，并比较生产 CA 信任与临时 skip_verify 的边界。
- 数据库笔试复盘：从 SQL 语义到批量数据处理 — 把一套数据库笔试题复盘为可验证的判断链：先分清 SQL 语义与方言，再处理 NULL、重复与空结果，最后把 Kettle 和超大表操作落到分片、恢复、对账与风险控制。
- HBase 基础、架构与运维：数据模型、表设计、Shell 与 Java API — 收敛 HBase 数据模型（逻辑/物理）、架构组件、表设计与运维操作，明确与 Redis/传统 RDBMS 的取舍。
- SSH 内网访问方案：连接方向、暴露面与故障恢复 — 以连接方向、暴露面、控制平面、数据平面和故障恢复比较 Cloudflare Tunnel、Tailscale 与 FRP，并提炼移动端限制、端口语义和 systemd/linger 的可验证边界。
- Java 后端面试复盘：项目真实性、工程机制与生产证据 — 把项目真实性、缓存与异步机制、线上性能排障串成一套能力模型：先说明自己负责的事实，再解释工程取舍，最后用生产证据证明系统如何被验证和恢复。
- Spark 与大数据生态：Hadoop、HBase、Spark 运行模式与集群 — 对比分布式计算引擎，收敛 Spark 概述、运行模式与 Hadoop/HBase 集群搭建的最小验证。
- Testcontainers 1.20.6：先排查 Docker API 版本，再判断 daemon 不可用 — 说明 Testcontainers 1.20.6 如何将未知 Docker API 版本回退到 1.32、为什么 DOCKER_API_VERSION 不应套用 Docker CLI 经验，以及如何从最早的 400 错误区分版本不兼容和 Docker 环境缺失。
AI 工具
- Docker Fundamentals: Image Layers, Container Operations, and Compose Networking — Distills Docker image layers, common commands, volumes, networking, and Compose suitability and boundaries.
- Headroom with cc-switch / Claude Code Coexistence: Single Synthesis and Security Boundaries — Synthesizes pinned project commits and runtime evidence: how Headroom 8787 receives Claude Code Messages before cc-switch 15721, keeping the OMP path isolated, a single synthesis responsibility, and a rollback-safe systemd security boundary.
- Headroom 0.34 Compression and Retrieval Contract: Fields, Modes, and Real-Endpoint Tests — Pins the Headroom 0.34.0 /v1/compress and /v1/retrieve request, response, and mode boundaries, and explains why mocks and real loopback contract tests must share one schema.
- Headroom Single-Port Synthesis: Entry, Dynamic Upstreams, and Verification Boundaries — Synthesizes the Headroom single-port routing model: one loopback entry can serve explicitly configured custom providers and dynamic upstreams while preserving protocol differences. It separates OMP role selection, model_cache, request routing, and wrapper lifecycle and verifies each layer independently. Historical routes remain provisional.
- Hindsight Fully Local Deployment and Unified Memory Integration for OMP / Codex (archived) — Historical integrated page, split into deployment, agent integration and troubleshooting pages. Retained as an archive guide.
- Hindsight Local Compute Allocation and Dockerized Deployment — Documents the local compute split for the Vectorize Hindsight memory hub (AMD GPU inference plus CPU embedding), the UID 1000 permission model, and Docker Compose container orchestration.
- Hindsight Unified Memory Access: FastMCP Bridge and Dynamic Multi-Project Routing — Explains the FastMCP stdio bridge state machine, Git-root-adaptive dynamic Bank routing, and dual-client configuration used to give OMP and Codex unified access to Hindsight memory.
- Hindsight Runtime Troubleshooting Matrix and Failure Modes — Summarizes seven typical failure modes in Hindsight local deployment and Agent integration (wrong package, permissions, timeout, routing, lost Session, and workspace drift) with a troubleshooting matrix.
- The LLM-Wiki Pattern: Maintaining a Compounding Personal Knowledge Base — The operating manual for DavidHLPL's personal AI knowledge base: raw sources, wiki pages, schema, and the ingest/query/lint loop.
- MCP Protocol Era Boundary and the codebase-memory-mcp v0.10.2 Graph Workflow — The boundary and error codes between the MCP 2026-07-28 modern per-request _meta and the legacy initialize handshake, plus the codebase-memory-mcp v0.10.2 graph-search workflow: graph results are not a completeness proof, and negative conclusions must return to coverage and source code.
- Multi-Service Startup Readiness: running, ready, and Dependency/Failure/Restart Propagation — Uses a decision table to distinguish six concepts in multi-service orchestration — process startup, business readiness, ordering, dependency establishment, and failure/restart propagation — and gives the minimal combinations and verification paths for Compose healthcheck/depends_on and systemd After/Wants/Requires.
- OMP Configuration Layers: Model Roles, Agent Overrides, and Fallback Chains — A reusable model for OMP configuration layers: modelRoles selects a role default, agentModelOverrides supplies a local exception, and fallbackChains recovers after failure; the page also separates Headroom, rule discovery, and model selection and gives an ordered validation method.
- Headroom Route Persistence Synthesis: Named Profiles, model_cache, and Recovery — Synthesizes Headroom route persistence when OMP rewrites runtime model caches: Named Profiles isolate intent and credentials, an external declaration can preserve route intent, model_cache remains rebuildable derived state, and the legacy reconciler is limited to isolated migration recovery. Current wrapper lifecycle and version dependencies are explicit.
- OMP Headroom Bridge: External Routing Controller and Native Codex/OMP Proxy Boundaries — Documents how OMP Headroom Bridge uses an external controller to maintain the coexistence boundaries between a loopback Headroom, OMP provider routes, the native Codex CLI/Desktop Responses provider, and Claude Code/cc-switch.
- OMP Hook Extension Concept: Decision-Point Nudges, Hard Blocks, and Status Bridges — Treats an OMP Hook as an event extension at a tool decision point: sendMessage supplies a soft nudge without blocking, a hard result can reject a call, and setStatus bridges state into the UI. Includes API boundaries, mock and live-session checks, and the explicit warning that a suggestion is not a security boundary.
- Plugin Lifecycle Management at Million-Endpoint Scale: State, Heartbeats, and Controlled Release — A control-plane model for making plugin install, upgrade, uninstall, and rule delivery converge safely through a desired/current/ack/failure state machine, merged heartbeats, idempotent dispatch, canary circuit breakers, and explicit source assumptions about scale and endpoint capabilities.
- Docker 基礎：イメージレイヤー、コンテナ操作と Compose ネットワーク — Docker のイメージレイヤー、常用コマンド、ボリューム、ネットワークと Compose の適用条件と境界を整理。
- Headroom と cc-switch / Claude Code の共存：単一の整理責任とセキュリティ境界 — 固定プロジェクトコミットとランタイム証拠を総合する。Headroom 8787 が cc-switch 15721 の前で Claude Code Messages を受け、OMP パスを分離し、単一の整理責任とロールバック可能な systemd セキュリティ境界を保つ方法を記録する。
- Headroom 0.34 圧縮・取得契約：フィールド、モード、実エンドポイント検証 — Headroom 0.34.0 の /v1/compress と /v1/retrieve の request、response、mode の境界を固定し、mock と実 loopback contract test が同じ schema を使う必要性を説明する。
- Headroom 単一ポートの総合：入口、動的上流、検証の境界 — Headroom 単一ポートルーティングのモデルを総合する。明示的に設定した custom provider と動的上流を一つの loopback 入口で扱いながらプロトコル差を保持し、OMP のロール選択、model_cache、リクエストルート、wrapper ライフサイクルを分離して検証する。過去のルートは provisional である。
- Hindsight 完全ローカルデプロイと OMP / Codex 統一メモリ連携の実践（アーカイブ） — デプロイ、エージェント連携、障害調査に分割された歴史的な統合ページです。アーカイブ案内として保持されています。
- Hindsight のローカル計算資源分担と Docker コンテナ化デプロイ — Vectorize Hindsight 記憶ハブのローカル計算資源分担（AMD GPU 推論 + CPU Embedding）、UID 1000 の権限モデル、Docker Compose によるコンテナオーケストレーションを記録する。
- Hindsight 統合メモリアクセス：FastMCP ブリッジと動的マルチプロジェクトルーティング — OMP と Codex が Hindsight メモリへ統合アクセスするための FastMCP stdio ブリッジ状態機械、Git ルート適応型の動的 Bank ルーティング、両クライアントの設定規約を解説する。
- Hindsight ランタイムトラブルシューティングマトリクスと失敗モード — Hindsight のローカルデプロイと Agent 統合における典型的な 7 つの失敗モード（誤パッケージ、権限、タイムアウト、ルーティング、Session 消失、ワークスペースドリフト）と調査マトリクスをまとめる。
- LLM-Wiki パターン：LLM で蓄積する個人 AI ナレッジベース — DavidHLPL 個人 AI ナレッジベースの運用説明。raw、wiki、schema の三層と ingest/query/lint の流れを定義する。
- MCP プロトコル時代の境界と codebase-memory-mcp v0.10.2 のグラフワークフロー — MCP 2026-07-28 modern の request 単位 _meta と legacy initialize ハンドシェイクの境界とエラーコード、および codebase-memory-mcp v0.10.2 のグラフ検索ワークフロー。グラフ結果は完全性の証明ではなく、否定的結論は coverage とソースに立ち戻らなければならない。
- マルチサービス起動レディネス：running、ready と依存/失敗/再起動の伝播 — 一つの決定表でマルチサービスオーケストレーションにおけるプロセス起動、業務レディネス、順序付け、依存確立、失敗と再起動の伝播という六つの概念を区別し、Compose の healthcheck/depends_on と systemd の After/Wants/Requires の最小組み合わせと検証経路を示す。
- OMP 設定の階層：モデルロール、Agent オーバーライド、フォールバックチェーン — OMP 設定を再利用可能な階層モデルとして整理する。modelRoles はロールのデフォルトを選び、agentModelOverrides は局所的な例外を指定し、fallbackChains は障害後に復旧する。Headroom、ルール検出、モデル選択の境界と、順序付き検証方法も示す。
- Headroom ルート永続化の総合：Named Profile、model_cache、復旧 — OMP が runtime model cache を書き換える場合の Headroom ルート永続化を総合する。Named Profile は意図と資格情報を分離し、外部宣言はルート意図を保持し、model_cache は再生成可能な派生状態とする。旧 reconciler は隔離した移行復旧だけに限定し、現在の wrapper ライフサイクルとバージョン依存も明記する。
- OMP Headroom Bridge：外部ルーティングコントローラとネイティブ Codex/OMP プロキシ境界 — OMP Headroom Bridge が外部コントローラで loopback Headroom、OMP provider route、ネイティブ Codex CLI/Desktop Responses provider、Claude Code/cc-switch の共存境界をどう維持するかを記録する。
- OMP Hook 拡張の概念：意思決定ポイントのヒント、ハードブロック、ステータス橋渡し — OMP Hook をツール意思決定ポイントのイベント拡張として整理する。sendMessage はブロックせずソフトヒントを渡し、ハード結果は呼び出しを拒否し、setStatus は状態を UI へ橋渡しする。API の境界、mock と実セッションの検証、提案機構をセキュリティ境界にしない原則を示す。
- 百万端末のプラグインライフサイクル管理：状態・ハートビート・制御されたリリース — desired/current/ack/failure 状態機械を中心に、マージハートビート、冪等ディスパッチ、カナリアとサーキットブレーカ、障害復旧を一つの制御プレーンとして捉える。百万級の規模と端末能力の差はソースにある設計仮定として扱う。
- Docker 基础：镜像分层、容器操作与 Compose 网络 — 归纳 Docker 镜像分层、常用命令、数据卷、网络与 Compose 的适用条件与边界。
- Headroom 与 cc-switch / Claude Code 共存：单一整理与安全边界 — 综合固定项目提交与运行时证据：Headroom 8787 如何在 cc-switch 15721 前承接 Claude Code Messages，保持 OMP 路径隔离、单一整理责任和可回滚的 systemd 安全边界。
- Headroom 0.34 压缩与检索契约：字段、模式与真实端点验证 — 固定 Headroom 0.34.0 的 /v1/compress 与 /v1/retrieve 请求、响应和模式边界，并说明为何真实 loopback contract test 必须与 mock 使用同一 schema。
- Headroom 单端口路由综合：入口、动态上游与验证边界 — 综合 Headroom 单端口路由的演进模型：一个 loopback 入口如何承接显式 custom provider、动态上游和不同协议，并把 OMP 角色选择、model_cache、请求级路由与 wrapper 生命周期分开验证。历史路由均标为 provisional。
- Hindsight 完全本地化部署与 OMP / Codex 统一记忆集成实践（已拆分归档） — 历史巨石页面已按 LLM-Wiki 原子化原则拆分为部署、接入与排障 3 个独立正典知识页。本页作为归档导引保留。
- Hindsight 本地算力分工与 Docker 容器化部署 — 记录 Vectorize Hindsight 记忆中枢的本地算力分工（AMD GPU 推理 + CPU Embedding）、UID 1000 权限模型与 Docker Compose 容器化编排。
- Hindsight 统一记忆接入：FastMCP 桥接与多项目动态路由 — 详解 Hindsight 为 OMP 与 Codex 统一接入记忆的 FastMCP stdio 桥接状态机、Git 根目录自适应 Bank 动态路由及双端配置规范。
- Hindsight 记忆系统运行时排障矩阵与失效模式 — 归纳 Hindsight 本地部署与 Agent 集成中的 7 大典型失效模式（假包、权限、超时、路由、Session丢失、工作区漂移）与排查矩阵。
- LLM-Wiki 模式：用 LLM 增量维护一个持久的个人知识库 — 本页是 DavidHLPL 个人 AI 知识库的自我说明书，解释 raw、wiki、schema 三层和 ingest、query、lint 三个操作。
- MCP 协议时代边界与 codebase-memory-mcp v0.10.2 图工作流 — MCP 2026-07-28 modern 逐请求 _meta 与 legacy initialize 握手的边界及错误码，以及 codebase-memory-mcp v0.10.2 的图搜索工作流：图结果不等于完整性证明，负面结论必须回到 coverage 与源码。
- 多服务启动就绪：running、ready 与依赖/失败/重启传播 — 用一张决策表区分多服务编排中的进程启动、业务就绪、排序、依赖建立、失败与重启传播六个概念，给出 Compose healthcheck/depends_on 与 systemd After/Wants/Requires 的最小组合和验证路径。
- OMP 配置分层：模型角色、Agent 覆盖与降级链 — 用可复用的分层模型解释 OMP 配置：modelRoles 负责角色默认路由，agentModelOverrides 负责局部覆盖，fallbackChains 负责故障后的恢复；同时划清 Headroom、规则发现与模型选择的边界，并给出按层验证的顺序。
- Headroom 路由持久化综合：Named Profile、model_cache 与恢复 — 综合 OMP 更新重写运行时模型缓存时的 Headroom 路由持久化模型：Named Profile 隔离意图与凭据，外部声明保存路由意图，model_cache 作为可重建派生状态，旧 reconciler 只在隔离迁移中恢复并验证。当前 wrapper 生命周期与版本依赖明确标为 provisional。
- OMP Headroom Bridge：外部路由控制器与原生 Codex/OMP 代理边界 — 记录 OMP Headroom Bridge 如何用外部控制器维护 loopback Headroom、OMP provider route、原生 Codex CLI/Desktop Responses provider 和 Claude Code/cc-switch 共存边界。
- OMP Hook 扩展概念：决策点提示、硬阻断与状态桥接 — 把 OMP Hook 抽象为位于工具决策点的事件扩展：soft hook 用 sendMessage 提醒但不阻断，hard result 才能拒绝调用；setStatus 通过事件桥接到 UI。页面给出 API 边界、mock 与真实会话验证，并明确软提示不是安全强制边界。
- 百万级终端插件生命周期管理：状态、心跳与受控发布 — 把终端插件管理建模为一个可收敛的控制面：用 desired/current/ack/failure 状态机连接合并心跳、幂等调度、灰度熔断与故障恢复，并标出来源中的规模与能力假设。
项目实践
- Why Async Early Expiration Only Shortens TTL: Version CAS Makes Stale Jobs Harmless — How ResiCache uses cache-value versions, Redis Lua CAS, and the normal miss path to prevent an old asynchronous job from modifying a newer cache value.
- ResiCache's Cache Responsibility Chain: Control Flow, Nested Fragments, and Observer Lifecycles — How ResiCache's current line uses HandlerResult, handler snapshots, in-lock fragments, and observer scope tokens to preserve control-flow and lifecycle boundaries in a cache responsibility chain.
- ResiCache: Observer Nested Execution Must Distinguish Lifecycle, Fragments, and Scope Tokens — Distills from a public ResiCache fixed commit the boundaries of the observer lifecycle, lock-held fragments, per-call scope tokens, and ThreadLocal snapshot isolation, to avoid nested execution re-firing hooks or polluting concurrent state.
- Replacing a Redis Serializer Is Not a One-Line Configuration Change: Object Trust and Rollback-Safe Migration — Why wire format, type trust, and migration of existing data must be designed together, based on ResiCache's secure deserialization and migration engine.
- Why Cache Stampedes Need a Future, a Distributed Lock, and a Double-Check — What single-flight, distributed locking, double-checking, and failure-result modeling each solve in ResiCache's load path—and what they cannot guarantee.
- ResiCache: Verifiable Concurrency and Consistency Boundaries for Cache Protection — Examines five designs in pinned source and boundary tests: responsibility chains, single-flight, versioned early expiration, whitelist serialization, and observer lifecycles, while separating repository evidence from production performance claims.
- Enhanced UISA: Owners, Boundaries, and Recovery for Heterogeneous-Node Sync — A synthesis of Enhanced UISA and the plugin-lifecycle source, reorganized around owner/boundary, sync protocol, reliability and idempotency, heterogeneous nodes, failure recovery, and trade-offs rather than an architecture-blog sequence. Scale and thresholds remain source assumptions, not production promises.
- UltiCode Async Execution Contract: Idempotency, Fingerprints, and Bounded Receipts — How UltiCode lets synchronous previews and asynchronous execution share a contract, using idempotency keys, SHA-256 fingerprints, a state machine, and memory limits to constrain long-running jobs.
- UltiCode Verification and Supply-Chain Gates: From Static Contracts to Verifiable Releases — How UltiCode organizes zero-infra static contracts, layered verification, Trivy, SBOM, provenance, and Cosign into traceable delivery gates.
- Treat a Modular Monolith as a Testbed: UltiCode Core's Allowlist, Timeouts, and Close-Once Lifecycle — How UltiCode Core's owner-context manager uses opt-in, an allowlist, bounded startup, and close-once handoff to keep a modular monolith a reversible topology testbed.
- UltiCode Docker Sandbox: Resource Isolation and Infrastructure Error Classification — What UltiCode's D-form execution path says about Docker resource and security parameters, fail-closed seccomp handling, and the distinction between user and infrastructure errors.
- A Database Lease Is Not Enough: UltiCode Uses Fence Tokens to Stop Stale Singleton Jobs — Why an expiry time alone is insufficient, and how UltiCode's fenced_job_leases and reconciliation-run writes invalidate an old executor at the database boundary.
- UltiCode Generation and attemptId: Fencing Stale Judging Results with Conditional Updates — How UltiCode uses generations, attemptIds, leases, and conditional updates to stop rejudges, timeouts, or old workers from overwriting newer state.
- UltiCode Outbox and Redis Streams: Making Judge Delivery Recoverable — How UltiCode uses a database outbox, atomic Redis Streams delivery, retries/dead letters, and PEL recovery to turn a judging message into recoverable state.
- UltiCode Data Owners and Fact Snapshots: Keeping Cross-Service Submissions Bounded — How UltiCode's owner boundaries and SubmissionFactsSnapshot turn the source, capture time, and schema version of cross-service facts into an explicit contract.
- Do Not Audit Across Owners by Writing Across Databases: UltiCode's Local Outbox and Consumer Inbox — How Auth/App local audit outboxes, owner-specific Redis Streams, and an Admin consumer inbox handle double writes, duplicate delivery, lease recovery, and eventual consistency across owners.
- UltiCode: Verifiable Boundaries for Online Judging and Agent Engineering — A source-based study of owner boundaries, snapshots, recoverable delivery, result fencing, Docker isolation, asynchronous contracts, and supply-chain gates, with explicit evidence limits.
- 非同期の早期期限切れが TTL 短縮だけを行う理由：version CAS で古い task を無効化する — キャッシュ値の version、Redis Lua CAS、通常の miss 経路を使い、古い非同期 task が新しい cache value を変更しないようにする ResiCache の方法。
- ResiCache の cache responsibility chain：control flow、nested fragment、observer lifecycle — HandlerResult、handler snapshot、lock 内 fragment、observer scope token を使い、cache responsibility chain の control flow と lifecycle 境界を保つ ResiCache の現在の実装を分析する。
- ResiCache：observer のネスト実行はライフサイクル、fragment、scope token を区別しなければならない — 公開 ResiCache の固定コミットから、observer ライフサイクル、ロック内 fragment、per-call scope token、ThreadLocal スナップショット分離の境界を抽出し、ネスト実行での hook の二重発火や並行状態の汚染を避ける。
- Redis serializer の交換は一行の設定変更ではない：object trust から rollback 可能な migration へ — ResiCache の安全な deserialization と migration engine から、wire format、type trust、既存データ migration を一緒に設計すべき理由を説明する。
- cache stampede に Future、distributed lock、double-check が同時に必要な理由 — ResiCache の load path で single-flight、distributed lock、double-check、failure result model がそれぞれ解決する問題と、保証しないことを整理する。
- ResiCache：キャッシュ保護を検証可能な並行性・一貫性の境界にする — 固定ソースと境界テストから、責任チェーン、single-flight、version 付き早期期限切れ、ホワイトリスト・シリアライズ、observer の五つの設計を整理し、本番性能の結論とは区別する。
- Enhanced UISA：異種ノード同期の owner・boundary・復旧モデル — Enhanced UISA とプラグインライフサイクルの raw を、owner/boundary、同期プロトコル、信頼性と冪等性、異種ノード、障害復旧、trade-offs の順に総合する。規模と閾値は本番保証ではなく、ソースの仮定として扱う。
- UltiCode 非同期実行コントラクト：冪等性、フィンガープリント、上限付き receipt — UltiCode が同期プレビューと非同期実行で同じコントラクトを共有し、冪等キー、SHA-256 フィンガープリント、状態機械、メモリ上限で長時間タスクを制約する方法。
- UltiCode の検証とサプライチェーンゲート：static contract から検証可能なリリースへ — zero-infra の static contract、段階的検証、Trivy、SBOM、provenance、Cosign を追跡可能な delivery gate として組み立てる UltiCode の方法。
- modular monolith を実験場として扱う：UltiCode Core の allowlist、timeout、close-once lifecycle — UltiCode Core の owner-context manager が opt-in、allowlist、起動上限、close-once handoff を使い、modular monolith を可逆な topology testbed に限定する方法。
- UltiCode Docker sandbox：リソース隔離とインフラエラーの分類 — UltiCode の D-form 実行経路から、Docker のリソース・安全パラメータ、seccomp の fail-closed、ユーザーエラーとインフラエラーの分類を整理する。
- database lease だけでは足りない：UltiCode の fence token で期限切れ singleton task を止める — 期限時刻だけでは不十分な理由と、UltiCode の fenced_job_leases と reconciliation run の write path が database 境界で古い executor を無効にする方法。
- UltiCode の generation と attemptId：条件付き更新で古い判定結果を遮断する — generation、attemptId、lease、条件付き更新によって、再判定・タイムアウト・古い Worker の結果が新しい状態を上書きしないようにする UltiCode の方法。
- UltiCode Outbox と Redis Streams：判定タスクの配送を復旧可能な状態にする — データベース outbox、Redis Streams の atomic delivery、retry/dead letter、PEL 回収によって、判定メッセージを復旧可能な状態へ変える UltiCode の方法。
- UltiCode の Data Owner と fact snapshot：サービス間 submit の境界を保つ — UltiCode の owner 分割と SubmissionFactsSnapshot から、サービス間 submit に必要な事実の出所・取得時刻・schema version を明示的なコントラクトにする方法を説明する。
- Owner 間 audit を cross-database write にしない：UltiCode の Local Outbox と Consumer Inbox — Auth/App の local audit outbox、owner-specific Redis Stream、Admin consumer inbox から、owner 間 audit の double write、重複 delivery、lease 回復、eventual consistency を説明する。
- UltiCode：オンラインジャッジと Agent 工学の検証可能な境界 — owner 境界、事実スナップショット、配送回復、結果 fence、Docker 隔離、非同期契約、供給網ゲートをソースから整理し、証拠の限界を明示する。
- 异步提前过期为什么只缩短 TTL：用版本 CAS 让旧任务自动失效 — 分析 ResiCache 如何用缓存值版本、Redis Lua CAS 和正常 miss 路径，避免旧异步任务误修改新缓存值。
- ResiCache 的缓存责任链：控制流、嵌套 fragment 与 observer 生命周期 — 从 ResiCache 当前主线分析 HandlerResult、handler snapshot、锁内 fragment 与 observer scope token 如何共同保持缓存责任链的控制流和生命周期边界。
- ResiCache：observer 嵌套执行必须区分生命周期、fragment 与 scope token — 从公开 ResiCache 固定提交提炼 observer 生命周期、锁内 fragment、per-call scope token 与 ThreadLocal 快照隔离的边界，避免嵌套执行重复 hook 或污染并发状态。
- 换 Redis 序列化器不是改一行配置：从对象信任到可回滚迁移 — 从 ResiCache 的安全反序列化和迁移引擎分析，为什么 wire format、类型信任和存量数据迁移必须一起设计。
- 缓存击穿时，为什么要同时有 Future、分布式锁和 double-check？ — 从 ResiCache 的加载路径分析 single-flight、分布式锁、double-check 和失败结果建模分别解决什么问题，以及它们不能保证什么。
- ResiCache：把缓存防护写成可验证的并发与一致性边界 — 以 ResiCache 当前 main 的源码与边界测试为证据，提炼责任链、single-flight、版本化提前过期、白名单序列化和 observer 生命周期五个工程亮点，并明确与生产性能结论的距离。
- Enhanced UISA：异构节点信息同步的 owner、边界与恢复模型 — 综合 Enhanced UISA 与插件生命周期来源，按 owner/boundary、同步协议、可靠性与幂等、异构节点、失败恢复和权衡重组一套可验证的控制面模型；不把来源中的规模与阈值当作生产承诺。
- UltiCode 异步执行契约：idempotency、fingerprint 与有界 receipt — 解释 UltiCode 如何让同步预览与异步执行共享 contract，并用幂等键、SHA-256 fingerprint、状态机和内存上限约束长任务。
- UltiCode 验证与供应链门禁：从 static contract 到可验证发布 — 提炼 UltiCode 如何将 zero-infra static contract、分层验证、Trivy、SBOM、provenance 与 Cosign 组织成可追溯的交付门禁。
- 把模块化单体当实验场：UltiCode Core 的 Allowlist、超时与 Close-once 生命周期 — 从 UltiCode Core 的 owner context 管理器出发，解释如何用 opt-in、allowlist、有界启动和 close-once 交接，把模块化单体限制为可回滚的拓扑实验场。
- UltiCode Docker 沙箱：资源隔离与基础设施错误分类 — 从 UltiCode 的 D-form 执行路径提炼 Docker 资源/安全参数、seccomp fail-closed 和用户错误与基础设施错误分类。
- 数据库租约不够：UltiCode 用 Fence Token 拦住过期单例任务 — 从 UltiCode 的 fenced_job_leases 和 reconciliation run 写入路径出发，说明为什么只有租约过期时间还不够，以及 fence token 如何让旧执行者在数据库门口失效。
- UltiCode generation 与 attemptId：用条件更新拦截过期判题结果 — 用 UltiCode 的 generation、attemptId、租约和条件更新解释如何防止重判、超时或旧 Worker 的结果覆盖新状态。
- UltiCode Outbox 与 Redis Streams：把判题投递做成可恢复状态 — 解释 UltiCode 如何用数据库 outbox、Redis Streams 原子投递、重试/死信和 PEL 回收，把判题消息从一次调用变成可恢复状态。
- UltiCode 数据 Owner 与事实快照：跨服务提交如何保持边界 — 从 UltiCode 的 owner 划分和 SubmissionFactsSnapshot 出发，说明跨服务写入如何把事实来源、捕获时间和 schema 版本变成显式契约。
- 跨 Owner 审计别靠跨库写入：UltiCode 的 Local Outbox 与 Consumer Inbox — 从 Auth/App 本地审计 outbox、owner-specific Redis Stream 到 Admin consumer inbox，解释跨 owner 审计如何处理双写、重复投递、租约恢复与最终一致性。
- UltiCode：把在线评测做成可验证的工程系统 — 以 UltiCode 当前 main 的固定提交为证据，解释 owner 边界、outbox 与 Streams、generation/attempt 围栏、Docker 沙箱和交付门禁如何组合成可验证的在线评测系统，并明确生产验证与性能结论的缺口。