diff --git a/CLAUDE.md b/CLAUDE.md index 240e547..a8547f4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -40,11 +40,8 @@ Documents covering what's actually been built, narrower than the full design abo built across two closed Wayfinder maps; links to `docs/adr/` for the "why" behind each resolved decision. -Active, not-yet-resolved design work lives alongside these rather than inside them: - -- **[cross-linker-spec.md](docs/design/cross-linker-spec.md)** — skill spec for automated cross-referencing, still open - (issue #94); see [cross-linker-scale-research.md](docs/design/cross-linker-scale-research.md) for in-flight research - feeding into it. +Active, not-yet-resolved design work lives alongside these rather than inside them — none open right now; +the most recent one (cross-linker, issue #94) closed and folded into `implementation-history.md`'s Phase 3. ## Key design decisions already made (don't re-litigate without reason) diff --git a/docs/design/cross-linker-scale-research.md b/docs/design/cross-linker-scale-research.md deleted file mode 100644 index 3a2d327..0000000 --- a/docs/design/cross-linker-scale-research.md +++ /dev/null @@ -1,84 +0,0 @@ -# Research: prior art on cross-linking / link-suggestion at scale - -Ticket: #97 (child of Cross-linker skill spec map, #94) - -Feeds into: [cross-linker-spec.md](cross-linker-spec.md) — this research's two follow-ups -(incremental scan, literal-string pre-filter) aren't yet folded into that spec. - -## Question - -Does the toolkit's existing frontmatter-registry + selective-full-read pattern -(from `Reference/llm-wiki.md`'s "index.md is content-oriented... -avoids the need for embedding-based RAG infrastructure" primitive) hold up as -the scale strategy for `cross-linker`, or does prior art suggest something -meaningfully better? - -## Prior art surveyed - -- **Obsidian "Smart Connections"** — embedding-based link suggestion. - Confirms the frontmatter-registry pattern's underlying assumption: it - re-embeds only *changed* notes on save (event-driven incremental update), - not the whole vault each run. Full re-embed only happens once, at initial - install. Initial full-vault indexing cost scales roughly linearly (~2 min - per 1K notes on decent hardware) — i.e. even the embedding-heavy approach - treats "rescan everything" as a one-time cost, not a steady-state one. -- **Roam Research / Logseq "unlinked references"** — not embedding-based at - all. It's literal substring/title matching: each page title is scanned - against block text via the app's maintained block-level index (Datalog DB - in Roam, DataScript in Logseq), not a fresh full-text pass over raw files. - Candidate generation is a plain string match; no ranking model needed - because exact title occurrence is treated as sufficient signal for a - suggestion. -- **Docs linters (Vale, markdown-link-check, mkdocs)** — cheap because they're - not LLM-token-metered, but the transferable idea is uniform: they scope - work to files touched since the last run (git diff / mtime), not the whole - tree, every run. -- **RAG / embedding-based relation suggestion** — the standard shape is - candidate generation (cheap, high-recall) → rerank (expensive, high- - precision). This is structurally identical to what the toolkit's - frontmatter-registry → selective-Read pattern already does; frontmatter - summaries/tags stand in for embeddings as the cheap candidate filter, and - the LLM's full-body read + judgment stands in for the reranker. - -## Verdict - -The frontmatter-registry + selective-read pattern is the right shape and -doesn't need to be replaced. At wiki scale (hundreds, not millions, of -pages) it's a reasonable, infrastructure-free substitute for an embedding -index — this matches the toolkit's existing bias against fuzzy-matching -infra. Two concrete gaps are worth a follow-up design ticket, both drawn -directly from the prior art above: - -1. **Incremental scan, not full-registry rescan, per run.** Every surveyed - tool (Smart Connections' event-driven re-embed, docs linters' mtime/diff - scoping) treats "reprocess everything" as a one-time cost, not a - steady-state one — but cross-linker currently has no such boundary - specified. Concrete hook: `catalog.jsonl` already carries an `updated` - field per page. A cross-linker run should diff against its own last-run - timestamp (or a `.cross-linker-state` marker) and only treat pages with - `updated` newer than that marker as new candidates needing outbound-link - scanning — existing pages only get pulled in as potential *targets* found - via the frontmatter registry, not rescanned as sources. -2. **A cheap non-LLM pre-filter beyond frontmatter, borrowed from Roam/ - Logseq's unlinked-references mechanism**: a literal-string grep - (`grep -l -F ""` / ripgrep) for other pages' exact titles and - aliases across body text, run before any LLM `Read` call. This costs zero - LLM tokens (it's a shell op, not a context read) and directly produces - high-confidence EXTRACTED-tier candidates (exact title mention = strong - signal), narrowing what needs a full-body `Read` + LLM judgment call to - the INFERRED/AMBIGUOUS tier only — pages with topical/tag overlap in the - frontmatter registry but no literal string hit. - -Neither of these requires new infrastructure (no vector DB, no fuzzy -matching) — both fit the toolkit's existing "stable ID / cheap primitive -first" design bias. Recommend the follow-up grilling ticket decide: (a) -where the last-run marker lives, and (b) whether the grep pre-filter runs -against page titles only or titles+aliases from frontmatter. - -## Sources - -- https://github.com/brianpetro/obsidian-smart-connections -- https://smartconnections.app/smart-connections/ -- https://starlog.is/articles/data-knowledge/brianpetro-obsidian-smart-connections -- https://discuss.logseq.com/t/unlinked-reference-finder/4510 -- https://discuss.logseq.com/t/have-you-ever-designed-for-unlinked-references/19896 diff --git a/docs/design/cross-linker-spec.md b/docs/design/cross-linker-spec.md deleted file mode 100644 index 0579cab..0000000 --- a/docs/design/cross-linker-spec.md +++ /dev/null @@ -1,255 +0,0 @@ -# Cross-linker — Skill Spec - -Design for the `cross-linker` skill: scan the wiki and automatically discover missing -cross-references between pages. Extracted from `batching-and-crosslink.md` (that file's other -sections — additional metadata, batch planner — were absorbed into -[toolkit-spec.md](toolkit-spec.md) and removed). - -Status: active design for the open [cross-linker map, issue #94](https://github.com/callowayproject/wiki-toolkit/issues/94). -Scale strategy: see [cross-linker-scale-research.md](cross-linker-scale-research.md) (issue #97) for the prior-art -survey; the "Scale mechanism" subsection below (issue #115) is the resolved design. - -You are weaving the wiki's knowledge graph tighter by finding and inserting missing `[[wikilinks]]` between pages that should reference each other but currently don't. - -**Follow the Retrieval Primitives table in `llm-wiki/SKILL.md`.** Build the registry in Step 1 by grepping frontmatter only (not full pages). Reserve full `Read` for the unlinked-mention detection pass, and even there, only read pages whose summaries/titles make them plausible link targets. Blind full-vault reads are what this framework exists to avoid. - - -## Step 1: Read the catalog - -The catalog (`catalog.jsonl`) is an index of all the documents in the wiki (`wiki/`), with cross-references to the sources they reference. - -This is your "vocabulary" — every entry in this table is a valid wikilink target. Each entry's `aliases` -field (see toolkit-spec.md's Catalog schema) widens the vocabulary beyond the canonical `title` — an alternate -name a page is also known by. - -### Scale mechanism: no full-vault rescan per run - -Candidate detection scopes to **this ingest session's pages**, not the whole vault, every run: - -- **Sources scanned** — only the pages this ingest session wrote or updated. `cross-link-candidates` takes - these as explicit path arguments (the same page list the session is about to `log`/`propose-pr`), rather - than diffing `catalog.jsonl`'s `updated` field against a persisted last-run marker. No state file is needed — - the session already knows which pages it touched. -- **Targets available** — the full catalog registry (Step 1) stays the match target for those scanned pages; - existing pages are never rescanned as sources, only looked up as potential link destinations. -- **Zero-token pre-filter** — before any LLM `Read`, `cross-link-candidates` runs a literal `grep -F` match of - every catalog `title` and `aliases` entry against the session's page bodies. This produces the high-confidence - EXTRACTED-tier candidates cheaply; only pages with a hit (or with tag/`sources:` overlap feeding the - INFERRED tier per #96) need a full-body `Read` for scoring and relationship-type inference. - -## Step 2: Scan for Missing Links - -For each page in the vault: - -1. **Read the full content** -2. **Extract existing wikilinks** — find all `[[...]]` references already present -3. **Search for unlinked mentions** — check if the page's text contains any of these, without being wrapped in `[[...]]`: - - Page filenames (e.g., the word "MyProject" appears but `[[projects/my-project/my-project]]` is missing) - - Page titles from frontmatter - - Aliases from frontmatter - - Entity names, project names, concept names from the registry - -4. **Check for semantic connections** — pages that share multiple tags or are in the same project directory but don't link to each other - -### Matching Rules - -- **Case-insensitive matching** for names (e.g., "my-project" matches page `MyProject`) -- **Diacritic-insensitive matching** — normalize both the page name and the body text with Unicode NFKD (decompose accented characters to base + combining marks, strip combining marks) before comparing. This ensures body text "Muller" matches page `[[entities/müller]]` and vice versa. -- **Skip self-references** — a page shouldn't link to itself -- **Skip common words** — don't link "the", "and", generic terms. Only match on distinctive names -- **Prefer the shortest unambiguous wikilink path** — use `[[page-name]]` not `[[full/path/to/page-name]]` when the name is unique across the vault -- **Don't link inside code blocks** or frontmatter -- **Don't double-link** — if `[[foo]]` already appears on the page, don't add another - -## Step 3: Score and Rank Suggestions - -Not every possible link is worth adding. Score each candidate using a composite signal, then tag it with a confidence label. - -### Scoring - -| Signal | Points | Example | -|-------------------------------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **Exact name match in text** | +4 | "MyProject" appears in body text → link to my-project.md | -| **Shared tags (2+)** | +2 | Both tagged `#ai #agent` but no link between them | -| **Same project, no link** | +2 | Both under `projects/my-project/` but don't reference each other | -| **Mentioned entity/concept** | +2 | Page mentions "knowledge graphs" → link to `[[concepts/knowledge-graphs]]` | -| **Cross-category connection** | +2 | Source is in `concepts/`, target is in `entities/` (or `skills/` ↔ `synthesis/`) — different knowledge layers make this link more architecturally valuable | -| **Peripheral→hub reach** | +2 | Source page has ≤ 2 total links (peripheral) but target has ≥ 8 (hub) — connecting a loose page to a load-bearing concept | -| **Partial name match** | +1 | "graph" appears but page is `knowledge-graphs` — plausible but ambiguous | - -### Confidence labels - -Tag each candidate with a confidence label based on its score: - -| Score | Label | Action | -|-------|---------------|----------------------------------------------------------------------------------------------------------------------| -| ≥ 6 | **EXTRACTED** | Link is effectively certain — exact mention or very strong match. Apply inline. | -| 3–5 | **INFERRED** | Link is a reasonable inference — shared context, cross-category, peripheral→hub. Apply inline or as Related section. | -| 1–2 | **AMBIGUOUS** | Weak or partial match. Skip unless user specifically asks to connect loose pages. | - -Only act on **EXTRACTED** and **INFERRED** candidates. Include the confidence label in the Cross-Link Report so the user can review INFERRED links before trusting them. - -## Step 4: Apply Links - -**Pre-write snapshot** — before the first file write, check whether the vault itself is the root of a Git repository. Merely being a subdirectory of a larger repository does not qualify: running `git add -A` there could capture unrelated files. If the vault is not a standalone Git repository, skip this step silently — no nagging, no suggesting `git init`. - -```bash -VAULT_REAL_PATH=$(cd "$OBSIDIAN_VAULT_PATH" && pwd -P) -VAULT_GIT_ROOT=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse --show-toplevel 2>/dev/null || true) -SNAPSHOT_SHA="" - -if [ -n "$VAULT_GIT_ROOT" ] && [ "$VAULT_GIT_ROOT" = "$VAULT_REAL_PATH" ]; then - if git -C "$OBSIDIAN_VAULT_PATH" diff --quiet \ - && git -C "$OBSIDIAN_VAULT_PATH" diff --cached --quiet \ - && [ -z "$(git -C "$OBSIDIAN_VAULT_PATH" ls-files --others --exclude-standard)" ]; then - SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD) - else - if ! git -C "$OBSIDIAN_VAULT_PATH" add -A; then - echo "Pre-write snapshot failed; abort the skill without writing any vault files." >&2 - exit 1 - fi - if ! git -C "$OBSIDIAN_VAULT_PATH" commit -m "pre-cross-linker snapshot" --quiet; then - echo "Pre-write snapshot failed; abort the skill without writing any vault files." >&2 - exit 1 - fi - SNAPSHOT_SHA=$(git -C "$OBSIDIAN_VAULT_PATH" rev-parse HEAD) - fi -fi -``` - -The clean-repository branch deliberately avoids calling `git commit`, so "nothing to commit" is not treated as an error. If `git add` or `git commit` fails, stop before editing the vault; never continue without the promised snapshot. - -If `SNAPSHOT_SHA` is non-empty and the skill writes files, include the SHA in the final report. To discard the entire run, after confirming there are no later changes worth keeping, the user can run: - -```bash -git -C "$OBSIDIAN_VAULT_PATH" reset --hard "$SNAPSHOT_SHA" -git -C "$OBSIDIAN_VAULT_PATH" clean -fd -``` - -For each page with missing links: - -### 4a: Inline linking (preferred) - -Find the first natural mention of the term in the body text and wrap it in wikilinks: - -**Before:** -```markdown -This project uses knowledge graphs to connect entities. -``` - -**After:** -```markdown -This project uses [[concepts/knowledge-graphs|knowledge graphs]] to connect entities. -``` - -Use the `[[path|display text]]` format when the wikilink path differs from the display text. - -### 4b: Related section (fallback) - -If the term isn't mentioned naturally in the body but the pages are semantically related (shared tags, same project), add a `## Related` section at the bottom of the page: - -```markdown -## Related - -- [[projects/my-project/my-project]] — Also uses AI agents for research automation -- [[concepts/knowledge-graphs]] — Core technique used in this project -``` - -If a `## Related` section already exists, append to it. Don't duplicate existing entries. - -### 4c: Infer and write relationship type - -For every EXTRACTED or INFERRED link added (inline or related section), infer a semantic relationship type from the surrounding sentence context and write it to the page's `relationships:` frontmatter block. Skip AMBIGUOUS links. - -**Type inference rules** — scan the sentence containing the mention (or, for related-section links, the page title and shared-tag context): - -| Sentence pattern | Inferred type | -|-----------------------------------------------------------------|----------------| -| "X extends / builds on / generalises Y" | `extends` | -| "X implements / is an implementation of Y" | `implements` | -| "X contradicts / opposes / refutes / is at odds with Y" | `contradicts` | -| "X is derived from / based on / adapted from Y" | `derived_from` | -| "X uses / relies on / depends on / requires Y" | `uses` | -| "X replaces / supersedes / deprecates Y" | `replaces` | -| Shared tags or cross-category inference with no directional cue | `related_to` | - -If the surrounding context is ambiguous or the link came from shared-tag matching (no in-body mention), default to `related_to`. - -If a sentence matches more than one pattern (e.g. "RAG uses and extends the base retriever"), take the first matching row in table order above — `extends` beats `uses` in that example. Table order is the tie-break; don't add a separate specificity ranking. - -Only infer and write a relationship type for EXTRACTED and INFERRED links. AMBIGUOUS links are skipped by Step 3 already — no relationship entry is written for them, and no type is inferred at all. - -**Writing the block:** - -Read the page's YAML frontmatter. If a `relationships:` block already exists, append new entries without duplicating existing targets. If the block is absent, add it after `aliases:` (or after `tags:` when `aliases:` is missing). - -```yaml -relationships: - - target: "[[concepts/knowledge-graphs]]" - type: uses -``` - -Always use wikilink format (`[[path/to/page]]`) for `target` values in the `relationships:` YAML block. - -Only add entries for links added in this cross-linker run — do not touch typed entries that were already present. - -## Step 5: Score Misc Page Affinity - -After the main linking pass, update affinity scores for all pages in `misc/` (pages with `promotion_status: misc` in their frontmatter, or located under the `misc/` directory). - -For each misc page: - -1. **Collect outgoing links** — all `[[wikilinks]]` in the page body -2. **Collect incoming links** — grep the vault for `[[misc/]]` and `[[]]` references -3. For each linked page (both directions), check if it belongs to a project: - - Lives under `projects//` - - Has a `project:` frontmatter field matching a project name -4. Group by project name and sum: `outgoing_links + incoming_links` -5. Update the `affinity` frontmatter block on the misc page: - -```yaml -affinity: - obsidian-wiki: 3 - another-project: 1 -``` - -6. If any project's score ≥ 3: flag this page as a **promotion candidate** and record it for the report - -**Efficiency note:** only read the full body of misc pages — other pages only need a frontmatter grep to determine their project membership. - -## Step 6: Report - -Present a summary: - -```markdown -## Cross-Link Report - -### Links Added: 23 across 12 pages - -| Page | Links Added | Confidence | Placement | Relationship Types | -|-------------------------------------|-------------|------------|---------------------|------------------------------------| -| `projects/my-project/my-project.md` | 3 | EXTRACTED | 2 inline, 1 related | uses ×2, related_to ×1 | -| `entities/jane-doe.md` | 5 | INFERRED | 3 inline, 2 related | extends ×1, uses ×3, related_to ×1 | -| ... | | | | | - -### Orphan Pages Remaining: 2 -- `references/foo.md` — no incoming or outgoing links found -- `concepts/bar.md` — could not find related pages - -### Misc Promotion Candidates: N -Pages in misc/ that have ≥ 3 connections to a single project — ready to be promoted: - -| Page | Top Project | Score | -|---------------------------------------------------|-----------------|-------| -| `misc/web-martinfowler-articles-microservices.md` | `obsidian-wiki` | 4 | - -To promote: move the page to `projects//references/` and update all backlinks. -``` - -## Tips - -- **Run after every ingest.** New pages are almost always poorly connected. This is the fix. -- **Be conservative with inline links.** Only link the first natural mention, not every occurrence. -- **Don't touch pages in `_archives/` or `_readouts/`.** Archives are frozen snapshots; readouts are derived output from `wiki-narrate`, not knowledge pages. -- **Respect existing structure.** If a page carefully curates its links in a `## Key Concepts` section, add to that section rather than creating a separate `## Related`. -- **Entity pages are link magnets.** An entity like `jane-doe` should be linked from almost every project page. Prioritize these. diff --git a/docs/design/implementation-history.md b/docs/design/implementation-history.md index d65abd4..0c632d3 100644 --- a/docs/design/implementation-history.md +++ b/docs/design/implementation-history.md @@ -1,6 +1,6 @@ # Implementation history -How `wiki_toolkit` ([idea.md](idea.md) → [toolkit-spec.md](toolkit-spec.md)) actually got built, across two closed Wayfinder maps and their follow-on tickets. This is the connective narrative; the individual resolved decisions live in [`docs/adr/`](../adr/) — link there for the "why," not here. +How `wiki_toolkit` ([idea.md](idea.md) → [toolkit-spec.md](toolkit-spec.md)) actually got built, across closed Wayfinder maps and their follow-on tickets. This is the connective narrative; the individual resolved decisions live in [`docs/adr/`](../adr/) — link there for the "why," not here. ## Phase 1 — v1 CLI ([map #2](https://github.com/callowayproject/wiki-toolkit/issues/2), closed 2026-08-05) @@ -34,6 +34,21 @@ Scope: package the five agent-facing `SKILL.md` files (`ingest`, `query`, `lint` [#68](https://github.com/callowayproject/wiki-toolkit/issues/68) turned those four decisions into a build spec; #69–#75 implemented it: the plugin scaffold plus `ingest`/`query` (#70), `lint` (#71), `source-update` (#72), `maintain` (#73), `init`'s skills-copy scaffolding (#74), and `doctor`'s drift check (#75) — shipped as `wiki-toolkit` 0.18.0–0.18.2. +## Phase 3 — Cross-linker skill ([map #94](https://github.com/callowayproject/wiki-toolkit/issues/94), closed 2026-08-10) + +Scope: weave newly-ingested pages into the rest of the wiki's knowledge graph automatically, instead of relying on whatever `[[wikilink]]`s the agent happens to add while drafting. No ADRs for this map — its design questions were resolved directly into `toolkit-spec.md`'s schema/CLI surface and the `cross-linker` skill file itself, via [#116](https://github.com/callowayproject/wiki-toolkit/issues/116) (the map's implementation-spec handoff ticket): + +| Question | Resolved as | +|---|---| +| Candidate detection at scale | Scope to the session's own pages, not a full-vault rescan; a zero-token literal `grep -F` pre-filter over `catalog.jsonl` titles/aliases before any LLM read (research: issue #97) | +| Scoring rubric | 4-signal composite (exact match, partial match, shared sources, tag overlap, co-citation) with EXTRACTED/INFERRED/AMBIGUOUS tiers (issue #96) | +| Relationship-type inference | Seven fixed sentence patterns, first match in table order wins, default `related_to` (issue #98) | +| Alias/co-citation data | New optional `aliases:` frontmatter field plus `aliases`/`links` catalog fields, both additive with no migration (issue #115) | + +[#116](https://github.com/callowayproject/wiki-toolkit/issues/116) turned those decisions into a build spec; #117–#120 implemented it: `aliases`/`links` catalog fields (#117), the deterministic `cross-link-candidates` CLI subcommand (#118), narrowing `lint`'s semantic pass to report-only for cross-references (#119), and the `cross-linker` skill wired into `ingest` between `build` and `lint` (#120). + +`docs/design/cross-linker-spec.md` and `cross-linker-scale-research.md` were the map's working design docs (spec draft + prior-art research feeding into it) and are deleted now that it's closed — the as-built behavior lives in `skills/cross-linker/SKILL.md`, and the schema/CLI surface in [toolkit-spec.md](toolkit-spec.md). Two ideas from the spec draft were considered and explicitly dropped rather than carried forward: a git-snapshot/`reset --hard` undo mechanism (the existing `--frame needs-review` PR is the undo path) and misc-page affinity/promotion scoring (this toolkit has no `misc/`/`projects/` folder concept). + ## What's still open Neither phase touched idea.md's [Gaps section](idea.md) — the receiver's security boundary for untrusted external content, whether PR-review friction suppresses automated updates in practice, or whether the wiki should live in the code repo or a separate one. Those remain unresolved and are not implicitly closed by anything built here; source adapters (GitHub/Jira/Confluence), webhook wiring, the hosted-agent receiver, and real GitHub PR creation are all still future work. diff --git a/docs/design/toolkit-spec.md b/docs/design/toolkit-spec.md index f70df24..fc24d67 100644 --- a/docs/design/toolkit-spec.md +++ b/docs/design/toolkit-spec.md @@ -269,26 +269,14 @@ earlier drafts — see [CONTEXT.md](CONTEXT.md)). No adapter arguments yet. | `source-snapshot --units comments\|fields` | Write the new Raw snapshot unit(s) for the given mutation type | | `source-dedupe` | List `duplicate: true` files with rule-based (mtime/content-similarity) keep/discard suggestions; human confirms/executes — not auto-resolved | | `search-catalog --query "text"` | Search compiled wiki notes through the catalog | +| `cross-link-candidates ` | Literal, case-insensitive title/alias match of `page-paths`' bodies against every other `catalog.jsonl` entry (skipping code blocks, frontmatter, and mentions already wrapped in `[[...]]`); emits one JSONL candidate per line (`page`, `target`, `mention_text`, `match_type`). Zero LLM judgment — scoring and relationship-type inference are `cross-linker`'s job | | `log --title "..." --details "..."` | Append entry to `docs/log.jsonl` | -| `propose-pr --pages --frame routine\|needs-review` | Branch + commit locally, framed per mutation type that triggered it (no real GitHub PR yet) | +| `batch-plan ` | Split the files under `source-dir` into batches (100,000 bytes or 20 files per batch, whichever comes first) for parallel wiki-ingest subagent dispatch; prints `{batches: [{id, files, total_bytes}], stats: {total_files, total_bytes, batch_count}}` | +| `start-branch --frame routine\|needs-review` | Open a session's local branch up front, before any pages are committed — used by a batch coordinator so streaming `commit-pages` calls and the closing `propose-pr` call land on the same branch | +| `commit-pages --pages --message ` | Add and commit `pages` onto the currently checked-out branch — a batch coordinator calls this once per source, as soon as that source's subagent reports back, rather than waiting for the whole batch to finish | +| `propose-pr --pages --frame routine\|needs-review` | Branch + commit locally, framed per mutation type that triggered it (no real GitHub PR yet). If the current branch was already opened by `start-branch`, reuses it instead of creating a new one, and tolerates pages already committed via `commit-pages` | | `config show` | Read-only: print the resolved configuration and which source (default/env/`pyproject.toml`/flag) each value came from | -### Not yet built: batching extensions - -Planned additions for batched multi-source ingest (one PR per ingestion session, not one per -source) — spec written but not yet fully implemented: - -- `batch-plan ` — split the files under `source-dir` into batches (100,000 - bytes or 20 files per batch, whichever comes first), for parallel wiki-ingest subagent dispatch. -- `start-branch --frame routine|needs-review` — open a session's local branch up front, before any - pages are committed. Used by a batch coordinator so streaming per-source commits and the closing - `propose-pr` call land on the same branch. -- `commit-pages --pages --message ` — add and commit `pages` onto the currently - checked-out branch. A batch coordinator calls this once per source, as soon as that source's - subagent reports back, rather than waiting for the whole batch to finish. -- `propose-pr` extended to reuse a branch already opened by `start-branch` instead of creating a - new one, and to tolerate pages already committed by `commit-pages`. - ## Not yet built: adapters Each source type (GitHub, Jira, ...) would implement: