Skill Step 9 passes the AST+semantic merge to _stamped_manifest_files, stamping semantic_hash on docs that were never extracted #2844

Summary

SKILL.md Step 9:

extract = json.loads(Path('graphify-out/.graphify_extract.json').read_text(...))   # AST + semantic
_manifest_files = _stamped_manifest_files(_corpus, extract, Path(INPUT_PATH))

_stamped_manifest_files stamps semantic_hash on any document present in the result it is handed. The Part C merge contains AST nodes for every markdown file, so whenever documents are AST-extracted, every document is stamped as semantically extracted — including files no agent ever saw.

Observed: a deliberately scoped 21-file semantic run stamped all 122 documents in the corpus. Since detect_incremental(kind="semantic") reads that field, the other 101 would have been reported unchanged on every subsequent --update and never re-queued.

Version: graphify 0.9.46, skill-windows.md variant, Windows 11 / Python 3.10.

Fix

Pass the semantic-only result:

_semantic = json.loads(Path('graphify-out/.graphify_semantic.json').read_text(...))
_manifest_files = _stamped_manifest_files(_corpus, _semantic, Path(INPUT_PATH))

The existing clear_semantic computation then does the right thing for both full and scoped runs. Verified: detect_incremental reports 106 to re-extract / 20 done, against 0 / 122 before the fix.

Scope note

This only bites when markdown is AST-extracted. Stock Part A extracts detect['files']['code'] only, but watch._rebuild_code does add documents that have an AST extractor, so any corpus that has been through graphify update is in that state. A Part A that mirrors _rebuild_code — which is needed on an existing graph, or the #479 shrink guard refuses the rebuild for dropping every heading node — hits it directly.

Related: the _origin stamping issue filed alongside this one. Both were found in the same run and both have the same shape, a tier/provenance signal that Part C does not carry through.