Knowledge Ingest

Phase 4 of the inverted pipeline. Reads <project>/.metadata/fetch-manifest.json, dispatches source-ingester per fetched source to write wiki/sources/<slug>.md pages, and merges per-source results into the canonical <project>/.metadata/ingest-manifest.json. After per-source emission, a single first-party post-processing call (scripts/knowledge-ingest-postprocess.py, Step 4) applies the curated per-slug backlinks, indexes each source, and promotes each sub-question into a first-class type: question node at wiki/questions/<slug>.md whose ## Findings body [[links]] the source findings that answer it, backfilling the reverse source→question link (SCHEMA R1). Finally appends one ingest summary line to wiki/log.md.

By the end of this phase the wiki is populated with one type: source page per fetched[] entry, each carrying pre_extracted_claims: in its frontmatter. The composer reads these pages; verification string-matches draft sentences against the pre-extracted claims with zero network calls — the structural win.

Read ${CLAUDE_PLUGIN_ROOT}/references/inverted-pipeline.md §"Phase 4 — knowledge-ingest" and references/claim-at-ingest.md once to anchor on the contract.

When to run

• fetch-manifest.json exists for the project (Phase 3 has run) AND either ingest-manifest.json does not yet exist OR the user explicitly wants to re-ingest.
• User explicitly invokes /cogni-knowledge:knowledge-ingest.

Never run when

• No fetch-manifest.json exists at <project_path>/.metadata/ — offer knowledge-fetch first.
• No binding.json exists at the resolved knowledge root — offer knowledge-setup first.
• binding.wiki_path does not resolve to a directory containing .cogni-wiki/config.json — the binding is stale.