dxkit-author-extensionlisted

# dxkit-author-extension You are writing the extension; the user describes the convention. Work the ladder from the bottom — the lowest rung that expresses the need wins, and every rung down is less code the user owns: 1. **Config / declared artifact** — if the evidence already exists as a Postman collection, Pact, `.http` file, HAR, or OpenAPI doc, declare it in `.dxkit/policy.json:flow.sources` and STOP. No code. 2. **External script (rung 3)** — the user has extraction logic (any language) or you can write ~50 lines of Python: a manifest + stdin-payload adapter emitting one wire document. This covers almost everything: inventories, custom findings, delivery sinks. 3. **TypeScript plugin (rung 4)** — only when the need is INSIDE dxkit's gather: a bespoke HTTP-client wrapper flow can't see, a custom artifact format for `flow.sources`, base-URL logic beyond `stripUrlPrefixes`, or an assertion over the gathered flow model. ## The authoring loop (all rungs) 1. Scaffold: `vyuh-dxkit extensions init <name> --kind <kind> --command "…"` (rung 3, `--stub` for a Python starter) or `vyuh-dxkit extensions init <name> --plugin [--kind <kind>]` (rung 4). 2. Read sample source/artifacts the user points at; fill in the logic. 3. `vyuh-dxkit extensions dev <name>` — field-precise errors ARE the spec; iterate until VALID and the summary shows the expected counts. 4. Sanity-check counts against ground truth (grep the repo, count rows). 5. Commit the manife