panache-cli 2.39.0__tar.gz

panache_cli-2.39.0/.claude/rules/config.md

@@ -0,0 +1,22 @@
+---
+paths:
+  - "src/config.rs"
+  - "docs/guide/configuration.qmd"
+---
+
+Configuration changes should preserve predictable defaults, compatibility, and
+clear migration paths.
+
+- Preserve config discovery precedence and failure behavior for explicit
+  `--config` paths.
+- Keep flavor/extension merging deterministic: start from flavor defaults, then
+  apply user overrides.
+- Maintain backward compatibility for deprecated keys/sections where currently
+  supported; keep warnings explicit and actionable.
+- Use canonical kebab-case keys while preserving documented aliases. Existing
+  aliases to snake_case are only there for backwards compatibility and should
+  not be used in new code.
+- Update `docs/guide/configuration.qmd` whenever defaults, keys, or deprecation
+  behavior changes.
+- Add focused tests in `src/config.rs` for parsing, precedence, merge behavior,
+  and deprecation handling when config behavior changes.

panache_cli-2.39.0/.claude/rules/formatter.md

@@ -0,0 +1,25 @@
+---
+paths:
+  - "src/formatter.rs"
+  - "crates/panache-formatter/**/*.rs"
+  - "tests/fixtures/cases/**/expected.md"
+  - "tests/format/**/*.rs"
+---
+
+Formatter changes should preserve idempotency and avoid parser-side workarounds.
+
+- Keep formatting deterministic: `format(format(x)) == format(x)`.
+- Reuse existing wrapping/inline/list/table helpers instead of duplicating
+  rendering logic.
+- Keep formatter-core logic in `crates/panache-formatter`; keep host-specific
+  process/runtime integrations in top-level `src/formatter.rs` and related host
+  modules.
+- Keep `crates/panache-formatter` dependency-lean (parser-style): avoid pulling
+  config file parsing or LSP-only dependencies/features into the formatter core.
+- If behavior changes, add or update the smallest relevant golden case in
+  `tests/fixtures/cases/`.
+- Keep docs aligned with formatter behavior: update `docs/guide/formatting.qmd`
+  when user-visible formatting rules or examples change.
+- Avoid touching unrelated golden cases; verify diffs are intentional.
+- Prefer targeted tests (`cargo test --test golden_cases <case_name>`) before
+  full suite reruns.

panache_cli-2.39.0/.claude/rules/integration-tests.md

@@ -0,0 +1,23 @@
+---
+paths:
+  - "tests/**/*.rs"
+  - "tests/fixtures/cases/**"
+---
+
+Integration tests should reflect user-visible behavior and minimize brittleness.
+
+- Prefer focused assertions tied to one behavior change.
+- Use fixtures under existing test directories rather than creating ad-hoc
+  layouts.
+- For new formatter golden scenarios (user-visible formatted output), add a new
+  case directory under `tests/fixtures/cases/` and wire it into
+  `tests/golden_cases.rs`.
+- For parser-only golden scenarios (CST/losslessness/parser behavior), add a new
+  case directory under `crates/panache-parser/tests/fixtures/cases/` and wire it
+  into `crates/panache-parser/tests/golden_parser_cases.rs`.
+- Update expected outputs only when behavior intentionally changed and after
+  manual diff review.
+- For CLI diagnostics, prefer focused substring/order assertions over asserting
+  entire rendered blocks (to reduce brittleness across renderer/layout tweaks).
+- Keep tests deterministic (no timing or environment-sensitive assumptions
+  unless already established by the suite).

panache_cli-2.39.0/.claude/rules/linter.md

@@ -0,0 +1,27 @@
+---
+paths:
+  - "src/linter/**/*.rs"
+  - "src/linter.rs"
+  - "src/diagnostic_renderer.rs"
+  - "tests/linting.rs"
+  - "tests/cli/lint.rs"
+  - "docs/guide/linting.qmd"
+---
+
+Linter changes should prioritize diagnostic correctness, actionable fixes, and
+stable CLI/LSP behavior.
+
+- Keep diagnostics precise: correct rule code, severity, and source range.
+- Prefer adding or extending fix edits only when the replacement is reliable and
+  preserves document intent.
+- Maintain rustc-like diagnostic UX in CLI output (clear primary span, optional
+  context, and concise help/note text).
+- Keep lint docs in sync: update `docs/guide/linting.qmd` whenever lint rules,
+  diagnostics, fix behavior, or CLI lint message format changes.
+- Preserve LSP compatibility: CLI rendering changes must not alter
+  `src/lsp/conversions.rs` behavior unless explicitly intended.
+- Reuse shared orchestration paths (including Salsa-backed lint/diagnostic
+  flows) between CLI and LSP where possible; avoid duplicating rule execution or
+  diagnostic-mapping logic in parallel code paths.
+- Add focused tests in `tests/linting.rs` and/or `tests/cli/lint.rs` for any
+  user-visible lint behavior changes before full suite reruns.

panache_cli-2.39.0/.claude/rules/lsp.md

@@ -0,0 +1,24 @@
+---
+paths:
+  - "src/lsp/**/*.rs"
+  - "src/lsp.rs"
+  - "tests/lsp/**/*.rs"
+  - "tests/lsp.rs"
+---
+
+LSP changes must prioritize protocol correctness and stable document state
+transitions.
+
+- Preserve request/notification behavior across open/change/save/close flows.
+- Ensure UTF-16/UTF-8 position and range conversions remain correct.
+- Prefer typed syntax wrappers for feature logic (symbols, diagnostics,
+  definitions, etc.).
+- Reuse shared conversion/state helpers (Salsa/document maps/range conversion)
+  rather than re-implementing protocol mapping logic.
+- Keep state updates explicit; avoid silent failure paths that hide
+  diagnostics/actions.
+- If lint/diagnostic payloads change, explicitly verify expected LSP diagnostic
+  fields remain stable unless the protocol output change is intentional.
+- Validate with targeted LSP integration tests before running the full suite.
+- Keep the docs at `docs/guide/lsp.qmd` aligned with any user-visible behavior
+  changes (e.g. new features, diagnostics, or client capabilities).

panache_cli-2.39.0/.claude/rules/parser.md

@@ -0,0 +1,29 @@
+---
+paths:
+  - "crates/panache-parser/src/parser/**/*.rs"
+  - "crates/panache-parser/src/parser.rs"
+  - "crates/panache-parser/src/syntax/**/*.rs"
+  - "crates/panache-parser/src/syntax.rs"
+  - "src/parser.rs"
+  - "src/syntax.rs"
+---
+
+Parser and syntax changes must preserve lossless CST behavior.
+
+- Treat Pandoc as the behavioral reference for ambiguous Markdown/Quarto syntax.
+- Preserve all structural markers and whitespace in CST nodes/tokens.
+- Do not move formatter policy into parser code.
+- Keep parser single-pass assumptions intact (block parsing with inline emission
+  during parse).
+- Prefer existing block dispatcher and inline parser utilities over introducing
+  parallel parsing paths.
+- Keep parser behavior independent of formatter/linter policy; parser should
+  remain lossless syntax capture only.
+- For bug fixes and new parsing behavior, add a focused test first (unit or
+  golden case).
+- Parser golden fixtures live under
+  `crates/panache-parser/tests/fixtures/cases/`; keep parser-specific coverage
+  there.
+- If parser CST snapshots change
+  (`crates/panache-parser/tests/snapshots/parser_cst_*.snap`), validate each
+  case intentionally.

panache_cli-2.39.0/.claude/rules/vscode-extension.md

@@ -0,0 +1,19 @@
+---
+paths:
+  - "editors/code/**/*.ts"
+  - "editors/code/package.json"
+  - "editors/code/README.md"
+---
+
+VS Code extension changes should preserve reliable LSP startup and predictable
+user configuration behavior.
+
+- Keep extension settings in sync across implementation, `package.json`
+  contributes schema, and `editors/code/README.md` documentation.
+- Preserve activation behavior for supported languages/workspaces and avoid
+  regressing startup reliability.
+- Prefer reusing existing process/download/config helpers over duplicating
+  command resolution or install logic.
+- When changing server launch behavior, ensure `panache lsp` invocation and
+  argument/environment wiring remain explicit and testable.
+- Validate extension changes with `npm run compile` in `editors/code/`.

panache_cli-2.39.0/.claude/rules/yaml-parser.md

@@ -0,0 +1,21 @@
+---
+paths:
+  - "crates/panache-parser/src/parser/yaml.rs"
+  - "crates/panache-parser/src/parser/yaml/**/*.rs"
+  - "crates/panache-parser/src/parser/**/*.rs"
+  - "crates/panache-parser/src/syntax/**/*.rs"
+  - "crates/panache-parser/tests/**/*yaml*"
+---
+
+YAML parser work is incremental and parser-crate scoped.
+
+- Keep YAML parsing lossless and CST-first (markers, whitespace, comments,
+  scalar trivia).
+- Prefer explicit, indentation-aware lexer + parser design; avoid parser styles
+  that hide indentation/recovery state.
+- Support both plain YAML and hashpipe-prefixed YAML through one core model.
+- Keep host↔embedded range mapping explicit and deterministic.
+- Introduce new behavior in shadow/parity mode before replacing existing YAML
+  pipeline paths.
+- Keep parser policy separate from formatter policy.
+- Add focused, deterministic tests for new YAML behavior and mapping rules.

panache_cli-2.39.0/.claude/rules/yaml-tests.md

@@ -0,0 +1,22 @@
+---
+paths:
+  - "crates/panache-parser/tests/yaml.rs"
+  - "crates/panache-parser/tests/yaml/**/*.txt"
+  - "crates/panache-parser/tests/fixtures/yaml-test-suite/**"
+---
+
+YAML test-suite harness changes must stay fixture-driven and parity-oriented.
+
+- Treat each yaml-test-suite case directory as the source of truth.
+- Use `test.event` as the expected parse-event contract for successful parse
+  behavior; use `error` as an expected-failure contract.
+- Never move a case into `crates/panache-parser/tests/yaml/allowlist.txt`
+  without checking both `test.event` and `error`.
+- If an `error` file exists for a case, do not allowlist it unless tests
+  explicitly model the expected error behavior.
+- Keep `allowlist.txt` intentionally small; add one case at a time with focused
+  rationale.
+- Keep `blocked.txt` reasons specific and actionable so future work can target
+  concrete parser gaps.
+- Prefer structured snapshots for CST/parity data (e.g. JSON snapshot of
+  `cst_to_json`) over ad-hoc freeform text.

panache_cli-2.39.0/.claude/skills/smoke-test-triage/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: smoke-test-triage
+description: Triage and fix panache smoke-test regressions (idempotency,
+  losslessness, parse/format checks) from CI debug-format reports and linked
+  issues.
+---
+
+Use this skill when asked to investigate failures reported by smoke-test scans
+or `debug format` CI issues (especially idempotency/losslessness regressions).
+
+## Goals
+
+1. Reproduce the exact failure from the report.
+2. Minimize to a stable local fixture.
+3. Add regression coverage in the right test surface.
+4. Fix root cause (not symptom).
+5. Validate targeted cases, then full repository checks.
+
+## Triage workflow
+
+1. Read the issue/report details first:
+   - failing check type (`idempotency`, `losslessness`, parse, etc.)
+   - sample file path
+   - upstream repo + commit SHA
+   - panache commit/version used by scan
+   - diff excerpt and approximate line
+
+2. Reproduce in a local clone of the target repository:
+   - checkout the exact target commit from the report
+   - run:
+     - `panache debug format --checks all --report <sample-file>`
+   - if needed, collect pass artifacts with:
+     - `panache debug format --checks all --dump-dir <dir> --dump-passes <file>`
+
+3. Minimize:
+   - reduce to smallest snippet that still reproduces
+   - keep source syntax realistic (especially chunk/hashpipe/YAML edge cases)
+   - confirm reproduction is deterministic across repeated runs
+
+4. Classify the failure before fixing:
+   - First determine whether this is primarily a parser issue or formatter
+     issue.
+   - Quick heuristic:
+     - parser issue: losslessness mismatch, CST/marker/trivia dropped, parse
+       shape changes, syntax not captured correctly.
+     - formatter issue: idempotency drift, wrapping/whitespace churn,
+       hashpipe/YAML reflow instability, output normalization changing across
+       passes.
+   - Use debug artifacts (`--dump-passes`) to compare:
+     - input vs parsed output (parser/losslessness boundary)
+     - first format vs second format (formatter/idempotency boundary)
+   - If uncertain, state the best hypothesis and why before implementing.
+
+5. Add regression fixture(s):
+   - Formatter user-visible cases:
+     - `tests/fixtures/cases/<case-name>/input.{md,qmd,Rmd}`
+     - `tests/fixtures/cases/<case-name>/expected.{md,qmd,Rmd}`
+     - add case name to `tests/golden_cases.rs`
+   - Parser-only behavior:
+     - add parser golden case under
+       `crates/panache-parser/tests/fixtures/cases/<case-name>/`
+     - wire in parser golden runner
+
+6. Fix implementation at root cause:
+   - parser lossless/CST bugs -> parser crate
+   - formatting/idempotency bugs -> formatter crate
+   - avoid papering over by changing expected outputs only
+   - preserve existing behavior for unrelated fixtures
+
+7. Validate:
+   - targeted first:
+     - `cargo test --test golden_cases <case-name>`
+     - `panache debug format --checks all --report <fixture-input>`
+   - then full validation:
+     - `cargo check --workspace`
+     - `cargo test --workspace`
+     - `cargo clippy --workspace --all-targets --all-features -- -D warnings`
+     - `cargo fmt -- --check`
+
+## Panache-specific guidance
+
+- For `.qmd` smoke regressions, ensure tests run with correct flavor context
+  (Quarto detection matters for hashpipe/chunk behavior).
+- Prefer adding one focused regression fixture per bug.
+- Do not update unrelated golden fixtures.
+- Be careful with trailing whitespace and wrapping in hashpipe/YAML paths: these
+  are common idempotency triggers.
+- Use Pandoc behavior as reference for ambiguous syntax.
+
+## Report-back format
+
+When done, report:
+
+1. Whether the issue reproduced (and exact command).
+2. Minimal reproducer summary.
+3. Fixture(s) added/updated.
+4. Root cause and code path changed.
+5. Validation commands run and outcomes.

panache_cli-2.39.0/.claude/skills/yaml-shadow-expand/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: yaml-shadow-expand
+description: Incrementally expand the Panache YAML shadow parser by triaging
+  yaml-test-suite fixtures one (or a few) at a time and allowlisting cases as
+  parser/projection support grows.
+---
+
+Use this skill when asked to extend YAML shadow parser coverage, add a new
+yaml-test-suite case to the allowlist, or pick "the next best case" to work on.
+
+## Scope boundaries
+
+- Target is the incremental shadow YAML parser in
+  `crates/panache-parser/src/parser/yaml/` and the event-parity harness in
+  `crates/panache-parser/tests/yaml.rs`.
+- This is a **long-horizon effort**. Do not frame it as a near-term replacement
+  for the existing `yaml_parser` dependency.
+- Stay parser-crate scoped. Do not leak YAML parser changes into the formatter
+  or CLI.
+- Keep CST lossless (markers, whitespace, comments, scalar trivia preserved).
+
+## Key files
+
+- `crates/panache-parser/src/parser/yaml/lexer.rs` — indentation-aware lexer,
+  block/flow token emission, block-scalar handling.
+- `crates/panache-parser/src/parser/yaml/parser.rs` — rowan CST builder, block
+  map/sequence and flow collection parsing, diagnostics.
+- `crates/panache-parser/src/parser/yaml/model.rs` — token enum, diagnostic
+  codes, shadow report shape.
+- `crates/panache-parser/tests/yaml.rs` — fixture-driven tests, including:
+  - `yaml_allowlist_cases_snapshot` — diagnostic/tree snapshot per case
+  - `yaml_allowlist_cases_cst_snapshot` — full CST snapshot per case
+  - `yaml_allowlist_losslessness_raw_input` — byte-exact round-trip
+  - `yaml_allowlist_projected_event_parity` — event stream vs
+    fixture `test.event`
+  - `yaml_suite_generate_triage_report` (ignored) — regenerates
+    `tests/yaml/triage.json` bucketing every fixture
+- `crates/panache-parser/tests/yaml/allowlist.txt` — small, intentionally curated
+  list of case IDs. One case per addition, with a short `#` comment explaining
+  what the case exercises.
+- `crates/panache-parser/tests/yaml/triage.json` — derived; do not hand-edit.
+- `crates/panache-parser/tests/fixtures/yaml-test-suite/` — vendored fixtures,
+  refreshed via `scripts/update-yaml-test-suite-fixtures.sh`.
+
+## Triage buckets
+
+`triage.json` splits every fixture into four buckets. Understand which bucket a
+case is in before touching it:
+
+- `passes_now` — tree parses AND projected events match `test.event`. Safe to
+  allowlist if not already listed.
+- `error_contract_ok` — case has an `error` file and we correctly reject it
+  with at least one diagnostic. Do not allowlist unless the test harness
+  explicitly models the expected error contract.
+- `fails_needs_error_path` — case has an `error` file but we currently parse
+  it successfully (no diagnostic). Needs parser work to detect the error.
+- `fails_needs_feature` — no `error` file. Two sub-patterns:
+  - `tree: true, event_parity: false` — parses OK, projection fails. Usually
+    low-effort: fix `cst_yaml_projected_events` / helpers in `tests/yaml.rs`.
+  - `tree: false` — parser rejects. Usually needs lexer/parser work.
+
+## Workflow
+
+1. **Regenerate triage** if stale:
+   ```
+   cargo test -p panache-parser --test yaml yaml_suite_generate_triage_report -- --ignored
+   ```
+   Then inspect counts:
+   ```
+   grep -E '"passes_now_count"|"fails_needs_feature_count"|"error_contract_ok_count"|"fails_needs_error_path_count"' \
+     crates/panache-parser/tests/yaml/triage.json
+   ```
+
+2. **Pick a case** — prefer highest-leverage, lowest-risk:
+   - Start with `fails_needs_feature` entries where `tree: true` — these only
+     need projection fixes.
+   - Skim `in.yaml` and `test.event` for a few candidates. Group cases that
+     share a root cause so one fix unlocks several.
+   - Do not allowlist a case that has an `error` file without modeling the
+     error contract explicitly.
+
+3. **Probe the gap** if not obvious. A throwaway `#[ignore]` test in
+   `tests/yaml.rs` printing `parse_yaml_tree(input)` and
+   `cst_yaml_projected_events(input)` is cheap and informative. Remove the
+   probe before finishing.
+
+4. **Classify the fix** before coding:
+   - Projection-only → edit `tests/yaml.rs` helpers
+     (`project_block_map_entries`, `project_block_sequence_items`,
+     `project_flow_map_entries`, `cst_yaml_projected_events`).
+   - Parser-shape issue → edit `parser.rs` emitters
+     (`emit_block_map`, `emit_block_seq`, `emit_flow_map`, etc.).
+   - Lexer gap → edit `lexer.rs`; consider indent/flow/block-scalar state
+     interactions.
+   - Diagnostic gap → add a code in `model.rs::diagnostic_codes` and surface
+     it at the right point.
+
+5. **Apply the smallest focused change.** Keep changes parser-crate scoped,
+   CST-lossless, and don't regress already-allowlisted cases.
+
+6. **Add the case(s) to `allowlist.txt`** with a one-line `#` comment capturing
+   the pattern (not the case ID — the shape, e.g. "Block map with inline
+   flow-map values"). One commit/session can add several if they share a root
+   cause, but annotate each.
+
+7. **Run the parity tests**:
+   ```
+   cargo test -p panache-parser --test yaml
+   ```
+   Expect snapshot tests to fail the first time with `.snap.new` files. Review
+   each new snapshot before accepting:
+   - `tests/snapshots/yaml__yaml_suite_<ID>.snap.new` — summary
+   - `tests/snapshots/yaml__yaml_cst_suite_<ID>.snap.new` — CST tree
+   Accept by renaming (`mv ...snap.new ...snap`) only after confirming the CST
+   shape matches the fixture semantics. Note: `insta` stops on the first
+   snapshot failure, so you may need to iterate (accept, re-run, accept…).
+
+8. **Check for unlocked cases.** A single projection or parser fix can flip
+   several cases to passing. After regenerating triage, diff `passes_now` vs
+   the allowlist and allowlist the cleanly-unlocked ones with their own
+   rationale comments.
+
+9. **Validate**:
+   - `cargo test -p panache-parser --test yaml`
+   - `cargo clippy -p panache-parser --all-targets -- -D warnings`
+   - `cargo fmt -p panache-parser -- --check`
+   - Regenerate `triage.json` a final time so it reflects the new state.
+
+## Dos and don'ts
+
+- **Do** keep `allowlist.txt` intentionally small. One case per addition, with
+  an explanatory comment.
+- **Do** prefer fixing the underlying projection/parser gap over papering over
+  a single case — shared-root fixes are the main source of leverage.
+- **Do** verify losslessness visually in the CST snapshot (byte ranges
+  contiguous, all trivia captured).
+- **Don't** allowlist error-contract cases without explicit error-path
+  coverage.
+- **Don't** hand-edit `triage.json` — it is derived output.
+- **Don't** drift into formatter territory. Parser/CST only.
+- **Don't** introduce parser styles that hide indentation or recovery state.
+  The lexer is explicitly indentation-aware by design.
+
+## Report-back format
+
+When done, report:
+
+1. Triage counts before and after (`passes_now`, `fails_needs_feature`,
+   `error_contract_ok`, `fails_needs_error_path`).
+2. Cases allowlisted this session and the shared pattern behind them.
+3. Files changed and the root cause addressed.
+4. Any cases unlocked but not yet allowlisted (candidates for follow-up).
+5. Suggested next targets grouped by shared root cause.

panache_cli-2.39.0/.envrc

@@ -0,0 +1,11 @@
+export DIRENV_WARN_TIMEOUT=20s
+
+eval "$(devenv direnvrc)"
+
+# `use devenv` supports the same options as the `devenv shell` command.
+#
+# To silence the output, use `--quiet`.
+#
+# Example usage: use devenv --quiet --impure --option services.postgres.enable:bool true
+use devenv
+use vim

panache_cli-2.39.0/.gitattributes

@@ -0,0 +1,27 @@
+# Let Git auto-detect text files
+* text=auto
+
+# All test case input/expected files should use LF by default (for consistent AST across platforms)
+tests/fixtures/cases/*/*.md eol=lf
+tests/fixtures/cases/*/*.qmd eol=lf
+tests/fixtures/cases/*/*.Rmd eol=lf
+crates/panache-parser/tests/fixtures/cases/*/*.md eol=lf
+crates/panache-parser/tests/fixtures/cases/*/*.qmd eol=lf
+crates/panache-parser/tests/fixtures/cases/*/*.Rmd eol=lf
+tests/fixtures/bibtex_samples/*.bib eol=lf
+crates/panache-parser/tests/fixtures/yaml-test-suite/**/in.yaml eol=lf
+
+# Preserve CRLF in test cases that specifically test CRLF handling (must have CRLF line endings)
+tests/fixtures/cases/crlf_*/* -text
+tests/fixtures/cases/line_ending_crlf/* -text
+tests/fixtures/cases/line_ending_lf/* -text
+crates/panache-parser/tests/fixtures/cases/crlf_*/* -text
+crates/panache-parser/tests/fixtures/cases/line_ending_crlf/* -text
+crates/panache-parser/tests/fixtures/cases/line_ending_lf/* -text
+tests/fixtures/bibtex_samples/bibtex_crlf.bib -text
+
+# CST fixtures (parser-internal) should use LF endings
+tests/fixtures/bibtex_samples/*.cst eol=lf
+
+# Other test cases can use LF (the default for most projects)
+# Individual test cases can override if needed

panache_cli-2.39.0/.github/FUNDING.yml

@@ -0,0 +1 @@
+github: jolars

panache_cli-2.39.0/.github/ISSUE_TEMPLATE/blank.yml

@@ -0,0 +1,17 @@
+name: Blank Issue
+description: Create an issue for discussions, questions, or topics that don't fit other templates
+title: ""
+labels: []
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this template for general questions, discussions, or issues that don't fit the bug report or feature request templates.
+
+  - type: textarea
+    id: content
+    attributes:
+      label: Description
+      description: Describe your question, discussion topic, or issue
+    validations:
+      required: true

panache_cli-2.39.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,100 @@
+name: Bug Report
+description: Report a bug in panache (formatter, linter, LSP, or parser)
+title: "[Bug]: "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug! Please provide as much detail as possible to help us reproduce and fix the issue.
+
+  - type: dropdown
+    id: component
+    attributes:
+      label: Component
+      description: Which component is affected?
+      options:
+        - Formatter
+        - Linter
+        - LSP (Language Server)
+        - CLI
+        - Other
+    validations:
+      required: true
+
+  - type: input
+    id: version
+    attributes:
+      label: Panache Version
+      description: "Run `panache --version` to get the version"
+      placeholder: "e.g., 2.7.0"
+    validations:
+      required: true
+
+  - type: input
+    id: os
+    attributes:
+      label: Operating System
+      description: What operating system are you using?
+      placeholder: "e.g., Ubuntu 24.04, macOS 14.2, Windows 11"
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: A clear and concise description of the bug
+      placeholder: Tell us what happened
+    validations:
+      required: true
+
+  - type: textarea
+    id: input
+    attributes:
+      label: Input Document
+      description: Provide a minimal example that reproduces the issue
+      placeholder: |
+        # Example heading
+
+        This is a paragraph with **bold** text.
+      render: markdown
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected Output
+      description: What output did you expect?
+      placeholder: Describe or paste the expected output
+      render: markdown
+    validations:
+      required: true
+
+  - type: textarea
+    id: actual
+    attributes:
+      label: Actual Output
+      description: What output did you actually get?
+      placeholder: Describe or paste the actual output
+      render: markdown
+    validations:
+      required: true
+
+  - type: textarea
+    id: config
+    attributes:
+      label: Configuration
+      description: If relevant, provide your `.panache.toml` or `panache.toml` configuration
+      placeholder: |
+        flavor = "Quarto"
+        line-width = 80
+        wrap = "Reflow"
+      render: toml
+
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: Add any other context about the problem here (error messages, screenshots, etc.)

panache_cli-2.39.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: true
+contact_links:
+  - name: 📖 Documentation
+    url: https://jolars.github.io/panache
+    about: Read the panache documentation
+  - name: 💬 Discussions
+    url: https://github.com/jolars/panache/discussions
+    about: Ask questions and discuss ideas with the community
+  - name: 🔍 Search Existing Issues
+    url: https://github.com/jolars/panache/issues
+    about: Check if your issue has already been reported