[Task] code-doc sync before 1.8.0

[imbajin]

Release 1.8.0 gate

• [P1] Audit all unmerged PRs intended for the 1.8.0 release and synchronize every user-visible change to the documentation before release.
  • TODO steps:
    • Enumerate open and unmerged PRs across HugeGraph, Toolchain, AI, and Computer / Vermeer that are candidates for 1.8.0.
    • Check each PR for user-visible changes in installation, configuration, APIs, behavior, examples, operations, or compatibility.
    • Map each affected change to the corresponding Chinese and English documentation pages.
    • Update or add the documentation in the existing release workflow, then verify links, examples, and bilingual consistency.
    • Record the PR-to-documentation mapping and block 1.8.0 documentation sign-off until every applicable item is complete.
  • Evidence: the current issue scope covers the merged documentation-sync PRs doc(toolchain): sync client-go with master #473–doc(server): sync server-api with master #490 only; it does not track still-unmerged PRs that may land before 1.8.0.
  • Impact: user-visible changes can enter the 1.8.0 release without corresponding documentation, even if the already-merged synchronization batch is complete.
  • Recommendation: treat this as a release gate and refresh the inventory against the live open-PR lists immediately before the release branch or tag is cut.
  • Acceptance: every in-scope unmerged 1.8.0 PR has an explicit documentation disposition, all required Chinese and English updates are complete, and the final inventory has no unreviewed user-visible change.

HugeGraph

• [P2] Document the current Server startup timeout setting in the Docker guide.

  • TODO steps:
    • Add HG_SERVER_STARTUP_TIMEOUT_S, its default (120 seconds), valid range (1–86400), and failure behavior to the Chinese and English guides.
    • Add a Docker or Compose example showing how to raise the startup budget and explain how it differs from the health-check budget.
  • Location: English Docker Cluster guide and Chinese guide.
  • Evidence: the current Server entrypoint accepts HG_SERVER_STARTUP_TIMEOUT_S, defaults it to 120, validates 1–86400, and passes it to start-hugegraph.sh in the entrypoint and the startup call, but the guide does not mention it.
  • Impact: users on slow or contended hosts cannot discover the supported way to extend the Server startup wait, and may confuse process startup failure with an unhealthy probe.
  • Recommendation: describe the variable and keep its process-startup budget distinct from Docker health-check timing.
  • Acceptance: both languages document the variable, constraints, and a runnable override example with the health-check distinction.

• [P2] Add the existing backend configuration pages to the Server configuration index.

  • TODO steps:
    • Link the HBase, HStore, and RocksDB backend pages from the Chinese and English configuration landing pages.
    • Verify each new link resolves to the corresponding page.
  • Location: English configuration index and Chinese configuration index; the target pages are config-backend-hbase.md, config-backend-hstore.md, and config-backend-rocksdb.md.
  • Evidence: all three backend pages exist in the current docs tree, but both landing pages list only the general guide, options, authentication, and HTTPS pages.
  • Impact: the backend documentation added or refreshed by PRs doc(server): sync backend-hbase with master #477, doc(server): sync backend-hstore with master #486, and doc(server): sync backend-rocksdb with master #487 is difficult to discover from the main configuration entry point.
  • Recommendation: add the three backend links under a clearly named backend subsection or list.
  • Acceptance: users can reach all three backend pages from both configuration indexes without relying on search.

Toolchain

• [P2] Remove or implement the Kafka skipped_line option documented by Loader.
  • TODO steps:
    • Decide whether Kafka records should support skipped_line filtering.
    • If supported, apply the configured regex before parsing and add a focused test; otherwise remove the option and examples from both language pages.
    • Make the default-behavior statement identical to the implementation in Chinese and English.
  • Location: English Loader Kafka input source and Chinese section.
  • Evidence: KafkaSource deserializes skipped_line, but KafkaReader.next() sends every record directly to the parser without applying it.
  • Impact: a user who configures the documented regex can receive and parse records that should have been skipped.
  • Recommendation: align the feature contract, implementation, tests, and bilingual reference.
  • Acceptance: a focused test proves the selected behavior for matching and non-matching Kafka records, and both pages state the same default.

AI

• [P3] Add the Vermeer Python Client page to the AI quick-start follow-up links.

  • TODO steps:
    • Add a Vermeer Python Client link to the English Next Steps list.
    • Add the corresponding link to the Chinese “后续阅读” list.
  • Location: English AI quick-start index and Chinese index.
  • Evidence: the module appears in the AI module list, and the page exists, but neither follow-up list links to vermeer-python-client.md.
  • Impact: users following the recommended AI reading path may not find the Vermeer SDK guide.
  • Recommendation: add the page beside the existing Python Client link.
  • Acceptance: both follow-up lists link directly to the Vermeer Python Client page.

• [P1] Make the Vermeer Python Client example actually wait for task completion.

  • TODO steps:
    • Replace the single immediate status read with bounded polling of the created task.
    • Handle success and failure terminal states before reading the graph.
    • Keep the Chinese and English examples behaviorally identical.
  • Location: English example and Chinese example.
  • Evidence: the page says that the example “adds the polling step”, but it calls get_task() once and immediately calls get_graph(). The current Task API also returns immediately and provides no implicit wait.
  • Impact: the example can inspect the graph before the load task finishes, producing an incomplete result or an avoidable failure.
  • Recommendation: show an explicit, bounded polling loop with terminal-state and timeout handling.
  • Acceptance: a reader can run the example and it waits for a successful load before querying the graph, while reporting task failure clearly.

Computer / Vermeer

• [P1] Update the Computer quick start to use the current graph-space REST paths.

  • TODO steps:
    • Replace the graph read-mode URL in both languages with /graphspaces/DEFAULT/graphs/hugegraph/graph_read_mode.
    • Replace the vertex query URL in both languages with /graphspaces/DEFAULT/graphs/hugegraph/graph/vertices.
    • Re-run the examples against the current Server baseline.
  • Location: English Computer quick start and Chinese quick start.
  • Evidence: the docs still use /graphs/hugegraph/..., while the current Server exposes graph read mode under GraphsAPI and vertices under VertexAPI, both requiring the graphspaces/{graphspace}/graphs/{graph} prefix.
  • Impact: the documented result-query step can fail against the current Server API.
  • Recommendation: use the current DEFAULT graph-space path and keep the example consistent with the REST API guide.
  • Acceptance: both examples return 2xx against the current Server baseline and show the same graph-space-qualified paths.

• [P1] Align the documented Vermeer master HTTP port with the current configuration.

  • TODO steps:
    • Choose one documented contract: use the default master HTTP port 6688, or explicitly define a host-port mapping for 8688.
    • Update the Chinese and English Vermeer REST examples to follow the selected contract.
    • Update the Chinese and English Python Client requirements and connection examples to follow the selected contract.
    • Add or update one runnable Docker or curl example that demonstrates the selected port without relying on an unstated mapping.
  • Location: English Vermeer REST examples and Chinese examples; English Python Client examples and Chinese examples.
  • Evidence: the current Vermeer master template binds http_peer=0.0.0.0:6688 in master.ini, while the docs use 8688 throughout. The provided Compose example does not publish or map 8688:6688, so the difference is not explained as a host-port mapping.
  • Impact: readers following the REST or Python examples can connect to the wrong port and fail to reach the master.
  • Recommendation: use 6688 consistently for the default master HTTP endpoint, or explicitly document and configure a host-to-container mapping wherever 8688 is intentionally retained. Keep the worker gRPC port (6689) distinct from the master HTTP port.
  • Acceptance: the Chinese and English startup guidance, REST URLs, and Python Client examples agree with the selected port contract, and at least one runnable Docker or curl example demonstrates that contract without relying on an unstated mapping.