nncg 0.2.0__tar.gz

nncg-0.2.0/.bandit

@@ -0,0 +1,2 @@
+[bandit]
+skips = B101

nncg-0.2.0/.claude/commands/rhiza_book.md

@@ -0,0 +1,53 @@
+---
+description: Build the documentation book into a local _book folder and open it in the default browser
+allowed-tools: Bash, Read
+---
+
+Build the MkDocs/zensical documentation book locally and open it in the user's
+standard web browser. Follow the command-execution policy: always prefer
+`make <target>`; never invoke `.venv/bin/...` directly.
+
+This command depends on the **book** bundle (it expects a root `mkdocs.yml` and a
+`make book` target from `.rhiza/make.d/book.mk`). If `mkdocs.yml` is missing,
+stop and tell the user the `book` bundle is not set up here rather than guessing.
+
+Do the following, in order:
+
+1. **Build the book.** Run `make book`. This regenerates the `_book/` output
+   folder via zensical (it also runs the `_book-reports` / `_book-notebooks`
+   prerequisites). Run it in the foreground so build errors are visible. If it
+   fails, show the relevant output, diagnose the root cause, and stop — do not
+   try to open a stale or partial book.
+
+2. **Confirm the output.** Verify `_book/index.html` exists after the build. If
+   it does not, report what `make book` produced instead and stop.
+
+3. **Serve it locally (background).** Static zensical sites need to be served
+   over HTTP — search and navigation break under `file://`. Start a local server
+   for the built folder **in the background** so it does not block the session:
+
+   ```
+   (cd _book && uv run python -m http.server 8000)
+   ```
+
+   Use port 8000 by default (this matches `make serve`). If 8000 is already in
+   use, pick the next free port (8001, 8002, …) and use that URL throughout.
+   Do **not** use `make serve` here — it rebuilds the book a second time and
+   blocks the terminal; the book is already built from step 1.
+
+4. **Open the default browser.** Open the served URL with the platform's
+   standard opener:
+   - macOS: `open http://localhost:8000`
+   - Linux: `xdg-open http://localhost:8000`
+   - Windows: `start http://localhost:8000`
+
+   Detect the platform and use the right one.
+
+5. **Report.** Tell the user the book was built at `_book/`, the URL it is being
+   served at, and how to stop the background server (e.g. the background task /
+   PID, or "kill the `http.server` process on port 8000"). Note that `_book/` is
+   a generated, gitignored artifact.
+
+If `$ARGUMENTS` is non-empty, treat it as an override hint — e.g. a custom port
+(`/rhiza_book 9000`) or a request to only build without serving/opening (`/rhiza_book
+build-only`) — and adjust accordingly.

nncg-0.2.0/.claude/commands/rhiza_quality.md

@@ -0,0 +1,98 @@
+---
+description: Run the Rhiza code-quality gate and score the repo (lint, types, docs, deps, security, tests)
+---
+
+Assess the quality of this repo against Rhiza standards. Follow the
+command-execution policy: always prefer `make <target>`; never invoke
+`.venv/bin/...` directly. Run the gates in order — cheapest checks first so fast
+failures surface before the slow test suite — and collect results:
+
+1. `make fmt` — pre-commit hooks + linting (ruff format/check, markdownlint, bandit, actionlint, …)
+2. `make typecheck` — static type checking (`ty`, and `mypy --strict` if configured) over `src/`
+3. `make docs-coverage` — docstring coverage (interrogate) over `src/`
+4. `make deptry` — unused/missing/misplaced dependency analysis
+5. `make security` — pip-audit + bandit scans
+6. `make validate` — validate project structure against the Rhiza template (`.rhiza/template.yml`)
+7. `make test` — full test suite **with** its coverage gate (slowest, run last)
+
+Guidelines:
+
+- Run each gate as a single, bare `make <target>` command — one Bash call per
+  gate. Do **not** pipe (`| tee`, `| tail`), redirect (`2>&1 >`), chain
+  (`make fmt && make typecheck`), or prefix with `cd`. Bare `make <target>`
+  invocations match the allow-listed `Bash(make *)` rule and run without a
+  permission prompt; compound or piped commands do not and will prompt on every
+  gate. Read the full output directly from each call rather than capturing it to
+  a file.
+- Run all gates even after an early failure, so the full picture is visible
+  rather than stopping at the first red.
+- If something fails, show the relevant output, diagnose the root cause, and
+  propose (or apply, if clearly correct, low-risk, **and** the fix is in a
+  locally-owned file per the scoping rule below) a fix.
+- If `$ARGUMENTS` is non-empty, scope the assessment to that path or topic
+  instead of the whole repo.
+- End with a concise PASS/FAIL summary per gate.
+
+**Coverage expectation.** `make test` enforces a coverage gate
+(`COVERAGE_FAIL_UNDER`, default 90%; many projects raise it to 100%). Treat
+anything below the configured threshold on locally-owned `src/` as a gap to
+flag, not an acceptable baseline. When scoring the test-coverage subcategory,
+the configured threshold is the bar for a 10; report uncovered lines
+(`file:line`) and the test that would close each.
+
+**`make validate`.** A failure means this repo has drifted from the Rhiza
+template (a synced file edited locally, or a missing/extra file). That is
+in-scope: fix it by re-syncing from Rhiza or by adjusting `.rhiza/template.yml`,
+not by editing the synced artifact in place.
+
+Then report:
+
+- A pass/fail summary per step.
+- Failures grouped by file, with the specific rule/error and line.
+- A prioritized list of what to fix first (blocking errors before style nits).
+
+Then analyse the repo and give marks on a scale of 1 to 10 for all relevant
+subcategories. Pick the subcategories that fit what you actually observe — e.g.
+linting/style, type safety, test pass rate, test coverage & depth, code
+structure & readability, documentation, dependency & security hygiene, CI/tooling
+health. For each: the score, a one-line justification grounded in evidence from
+the checks above (and a quick look at the code where needed), and what would
+raise it. Close with an overall score and the single highest-leverage
+improvement.
+
+**Scope the scorecard to locally-owned items — not what the mother repo (Rhiza)
+owns.** This project syncs its dev infrastructure from `jebel-quant/rhiza`; see
+`CLAUDE.md` for the authoritative split and the `files:` block of
+`.rhiza/template.lock` for the machine-generated list of synced files. Score
+only what this repo actually controls — `src/`, `tests/`, `pyproject.toml`,
+`README.md`, project-specific docs, `.rhiza/template.yml`, and any
+locally-hardened config. Do **not** let Rhiza-managed files (the
+`.github/workflows/*`, `Makefile`, `.pre-commit-config.yaml`, `pytest.ini`,
+`ruff.toml`, the typecheck/mutation/fuzzing targets, etc.) drive the marks — a
+gap there is fixed upstream in Rhiza, not here. If a relevant signal is
+Rhiza-owned, note it as "upstream/out-of-scope" rather than scoring it against
+this repo.
+
+Then, from the scorecard above, identify **actionable issues to improve the
+score** — one per subcategory scoring below 10 (skip any that are maxed). For
+each, give: a concrete title, the subcategory and current→target score it moves,
+the specific file(s)/lines or config to change, and a crisp acceptance criterion
+("done when…"). Keep them in-scope (locally-owned, per the scoping rule above) —
+flag anything Rhiza-owned as upstream rather than listing it as a local action.
+Order them by leverage (biggest score gain for least effort first). This is a
+list of recommendations only — do not change code unless I explicitly ask.
+
+Then offer to file the findings as issues — using a menu, not a free-text prompt.
+Present the actionable findings as a multi-select menu (the AskUserQuestion tool
+with `multiSelect: true`), one option per finding labelled by its title, so I can
+pick exactly which ones to file — including none. Create nothing without an
+explicit selection. For each finding I select, detect the hosting platform from
+the git remote (`git remote get-url origin`) and create one issue with the
+matching CLI — GitHub → `gh issue create`, GitLab → `glab issue create` (skip and
+say so if the relevant CLI is unavailable or unauthenticated). Make each issue
+self-contained: title from the finding, and a body carrying the subcategory, the
+current→target score, the specific file(s)/lines or config to change, and the
+"done when…" acceptance criterion. Report back the created issue URLs.
+
+If everything passes, say so plainly — but still produce the 1–10 subcategory
+marks. Do not fix anything unless I ask — this command only assesses.

nncg-0.2.0/.claude/commands/rhiza_release.md

@@ -0,0 +1,82 @@
+---
+description: Cut a release — choose the version bump, push the tag, and watch the release workflow
+allowed-tools: Bash, Read
+---
+
+Cut a release for this repository. Follow the command-execution policy: always
+prefer `make <target>`; never invoke `.venv/bin/...` directly.
+
+How releasing works here. `make release` delegates to `rhiza-tools release`
+(`.rhiza/make.d/releasing.mk`). It **always bumps** the version, folds a freshly
+generated `CHANGELOG.md` into the version-bump commit (git-cliff pre-commit
+hook), creates a `v*` tag, and pushes it. The tag push triggers the
+`rhiza_release.yml` GitHub Actions workflow (validate → build → SBOM → draft →
+publish → finalize). There is no separate post-tag changelog commit — the tagged
+commit already carries the changelog.
+
+**The bump type is a user decision.** Run interactively, `make release` prompts
+the user to pick `MAJOR`, `MINOR`, or `PATCH`. Because this command runs in a
+non-interactive shell (where the tool would silently default to `PATCH`), **you
+must ask the user which bump to apply** and pass their choice through with
+`BUMP=major|minor|patch` (supported by both `make release` and `make bump`).
+
+Do the following, in order:
+
+1. **Pre-flight checks.** Confirm the release is safe to cut and stop with a
+   clear explanation if any check fails (do not push a tag from a dirty or
+   behind branch):
+   - Working tree is clean (`git status --porcelain` is empty).
+   - On the default branch (`main`) — or confirm with the user if not.
+   - Local `main` is up to date with `origin/main` (`git fetch` then compare).
+   - `pyproject.toml` exists (the bump is skipped without it).
+
+2. **Ask the user for the bump type.** Just like `make release` does
+   interactively, ask the user to choose **MAJOR**, **MINOR**, or **PATCH**
+   (semver: breaking / feature / fix). Skip this question only when
+   `$ARGUMENTS` already names a bump type or authorises a default (see below).
+   Hold the chosen `<bump>` (lowercase: `major` / `minor` / `patch`) for the
+   next steps.
+
+3. **Preview the bump (dry run).** Run `make release DRY_RUN=1 BUMP=<bump>` to
+   show the user the planned new version and tag **before** anything is pushed.
+   The `DRY_RUN=1` flag previews the bump/tag/push without applying them.
+   Summarise what the real run will do (old → new version, tag name).
+
+4. **Confirm.** Unless `$ARGUMENTS` explicitly authorises proceeding (see
+   below), stop here and ask the user to confirm the previewed version before
+   cutting the real release. Pushing a tag triggers a public release workflow —
+   treat it as outward-facing and confirm first.
+
+5. **Cut the release.** Run `make release BUMP=<bump> PUSH=1`. This bumps,
+   commits (with changelog), tags, and pushes. The `PUSH=1` flag is **required
+   here**: without it the tool asks an interactive `Push tag to remote? [y/N]`
+   question that this non-interactive shell auto-declines, leaving the bump
+   commit and tag stranded locally (unpushed). Since you already confirmed with
+   the user in step 4, `PUSH=1` pushes straight through. Run it in the
+   foreground so any failure is visible. If it fails, show the relevant output,
+   diagnose the root cause, and stop — do not re-run blindly or hand-craft a tag.
+
+6. **Watch the workflow.** Run `make release-status` to show the release
+   workflow run and the latest release info. If the workflow is still in
+   progress, tell the user it is running and how to re-check
+   (`make release-status`). Report the final release URL once available.
+
+7. **Report.** Tell the user the version that was released, the tag, and the
+   release/workflow URL. If anything is still pending (workflow running, draft
+   not yet published), say so plainly.
+
+`$ARGUMENTS` handling:
+
+- Empty → run the full ask-bump → preview → confirm flow above.
+- `major` / `minor` / `patch` → use that as the bump type and skip the question
+  in step 2 (still preview and confirm).
+- `dry-run` (or `preview`) → do steps 1–3 only and stop; do **not** cut a real
+  release. If no bump type is also given, still ask for it in step 2.
+- `yes` / `confirm` / `--force` → skip the interactive confirmation in step 4
+  and proceed straight through (still run the dry-run preview in step 3 so the
+  user sees what shipped). If no bump type is also given, still ask for it in
+  step 2.
+- `status` → skip to step 6 and just report current release/workflow status.
+
+Argument tokens combine, e.g. `minor yes` cuts a minor release without the
+confirmation prompt; `minor dry-run` previews a minor bump only.

nncg-0.2.0/.claude/commands/rhiza_update.md

@@ -0,0 +1,100 @@
+---
+description: Update the pinned Rhiza version in .rhiza/template.yml, sync, resolve conflicts, and verify
+---
+
+Update this repo's Rhiza template to a newer release: bump the pin in
+`.rhiza/template.yml`, run the sync, resolve every conflict, verify the quality
+gates, and open a PR. Follow the command-execution policy: always prefer
+`make <target>`; never invoke `.venv/bin/...` directly.
+
+`$ARGUMENTS` may name a target version (e.g. `v0.19.1`). If empty, target the
+**latest** release of the upstream template repo.
+
+## 1. Determine current and target versions
+
+- Read `.rhiza/template.yml`: the `repository:` field is the upstream template
+  repo (usually `jebel-quant/rhiza`) and `ref:` is the currently pinned version.
+- Resolve the target version:
+  - If `$ARGUMENTS` names a version, use it (verify the tag exists:
+    `gh api repos/<repository>/git/ref/tags/<ref>`).
+  - Otherwise get the latest release:
+    `gh release view --repo <repository> --json tagName,publishedAt`.
+- If `ref:` already equals the target, report "already up to date" and stop.
+- Briefly summarize what's between the two versions when it's cheap to do so
+  (`gh release view`/release notes), so the reviewer knows what's landing.
+
+## 2. Bump the pin and commit (the tree must be clean to sync)
+
+- `make sync` refuses to run on a dirty tree, so the bump lands first.
+- Branch off the default branch (don't work on `main`/`master` directly):
+  `git checkout -b sync/rhiza-<target>`.
+- Edit only `ref:` in `.rhiza/template.yml` to the target version.
+- Commit just that change (e.g. `Chore: bump rhiza template ref <old> → <target>`).
+
+## 3. Sync
+
+- Run `make sync` (it invokes `rhiza sync`). Expect it to either complete
+  cleanly or report conflicts. It writes the refreshed `.rhiza/template.lock`.
+- If it completes with no conflicts, skip to step 5.
+
+## 4. Resolve every conflict
+
+The sync is a 3-way merge. Two kinds of leftovers can appear — handle both, and
+finish with **zero** `*.rej` files and **zero** conflict markers
+(`<<<<<<<` / `=======` / `>>>>>>>`) anywhere tracked
+(`git grep -lE '^(<<<<<<<|=======|>>>>>>>)'`).
+
+**`*.rej` files (rejected hunks).** The 3-way merge often *already applied* a
+hunk and still drops a duplicate `.rej`. For each, verify whether the change is
+already present in the file (the added `+` lines exist; no conflict markers
+remain). If it is, the `.rej` is spurious — delete it. If a hunk genuinely did
+not apply, apply it by hand, then delete the `.rej`.
+
+**Conflict-marked files.** Resolve by the ownership rule (see `CLAUDE.md` and the
+`files:` block of `.rhiza/template.lock` for the authoritative managed-file list):
+
+- **Rhiza-managed files** (the `.github/workflows/*`, `Makefile`,
+  `.pre-commit-config.yaml`, `pytest.ini`, the `.rhiza/` engine, etc.): take the
+  **incoming/upstream** side — these are owned by the template and should match
+  it (`git checkout --theirs -- <file>` then `git add`).
+- **Locally-owned or locally-hardened files** (notably `ruff.toml`, plus
+  `pyproject.toml`, `README.md`, `src/`, your `tests/`): **merge by hand** —
+  keep the local intent (e.g. stricter lint rules) while folding in genuine
+  upstream additions, and make the result internally coherent (dedupe, drop
+  comments that now contradict the config).
+
+Validate every touched workflow/YAML still parses before moving on.
+
+## 5. Verify the gates and fix fallout
+
+A version bump can tighten the gates (new lint rules, `mypy --strict`, expanded
+docs-coverage scope, etc.) and surface pre-existing issues. Run them and get
+them green:
+
+1. `make fmt` — pre-commit + lint
+2. `make typecheck`
+3. `make docs-coverage`
+4. `make deptry`
+5. `make security`
+6. `make test`
+
+**Scope your fixes.** Fix issues only in **locally-owned** files (`src/`,
+`tests/`, `pyproject.toml`, locally-hardened config). If a gate fails because of
+a **Rhiza-managed** file, that is an upstream problem: fix it in
+`jebel-quant/rhiza` and bump again — do **not** edit the synced artifact in
+place. Call out any such upstream-owned failure explicitly rather than papering
+over it locally.
+
+## 6. Commit, push, open a PR
+
+- Commit the resolution and any in-scope fixes with clear messages (one logical
+  change per commit: the conflict resolution, then each gate fix).
+- Push the branch and open a PR (`gh pr create`) titled for the bump, e.g.
+  `Chore: sync Rhiza template <old> → <target>`. In the body, summarize how each
+  conflict was resolved, list any gate fallout you fixed, and flag anything that
+  needs an **upstream** fix in Rhiza.
+- Report a concise per-gate PASS/FAIL summary. If the workflow files changed,
+  note that pushing them needs a token with the `workflow` scope.
+
+Do not merge the PR. Stop after it is open and summarize what landed and what
+(if anything) is blocked on an upstream Rhiza change.

nncg-0.2.0/.editorconfig

@@ -0,0 +1,41 @@
+# This file is part of the jebel-quant/rhiza repository
+# (https://github.com/jebel-quant/rhiza).
+#
+root = true
+
+# Default settings for all files
+[*]
+end_of_line = lf
+trim_trailing_whitespace = true
+insert_final_newline = true
+charset = utf-8
+
+# Python, reStructuredText, and text files
+[*.{py,rst,txt}]
+indent_style = space
+indent_size = 4
+
+# YAML, JSON, and other config files
+[*.{yml,yaml,json}]
+indent_style = space
+indent_size = 2
+
+# Markdown files
+# [*.{md,markdown}]
+# trim_trailing_whitespace = false
+
+# Makefiles require tabs
+[{Makefile,*.mk,*.make}]
+indent_style = tab
+indent_size = 4
+
+# Don't apply editorconfig rules to vendor/ resources
+# This is a "defensive" rule for the day we may have
+# the vendor folder
+[vendor/**]
+charset = unset
+end_of_line = unset
+indent_size = unset
+indent_style = unset
+insert_final_newline = unset
+trim_trailing_whitespace = unset

nncg-0.2.0/.github/CONFIG.md

@@ -0,0 +1,66 @@
+# GitHub Actions Configuration
+
+This document describes the secrets used by the Rhiza-provided GitHub Actions workflows
+(`.github/workflows/rhiza_*.yml`) and how to configure them.
+
+## PAT_TOKEN (template sync)
+
+The sync workflow (`.github/workflows/rhiza_sync.yml`) keeps your repository up to date with the
+upstream Rhiza template. It commits the synced files directly to a branch or opens a pull request.
+
+By default the workflow authenticates with the automatic `github.token`. That token **cannot push
+changes to files under `.github/workflows/`** — GitHub rejects such pushes unless the token has the
+`workflow` scope. Since template syncs regularly update workflow files, you should configure a
+Personal Access Token (PAT) with that scope and store it as a repository secret named `PAT_TOKEN`.
+
+If `PAT_TOKEN` is not configured, the workflow falls back to `github.token` and prints a warning.
+Syncs that touch only non-workflow files will still succeed.
+
+### Creating the token
+
+**Fine-grained PAT** (recommended):
+
+1. Go to **Settings → Developer settings → Fine-grained tokens → Generate new token**
+   (<https://github.com/settings/personal-access-tokens/new>).
+2. Restrict **Repository access** to the repository (or repositories) using Rhiza.
+3. Under **Repository permissions**, grant:
+   - **Contents**: Read and write
+   - **Workflows**: Read and write
+   - **Pull requests**: Read and write (needed for the scheduled sync-PR mode)
+4. Generate the token and copy it.
+
+**Classic PAT** (alternative):
+
+1. Go to **Settings → Developer settings → Tokens (classic) → Generate new token**.
+2. Select the `repo` and `workflow` scopes.
+3. Generate the token and copy it.
+
+### Storing the secret
+
+In the repository that consumes Rhiza:
+
+1. Go to **Settings → Secrets and variables → Actions → New repository secret**.
+2. Name: `PAT_TOKEN`
+3. Value: the token created above.
+
+Or with the GitHub CLI:
+
+```bash
+gh secret set PAT_TOKEN
+```
+
+A PAT expires; when sync pushes start failing with a `refusing to allow ... workflow` error,
+regenerate the token and update the secret.
+
+## Release workflow secrets (optional)
+
+The release workflow (`.github/workflows/rhiza_release.yml`) supports additional secrets, all
+optional depending on which release features you use:
+
+| Secret | Purpose |
+| --- | --- |
+| `PYPI_TOKEN` | Publish the built package to PyPI. Not needed when using trusted publishing (OIDC). |
+| `GH_PAT` | Git authentication for installing private dependencies during the release build. |
+| `UV_EXTRA_INDEX_URL` | Extra package index URL (with credentials) for private dependencies. |
+
+`GITHUB_TOKEN` is provided automatically by GitHub Actions and needs no configuration.

nncg-0.2.0/.github/DISCUSSION_TEMPLATE/help-wanted.yml

@@ -0,0 +1,48 @@
+title: "[Help Wanted] "
+labels: ["help wanted"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Use this template to surface a contribution opportunity. It lets maintainers
+        describe work that is ready to be picked up — without opening a formal issue.
+
+  - type: input
+    id: area
+    attributes:
+      label: Topic / Area
+      description: Which part of the project does this involve?
+      placeholder: e.g. CI workflows, documentation, a specific bundle
+    validations:
+      required: true
+
+  - type: textarea
+    id: help-needed
+    attributes:
+      label: What Help Is Needed
+      description: Describe the task and what "done" looks like.
+    validations:
+      required: true
+
+  - type: textarea
+    id: getting-started
+    attributes:
+      label: Getting Started
+      description: Pointers to relevant files, docs, or prior discussion that help a contributor begin.
+      placeholder: |
+        - Relevant files: ...
+        - Related docs: ...
+    validations:
+      required: false
+
+  - type: dropdown
+    id: skill-level
+    attributes:
+      label: Skill Level
+      description: Roughly how much experience is needed to take this on?
+      options:
+        - Good first issue (beginner friendly)
+        - Intermediate
+        - Advanced
+    validations:
+      required: false

nncg-0.2.0/.github/DISCUSSION_TEMPLATE/ideas.yml

@@ -0,0 +1,40 @@
+title: "[Idea] "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Propose an idea before implementing it. This lightweight RFC process lets the
+        community gauge interest and shape the design before any code is written.
+
+  - type: textarea
+    id: idea
+    attributes:
+      label: The Idea
+      description: What are you proposing? Describe it clearly enough that others can react.
+    validations:
+      required: true
+
+  - type: textarea
+    id: motivation
+    attributes:
+      label: Motivation
+      description: What problem does this solve, and who benefits?
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives Considered
+      description: Other approaches you weighed, and why this one is preferable.
+    validations:
+      required: false
+
+  - type: textarea
+    id: references
+    attributes:
+      label: References
+      description: Links to prior art, related discussions, issues, or external resources.
+    validations:
+      required: false

nncg-0.2.0/.github/DISCUSSION_TEMPLATE/q-and-a.yml

@@ -0,0 +1,25 @@
+title: "[Question] "
+labels: ["question"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Welcome! Use this space to ask questions, share how your use-case, or explore ideas with the community.
+
+  - type: textarea
+    id: question
+    attributes:
+      label: Your Question or Topic
+      description: What would you like to discuss?
+    validations:
+      required: true
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Context
+      description: Any relevant code, configuration, or background that helps frame your question.
+      placeholder: |
+        ```python
+        # your code snippet here
+        ```

nncg-0.2.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,57 @@
+name: Bug Report
+description: Report a bug or unexpected behaviour
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug. Please fill out the sections below.
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: A clear and concise description of what the bug is.
+      placeholder: What happened?
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to reproduce
+      description: Minimal steps to reproduce the behaviour.
+      placeholder: |
+        1. Run `make ...`
+        2. See error
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behaviour
+      description: What did you expect to happen?
+    validations:
+      required: true
+
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: |
+        Relevant versions and system info. Run `make info` if available.
+      placeholder: |
+        - OS: macOS 14 / Ubuntu 24.04 / Windows 11
+        - Python: 3.13.x
+        - rhiza version:
+    validations:
+      required: false
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Additional context
+      description: Logs, screenshots, or anything else that may be helpful.
+    validations:
+      required: false

nncg-0.2.0/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,41 @@
+name: Feature Request
+description: Suggest a new feature or enhancement
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for proposing a feature. Please align with the team before investing significant effort.
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem / motivation
+      description: What problem does this solve? Why is it valuable?
+      placeholder: As a contributor I find it hard to ... because ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: solution
+    attributes:
+      label: Proposed solution
+      description: Describe the solution you have in mind.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: Other approaches you have considered and why you ruled them out.
+    validations:
+      required: false
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Additional context
+      description: Links, mockups, prior art, or anything else that may be helpful.
+    validations:
+      required: false