Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

detect_changes: report the code a changed documentation section references

Aperta
  • Qualcosa non va?
#2,614 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
c, markdown
Ambito
devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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"].

Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 14h
PR unite (30g)
210

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.