Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

detect_changes: report the code a changed documentation section references

Đang mở
  • Có gì không ổn?
#2,614 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
c, markdown
Lĩnh vực
devtools

Hướng nghiên cứu

Start with detect_is_seedable_label and detect_walk_parse in src/mcp/mcp.c, then read doclink_md.c to understand how references are attributed to sections. Reproduce with case 5 from the script attached to #2585 and inspect how prose edits affect section ownership and MENTIONS traversal. Done means the design questions in the issue are resolved and changed documentation can report its referenced code separately from blast-radius results.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement parsing/quality priority/backlog

Concerns detect_changes together with the doc-links feature from #2551. I
found no existing issue or PR.

A documentation-only edit produces no seeds, so detect_changes cannot list
the code a changed section references, although the graph already holds the
MENTIONS edges that do:

MENTIONS from the section: [['Posting', 'post_entry']]
doc-only edit, edge_types ["CALLS","MENTIONS"]: changed_files=['docs/notes.md'] seed_symbols=0

detect_is_seedable_label (src/mcp/mcp.c) excludes Section, along with
File, Folder, Module, Project and Package. That is the right default
for the blast-radius walk. The code-to-doc direction already works: a
code-only edit to post_entry reaches the Posting section at hop 2 with the
same call. Only the doc-to-code direction is missing.

What this would report. The code a changed section names: code that may
need review because its documentation changed. That is not behavioral impact.
Changing a document changes nothing the code does, so this output should be
labeled apart from the blast radius, not merged into it.

Simply making Section seedable is not enough. There are three design
questions I'd like settled before sending a PR:

  1. Which section owns a changed line? A Section node's stored range covers
    its heading line only, not the prose below it (push_simple_class_def_doc
    records the heading node's lines). Ordinary hunk intersection would miss
    edits to the prose. Since nothing would overlap, it would also trip the
    whole-file fallback and seed every section of the document. One option: a
    changed line belongs to the nearest heading at or above it, the same rule
    doclink_md.c uses to attribute references. Another: store each Section's
    body range on the node.
  2. Traversal direction. A request with edge_types must be inbound
    (detect_walk_parse rejects anything else: "edge_types, fixpoint and via
    walk the blast radius only"). Reaching code from a Section means following
    MENTIONS outbound. Should this be an explicit mode of detect_changes
    (for example doc_references: true)? Or a separate doc-to-code step, one
    outbound MENTIONS hop from the changed sections, whose results are
    reported, and possibly fed to the inbound walk as further seeds?
  3. File-level references. Should a change above a document's first heading
    use the document's File node? doc_links attributes references written there
    to the File.

Environment: built from main at ec4fbd3a (2026-10-10), Linux x86-64, CLI
mode, fresh cache.

Reproduction

CBM="codebase-memory-mcp cli" ./repro.sh 5, using the script attached to
#2585. Case 5 indexes docs/notes.md, which has a ## Posting section that
references src/ledger.py::post_entry. It edits only the prose and re-indexes,
then calls detect_changes with edge_types: ["CALLS","MENTIONS"].

Ngôn ngữ chính
C
Star
45.8k
Fork
3.8k
Merge trung bình
3 ngày 10 giờ
Pull request đã merge (30 ngày)
200

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DeusData/codebase-memory-mcp

Tất cả issue của DeusData/codebase-memory-mcp

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.