kd-cli 2.6.0__tar.gz → 2.6.1__tar.gz

{kd_cli-2.6.0/kd_cli.egg-info → kd_cli-2.6.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: kd-cli
-Version: 2.6.0
+Version: 2.6.1
 Summary: Knowledge Dispatcher for issue trackers and knowledge bases
 Author: Sergiy Gladkyy
 License-Expression: MIT

{kd_cli-2.6.0 → kd_cli-2.6.1}/kd/resources/CHANGELOG.md

@@ -4,6 +4,17 @@ All notable changes to kd-cli are recorded here. The project follows [Semantic V
 
 ## [Unreleased]
 
+## [2.6.1] — 2026-04-27
+
+### Documentation
+- `kd --sdlc` now opens with a reader-first mental model and vocabulary before
+  the layer, cache, marker-bridged, and closeout rules. The packaged doctrine
+  keeps the same tool contracts while making the SDLC easier for first-time
+  human readers and LLM agents to explain.
+- `kd --sdlc` now defines daybooks, surfaces the session starter checklist
+  near the front, and clarifies the planning path from ideation through setup
+  into the repeatable session loop.
+
 ## [2.6.0] — 2026-04-27
 
 ### Added

kd_cli-2.6.1/kd/resources/sdlc-doctrine.md

@@ -0,0 +1,602 @@
+# SDLC Doctrine (Portable)
+
+This is the portable SDLC reference bundled with kd-cli and printed by
+`kd --sdlc`. It explains the working method for projects that use kd and
+YouTrack as a knowledge-network substrate.
+
+The short version:
+
+1. YouTrack is the canonical place for planning and durable knowledge.
+2. The repository stays thin: code, build machinery, session harness files,
+   and a narrow class of repo-reviewed knowledge files.
+3. `.kd/` is local context: primer plus disposable cache, never authority.
+4. A session starts by pulling context, proceeds through work and verification,
+   and closes by pushing focused results back to the tracker.
+
+This document is not a command catalog. Use `kd --reference` for exact syntax
+and `kd --guide` for kd-specific operating guidance.
+
+## The mental model
+
+The SDLC is a loop:
+
+```text
+pull context -> reason and work -> verify -> publish the outcome
+```
+
+The operator, human or LLM, begins with a small local primer, pulls the issue
+or article context needed for the task, performs the work in the repository,
+then records the outcome upstream. kd supports that loop with narrow commands:
+
+- `kd /primer show` reads the workspace's curated starting context.
+- `kd /issue show`, `kd /article show`, `kd /tag entities`, and saved queries
+  pull live context from YouTrack.
+- `kd /cache refresh`, `kd /cache status`, and `kd /cache search` support
+  read-side local resilience.
+- `kd /article push` publishes a repo-authored article render upstream.
+- `kd /issue touched --git-range A..B` helps reconcile offline work from git
+  history.
+
+The doctrine is deliberately upstream-first, not repo-doc-first. Most durable
+knowledge belongs in YouTrack articles. The repo keeps only what needs to live
+beside code or be loaded by the tool and harness.
+
+## Vocabulary
+
+These terms are used throughout the doctrine.
+
+| Term | Meaning |
+|------|---------|
+| Upstream | The live tracker and knowledge base, normally YouTrack. |
+| Issue | The execution record for work: task, bug, story, epic, or subtask. |
+| Epic | The upstream container for milestone-sized work. |
+| Article | A durable knowledge page in YouTrack: design note, how-to, index, playbook, daybook, accepted proposal. |
+| Daybook | A chronological project article for operational memory: context shifts, notable decisions, incidents, and narrative breadcrumbs that do not belong in a single issue closeout or timeless design record. |
+| Primer | Workspace-local `.kd/primer.yaml`: short notes plus pinned references that tell the operator what to read first. |
+| Cache | Disposable `.kd/cache/` mirror of selected upstream content for reading and offline resilience. |
+| Session | One bounded work cycle against an issue or, for non-code exploration, an explicitly chosen no-ticket path. |
+| HITL | Human-in-the-loop validation against a real upstream system. |
+| Publication tier | The rule that decides how much of a session becomes upstream record: full closeout, compact capsule, article, or summary only. |
+| Profile | A project-local article that records conventions not shared by every project using this portable doctrine. |
+| Umbrella ticket | One fixed project ticket for tiny hygiene commits that genuinely have no story worth telling. |
+| Marker-bridged file | A repo file with a `kd-meta` marker that is reviewed in git but rendered as an upstream article. |
+
+## Session starter checklist
+
+When beginning a session:
+
+1. Run `kd /primer show`.
+2. Read this doctrine with `kd --sdlc` when the method is not already loaded.
+3. Read the project profile article if the primer pins one.
+4. Read the assigned issue, or create/select one before committing.
+5. Classify the cycle variant: standard, offline, no-HITL, no-ticket, or
+   cold-start.
+6. Plan the work in the project's chosen session record.
+7. Execute code, tests, and docs.
+8. Verify with the project's test, lint, type-check, and HITL expectations.
+9. Close out per publication tier and record the verification mode.
+10. Run the repo-doc audit when documentation changed.
+11. Commit with `PROJ-N:` prefix.
+12. Transition the ticket when upstream is reachable.
+
+## The three layers
+
+Every artifact belongs to exactly one layer.
+
+### Layer A - Upstream
+
+YouTrack is canonical for planning and durable knowledge.
+
+- Epic issues contain milestone-sized plans.
+- Child issues contain session-sized execution work.
+- Articles contain durable knowledge: designs, accepted proposals, how-tos,
+  indexes, daybooks, and migration playbooks.
+- Tags and saved queries make that knowledge discoverable.
+
+If a document does not need to be in the repository for code review, build,
+packaging, or session bootstrapping, it normally belongs upstream as an
+article.
+
+### Layer B - Thin repo
+
+The repository is committed, reviewed, and built. A non-code file belongs here
+only when it satisfies one of the mechanical categories in the next section.
+
+Layer B exists because some files must travel with the code: harness rules,
+packaged resources, release machinery, and the few knowledge files whose
+source must be reviewed in the same pull request as the code they govern.
+
+### Layer C - Workspace-local
+
+`.kd/` is local context and never committed.
+
+- `.kd/primer.yaml` is curated by the operator.
+- `.kd/cache/` is disposable upstream mirror content.
+
+Deleting cache loses no authority because upstream can rehydrate it. Deleting
+the primer loses local orientation, not upstream truth.
+
+## Where does this file go?
+
+Layer B membership is mechanical. Do not decide by asking whether a document
+"feels code-adjacent." Decide by category.
+
+| Category | Contents | Examples |
+|----------|----------|----------|
+| Harness-consumed | Loaded every session by humans or LLM harnesses. | `AGENTS.md`, `RULES.md`, coding-style files. |
+| Tool-packaged | Ships in the wheel or is read by the installed tool. | Embedded guides, packaged resources. |
+| Build-essential | Required for build, test, CI, release, or changelog flow. | `pyproject.toml`, CI config, `CHANGELOG.md`. |
+| Marker-bridged | Repo source with a `kd-meta` marker and an upstream article render. | ADRs or code-coupled specs that need PR review and upstream discoverability. |
+
+Decision flow:
+
+1. Loaded at session start by the harness or humans? Keep in Layer B.
+2. Shipped or read by the installed tool? Keep in Layer B.
+3. Needed for build, test, CI, release, or changelog flow? Keep in Layer B.
+4. Needs both PR review with code and upstream discoverability? Make it
+   marker-bridged.
+5. Otherwise publish it upstream as an article.
+
+**Repo documentation audit.** At closeout, every committed documentation file
+must still satisfy one Layer B category. If a document moved upstream, delete
+the repo copy unless it still has a named Layer B reason or a recorded
+compliance/audit exception.
+
+**Incubation exception.** A project may keep a repo-local proposal staging
+area for design drafts before acceptance. At acceptance, the proposal becomes
+an upstream article tagged as accepted, and the local draft is deleted. This is
+not a general place for durable docs.
+
+## What belongs upstream as an article?
+
+Use articles for durable knowledge that does not need repo review coupling:
+
+- Design records.
+- Specs not tied to a code review.
+- How-tos that do not require the source tree.
+- Branch or topic indexes, such as "Index: Proposals" or "Index: How-to".
+- Migration playbooks.
+- Daybooks.
+- Accepted proposals.
+
+Operational articles should be network-shaped, not just searchable prose.
+Minimum structure:
+
+- `kind:*` tag for artifact type.
+- `lifecycle:*` tag for state.
+- Owning project.
+- Backrefs to governing epics, issues, proposals, or code-coupled artifacts.
+
+### Proposal shape in YouTrack
+
+A proposal is knowledge, not an execution container.
+
+- During incubation, a draft may live in the repo's proposal staging area.
+- Once accepted, the canonical proposal is a YouTrack article.
+- Epics and session issues may link to the proposal when it governs the work.
+- The proposal does not replace the epic -> child-issue hierarchy.
+
+### Tag taxonomy pattern
+
+Adapt tags per project, but keep common namespaces stable:
+
+- `kind:*` for artifact type, such as `kind:proposal`, `kind:how-to`,
+  `kind:spec`, `kind:design`, `kind:adr`, `kind:sdlc`, `kind:index`,
+  `kind:daybook`, `kind:history`, `kind:digest`.
+- `lifecycle:*` for state, such as `lifecycle:draft`,
+  `lifecycle:accepted`, `lifecycle:deprecated`, `lifecycle:historical`.
+- `area:*`, `component:*`, and `module:*` for project structure.
+- Domain-specific namespaces when the project needs them.
+
+## How does planning start?
+
+The repeated session loop is only the mechanical part of the SDLC. Before that
+loop is useful, the project needs direction and executable structure.
+
+The planning shape is:
+
+```text
+ideation -> setup -> mechanical loop
+```
+
+### Ideation
+
+Ideation is where direction becomes durable knowledge. It may start as a
+vision, design sketch, proposal, migration playbook, incident lesson, or open
+question. In the kd-native shape, accepted durable thinking lives upstream as
+articles, tagged and cross-linked. Draft proposals may temporarily live in the
+repo's proposal staging area, but accepted knowledge moves upstream.
+
+The point of ideation is not to create a perfect plan. It is to make the
+reasoning discoverable enough that future epics and sessions inherit context
+instead of reconstructing it.
+
+### Setup
+
+Setup turns direction into executable tracker structure.
+
+Typical setup work:
+
+- Identify the governing article or create one.
+- Create one epic issue for a milestone-sized body of work.
+- Split the epic into child session issues.
+- Record required ordering on child issues or in the epic plan.
+- Add tags, saved queries, or index articles that make the work discoverable.
+- Pin high-signal references in the primer when they should be read at session
+  start.
+
+This is the planning session. It is where an operator converts "we should do
+this" into "here are the epics and session issues that make it executable."
+
+### Mechanical loop
+
+Once setup exists, normal sessions repeat the bounded execution cycle:
+
+```text
+read context -> plan session -> execute -> verify -> close out -> optionally release -> repeat
+```
+
+The old paper workflow maps to the kd-native shape like this:
+
+| Paper-era artifact | kd-native home |
+|--------------------|----------------|
+| Main design or vision document | Upstream design, proposal, vision, or playbook article. |
+| Master plan document | Usually an upstream planning/index article plus epic hierarchy; not mandatory as a fixed artifact. |
+| Milestone document | Epic issue, optionally backed by a governing article. |
+| Session slice inside a milestone | Child issue under the epic. |
+| Session plan and execution notes | Session issue plus local session record when the project still uses one. |
+| Session conclusion | Issue closeout comment; durable reference output becomes an article link. |
+
+The conclusion is simple: planning becomes graph-shaped upstream knowledge, but
+execution stays mechanical. Ideation creates the "why"; setup creates the
+tracker shape; sessions repeatedly move one slice through verification and
+publication.
+
+## How do I model milestone-sized work?
+
+Use native YouTrack hierarchy for execution. Do not flatten planning into a
+free-text custom field.
+
+- **Rationale** lives as an article: proposal, design note, or playbook.
+- **Epic issue** is the canonical container for one milestone-sized body of
+  work.
+- **Session issue** is a child of the epic and holds one execution slice with
+  its own closeout.
+- **Subtasks or checklists** break a session down further when useful.
+- **Custom fields** can support filtering, boards, and reports, but they do
+  not replace the epic -> child-issue structure.
+- **Ordering** is explicit on child issues or the epic plan when order matters.
+
+## How do I run a session?
+
+A session is one bounded pass through the loop:
+
+```text
+load context -> choose cycle variant -> plan -> execute -> verify -> publish -> commit/transition
+```
+
+Start with:
+
+1. `kd /primer show` to load workspace context.
+2. The portable doctrine, usually from `kd --sdlc`.
+3. The project profile article if the primer pins one.
+4. The assigned issue, usually with `kd /issue show PROJ-123 -o yaml`.
+
+Then classify the session. Four inputs decide the cycle variant.
+
+| Input | State(s) | Consequence |
+|-------|----------|-------------|
+| Tracker | Reachable / unreachable | Unreachable means offline cycle if cache is warm. |
+| Ticket | Exists / missing | Missing means create/select a ticket or use the umbrella only when allowed. |
+| HITL | N/A / executed / deferred | Deferred means name the reason; no automatic follow-up ticket. |
+| Cache | Warm / cold | Cold plus tracker unreachable means cold-start limits. |
+
+### Standard cycle
+
+Tracker is reachable, a real ticket exists, and HITL is either completed or
+not applicable. Work normally, verify normally, close out per publication
+tiers, and use commit subjects prefixed with `PROJ-N:`.
+
+### Offline cycle
+
+Tracker is unreachable but cache is warm. Work proceeds against cached context.
+Commits still use `PROJ-N:` prefixes. Reconciliation happens later with
+`kd /issue touched --git-range A..B`, issue closeout comments, transitions, and
+article pushes.
+
+### No-HITL cycle
+
+Use the verification vocabulary precisely:
+
+- **HITL not applicable.** The work has no upstream-facing behavior. Close out
+  normally and record `not_applicable` when a verification mode is needed.
+- **HITL deferred.** The work touches upstream behavior but a live check was
+  not run. Closeout names the limitation. Do not create a placeholder follow-up
+  automatically; a future session or real incident can create real work.
+
+### No-ticket cycle
+
+No commit lands without a ticket prefix.
+
+- **New-ticket path.** If exploration produces code or operator-visible docs
+  worth keeping, create or select a real ticket before committing.
+- **Umbrella path.** Use the fixed project umbrella only for hygiene that has
+  no story worth telling.
+
+### Cold-start cycle
+
+Fresh clone, no tracker, and no cache. Work is limited to repo-local reading,
+code review, and proposal drafting in the project's staging area for later
+publication.
+
+## How do I verify HITL?
+
+Use this closed vocabulary in closeouts and session records.
+
+| Mode | Meaning | Closeout consequence |
+|------|---------|----------------------|
+| `live_hitl` | Real upstream read and write verification completed. | Full closeout. |
+| `read_only_hitl` | Real upstream reads completed; writes not exercised. | Closeout names the limitation. |
+| `cached` | Verified against hydrated cache only. | Closeout notes upstream validation debt. |
+| `simulated` | Unit tests or fixtures only. | Defer closeout if behavior touches upstream. |
+| `not_applicable` | No upstream-facing behavior. | No HITL mention required. |
+
+## How do I close out a session?
+
+Publication is tiered. The goal is durable trace, not log migration.
+
+| Session kind | Upstream record |
+|--------------|-----------------|
+| Short session | Full closeout comment on the issue: changes, files, decisions, test results. |
+| Long session | Compact issue capsule plus article link for durable parts. |
+| Durable reference produced | Publish the artifact as an article and reference it from the issue. |
+| Ephemeral raw thinking | Do not publish raw. Summarize the outcome and discard the rest. |
+
+Test question: would a future reader of this issue benefit from the full
+session, or only from the outcome? Full session means publish the durable part.
+Outcome only means summarize.
+
+For sessions that change both code and operator-visible docs, the recommended
+commit shape is:
+
+1. Code and tests.
+2. Docs and session conclusion.
+
+Single-commit closeout is fine for docs-only, hygiene-only, or small sessions.
+The invariant is that every commit subject carries a `PROJ-N:` prefix.
+
+## What happens when the tracker is down?
+
+Tracker-down work is an offline cycle, not a separate state machine.
+
+Use cache only for reading:
+
+```bash
+kd /cache refresh --primer-scope
+kd /cache refresh --issue PROJ-123
+kd /cache refresh --article PROJ-A-1
+kd /cache status
+kd /cache search "phrase"
+```
+
+The cache never becomes a write buffer. Mutations still require a live tracker.
+
+When the tracker returns, reconcile from git:
+
+```bash
+kd /issue touched --git-range origin/main..HEAD -o yaml
+```
+
+Then, for each touched ticket:
+
+1. Push commits if needed.
+2. Post the closeout record required by the publication tier.
+3. Transition the issue.
+4. Push any article edits that were drafted locally.
+
+There is no local `pending-syncs.yaml`. Git history is the queue; commit
+prefixes are the index.
+
+## What's in `.kd/`?
+
+`.kd/` contains local context. Do not commit it.
+
+| Concept | Source of truth | Deletion loss | Where |
+|---------|-----------------|---------------|-------|
+| Primer | Operator-curated local context. | Loses workspace orientation. | `.kd/primer.yaml` |
+| Cache | Upstream. | None; rehydrate from tracker. | `.kd/cache/` |
+| Durable state | Not introduced by this doctrine. | Would need its own contract. | Not used today. |
+| Scratch | Operator or LLM transient work. | None by construction. | Use `/tmp` or untracked files. |
+
+### Cache contract
+
+`.kd/cache/` contains rehydratable upstream-mirror content: article bodies,
+issues, query results, tag/entity results, field schemas, and fetch metadata.
+
+Multi-connection workspaces materialize one scope per connection:
+
+```text
+.kd/cache/connections/<slug>/articles/
+.kd/cache/connections/<slug>/issues/
+.kd/cache/connections/<slug>/queries/
+```
+
+Each scope has `scope.yaml` with the immutable identity tuple
+`{kind, connection, provider, base_url, compat_tier, created_at}`. Refresh is
+idempotent on full identity match and refuses to write into a scope whose
+recorded identity diverges from the active connection.
+
+Cache rules:
+
+- **Explicit hydration.** Cache writes happen through `kd /cache refresh`.
+  Implicit read-through writes are out of scope.
+- **Disposable.** Deletion is safe; upstream is authoritative.
+- **Staleness is visible.** Cached entries carry fetched and upstream updated
+  timestamps where available.
+- **Read-side only.** No sync queue, no write buffer, no mutation from stale
+  context.
+
+`kd /cache clear` is local-only and defaults to the active scope. `--all`
+clears every scope. `kd /cache status` is also local-only and reports counts,
+fetch age, stale counts, and warnings for parse failures.
+
+Cached artifacts are marked as disposable mirrors. Markdown article bodies use
+a comment banner:
+
+```text
+<!-- kd-cache: upstream=PROJ-A-1 fetched=2026-04-21T10:12:00Z.
+     Disposable mirror. Edits lost on refresh. Not authoritative. -->
+```
+
+YAML payloads use `#` comments:
+
+```text
+# kd-cache: upstream=PROJ-105 fetched=2026-04-21T10:12:00Z.
+# Disposable mirror. Edits lost on refresh. Not authoritative.
+```
+
+The banner is informational. It is not a `kd-meta` marker.
+
+### Three operations that look alike
+
+These operations all copy text near the repository, but they have different
+ownership rules.
+
+| Operation | Destination | Ownership | Mutability |
+|-----------|-------------|-----------|------------|
+| Cache hydrate | `.kd/cache/` | kd-managed | Refresh overwrites; operator never edits. |
+| Article pull as claim | Repo file chosen by operator | Operator | One-shot transfer; operator authors thereafter. |
+| Marker-bridged pull | Repo file with `kd-meta` | Operator | Repo source can push back through the marker. |
+
+Only marker-bridged files are part of the ongoing repo-to-upstream publication
+loop.
+
+### Write-gating
+
+Commands that mutate upstream require a live tracker. They refuse to operate
+on cache-only context. This includes creating or updating issues, pushing
+articles, changing tags, assigning work, commenting, linking, deleting, and
+transitioning state.
+
+No stale cache read can silently become a destructive upstream write.
+
+## Marker-bridged files
+
+Most durable knowledge belongs directly upstream as articles. Marker-bridged
+files are the exception for knowledge that must be reviewed in git and also be
+discoverable upstream.
+
+A marker-bridged file is one artifact in two forms:
+
+- The repo file is authoritative and reviewed in pull requests.
+- The upstream article is a rendered, linkable view.
+
+`kd /article push` publishes from the repo file to the upstream article.
+Nothing flows back automatically. If the upstream article changed and the repo
+source needs those edits, the operator runs `kd /article pull`, diffs, and
+merges by hand.
+
+The `kd-meta` marker is identity, not tool state:
+
+```html
+<!-- kd-meta
+slug: docs/architecture/example
+upstream-id: 2-123
+-->
+```
+
+Rules:
+
+- Push writes the marker on first creation or when resolving a missing/stale
+  upstream ID.
+- Commit that one-time marker insertion with the content.
+- Subsequent pushes leave the local file unchanged.
+- Older markers may contain an `upstream-updated` field; kd still reads it for
+  compatibility, but new pushes and pulls do not emit it.
+- Every update push performs a live upstream read for conflict detection.
+- Baseline priority is `cache > legacy_marker > none`.
+- If both upstream and repo changed, pull, diff, merge by hand, then push.
+- `--force` is only for an inspected overwrite.
+
+## What's project-specific?
+
+The portable doctrine defines the invariant method:
+
+- Layer model.
+- Session cycle variants.
+- Verification modes.
+- Publication tiers.
+- Repo-doc audit.
+- Cache semantics.
+- Marker-bridged behavior.
+- Reconciliation flow.
+- Umbrella rule.
+
+Project-specific agreements belong in an SDLC profile: a project-local upstream
+article pinned from `.kd/primer.yaml`. Examples:
+
+- Document naming.
+- Required metadata fields.
+- Routing tables.
+- Closeout checklists.
+- Timeless-doc rules.
+- Project-specific publication-tier variations.
+
+Session-start load sequence becomes:
+
+```text
+primer -> portable doctrine -> project profile -> assigned issue
+```
+
+A project may operate without a profile when it follows the portable doctrine
+verbatim.
+
+## When do I use the umbrella ticket?
+
+Each project declares one fixed umbrella ticket in its primer or profile. The
+umbrella exists only to preserve the "no commit without a ticket" rule for work
+that genuinely has no story.
+
+Use umbrella for:
+
+- Formatting, lint, or whitespace sweeps.
+- Typo and comment fixes.
+- Dependency bumps with no behavior change.
+- Internal hygiene with no narrative.
+
+Do not use umbrella for:
+
+- Behavior changes.
+- Work that merits a changelog entry.
+- API, test, or documentation-contract changes.
+- Anything a future reader would expect to find under its own issue.
+
+Test question: does this commit have a story worth telling? If yes, use a real
+ticket. If no, umbrella is acceptable.
+
+## Migration safety rules
+
+When moving repo-local operational docs upstream, keep the migration thin and
+auditable:
+
+- Create tag taxonomy and root/index articles first.
+- Migrate in small slices: read, classify, push, read back, verify tags, delete
+  local shadow, commit.
+- Do not delete a local document before upstream readback confirms the article
+  exists, is readable, and carries intended tags/backrefs.
+- The primer points to the migration plan; it does not track session progress.
+- Do not leave duplicate repo copies unless they satisfy a Layer B category or
+  a named compliance/audit exception.
+
+## Accepted tradeoffs
+
+- Article history lives in YouTrack page history. There is no git-style
+  line-level diff or git blame for ordinary upstream articles.
+- Marker-bridged files preserve repo review for the narrow class of knowledge
+  that needs it, at the cost of a manual push step.
+- Cache is read-side only. kd does not run a sync daemon and does not buffer
+  upstream mutations while offline.
+- Publication is summarized by value, not by volume. Durable outcomes are kept;
+  raw session thinking is not automatically migrated.
+
+Updated: 2026-04-27

{kd_cli-2.6.0 → kd_cli-2.6.1/kd_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: kd-cli
-Version: 2.6.0
+Version: 2.6.1
 Summary: Knowledge Dispatcher for issue trackers and knowledge bases
 Author: Sergiy Gladkyy
 License-Expression: MIT

{kd_cli-2.6.0 → kd_cli-2.6.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "kd-cli"
-version = "2.6.0"
+version = "2.6.1"
 description = "Knowledge Dispatcher for issue trackers and knowledge bases"
 readme = "README.md"
 requires-python = ">=3.11"