agent-wiki-cli 2.1.0__tar.gz → 2.2.0__tar.gz

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0}/MANIFEST.in

@@ -1,5 +1,6 @@
-recursive-include examples/plugins/documentation-hooks *.py *.json
+recursive-include examples/plugins/documentation-hooks *.py *.json *.md
 include release_build_backend.py
+include src/llm_wiki_cli/py.typed
 include src/llm_wiki_cli/schemas/llm-wiki-knowledge-v1.schema.json
 include src/llm_wiki_cli/extractors/ts_scripts/package-lock.json
 include docs/standalone-documentation.md
@@ -7,4 +8,5 @@ include docs/wiki-guide.md
 include docs/cli-reference.md
 include docs/automation.md
 include docs/security-model.md
+include docs/native-knowledge-provider.md
 prune reports

{agent_wiki_cli-2.1.0/src/agent_wiki_cli.egg-info → agent_wiki_cli-2.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agent-wiki-cli
-Version: 2.1.0
+Version: 2.2.0
 Summary: CLI tool to maintain hybrid LLM Wikis for multi-language projects.
 Author-email: Denis Sivagin <denissvgn@gmail.com>
 License-Expression: MIT
@@ -45,7 +45,7 @@ and guides that static analysis cannot provide.
 The PyPI package is `agent-wiki-cli`, the command is `llm-wiki`, and the Python
 import package is `llm_wiki_cli`.
 
-[Quick start](#quick-start) · [Command reference](docs/cli-reference.md) ·
+[Quick start](#quick-start) · [Examples](examples/README.md) · [Command reference](docs/cli-reference.md) ·
 [Standalone documentation](docs/standalone-documentation.md)
 
 ## Installation
@@ -93,6 +93,10 @@ llm-wiki lint --strict --src-dir . --wiki-dir docs/llm_wiki --jobs 1
 For an isolated documentation workspace from source or an existing enriched
 wiki, follow the [standalone documentation guide](docs/standalone-documentation.md).
 
+For a small project you can copy and change, try the
+[Python, FastAPI, Go, and plugin tutorials](examples/README.md). They show the
+generated pages, a source edit, and the next sync without requiring a model service.
+
 ## What It Creates
 
 The default `docs/llm_wiki/` contains an index, module and entity pages,

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0}/README.md

@@ -8,7 +8,7 @@ and guides that static analysis cannot provide.
 The PyPI package is `agent-wiki-cli`, the command is `llm-wiki`, and the Python
 import package is `llm_wiki_cli`.
 
-[Quick start](#quick-start) · [Command reference](docs/cli-reference.md) ·
+[Quick start](#quick-start) · [Examples](examples/README.md) · [Command reference](docs/cli-reference.md) ·
 [Standalone documentation](docs/standalone-documentation.md)
 
 ## Installation
@@ -56,6 +56,10 @@ llm-wiki lint --strict --src-dir . --wiki-dir docs/llm_wiki --jobs 1
 For an isolated documentation workspace from source or an existing enriched
 wiki, follow the [standalone documentation guide](docs/standalone-documentation.md).
 
+For a small project you can copy and change, try the
+[Python, FastAPI, Go, and plugin tutorials](examples/README.md). They show the
+generated pages, a source edit, and the next sync without requiring a model service.
+
 ## What It Creates
 
 The default `docs/llm_wiki/` contains an index, module and entity pages,

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0}/docs/cli-reference.md

@@ -5,6 +5,10 @@
 Use `llm-wiki <command> --help` for the complete option list. The sections below
 explain command behavior, output contracts, and recovery procedures.
 
+Follow the [runnable examples](../examples/README.md) for a complete Python
+documentation cycle, production FastAPI contracts, Go HTTP analysis, or a custom
+task detector with Mermaid styling.
+
 | Task | Commands |
 |---|---|
 | Set up a wiki | [init](#init), [prepare-extractors](#prepare-extractors), [bootstrap](#bootstrap) |
@@ -338,6 +342,8 @@ execution order. Workflow pages require resolved direct calls into at least
 three other selected project modules; an executable need not meet that threshold.
 When a receiver type and its method are declared in different files, workflow
 entry labels and source paths use the file that defines the method.
+The [Go HTTP example](../examples/go-http/README.md) demonstrates helper
+preparation, cross-file handlers, package calls, and sync after a method rename.
 Haskell file entries are additive under `llm-wiki-extract/v1`. A Haskell entry
 uses `language: "haskell"`, `imports`, `classes`, and `functions`, with `module`
 present when the source declares one. Import records use `module`, `qualified`,
@@ -707,6 +713,14 @@ Text output shows these next steps directly.
 
 ## `context`
 
+Use `--request FILE --format packet` to deliver a canonical v1/v2 packet from
+a filter-bearing request file. The file owns semantic options; explicit
+budget, focus, freshness-preference, or knowledge-mode overrides are rejected.
+The file's inner format remains JSON or Markdown. For v3 requests, the declared
+outer format must agree with any explicit format flag. See
+[qualified context packets](qualified-context-packets.md) for request examples,
+error codes, and the distinction between validation and currentness.
+
 Build a token-budgeted source snapshot for agents.
 
 ```bash
@@ -792,6 +806,10 @@ same optional `knowledge_mode`. Qualified packet versioning and validation are
 described in [Qualified context packets](qualified-context-packets.md).
 
 `filters.language` and `filters.module` scope the budgeted `files` payload.
+Module filters are glob patterns over extensionless paths or dotted module
+names: use `app/service` or `app.service`, rather than `app/service.py`.
+Check the returned file set and native selection before relying on the result;
+an unmatched valid filter can correctly produce an empty selection.
 `filters.symbol`, `filters.entrypoint`, and `filters.surface` add bounded
 `graphs` and `surface` sections without changing the file-priority budget.
 `filters.freshness` and `filters.evidence` refine concept references and require
@@ -1089,6 +1107,10 @@ plugins cannot inject Markdown, labels, hrefs, or raw Mermaid lines. Core
 renderers keep labels Unicode-safe and bounded, and validate and percent-encode
 relative `click` hrefs.
 
+Data-flow style contexts also include `flow_id`, `category`, and the entry
+`symbol` with its original case. Hooks can use `symbol` to match the first
+numbered node label, such as `1. HANDLE_TASK`.
+
 These hooks are deterministic local extension contracts over explicit inputs;
 they do not perform network discovery and they do not mutate Markdown directly.
 They are not a sandbox, though: installing a plugin runs trusted project-local
@@ -1744,6 +1766,17 @@ of UTF-8 content, with 1–100 returned results. Exceeding a corpus limit fails
 explicitly; narrow `--kind` or choose a smaller wiki. Search is read-only and
 does not require embeddings or a model service.
 
+The query must contain a non-whitespace character. Nonblank queries retain
+their original whitespace, including in substring mode. `--limit` accepts a
+positive integer, defaults to 20, and caps the returned results at 100 even when
+a larger value is requested. Blank queries and invalid limits exit `2`, leave
+stdout empty, and print argument diagnostics to stderr in both output formats.
+A valid query with no matches exits `0` with empty results.
+
+JSON responses from both the CLI and MCP disclose `mode` (`ranked` or
+`substring`), `total`, `returned`, and `bounds.results`, including truncation.
+Ranked scores and provenance remain specific to ranked mode.
+
 ## `queue`
 
 Select advisory maintenance work for a managed wiki:
@@ -1762,6 +1795,20 @@ reuses existing freshness and worklist evidence, loads no project plugins, and
 does not edit pages or change the integrity gate. Prepared helpers are required
 for the selected source languages; `--helper-cache-dir` selects their cache.
 
+`--limit` accepts integers from 1 through 1000 inclusive and defaults to 30.
+Invalid limits exit `2` before reading the queue inputs, with empty stdout and
+an argument diagnostic on stderr in either output format.
+
+The JSON report includes the requested `limit`, `total`, `returned`, and
+`omitted`; `returned` equals the number of `items`, and `total` equals
+`returned + omitted`. The `limit` field is additive metadata in
+`llm-wiki-maintenance-queue/v1`. Consumers should accept additional fields.
+The `queue_id` hashes the complete report, including `limit`: identical inputs
+and limits give the same identity, while different limits give different
+identities even if every item fits. Reports from versions without this field
+have different identities. A valid advisory queue exits `0`, including when
+there is no recommended work.
+
 ## `upgrade`
 
 Refresh framework-managed artifacts in place.
@@ -1808,6 +1855,23 @@ managed instruction block or change its compact/expanded delivery, use
 
 ## `knowledge`
 
+Read eligibility and freshness diagnostics without enabling governance:
+
+```bash
+llm-wiki knowledge coverage --wiki-dir wiki
+llm-wiki knowledge coverage --src-dir src --wiki-dir wiki --live --format json
+```
+
+The default reads the committed snapshot only. `--live` performs source
+extraction with prepared helpers; `--source-selection`, `--helper-cache-dir`
+and `--allow-external-src` preserve the corresponding source options.
+The versioned report separates modeled concepts, intentionally unmodeled
+content, actual comparisons and missing/incompatible bases. It is advisory;
+`unknown` over all concepts is not a defect rate. Unavailable knowledge has
+null counts, while a valid empty model has zeroes. JSON failures leave stdout
+empty and emit a safe code/field record on stderr with exit 1; usage errors
+retain exit 2. See [coverage diagnostics](native-knowledge.md#coverage-diagnostics).
+
 Initialize durable identity, inspect governance, record explicit lifecycle or
 section review events, stage ambiguous moves, and run application-owned pure
 verification checkers:

agent_wiki_cli-2.2.0/docs/native-knowledge-provider.md

@@ -0,0 +1,184 @@
+# Integrating native knowledge
+
+Install `agent-wiki-cli` 2.2.0 or newer in your application's environment and use
+`llm_wiki_cli.api` for native reads. `llm_wiki_cli.api_types` defines their
+structured return types. The wheel and source distribution include inline
+annotations with the standard `py.typed` marker. Nested extractor or versioned
+wire records deliberately use `Any` where the narrower shape belongs to that
+separate contract; annotations do not replace runtime validation.
+
+The native consumer compatibility contract covers these public modules and
+their documented exports. Importing another service module does not make it
+part of this contract. Extension and documentation-controller interfaces have
+their own guides. See the Python
+[typing distribution specification](https://typing.python.org/en/latest/spec/distributing.html#packaging-type-information)
+for how installed annotations are discovered.
+
+## Choose a read operation
+
+| Public operation | Scope and result | Writes |
+|---|---|---|
+| `bootstrap_wiki(source_root, wiki_root)` | Creates initial deterministic Markdown and native projections; always uses source-adapter behavior | Explicit wiki creation; no agent setup |
+| `extract_source(..., deep=True, read_only=True)` | Source inventory with declared extraction scope | No implicit preparation or source edits |
+| `inspect_concept(..., live=False)` | One exact concept, typed edges, sections and coverage from a committed snapshot | None |
+| `inspect_concept(..., live=True)` | The same bounded result with one live full source capture and final input checks | None |
+| `get_knowledge_coverage(..., live=False)` | Eligibility counts; freshness is unevaluated | None |
+| `get_knowledge_coverage(..., live=True)` | Eligibility, actual comparisons and modeled freshness | None |
+| `build_documentation_query_service(...)` | Captures a live full inventory for several queries within one operation | Read-only by default |
+| `get_concept`, `related_concepts`, `list_concept_sections`, `traverse_typed_graph`, `explain_evidence` | Reuse `service=` or construct a live service; preserve each result's qualifiers | Read-only by default |
+| `query_documentation(request)` | Exact snapshot queries, supplied-path impact, or explicitly authorized full inventory | None |
+| `build_context`, `build_qualified_context` | Bounded source context or a canonical qualified packet | Read-only by default |
+| `validate_context_packet`, `compare_context_packet_basis` | Offline structural validation or supplied-basis comparison | None; no live-currentness claim |
+| `reconcile_context_packet` | New read against caller-designated roots | None; does not refresh projections |
+
+Only a new live read can evaluate currentness. Reusing a service retains its
+captured scope; rebuild it for later work. `required` knowledge mode requires
+ready native knowledge, not a positive live-currentness verdict. A successful
+unavailable/fallback response is different from a ready model with no matching
+concept. Check availability before interpreting `found=False`.
+
+```python
+from llm_wiki_cli import api
+
+result = api.inspect_concept(
+    "llm-wiki://entities/Item",
+    src_dir="src",
+    wiki_dir="wiki",
+    live=True,
+    helper_cache_dir=".cache",
+)
+assert result["schema_version"] == api.NATIVE_INSPECTION_SCHEMA_VERSION
+coverage = result["coverage"]
+assert coverage["schema_version"] == api.KNOWLEDGE_COVERAGE_SCHEMA_VERSION
+```
+
+Keep availability, source observation, review, verification, analyzer coverage,
+and response truncation separate. `current` means the captured observation is
+unchanged, not that prose or runtime behavior is correct. Intentionally
+unmodeled concepts are not stale concepts. Missing bases remain in the modeled
+population. See [native scopes and result bounds](native-knowledge.md#python-api).
+
+## Workspace and process boundaries
+
+The working directory is the allowed workspace boundary. Relative source and
+wiki paths are resolved there. An absolute wiki path must remain within that
+boundary. `allow_external_src=True` authorizes an external **source** root; it
+does not authorize arbitrary wiki roots or weaken symlink containment.
+
+The headless `bootstrap_wiki` writer also requires non-overlapping source and
+wiki roots. With a whole-repository source input, place its initial wiki beside
+that input in the consumer workspace. With `src/` as the input, a sibling
+`wiki/` is suitable. Existing read operations can consume a conventional wiki
+inside a repository; this does not relax the headless writer's source protection.
+
+A process can read two projects under a common trusted workspace without
+changing its working directory. Pass explicit roots for every operation:
+
+```python
+from pathlib import Path
+from llm_wiki_cli import api
+
+workspace = Path.cwd()
+results = {
+    project: api.get_knowledge_coverage(
+        src_dir=str(workspace / project / "src"),
+        wiki_dir=str(workspace / project / "wiki"),
+        live=False,
+    )
+    for project in ("project-a", "project-b")
+}
+```
+
+For unrelated workspace roots, launch a separate process with the consumer
+project as `cwd`. Do not temporarily change process-wide cwd in a threaded
+host. This CLI recipe returns the same coverage contract:
+
+```python
+import json
+from pathlib import Path
+import subprocess
+import sys
+
+project = Path("/work/consumer-project")
+completed = subprocess.run(
+    [sys.executable, "-I", "-m", "llm_wiki_cli.cli", "knowledge", "coverage",
+     "--wiki-dir", "wiki", "--format", "json"],
+    cwd=project, capture_output=True, text=True, check=True,
+)
+coverage = json.loads(completed.stdout)
+```
+
+Use separate mutable inventory-cache directories for separate projects.
+Prepared language helpers may share an explicitly selected, trusted cache.
+`--cache-dir BASE` during preparation and `--helper-cache-dir BASE` during reads
+refer to the same **base**: helper storage is placed in `BASE/llm-wiki-extractors`.
+Prepare dependencies explicitly before a read; unavailable helpers produce an
+actionable failure instead of an empty successful inventory.
+
+## Dependencies and optional adoption
+
+The base library requires Python 3.10+ and its declared parsing dependencies.
+It does not require an agent configuration, MCP, tokenizers, model-provider
+SDKs, or the provider repository's own wiki. Install `[mcp]` for the advertised
+stdio or local HTTP server, and `[tokens]` only for exact token counting with a
+caller-supplied local tokenizer. External language helpers require their
+documented runtimes and explicit preparation.
+
+The [downstream tutorial](../examples/native-knowledge/README.md) demonstrates
+bootstrap, qualified reads, source drift, authored follow-up and sync without
+agent setup. Add managed agent instructions, durable governance, scoped review
+or Site/Obsidian export only when your integration needs them. Existing user
+prose and rules remain consumer-owned. Snapshot readers do not initialize or
+repair those optional components.
+Export writers also enforce a managed wiki's recorded source-selection
+boundary. Carry the consumer's source root and profile into an Obsidian export,
+even when enriched export uses the committed snapshot without extracting source.
+
+## Producer and reader compatibility
+
+Static scope matters when judging whether a response answers the task:
+
+| Language | Useful boundary |
+|---|---|
+| Python | Declared signatures, members and supported static model metadata; TypedDict key presence is separate from nullability. Runtime validators and dynamic imports are not executed. |
+| TypeScript/JavaScript | Top-level class/interface/type declarations and supported exports; nested namespace members and dynamic initialization can require direct source inspection. A union with `undefined` does not itself make a property optional. |
+| Go | Package declarations, receiver identity and supported call observations; function-valued hooks do not imply a statically resolved target. |
+| Rust | Parsed declarations and impl associations; `cfg`/feature-dependent declarations do not prove which implementation is active at runtime. An omitted return-type field represents no explicit annotation. |
+| Haskell | Module/import/signature and type-oriented declaration inventory; constructor payloads and runtime behavior require additional source evidence. CPP needs an explicitly preprocessed snapshot, with that snapshot's scope and coordinates. |
+
+| Input | Reader behavior |
+|---|---|
+| Omitted knowledge mode / context v1 | Retains qualified packet v1 behavior |
+| Explicit `off`, `auto`, `required` / context v2 | Uses qualified packet v2; no implicit v1 reinterpretation |
+| Context v3 accounting envelope | Contains an existing qualified v2 packet; outer accounting is a separate contract |
+| Validated surface-only legacy wiki | Explicit absent native knowledge; supported fallback remains available |
+| Supported committed native schema | Snapshot reads validate commitments; live reads separately compare the producer/source basis |
+| Supported schema from a different producer basis | Snapshot qualification remains distinct from live compatibility; do not assume `current` |
+| Unsupported schema or broken commitments | Explicit unsupported/degraded result where a safe fallback exists, otherwise a structured integrity failure |
+
+The inspection and coverage schemas are separate from packet v1/v2 and the
+closed aggregate summary. Their public constants are exported by `api`.
+Preserve omitted-mode behavior when upgrading an existing consumer; use
+explicit `auto` in a native integration that permits fallback.
+
+Upgrade through the owning command: run `sync` with the recorded source
+selection and prepared helpers, review its Markdown changes, and rebuild
+handoffs. `--rebuild-knowledge` explicitly forces a new projection. Do not edit
+generated projection hashes to make incompatible inputs appear current.
+Consumers must compare a packet's embedded normalized request with their own
+intent before relying on reconciliation. See [qualified packets](qualified-context-packets.md).
+
+## Errors and authority
+
+Catch `api.LlmWikiApiError` or its `InvalidRequestError`, `WorkspaceStateError`
+and `ArtifactIntegrityError` subclasses. Native semantic failures expose safe
+codes and field details; validated wiki-relative recovery paths may be present.
+Raw chained causes are for local debugging. Ordinary Python argument binding,
+CLI usage errors and MCP argument-schema errors retain their native boundaries.
+See the [native error contract](native-knowledge.md#native-query-failures).
+
+Read-only native queries and packets use built-in source adapters and do not
+execute the target application or its project-local plugins. Their static
+observations do not establish runtime behavior, authenticated review, or
+secret-free publication. The consumer owns decisions to share prose, metadata
+and source content or to apply a blocking policy to advisory drift.

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0}/docs/wiki-guide.md

@@ -5,6 +5,8 @@
 Use this guide to understand the generated wiki, choose source inputs, and
 configure an agent. For the shortest setup, start with the
 [README quick start](../README.md#quick-start).
+The [examples](../examples/README.md) provide complete Python, FastAPI, Go HTTP,
+and plugin projects with commands and expected output.
 
 - [Wiki pages and content ownership](#what-it-creates)
 - [Supported inputs](#supported-inputs), [source selection](#source-selection), and [Haskell details](#haskell-inputs)
@@ -115,6 +117,10 @@ The original `PathPolicyError` name remains an alias for
 `InvalidRequestError`; `ExtractionError` and `BootstrapError` remain aliases
 for `WorkspaceStateError`. The original internal exception is available
 through `__cause__`.
+Native query operations also supply safe machine-readable codes and field
+details; see [native query failures](native-knowledge.md#native-query-failures).
+The [native knowledge tutorial](../examples/native-knowledge/README.md) shows
+a library consumer using shared inspection, coverage and qualified packets.
 
 The package has a small required Python runtime footprint. `PyYAML>=6` parses
 user-supplied OpenAPI YAML, and Python versions older than 3.11 use `tomli` for
@@ -211,6 +217,13 @@ entries.
 GHC 9.6.x is the supported Haskell helper toolchain for this release. Newer GHC
 9.x releases are best-effort, and helper preparation fails clearly when GHC
 version output is malformed or older than 9.6.
+The syntax parser starts with Haskell2010 and applies declared `LANGUAGE`
+options, including multiline pragmas, implied extensions and `No...` overrides.
+Only syntax options are read from `OPTIONS_GHC`; preprocessors, compiler
+plugins and target build actions are never executed. CPP-conditioned source
+requires an explicitly preprocessed input snapshot from the consumer's trusted
+build configuration. The reader does not guess dependency versions or choose
+CPP branches. Source coordinates then refer to the supplied snapshot.
 
 ## Agent Support
 

agent_wiki_cli-2.2.0/examples/plugins/documentation-hooks/README.md

@@ -0,0 +1,93 @@
+# Documentation hooks sample plugin
+
+This plugin adds task entry points and bounded Mermaid style hints to LLM Wiki.
+Use `agent-wiki-cli` 2.2.0 or newer on Python 3.10+. No model service, worker
+framework, or additional Python dependency is required.
+
+| File | Role |
+|---|---|
+| `llm-wiki-plugin.json` | Declares the `documentation-hooks` plugin and its two components |
+| `detectors.py` | Implements `documentation-hooks/worker-tasks` through `detectors:detect_worker_tasks` |
+| `styles.py` | Implements `documentation-hooks/brand-flowcharts` through `styles:style_flowcharts` |
+
+The detector normalizes path separators and case, then matches paths ending in
+`tasks.py` and function names `handle_task` or `task_handler`. This literal
+suffix rule also matches names such as `worker_tasks.py`. It returns category
+`task` and label `task-handler`; the core assigns the stable entry ID
+`task-task-handler` for the single-handler example. It is a naming convention,
+not a Celery/RQ adapter or proof that a worker schedules the function.
+
+## Try it in a fresh project
+
+Run the commands from a new project directory. Create `tasks.py` there:
+
+```python
+def handle_task(title: str) -> str:
+    """Normalize a task title without contacting a service."""
+    return title.strip()
+```
+
+Create `.gitignore` so generated content and plugin source stay out of the
+application inventory:
+
+```gitignore
+/wiki/
+/vendor/
+/.llm-wiki/
+/AGENTS.md
+__pycache__/
+```
+
+```sh
+llm-wiki init --agent generic --no-skills --wiki-dir wiki
+llm-wiki plugins samples export documentation-hooks --dest vendor/documentation-hooks
+llm-wiki plugins validate vendor/documentation-hooks
+llm-wiki install vendor/documentation-hooks --yes --wiki-dir wiki
+llm-wiki bootstrap --src-dir . --wiki-dir wiki
+```
+
+If you already exported this README and its three neighboring files to
+`vendor/documentation-hooks`, skip the export command. Export does not replace
+an existing directory by default. Files do not activate a plugin until you run
+`install`; hooks are Python code, so install only a plugin you trust. Here
+`--yes` accepts installation of the bundled sample you have inspected.
+
+Open `wiki/flows/task-task-handler.md`. The data-flow diagram contains:
+
+```text
+s1["1. handle_task"]
+classDef entry fill:#2E7D32,stroke:#2E7D32
+class s1 entry
+```
+
+A Mermaid viewer shows the first task node in green. The hook uses the entry
+`symbol` from the style context to match its actual numbered label, including
+case variants such as `1. HANDLE_TASK` and `1. Task_Handler`. It applies only
+when the surface is `data_flow` and its category is `task`. It leaves other task
+steps and unrelated data flows uncolored. Relationship/dependency flowcharts retain the sample's
+`task-handler` label hint and left-to-right direction. Sequence diagrams are
+outside this hook's supported surfaces. These are color, class, and direction
+hints; they do not change graph edges or the renderer's reserved classes.
+
+## Change and repeat
+
+Rename the function in `tasks.py` to `task_handler`, keeping its body, then run:
+
+```sh
+llm-wiki sync --jobs 1 --src-dir . --wiki-dir wiki
+llm-wiki lint --jobs 1 --src-dir . --wiki-dir wiki
+```
+
+The same flow page now identifies `task_handler` and colors its first node.
+Use sync for later runs and a fresh working copy for another bootstrap.
+
+To install from a source checkout instead of exporting, run
+`llm-wiki install PATH --yes --wiki-dir wiki` from your project directory,
+replacing `PATH` with the absolute path to
+`examples/plugins/documentation-hooks` in that checkout. The
+[full repository tutorial](https://github.com/Denissvgn/python-wiki-llm/tree/main/examples/plugin-hooks)
+adds a storage call to make transfers and filesystem boundaries visible.
+
+The older sample name `m4-documentation-hooks` remains an export alias with a
+deprecation warning. Use `documentation-hooks` for new commands; installed
+component references are unchanged.

agent_wiki_cli-2.2.0/examples/plugins/documentation-hooks/styles.py

@@ -0,0 +1,29 @@
+"""Sample bounded diagram-style hooks for LLM Wiki plugins."""
+
+from __future__ import annotations
+
+
+def style_flowcharts(context):
+    """Return safe Mermaid style hints for generated flowchart surfaces."""
+    context = context or {}
+    surface = str(context.get("surface", ""))
+    if surface not in {"relationships", "dependencies", "data_flow"}:
+        return {}
+    node_classes = {"task-handler": "entry"}
+    if surface == "data_flow":
+        # Data-flow nodes use numbered callable labels, not entry-point labels.
+        node_classes = (
+            {"1. handle_task": "entry", "1. task_handler": "entry"}
+            if context.get("category") == "task"
+            else {}
+        )
+        symbol = str(context.get("symbol") or "")
+        if context.get("category") == "task" and symbol.lower() in {
+            "handle_task", "task_handler",
+        }:
+            node_classes = {f"1. {symbol}": "entry"}
+    return {
+        "direction": "LR",
+        "node_classes": node_classes,
+        "category_colors": {"entry": "#2E7D32"},
+    }

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0}/pyproject.toml

@@ -5,7 +5,7 @@ backend-path = ["."]
 
 [project]
 name = "agent-wiki-cli"
-version = "2.1.0"
+version = "2.2.0"
 description = "CLI tool to maintain hybrid LLM Wikis for multi-language projects."
 readme = "README.md"
 license = "MIT"
@@ -65,6 +65,7 @@ where = ["src"]
 
 [tool.setuptools.package-data]
 "llm_wiki_cli" = [
+    "py.typed",
     "schemas/llm-wiki-knowledge-v1.schema.json",
     "extractors/ts_scripts/package.json",
     "extractors/ts_scripts/package-lock.json",
@@ -81,6 +82,7 @@ where = ["src"]
     "extractors/rust_scripts/src/main.rs",
     "examples/plugins/documentation-hooks/detectors.py",
     "examples/plugins/documentation-hooks/llm-wiki-plugin.json",
+    "examples/plugins/documentation-hooks/README.md",
     "examples/plugins/documentation-hooks/styles.py",
     "skills/agent-docs/SKILL.md",
     "skills/agent-docs/reference.md",

{agent_wiki_cli-2.1.0 → agent_wiki_cli-2.2.0/src/agent_wiki_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agent-wiki-cli
-Version: 2.1.0
+Version: 2.2.0
 Summary: CLI tool to maintain hybrid LLM Wikis for multi-language projects.
 Author-email: Denis Sivagin <denissvgn@gmail.com>
 License-Expression: MIT
@@ -45,7 +45,7 @@ and guides that static analysis cannot provide.
 The PyPI package is `agent-wiki-cli`, the command is `llm-wiki`, and the Python
 import package is `llm_wiki_cli`.
 
-[Quick start](#quick-start) · [Command reference](docs/cli-reference.md) ·
+[Quick start](#quick-start) · [Examples](examples/README.md) · [Command reference](docs/cli-reference.md) ·
 [Standalone documentation](docs/standalone-documentation.md)
 
 ## Installation
@@ -93,6 +93,10 @@ llm-wiki lint --strict --src-dir . --wiki-dir docs/llm_wiki --jobs 1
 For an isolated documentation workspace from source or an existing enriched
 wiki, follow the [standalone documentation guide](docs/standalone-documentation.md).
 
+For a small project you can copy and change, try the
+[Python, FastAPI, Go, and plugin tutorials](examples/README.md). They show the
+generated pages, a source edit, and the next sync without requiring a model service.
+
 ## What It Creates
 
 The default `docs/llm_wiki/` contains an index, module and entity pages,