diff --git a/docs/toplingdb/images/issues/v1/issue-212-cf-lifecycle.png b/docs/toplingdb/images/issues/v1/issue-212-cf-lifecycle.png
new file mode 100644
index 0000000000..b9df678a52
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-212-cf-lifecycle.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-213-jni-provenance.png b/docs/toplingdb/images/issues/v1/issue-213-jni-provenance.png
new file mode 100644
index 0000000000..3e3a1489ba
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-213-jni-provenance.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-240-overview.png b/docs/toplingdb/images/issues/v1/issue-240-overview.png
new file mode 100644
index 0000000000..4157ea12ee
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-240-overview.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-248-restart-investigation.png b/docs/toplingdb/images/issues/v1/issue-248-restart-investigation.png
new file mode 100644
index 0000000000..dc1a98f813
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-248-restart-investigation.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-249-wal-recovery.png b/docs/toplingdb/images/issues/v1/issue-249-wal-recovery.png
new file mode 100644
index 0000000000..c5bd2e624c
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-249-wal-recovery.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-250-provider-source.png b/docs/toplingdb/images/issues/v1/issue-250-provider-source.png
new file mode 100644
index 0000000000..8b58d5d102
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-250-provider-source.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-251-graphs-directory.png b/docs/toplingdb/images/issues/v1/issue-251-graphs-directory.png
new file mode 100644
index 0000000000..3ab6c1bcd2
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-251-graphs-directory.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-252-benchmark-plan.png b/docs/toplingdb/images/issues/v1/issue-252-benchmark-plan.png
new file mode 100644
index 0000000000..b6ef9be312
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-252-benchmark-plan.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-253-all-data-roots.png b/docs/toplingdb/images/issues/v1/issue-253-all-data-roots.png
new file mode 100644
index 0000000000..d5954a92f7
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-253-all-data-roots.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-254-truncate-coverage.png b/docs/toplingdb/images/issues/v1/issue-254-truncate-coverage.png
new file mode 100644
index 0000000000..ecc6993db9
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-254-truncate-coverage.png differ
diff --git a/docs/toplingdb/images/issues/v1/issue-255-diagnostic-gates.png b/docs/toplingdb/images/issues/v1/issue-255-diagnostic-gates.png
new file mode 100644
index 0000000000..5f23d02215
Binary files /dev/null and b/docs/toplingdb/images/issues/v1/issue-255-diagnostic-gates.png differ
diff --git a/docs/toplingdb/images/issues/v1/prompts.json b/docs/toplingdb/images/issues/v1/prompts.json
new file mode 100644
index 0000000000..56fe710e14
--- /dev/null
+++ b/docs/toplingdb/images/issues/v1/prompts.json
@@ -0,0 +1,100 @@
+{
+ "mode": "built-in image_gen",
+ "use_case": "infographic-diagram",
+ "assets": [
+ {
+ "issue": 240,
+ "slug": "overview",
+ "filename": "issue-240-overview.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: An architectural issue map with a clear central TP pipeline and a separate muted strip for general platform work. Title text: \"#240\" and \"ToplingDB 适配与实测\". Main flow labels: \"配置\" → \"启动 / JNI\" → \"DB / CF\" → \"验证\" → \"交付\". Under it, four visually grouped TP work areas labeled \"选择与隔离 #250 #251 #253\", \"覆盖与诊断 #254 #255\", \"恢复与归因 #249 #248 #212\", \"交付与对照 #213 #252\". Label this main region \"TP 主线 · 10 项\". A visually secondary independent horizontal lane labeled \"通用问题 · 11 项\" contains compact labels \"Schema / Cache\", \"连接与资源\", \"图快照\", \"部署\" and the explicit note \"ignore ≠ 已解决\". Do not draw this gray lane as a prerequisite blocking the TP path. Footer: \"Mac:开发与最小验证 | Linux:实测与性能\". This is a scope map, not a completion chart. No progress percentages or green all-passed stamps.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/240",
+ "revision_prompts": []
+ },
+ {
+ "issue": 250,
+ "slug": "provider-source",
+ "filename": "issue-250-provider-source.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Two parallel decisions inside the same Server that disagree. Title: \"#250\" and \"Provider 来源必须一致\". Current-state region clearly labeled \"当前问题\". One lane starts at a small environment-variable card labeled \"ENV: topling\", goes to a runtime module \"JNI: Topling\". A second lane starts at a configuration-file card \"Config: rocksdb\", goes to a Java module \"Java: RocksDB\". Connect their end nodes with a restrained mismatch mark and label \"状态分叉\". Show consequence as a small CF module labeled \"truncate 路径不一致\"; do not depict data destruction. A separate desired-state region labeled \"目标\" shows one configuration hub labeled \"唯一有效 provider\" branching consistently to \"JNI\" and \"Java\". Footer label: \"已复现配置分叉 · native 行为待验证\". Keep environment/config and native/Java differences explicit; this is the direct-launch override case, not a claim that Docker default is broken.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/250",
+ "revision_prompts": []
+ },
+ {
+ "issue": 251,
+ "slug": "graphs-directory",
+ "filename": "issue-251-graphs-directory.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: An incorrect directory lookup versus the configured directory. Title: \"#251\" and \"读取实际生效的图目录\". Use a configuration card labeled \"graphs=./custom-graphs\" as the authoritative input. Under \"当前问题\", show a selector magnifier searching a folder \"conf/graphs\" and selecting a gray chip \"rocksdb\". In parallel, show the Java graph loader reading a blue folder \"custom-graphs\" with a small file labeled \"provider=topling\". Highlight the diverging paths with the label \"目录错位\". Under \"目标\", the same actual configuration feeds both nodes \"Selector\" and \"Java\" through one shared directory. Footer \"自定义目录不应静默选择标准 runtime\". Do not draw missing config as an error raised, because current selector exits successfully with the wrong selection.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/251",
+ "revision_prompts": []
+ },
+ {
+ "issue": 253,
+ "slug": "all-data-roots",
+ "filename": "issue-253-all-data-roots.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Provider marker checking covers only the default graph, leaving an extra graph's data root outside the check. Title: \"#253\" and \"校验每个图的数据根\". Main current-state diagram labeled \"当前问题\": two graph cards \"默认图\" and \"额外图\". Default graph points through a blue guard/checkpoint labeled \"marker 校验\" to database root \"/tp-data\". Extra graph points around that guard on an amber dashed path to root \"/other-data\", with a small existing tag \"provider=rocksdb\" attached. On the extra graph card add \"provider=topling\". Label bypass \"未进入校验\". Do not depict actual data corruption or deletion. A small desired-state diagram labeled \"目标\" routes both graph roots through a common validation gate before a database-open icon labeled \"打开数据库\". Footer \"已确认校验覆盖遗漏 · 未打开跨 provider 数据\". The image should make the call-coverage gap clear, not suggest the marker helper itself is broken.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/253",
+ "revision_prompts": [
+ "Edit this technical infographic, preserving its typography, layout, colors, title #253 and footer. Correct ONLY these technical relationships: In the LEFT current-state panel, the extra graph card must contain only provider=topling. Move provider=rocksdb from that card to a tag attached directly below the /other-data database root. The dashed amber extra-graph arrow must run straight horizontally below the marker 校验 gate, from extra graph directly to /other-data, NEVER touching or entering the gate; place 未进入校验 above this horizontal bypass arrow. In the RIGHT target panel, remove provider=rocksdb from the extra graph card entirely, keep only provider=topling, preserve both graphs entering the common marker 校验 gate before 打开数据库. Everything else unchanged. Accurate Chinese labels; no added text."
+ ]
+ },
+ {
+ "issue": 254,
+ "slug": "truncate-coverage",
+ "filename": "issue-254-truncate-coverage.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Missing multi-key coverage for the TP clearTables range-delete branch. Title: \"#254\" and \"覆盖多 key 的 truncate\". Two clear panels: \"现有单测\" contains a single CF container with one key \"k1\" and the label \"first = last\", with a bypass arrow labeled \"跳过 deleteRange\". \"待补回归\" contains the same intact CF container holding \"k1\", \"k2\", \"k3\". Depict a range bracket \"[k1, k3)\" plus a separate action on \"k3\" to communicate range deletion followed by deleting the last key. Below, the intended validation sequence is labeled \"旧数据为空\" → \"CF 保留\" → \"新写入可读\", all under \"目标\", not as already passed. Add a small runtime badge \"Topling JNI\" and footer \"覆盖缺口 ≠ 已确认清理失败\". No claim that Topling has never had real lifecycle tests.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/254",
+ "revision_prompts": []
+ },
+ {
+ "issue": 255,
+ "slug": "diagnostic-gates",
+ "filename": "issue-255-diagnostic-gates.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: A CI diagnostic incorrectly funnels every kind of error into one known-assertion bucket. Title: \"#255\" and \"已知断言不能掩盖其他失败\". Current panel labeled \"当前问题\": four compact error cards \"已知 CF 断言\", \"配置失败\", \"JNI 加载失败\", \"读写失败\" all converge to a single amber box \"全部非阻塞\", with a small tag \"统一归因 #212\". Desired panel labeled \"目标\": a classifier gate sends only \"已知 CF 断言\" to \"保留诊断\", and sends the other errors to a red stop/status box \"检查失败\". Use visible split arrows and restrained failure indicators. Footer \"按实际错误分类 · 保留真实原因\". This explains one diagnostic step; do not claim all CI tests or all runtime checks are ineffective.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/255",
+ "revision_prompts": []
+ },
+ {
+ "issue": 249,
+ "slug": "wal-recovery",
+ "filename": "issue-249-wal-recovery.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Failure-safe checkpoint WAL restoration. Title: \"#249\" and \"WAL 恢复必须失败安全\". Status tag \"本分支新增代码 · 待收口\". Show a concrete staged file-flow diagram: old active log folder \"旧 WAL\" moves to a quarantined folder \"隔离\"; blue source files \"checkpoint tail\" copy to a staging folder \"staging\" then a publication gate labeled \"校验 / 发布\" into \"新 WAL\". At the transitions show three small amber warning labels \"移动失败\", \"复制失败\", \"发布失败\". A protective frame around checkpoint tail communicates preserving the recovery source. Desired invariant text under a clearly marked \"目标\" footer: \"旧日志不重放\" and \"恢复源不丢失\". Do not depict a completed fix or guaranteed atomicity. No claim this is a Topling native engine bug; it is shared recovery code introduced by this integration branch.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/249",
+ "revision_prompts": [
+ "Edit this referenced WAL recovery infographic to remove distracting invented filenames and to label the entire diagram as proposed work. Preserve title #249, subtitle, overall flow, Chinese typography, warning labels, protected checkpoint tail source, and footer. Remove every individual filename from all folders and source card, leaving only clean unnamed small file icons. Make 新 WAL folder and its file icons blue, matching staging and checkpoint tail, to unambiguously show it receives checkpoint data rather than the gray old WAL. Replace the annotation 完整保留 待人工处理 under 隔离 with \"目标:隔离旧日志\". Add a small clear label \"目标流程\" above the central diagram. Footer goal checkmarks should become neutral outlined unfilled circles, since this is pending work. Do not alter any other text. Opaque background."
+ ]
+ },
+ {
+ "issue": 248,
+ "slug": "restart-investigation",
+ "filename": "issue-248-restart-investigation.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: A bounded observation requiring investigation, not a claimed Topling data-loss diagnosis. Title: \"#248\" and \"重启后不可见:先确认根因\". Prominent amber tag \"Investigation\". Upper timeline labeled \"历史现象\": \"clear\" → \"v1 写入 / 读取成功\" → \"首次 Server 重启\" → \"v1 查询为空\". Lower comparison timeline: \"v2 新写入\" → \"再次 Server 重启\" → \"仍可读取\". Show a magnifying-glass investigative node with three dotted hypothesis branches labeled \"缓存\", \"事务 / 图 ID\", \"路由 / 持久化\"; no branch should be marked as the cause. Footer \"单次历史现象 · 根因待归属\". Visually distinguish query invisibility from physical data destruction; no shattered disks or deleted-file imagery. Mention only Server restart, not Store crash.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/248",
+ "revision_prompts": [
+ "Edit the referenced infographic with one factual correction. Replace ONLY the small red annotation 数据存在但查询不可见 underneath v1 查询为空 with the exact text \"物理数据状态待核实\". The original wording falsely asserted physical data exists; this is unknown. Preserve ALL other text, title, layout, issue number, colors, iconography and dimensions exactly. Opaque background."
+ ]
+ },
+ {
+ "issue": 212,
+ "slug": "cf-lifecycle",
+ "filename": "issue-212-cf-lifecycle.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Historical CF/session lifecycle fixes versus currently unresolved native shutdown warnings. Title: \"#212\" and \"DB / CF 生命周期收口\". A left section labeled \"历史已修复\" shows \"释放 session\" → \"保留 CF 清表\" → \"旧 SHA 三轮通过\" with modest green checkmarks confined to this historical section. A right section labeled \"当前残余待归因\" contains an amber native warning card with exact text \"db not closed\", connected by dotted investigative arrows to nodes \"Session 引用\", \"CF 注册\", \"JNI 生命周期\". A clear DB cylinder containing CF partitions connects the two sections without suggesting the entire issue is solved. Footer \"旧 SHA 通过 ≠ 当前全部闭环\". No claim that a new JNI binary was released or that all shutdown problems are native-specific.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/212",
+ "revision_prompts": []
+ },
+ {
+ "issue": 213,
+ "slug": "jni-provenance",
+ "filename": "issue-213-jni-provenance.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: Traceable JNI delivery rather than an opaque binary. Title: \"#213\" and \"JNI 产物可追溯交付\". Show a current compact input card \"JNI SNAPSHOT\" with a small established fingerprint badge \"SHA-256\" and label \"候选可用\". Next to it, a larger clearly labeled \"目标交付链\" flows through five illustrated modules: \"源码 / 子模块\" → \"工具链 / 构建参数\" → \"JNI + 校验和\" → \"签名 / 来源证明\" → \"Maven 发行\". Use outlined unfilled completion indicators for this target chain so it is obviously pending work. A small connective warning between current artifact and source says \"来源链待补齐\". Footer \"候选可用 ≠ 正式发行闭环\". No invented build versions, timestamps, hashes, certified seals, or claims of completed provenance.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/213",
+ "revision_prompts": []
+ },
+ {
+ "issue": 252,
+ "slug": "benchmark-plan",
+ "filename": "issue-252-benchmark-plan.png",
+ "prompt": "Use case: infographic-diagram.\nAsset type: GitHub engineering issue illustration for HugeGraph ToplingDB, one image in a coherent series.\nPrimary request: Generate a polished, accurate explanatory raster infographic, not a decorative banner. Wide landscape 16:9 composition, high resolution, crisp readable Chinese typography with short English code identifiers. Neutral near-white background, dark charcoal type, blue for the TP integration path, neutral gray for standard or out-of-scope paths, amber for uncertainty, restrained red for confirmed mismatch. Flat technical editorial illustration with subtly dimensional database/file modules, clean connectors, generous whitespace and strong visual hierarchy. No characters, mascots, brand logos, invented dashboards, photographic clutter or watermarks. Use only the exact short labels supplied below, no extra paragraphs. Keep all text large enough to read in a GitHub issue. The image is explanatory and cannot assert an unresolved issue is fixed. Any desired state must be clearly labeled 目标, never 已完成. Avoid invented performance numbers or signs of actual data loss. Preserve the technical distinctions in the brief. Include the issue number as a small but legible top label. Opaque background.\n\nSubject: A fair reproducible benchmark plan with no invented performance outcome. Title: \"#252\" and \"同条件比较 RocksDB 与 Topling\". Prominent neutral status \"Benchmark 待执行\". At the top, shared controls labeled \"同一源码\", \"固定数据\", \"相同资源\", \"记录实际 JNI\" feed two equally sized peer lanes \"RocksDB\" and \"Topling\". Both lanes pass through the same workload cards labeled \"写入\", \"点读\", \"范围 / 邻接\", \"混合负载\". At the bottom show an empty comparison report grid with three outlined round markers \"第 1 轮\", \"第 2 轮\", \"第 3 轮\", no numbers, no bars implying a winner. Footer \"仅 Linux 实测 · 不预设性能收益\". Do not insert fake speedups, percentages, latency values or benchmark results.",
+ "source_url": "https://github.com/hugegraph/hugegraph/issues/252",
+ "revision_prompts": []
+ }
+ ]
+}
diff --git a/docs/toplingdb/toplingdb-development.md b/docs/toplingdb/toplingdb-development.md
new file mode 100644
index 0000000000..6429dbcbc4
--- /dev/null
+++ b/docs/toplingdb/toplingdb-development.md
@@ -0,0 +1,315 @@
+# ToplingDB Developer Guide
+
+This guide describes the Topling integration maintained in this repository.
+Read the [quickstart](toplingdb-quickstart.md) first if you only need to run it.
+
+The runtime support target is native Linux x86_64 and Linux containers on
+macOS (Docker Desktop or OrbStack). Native macOS execution, including Intel,
+is deliberately outside the ToplingDB matrix; do not treat that CI job as a
+Topling image or container failure.
+
+## Scope and Design Priorities
+
+The integration focuses on Topling-specific adaptation, bug fixes, feature
+compatibility, usability, and maintainable engine selection. Keep HugeGraph
+on the standard RocksDB API with Easy Migrate owning native integration;
+do not add Java-side SidePluginRepo management or a parallel storage API.
+Reuse shared launch helpers and deployment topologies instead of maintaining
+separate copies per provider.
+
+Track provider-independent Server, PD, Store, schema/cache, client reconnect,
+and deployment defects in their own issues or PRs. Mark them `ignore` in the
+Topling task: this excludes them from its backlog and completion denominator,
+not from product ownership, and does not mean they passed. Preserve reproduction
+and dependency links. Such defects may limit an individual experiment; record
+that limit and continue independent Topling checks rather than making all
+pre-existing platform gaps prerequisites for this integration.
+
+Regressions introduced by this PR remain in scope even in shared code.
+Unattributed native or WAL failures need a minimal diagnosis before exclusion.
+Provider selection, native ownership, runtime packaging, data-directory safety,
+and standard RocksDB compatibility remain integration requirements.
+
+Review engine switching for explicit configuration, actionable startup errors,
+component-local JNI isolation, consistent defaults and versions, and recoverable
+configuration changes. Do not imply live hot switching or automatic conversion
+of an existing data directory. Use focused local tests and source/image/JNI-bound
+Linux acceptance; performance experiments belong on the Linux test host.
+
+Track native CF lifecycle in [#212](https://github.com/hugegraph/hugegraph/issues/212),
+release-grade JNI delivery in [#213](https://github.com/hugegraph/hugegraph/issues/213),
+and current coordination in [#240](https://github.com/hugegraph/hugegraph/issues/240).
+Issue [#214](https://github.com/hugegraph/hugegraph/issues/214) retains historical
+integration and publication milestones.
+Keep feature-merge criteria distinct from official-release requirements.
+Current configuration-source and multi-graph isolation gaps are tracked in
+[#250](https://github.com/hugegraph/hugegraph/issues/250),
+[#251](https://github.com/hugegraph/hugegraph/issues/251), and
+[#253](https://github.com/hugegraph/hugegraph/issues/253); adapter regression
+coverage and diagnostic classification are tracked in
+[#254](https://github.com/hugegraph/hugegraph/issues/254) and
+[#255](https://github.com/hugegraph/hugegraph/issues/255).
+
+## Runtime Contract
+
+HugeGraph keeps the RocksDB Java API. Topling Easy Migrate supplies the native
+runtime and configuration at process startup.
+
+```text
+component config
+ -> preload-topling.sh validates rocksdb or topling
+ -> component-local JAR joins CLASSPATH
+ -> component-local native library joins LD_PRELOAD
+ -> Easy Migrate YAML is exported
+ -> existing RocksDB Java calls open and close DB/CF handles
+```
+
+The supported providers are exactly `rocksdb` and `topling`. Duplicate
+configuration values must agree. Missing Topling files or dependencies stop
+startup. PD and Store never search a neighboring Server distribution.
+
+## Source Layout
+
+| Area | Path |
+|---|---|
+| Shared helper source | `hugegraph-server/hugegraph-dist/src/assembly/static/bin/common-topling.sh` |
+| Package-local preparation | `hugegraph-server/hugegraph-dist/src/assembly/static/bin/prepare-topling.sh` |
+| Startup selection | `hugegraph-server/hugegraph-dist/src/assembly/static/bin/preload-topling.sh` |
+| Checked-in Topling JAR | `hugegraph-server/hugegraph-dist/src/assembly/static/lib/topling/` |
+| Standalone Easy Migrate YAML | `hugegraph-server/hugegraph-dist/src/assembly/static/conf/toplingdb.yaml` |
+| PD Easy Migrate YAML | `hugegraph-pd/hg-pd-dist/src/assembly/static/conf/rocksdb_pd.yaml` |
+| Store Easy Migrate YAML | `hugegraph-store/hg-store-dist/src/assembly/static/conf/rocksdb_store.yaml` |
+| Topling distribution generator | `install-dist/scripts/build-topling-distribution.sh` |
+| Provider data marker | `hugegraph-server/hugegraph-dist/src/assembly/static/bin/verify-rocksdb-provider.sh` |
+| Docker build graph | `docker/bake.hcl` |
+| Focused shell tests | `hugegraph-server/hugegraph-dist/src/assembly/travis/test-topling-*.sh` |
+
+The PD and Store assembly descriptors copy the canonical helper scripts into
+their own `bin/` directories. Change the canonical Server copy, then verify all
+three assembled copies are identical.
+
+## Build Standard and Topling Distributions
+
+Use Linux x86_64. The distribution generator also requires `rsync`, `unzip`,
+`tar`, and `sha256sum`.
+
+```bash
+VERSION=$(mvn help:evaluate \
+ -Dexpression=project.version -q -DforceStdout)
+
+mvn clean package \
+ -pl hugegraph-server/hugegraph-dist,hugegraph-pd/hg-pd-dist,hugegraph-store/hg-store-dist \
+ -am -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -ntp
+
+for component in server pd store; do
+ install-dist/scripts/build-topling-distribution.sh \
+ "$component" "$VERSION"
+done
+```
+
+The standard distributions contain the selection helpers but no
+`lib/topling/rocksdbjni*.jar` or prepared Topling native library. Selecting
+Topling from a standard distribution must fail.
+
+When a Topling distribution is switched back to `rocksdb`, the Server and
+`init-store` launchers exclude the canonical `lib/topling/` subtree (including
+symlink aliases) from their classpaths; the optional Topling JAR is only added
+after the startup selector accepts `topling`.
+
+The Topling distributions add only build-time runtime files. The generator
+excludes PID files, logs, data directories, and prepared runtime state from the
+standard distribution before creating the Topling tarball. It writes
+`lib/topling/runtime.properties` with the component, project version, JAR name,
+and JAR SHA-256.
+
+That SHA-256 identifies the local input. It is not an official release
+signature or a full source-to-binary provenance record. Issue
+[#213](https://github.com/hugegraph/hugegraph/issues/213) tracks immutable
+coordinates, toolchain and CPU baseline, licensing, SBOM, signatures, and
+consumer verification.
+
+## Provider Configuration
+
+Server reads `rocksdb.provider` from local RocksDB graph `.properties` files
+in the `graphs` directory selected by the effective REST configuration.
+Relative graph directories resolve from the Server distribution root, as in
+the Java launchers. All local RocksDB graphs in one JVM must agree; a missing
+provider selects standard RocksDB. Remote and in-memory graphs do not select JNI.
+
+For Server, `TOPLINGDB_ROCKSDB_PROVIDER` checks that selection; it cannot override
+a different graph provider. A conflict stops startup before Java runs.
+Docker still generates `hugegraph.properties` in that directory from
+`HG_SERVER_ROCKSDB_PROVIDER`; the file must exist. Additional graphs must use
+the same effective value. Direct launch does not require that primary filename.
+
+Example graph property:
+
+```properties
+rocksdb.provider=topling
+```
+
+PD and Store read the provider under the root `rocksdb` YAML section:
+
+```yaml
+rocksdb:
+ provider: topling
+```
+
+Keep only one effective value for a component. The loader rejects unknown or
+conflicting values. The default is standard RocksDB when no provider is set.
+
+Server startup accepts plain properties and supported escaped path characters.
+It rejects includes, continuations, escaped keys, duplicate relevant properties,
+and interpolated/list values that cannot be safely matched to Java configuration.
+Server startup also rejects non-empty `rocksdb.data_disks` until those optimized
+roots can be enumerated safely. These errors name the affected property/file;
+they do not select a fallback runtime.
+
+Every Topling functional test must use a readable Easy Migrate YAML. Removing
+`TOPLINGDB_EASY_MIGRATE_CONF` reduces a test to Java ABI coverage and does not
+exercise the Topling runtime.
+
+## Focused Tests
+
+Run the platform-independent selection and packaging tests first:
+
+```bash
+TRAVIS_DIR=hugegraph-server/hugegraph-dist/src/assembly/travis
+
+"$TRAVIS_DIR/test-topling-runtime-selection.sh"
+"$TRAVIS_DIR/test-topling-native-diagnostic.sh"
+"$TRAVIS_DIR/test-topling-docker-entrypoints.sh"
+"$TRAVIS_DIR/test-topling-runtime-packaging.sh" \
+ "hugegraph-server/apache-hugegraph-server-$VERSION" \
+ "hugegraph-pd/apache-hugegraph-pd-$VERSION" \
+ "hugegraph-store/apache-hugegraph-store-$VERSION"
+```
+
+On Linux x86_64, validate each generated Topling distribution:
+
+```bash
+"$TRAVIS_DIR/test-topling-distribution.sh" \
+ server \
+ "hugegraph-server/apache-hugegraph-server-$VERSION" \
+ "hugegraph-server/apache-hugegraph-server-$VERSION-topling"
+
+"$TRAVIS_DIR/test-rocksdb-runtime.sh" \
+ topling \
+ "hugegraph-server/apache-hugegraph-server-$VERSION-topling"
+```
+
+Repeat the distribution and runtime checks for PD and Store. The CI jobs
+`server-rocksdb-runtime` and `distributed-rocksdb-runtime` build a matrix across
+standard RocksDB and ToplingDB. Standard runtime checks and both distribution
+contracts are required. The synthetic Topling column-family lifecycle check is
+allowed a non-blocking exception only after a separate runtime mapping/read/write/close
+probe passes and the synthetic CF phase exits with SIGABRT and the exact known
+assertion for issue #212. Missing configuration, class loading, mapping, IO and
+unknown failures fail the job. Probe/lifecycle logs and JAR/native SHA-256
+identities are uploaded even on failure. Only the exact producer warning for an
+unavailable optional DirectByteBuffer constructor is excluded from the error
+scan; successful probe status and phase remain mandatory. Image-backed service lifecycle tests
+remain required. The jobs also contaminate the standard build
+with known runtime-state fixtures and verify that the Topling directory and
+tarball remain clean.
+
+Run repository checks before pushing:
+
+```bash
+mvn editorconfig:check -ntp
+mvn clean compile -Dmaven.javadoc.skip=true -ntp
+git diff --check
+```
+
+Use ShellCheck on each changed shell script. Existing warnings in untouched
+lines do not justify unrelated cleanup in a Topling change.
+
+## Docker Images
+
+Server, PD, and Store Dockerfiles have explicit `standard` and `topling`
+targets. Build the complete Topling deployment set with Bake:
+
+```bash
+RUNTIME_VARIANT=topling \
+IMAGE_TAG=topling \
+docker buildx bake --file docker/bake.hcl
+```
+
+The Topling variant is Linux x86_64 only. It builds
+`hugegraph/hugegraph`, `hugegraph/pd`, and `hugegraph/store` from their
+`topling` targets. `hugegraph/server` remains the standard HStore Server and
+receives the same tag as the compatible deployment set.
+
+An HStore Server image remains free of a local Topling JAR and native library.
+PD and Store own their local runtime.
+
+Published candidates carry `org.opencontainers.image.source`,
+`org.opencontainers.image.revision`, and
+`org.apache.hugegraph.rocksdb-runtime` labels. Verify the exact source commit
+before accepting a mutable deployment tag:
+
+```bash
+docker image inspect hugegraph/hugegraph:topling \
+ --format '{{json .Config.Labels}}'
+```
+
+Run the generic standalone, minimal HStore, or 3+3+3 Compose file with
+provider parameters injected through the environment. Local development can
+use `local/hugegraph-{pd,store}:topling` with
+`HUGEGRAPH_{PD,STORE}_BUILD_TARGET=topling`; published candidates use
+`hugegraph/{pd,store}:topling` and `HUGEGRAPH_{PD,STORE}_PULL_POLICY=always`.
+Set `HUGEGRAPH_SERVER_IMAGE=hugegraph/server:topling` and
+`HUGEGRAPH_SERVER_PULL_POLICY=always` only when the matching HStore image is
+intended. Keep the provider-specific volume names and data roots explicit.
+The repository deliberately maintains one Compose topology per deployment
+shape rather than separate Topling files.
+
+Every local RocksDB owner uses a provider-specific data root. The Server entrypoint
+validates `.hugegraph-rocksdb-provider` for the default root and every effective
+local graph data/WAL path before initialization or Java startup. Marked ancestors
+and configured paths are checked so a nested path cannot bypass isolation.
+Primary configuration generation precedes enumeration; no database is opened
+until validation succeeds. PD and Store validate their component data roots. Topling rejects unmarked non-empty data. Standard RocksDB accepts existing
+non-empty legacy data without a marker; new or empty configured roots are
+claimed atomically, including bare Server startup on macOS. Both reject
+conflicting markers and storage symlinks. Topling/forced validation uses a
+pinned-directory lock and rechecks emptiness after creating its temporary marker
+so a competing child owner cannot be overwritten by a deployment-root marker.
+On Linux, Server launchers also check each configured local graph's `m`, `g`,
+and `s` database mount points before claiming graph roots or starting Java.
+The Java recovery lock still guards direct database opens.
+
+## Native Runtime Changes
+
+When replacing `rocksdbjni*.jar`:
+
+1. Keep exactly one Topling JAR in the checked-in source directory.
+2. Run `bin/prepare-topling.sh` in every generated component distribution.
+3. Check `ldd library/librocksdbjni-linux64.so` for unresolved dependencies.
+4. Run real DB and column-family create, close, reopen, restart, and persistence
+ tests with the component Easy Migrate YAML enabled.
+5. Record the JAR SHA-256 and the exact source and toolchain evidence available.
+
+Issue [#212](https://github.com/hugegraph/hugegraph/issues/212) tracks native
+DB/column-family lifecycle behavior. Real Server and 1+1+1 HStore tests must
+cover CRUD, clean HugeGraph transaction close, container recreation, and
+persistence. The current native runtime can still report a SidePluginRepo
+bookkeeping warning after HugeGraph closes successfully. Keep that upstream
+evidence separate from the provider-selection and data-isolation gates. ABI
+loading or `ldd` output cannot establish service correctness.
+
+## Review Boundaries
+
+A complete Topling change must keep these properties:
+
+- standard artifacts have no Topling JAR or native library;
+- Server, PD, and Store load only their component-local runtime;
+- an HStore Server does not load Topling locally;
+- standard and Topling data directories stay separate;
+- invalid or incomplete Topling selection fails before service startup;
+- shutdown uses the normal component lifecycle;
+- documentation names the exact configuration file and verification command.
+
+Do not claim hot switching, automatic data migration, safe reuse of a
+Topling-modified directory by standard RocksDB, or release provenance that the
+artifact metadata does not prove.
diff --git a/docs/toplingdb/toplingdb-hstore-integration.md b/docs/toplingdb/toplingdb-hstore-integration.md
new file mode 100644
index 0000000000..be6b21cbce
--- /dev/null
+++ b/docs/toplingdb/toplingdb-hstore-integration.md
@@ -0,0 +1,95 @@
+# ToplingDB and HStore Integration
+
+## Deployment Model
+
+ToplingDB and HStore solve different problems:
+
+- ToplingDB is an optional RocksDB-compatible native runtime.
+- HStore is HugeGraph's distributed storage backend.
+
+In an HStore deployment, HugeGraph Server sends storage requests to Store. It
+does not open a local RocksDB database.
+
+```text
+HugeGraph Server
+ HStore client
+ |
+ v
+PD cluster ---------------- Store cluster
+local RocksDB metadata local RocksDB data
+optional Topling runtime optional Topling runtime
+```
+
+ToplingDB therefore applies independently to PD and Store. Each process keeps
+its existing RocksDB Java calls and loads its own native runtime and Easy
+Migrate configuration.
+
+## Runtime Setup
+
+PD startup sets:
+
+```bash
+TOPLINGDB_EASY_MIGRATE_CONF="$PD_HOME/conf/rocksdb_pd.yaml"
+```
+
+Store startup sets:
+
+```bash
+TOPLINGDB_EASY_MIGRATE_CONF="$STORE_HOME/conf/rocksdb_store.yaml"
+```
+
+Both distributions carry the same `preload-topling.sh` helper and load only
+their component-local Topling JAR and native library. PD and Store do not
+discover or depend on a neighboring Server distribution. This is shared source
+tooling, not a shared Java provider or shared DB owner.
+
+## Configuration
+
+Set the provider for each component that should use ToplingDB:
+
+```yaml
+rocksdb:
+ provider: topling
+```
+
+PD and Store use distinct Easy Migrate YAML files and distinct HTTP ports.
+Their `DBOptions.default` mappings remain the global fallbacks, while
+`DBOptions.log` remains the specialized log-database profile.
+
+The Server's graph configuration does not enable a local ToplingDB instance
+when the backend is HStore.
+
+## Open and Close Behavior
+
+PD and Store continue to use normal RocksDB Java APIs. The preloaded native hook
+applies options and tracks DB/CF lifecycle. Neither component reflectively
+creates a repository or calls an alternate `openDB`.
+
+Shutdown is also unchanged:
+
+```text
+SIGTERM
+ -> PD/Store graceful shutdown
+ -> Java closes CF handles and RocksDB
+ -> native MaybeForgetCF and MaybeForgetDB
+ -> process exits
+```
+
+Store's existing shutdown timeout is a general process boundary. A timeout does
+not justify calling `SidePluginRepo.closeAllDB()` and this integration does not
+change the broader Store thread-exit behavior.
+
+## Validation
+
+Validate PD and Store separately:
+
+1. Confirm the component provider is `topling`.
+2. Confirm the startup log reports the expected
+ `TOPLINGDB_EASY_MIGRATE_CONF`.
+3. Confirm only the prepared component native library is mapped.
+4. Run DB/CF create, reopen, drop, and recreate operations with Easy Migrate
+ enabled.
+5. Stop the component with SIGTERM and verify normal process exit.
+
+An ABI-only check may inspect the JAR, Topling API marker, and native mapping
+without opening a database. It is not a storage-functionality test.
diff --git a/docs/toplingdb/toplingdb-operations.md b/docs/toplingdb/toplingdb-operations.md
new file mode 100644
index 0000000000..5dd40eb889
--- /dev/null
+++ b/docs/toplingdb/toplingdb-operations.md
@@ -0,0 +1,105 @@
+# ToplingDB Operations Guide
+
+## Preflight
+
+Before startup:
+
+1. Confirm the component configuration selects `topling`.
+2. Run the installation step for that component.
+3. Confirm its Easy Migrate YAML and prepared native library are readable.
+4. Check that the configured HTTP port is available and restricted to a
+ trusted interface.
+5. Create and verify a complete pre-migration RocksDB checkpoint or backup.
+
+The expected configuration files are:
+
+| Component | File |
+|---|---|
+| Standalone Server | `conf/toplingdb.yaml` |
+| PD | `conf/rocksdb_pd.yaml` |
+| Store | `conf/rocksdb_store.yaml` |
+
+## Monitoring
+
+Monitor read/write latency, compaction backlog, cache usage, WAL growth, disk
+space, native memory, and process health. The sample configurations keep the
+Topling HTTP endpoint disabled by default (`auto_start_http: false`). If it is
+needed, enable it explicitly; it can show native state but has no
+authentication and must not be exposed directly to untrusted networks.
+
+Use the component logs to confirm the selected configuration path and native
+library. Do not infer ToplingDB activation from the JAR name alone.
+
+## Tuning
+
+Change one YAML setting group at a time and benchmark with a representative
+workload. Preserve:
+
+- `DBOptions.default` as the global fallback;
+- the dedicated `DBOptions.log` profile;
+- component-specific HTTP ports;
+- a memory budget that includes JVM heap, block cache, memtables, native
+ allocations, and background jobs.
+
+## Graceful Stop and Restart
+
+Use the normal stop script or SIGTERM. Do not stop a separate “ToplingDB
+process”; none exists.
+
+```text
+SIGTERM
+ -> HugeGraph/PD/Store graceful shutdown
+ -> normal CF/DB close
+ -> native MaybeForgetCF / MaybeForgetDB
+ -> JVM exit
+```
+
+Do not invoke `SidePluginRepo.closeAllDB()`. Store's stop script already has a
+bounded wait. If it reports a timeout, collect thread dumps and component logs
+and investigate the ordinary Store shutdown path before any restart.
+
+## Upgrade and Rollback
+
+Drain traffic and stop the component cleanly before changing the runtime or
+YAML. Validate JAR/native compatibility and the YAML schema in staging first.
+
+A provider switch is not a data rollback. If the upgraded Topling runtime has
+written data and rollback is required, stop all writers and restore the full
+pre-upgrade snapshot into an empty data directory with the matching previous
+runtime.
+
+## Interrupted Standalone Snapshot Restore
+
+Standalone RocksDB snapshot restore keeps its checkpoint until the replacement
+has been installed and reopened. A sibling `