Skip to content

Showcase: Full System — Source-Verified Investigations, Live Discord Bot, Dispatch Approval #3

@frostebite

Description

@frostebite

GameCI Help Bot v3.0.0 — Real Run Showcase

All output below is from actual runs against game-ci/unity-builder (801 synced issues). Nothing is fabricated or templated.


Run Output (2026-03-07)

Skipping sync steps (skipSync=true)
Filtering issues for game-ci-unity-builder...
  Eligible: 35, Skipped: 766
    closed: 656
    collaborator-responded-body: 61
    stale: 28
    not-relevant: 21
  Deduped 5 automated PRs (35 → 30)
  Manifest written
Running security scan on game-ci-unity-builder...
  Security findings: 107 total (12 critical, 91 high)
Running LLM provider...
Provider: Claude Code CLI (model: claude-sonnet-4-20250514, max_turns: 75)
  Investigated: #430, #475, #488, #614, #622, #649, #657, #666, #702, #708
GitHub-only mode. Skipping Discord posting.
Posting GitHub responses (dry run: true)...
  DRY RUN: would post GitHub response for game-ci/unity-builder#430
  DRY RUN: would post GitHub response for game-ci/unity-builder#475
  DRY RUN: would post GitHub response for game-ci/unity-builder#488
  DRY RUN: would post GitHub response for game-ci/unity-builder#614
  DRY RUN: would post GitHub response for game-ci/unity-builder#622
  DRY RUN: would post GitHub response for game-ci/unity-builder#649
  DRY RUN: would post GitHub response for game-ci/unity-builder#657
  DRY RUN: would post GitHub response for game-ci/unity-builder#666
  DRY RUN: would post GitHub response for game-ci/unity-builder#702
  DRY RUN: would post GitHub response for game-ci/unity-builder#708

The 5-Stage Filter Pipeline

801 issues scanned. 766 removed before the LLM sees anything. Here's exactly what each stage catches:

Stage 1: Closed (656 removed)

Resolved issues. No action needed. Simple state check.

Stage 2: Collaborator Responded (61 removed)

A maintainer already commented. The bot checks both the official_response frontmatter flag and scans the body for collaborator username patterns. Example issues removed:

  • Issues where @GabLeRoux, @webbertakken, or other GameCI maintainers already replied
  • Even if the issue is still open, if a maintainer engaged, the bot defers

Stage 3: Stale (28 removed)

Open issues with 0 comments and no activity in 90+ days. Likely abandoned.

Stage 4: Not Relevant (21 removed)

The isRelevantForHelpBot() heuristic. Real examples from this run:

Pure feature requests (no question, no error, just proposals):

Issue Title Why Skipped
#771 "Add support for specifying unity modules for builder to install" enhancement label, no question or error in body
#789 "feat: Hot Runner Protocol" enhancement + next-gen labels, architectural proposal
#797 "feat: Unity Editor Tooling" enhancement + next-gen labels, design spec
#805 "feat: Automation & CI Dispatch Providers" enhancement + lts 2.0 labels, roadmap item
#451 "Test verification - skip cache duplicate improvement" enhancement + cloud-runner, no help signals

Dependency bumps (automated PRs containing "changelog" in body):

Issue Title Why Skipped
#644 "Bump undici from 5.28.3 to 5.28.4" Bot-generated PR with changelog notes
#646 "Bump tar from 6.1.15 to 6.2.1" Bot-generated PR with changelog notes
#655 "Bump ws from 6.2.2 to 6.2.3" Bot-generated PR with changelog notes

Stage 5: Bot Already Responded (0 this run)

Tracks which issues the bot has already investigated. Won't re-process them unless there's new activity since the bot's last response (requires redispatch).

What Passes — The 30 Eligible Issues

After deduplication of 5 automated PRs, 30 issues remain with genuine help signals. Examples:

Issue Signal Detected Why It Passes
#708 bug label + error keywords "doesn't set the Patch field"
#702 bug label "Adding Behaviour package breaks IL2CPP-Windows builds"
#690 Error keyword "Activation Failure when running..."
#657 bug label + error keyword "Docker command fails for some unity passwords"
#475 bug label + high comment count "Running action in self-hosted runner" (30 comments)
#667 Error keyword "WebGL build failing with no errors"

Real Investigations (10 total from 2026-03-07 run)

These are actual investigation outputs where the LLM read action.yml, grepped source code, and cross-referenced 800+ issues.

Classification Summary

Classification Count Issues
Bug 3 #708, #657, #430
Limitation 7 #475, #488, #614, #622, #649, #666, #702

Cross-Issue Patterns

The bot identified connections across issues that individual reporters cannot see:

  • macOS self-hosted runner pattern: #649 (custom Unity Hub paths) and #666 (Jenkins error 139) both expose gaps in macOS self-hosted support — hard-coded paths, no custom location support, no Jenkins integration
  • Authentication gaps across modes: #430 (Git-LFS auth) reveals that Orchestrator mode has comprehensive authentication while Docker mode (which most users use) lacks equivalent support — this pattern also connects to #614 (Asset Store auth) as another authentication surface unity-builder doesn't cover
  • Semantic versioning cluster: #708 (3-field tag bug) and #622 (fetch-depth requirement) both affect semantic versioning — combined, they show the versioning subsystem has both a logic bug and a documentation/error-handling gap
  • Docker command robustness: #657 (password escaping) exposes unsafe shell interpolation in Docker command construction — the codebase already uses shell-quote in the orchestrator provider but not in the Docker path
  • Self-hosted runner challenges: #475 (Docker-in-Docker), #649 (macOS paths), and #666 (Jenkins) form a cluster of self-hosted runner issues with different root causes
  • CI environment limitations: #488 (MP4 codecs) and #702 (App UI native plugins) both stem from Unity packages assuming full desktop environments that CI containers don't provide

Investigation 1: Semantic versioning bug with 3-field tags

Classification: bug | Severity: Medium | File: src/model/versioning.ts:124

Source: game-ci/unity-builder#708

Source verification
Status Item Evidence
VERIFIED versioning parameter action.yml lines 50-53
VERIFIED Bug in string splitting versioning.ts line 124: `${tag}.${commits}`.split('.')
VERIFIED Tag 0.1.0 + 14 commits = "0.1.0.14" Split gives ["0","1","0","14"], patch = "0" not "14"
VERIFIED Missing test coverage versioning.test.ts line 276-284: only 2-field tag tests
VERIFIED User's proposed fix Technically sound — extract major.minor from tag, always use commits as patch
Bug discovery

Affected code:

// src/model/versioning.ts line 124
const [major, minor, patch] = `${tag}.${commits}`.split('.');

What happens: For tag v0.1.0 with 14 commits since tag, string becomes "0.1.0.14". Split on . gives ["0", "1", "0", "14"]. Destructuring takes first 3 — patch becomes "0", commit count "14" is silently discarded.

Impact: Any project using standard SemVer 3-field tags (e.g., v1.2.3) gets stale version numbers that never increment. This affects all platforms and runner types.

Fix direction: Split tag into major/minor components only, always use commits as patch field. Add test cases for 3-field tags.

Generated response

You've identified a genuine bug in the semantic versioning logic at src/model/versioning.ts lines 124-125.

Root Cause: When a git tag has 3 fields (like v0.1.0), the code creates "0.1.0.14" and splits on .. It only destructures the first 3 elements, so patch becomes "0" instead of "14" (the commit count).

The existing test suite only covers 2-field tags (like 0.1) — no coverage for the 3-field scenario. Your proposed fix is sound: extract only major and minor from the tag, always use the commit count as the patch field.


Investigation 2: Password escaping + credential exposure

Classification: bug | Severity: High (security) | File: src/model/image-environment-factory.ts:18

Source: game-ci/unity-builder#657

Source verification
Status Item Evidence
VERIFIED UNITY_PASSWORD handling image-environment-factory.ts line 27
VERIFIED No shell escaping getEnvVarString() line 18: --env ${p.name}="${valueAsString}"
VERIFIED Direct interpolation docker.ts lines 63-91 interpolates env string into command
VERIFIED Multiline handling exists Lines 12-15, but no special-char escaping
VERIFIED shell-quote already used elsewhere Orchestrator local provider uses it correctly
Bug discovery

Two issues:

  1. Command failure: Passwords with \, ", $ break Docker command parsing. Password my\password becomes --env UNITY_PASSWORD="my\password" — shell interprets the backslash.

  2. Credential exposure: Passwords appear unmasked in debug output regardless of special characters.

Notable: The orchestrator's local provider already uses shell-quote for proper escaping — the Docker path lacks equivalent protection.

Fix direction: Apply shell-quote escaping to env var values, mask sensitive values in debug output, consider --env-file for better security.

Generated response

You've identified a legitimate bug with two concerning aspects: command construction failure and a security issue.

The issue is in src/model/image-environment-factory.ts at line 18, where environment variables are directly interpolated into the Docker command without shell escaping. When UNITY_PASSWORD contains characters like \, ", or $, they break Docker command parsing. Additionally, passwords appear unmasked in debug output.

The local orchestrator provider already uses shell-quote for proper escaping — the Docker path should do the same.


Investigation 3: Git-LFS auth gap between execution modes

Classification: bug | Severity: Medium | Context: Docker mode vs Orchestrator mode inconsistency

Source: game-ci/unity-builder#430

Source verification
Status Item Evidence
VERIFIED gitPrivateToken parameter action.yml lines 104-107
VERIFIED LFS auth in Orchestrator orchestrator/remote-client/index.ts lines 410-448
VERIFIED URL rewriting configured git config --global url."https://${gitPrivateToken}@github.com/"...
VERIFIED No LFS auth in Docker mode Only passes GIT_PRIVATE_TOKEN as env var
VERIFIED Multiple users affected Several comments confirming the issue
Bug discovery

Feature parity gap:

Mode Git Auth LFS Auth URL Rewriting
Orchestrator Yes Yes (lines 410-448) Yes
Docker (standard) Partial No No

Most users run Docker-based builds (the default). Git clone succeeds because GitHub Actions provides GITHUB_TOKEN, but Git-LFS uses a separate authentication path that isn't configured in Docker containers.

Why maintainer couldn't reproduce: Likely tested in Orchestrator mode or with public repos.

Generated response

Git-LFS authentication with private tokens is implemented, but only in Orchestrator mode. The code in src/model/orchestrator/remote-client/index.ts (lines 410-448) properly configures git credential handling with URL rewriting.

In standard Docker-based builds (which most users use), the container receives GIT_PRIVATE_TOKEN as an environment variable, but unity-builder doesn't configure git credential helpers or URL rewriting within the container. Git-LFS therefore has no way to authenticate.

The Docker mode needs the same git credential configuration that Orchestrator mode already implements — this represents a feature parity gap between execution modes.


Investigation 4: Docker-in-Docker volume mounting on self-hosted runners

Classification: limitation | Severity: High | File: src/model/docker.ts:76

Source: game-ci/unity-builder#475 (30 comments)

Source verification
Status Item Evidence
VERIFIED runAsHostUser parameter action.yml — for self-hosted Linux runners
VERIFIED dockerWorkspacePath parameter action.yml — workspace mount path
VERIFIED Entrypoint mounting docker.ts line 76: --volume "${actionFolder}/platforms/ubuntu/entrypoint.sh:/entrypoint.sh:z"
VERIFIED Command execution docker.ts line 91: "/entrypoint.sh"
Root cause analysis

Docker-in-Docker Volume Mounting Issue: The action mounts entrypoint.sh from its distribution folder, but in DinD environments Docker resolves volumes from the host filesystem, not the runner container. Since the host lacks action files, the mount fails or creates a directory.

Error: /bin/bash: /entrypoint.sh: Is a directory

Community-documented workarounds:

  1. Shared volumes (@liasece): Use named volumes accessible to both containers
  2. Custom Unity image (@Lachee): Pre-install action scripts in Unity image
  3. Container job (@seamon67): Use container: in workflow to run inside Unity image directly

This is a fundamental limitation of the current architecture when used in Docker-in-Docker environments.

Generated response

TL;DR: Docker-in-Docker volume mounting limitation — action scripts can't be mounted when runner is containerized. Use shared volumes or custom images.

Root Cause: The action mounts entrypoint.sh from its distribution folder, but in DinD environments Docker resolves volumes from the host, not the runner container. Since host lacks action files, the mount fails or creates a directory.

Workarounds:

  1. Shared volumes — Use named volumes accessible to both containers
  2. Custom Unity image — Pre-install action scripts in Unity image
  3. Container job — Run job inside Unity container directly

Investigation 5: iOS video import failures in CI

Classification: limitation | Severity: Medium | Context: Unity video codec limitation on Linux

Source: game-ci/unity-builder#488

Source verification
Status Item Evidence
VERIFIED No video codec parameters action.yml — Unity Builder doesn't control video codec support
VERIFIED No video format handling src/ — Unity Builder doesn't modify video import behavior
NOT FOUND Video codec installation Docker images use base Ubuntu with minimal codec support
Root cause analysis

Unity Video Codec Limitation on Linux: Unity on Linux (Ubuntu) does not support MP4 video format import due to missing H.264 codecs in the container environment.

Error: "Error while reading movie: /github/workspace/Assets/[filename].mp4"

This is a Unity Editor limitation on Linux, not a GameCI issue. Adding codec support would require legal licensing for H.264 codec distribution and significant container size increases.

Solutions:

  1. Convert to WebM VP8: ffmpeg -i video.mp4 -c:v libvpx -crf 4 -b:v 20M video.webm
  2. Use StreamingAssets: Place MP4s in StreamingAssets/ and load with VideoPlayer at runtime

Investigation 6: App UI / Behaviour package breaks IL2CPP-Windows builds

Classification: limitation | Severity: Medium | Context: Unity package compatibility with CI environments

Source: game-ci/unity-builder#702

Source verification
Status Item Evidence
VERIFIED enableGpu parameter action.yml — "Launches unity without specifying -nographics"
VERIFIED LLVMPipe support PR #706 — Mesa OpenGL software renderer for Windows CI
VERIFIED App UI requires OpenGL User reports indicate package needs GPU/renderer access
NOT FOUND App UI native plugin issues in GameCI source This is a Unity package issue
Root cause analysis

Unity App UI Package Limitation: App UI's native plugins require proper OpenGL context and Windows SDK runtime components not available in CI environments.

  • Local builds work — full GPU drivers and Windows runtime components available
  • CI builds fail — even with enableGpu: true and LLVMPipe, native plugins need additional Windows SDK dependencies
  • Linux builds work — different plugin requirements

Package maintainer (@jbltx) confirmed it's related to the App UI native plugin on Windows and missing dependencies.

Workaround: Remove Behaviour/App UI packages for CI builds, or build on Linux runners.


Investigation 7: Hard-coded macOS Unity Hub paths

Classification: limitation | File: src/model/platform-setup/setup-mac.ts:9-13 | Related: #666

Source: game-ci/unity-builder#649

Source verification
Status Item Evidence
VERIFIED No path override params action.yml has no macOS path parameters
VERIFIED Hard-coded Hub path setup-mac.ts line 9: /Applications/"Unity Hub.app"
VERIFIED Hard-coded editor path Line 13: /Applications/Unity/Hub/Editor/${version}/...
VERIFIED No alternative search No fallback path discovery logic
VERIFIED Hub detects installs correctly But action ignores Hub's configuration
Generated response

The action uses hard-coded Unity Hub paths in src/model/platform-setup/setup-mac.ts. Unity Hub correctly detects your existing editor installation — but unity-builder ignores Hub's configuration and only looks in /Applications/Unity/Hub/Editor/.

Enhancement options: add a unityInstallPath parameter, query Unity Hub CLI to discover paths, or search common alternative locations.


Investigation 8: Semantic versioning requires undocumented fetch-depth

Classification: limitation | File: src/model/versioning.ts:192-198

Source: game-ci/unity-builder#622

Source verification
Status Item Evidence
VERIFIED Semantic fetch trigger versioning.ts line 102-103: shallow check → fetch
VERIFIED Shallow check Line 180: git rev-parse --is-shallow-repository
VERIFIED Fetch attempts Lines 192-198: tries --unshallow, falls back to git fetch
VERIFIED Silent error logging Line 280: shouldLog = false masks errors
VERIFIED No documentation action.yml doesn't mention fetch-depth requirement
Generated response

Semantic versioning requires full git history — GitHub Actions defaults to fetch-depth: 1 (shallow clone). Adding fetch-depth: 0 to actions/checkout solves it.

The unhelpful errors come from versioning.ts line 280 running git commands with shouldLog = false. This fetch-depth requirement should be documented in action.yml.

Related: #708 reveals a logic bug in the same subsystem.


Investigation 9: Unity Asset Store package authentication

Classification: limitation | Scope: Missing feature

Source: game-ci/unity-builder#614

Source verification
Status Item Evidence
VERIFIED No Asset Store auth params action.yml has no Unity account params for Package Manager
VERIFIED gitPrivateToken is GitHub-only Line 104 — only for GitHub authentication
NOT FOUND No Unity Hub auth handling Searched entire source, not implemented
NOT FOUND No Asset Store token support No mechanism exists
Analysis

Unity Asset Store packages require authenticated access to download.packages.unity.com. Unity-builder handles editor licensing (UNITY_EMAIL, UNITY_PASSWORD, UNITY_SERIAL) but not Package Manager authentication.

Packages that work: Unity Registry (free), git-based (public), local/embedded, scoped registries.
Packages that don't: Asset Store packages requiring Unity account authentication.

This connects to the authentication gap pattern seen in #430.


Investigation 10: Jenkins build scope clarification

Classification: limitation | Scope: Outside unity-builder | Related: #649, #475

Source: game-ci/unity-builder#666

Analysis

The user is running Unity builds directly through Jenkins, not using the GameCI unity-builder GitHub Action. Exit code 139 (SIGSEGV) indicates a Unity Editor crash.

Unity-builder is designed for GitHub Actions workflows using Docker containers — not direct Jenkins integration. The user's issue is likely caused by Unity version compatibility with macOS Sonoma, missing graphics context, or Jenkins environment differences.


Live Discord Bot (New in v3.0.0)

The bot now operates as a persistent Discord Gateway bot monitoring help channels in real-time, in addition to the scheduled GitHub issue cycle.

Live Bot Capabilities

Feature Description
Real-time monitoring Persistent WebSocket connection to Discord, responds to @mentions and replies
Multi-phase investigation Same source-verified investigation pipeline as GitHub mode
Emoji status indicators 🔍 investigating, ✅ success, ❌ failure
Text file attachments Reads .txt, .log, .json, .yaml, .xml, .csv, .md files attached to messages (256KB max)
Conversation chaining Follow-up replies build on previous investigation context
Downvote feedback 👎 reaction logs the question + bad response for review
Re-investigation 🔁 reaction triggers fresh investigation with correction prompt
Question-first approach Bot asks clarifying questions when uncertain instead of guessing
Diagnostic patterns Known failure patterns (Git LFS, Docker, license) guide initial investigation
Differential diagnosis Lists 2-3 candidate causes with evidence for/against before concluding

Investigation Prompt Architecture

The live bot uses a 3-phase investigation prompt with built-in quality controls:

Phase 1: SEARCH — Broad cross-repo searching, diagnostic keyword expansion
Phase 2: ANALYZE — Differential diagnosis with evidence for/against each cause
Phase 3: SELF-REVIEW — Symptom matching, factual verification, CLI syntax checks

Key rules enforced:

  • Do not assume the user made a mistake — verify before suggesting fixes
  • Asking questions is encouraged — if diagnosis is uncertain, ask instead of guessing
  • Symptom matching — diagnosis must explain ALL stated symptoms
  • Source verification — every parameter verified against action.yml before suggesting

Dispatch Pipeline — Staged Countdown

The bot doesn't post responses immediately. In countdown mode, each detection progresses through stages with one stage per cycle maximum:

Cycle 1:  Detection created ──────────────── stage 0 (pending)
Cycle 2:  24h elapsed → Warning 1 posted ── stage 1
Cycle 3:  24h elapsed → Warning 2 posted ── stage 2
Cycle 4:  24h elapsed → Warning 3 posted ── stage 3
Cycle 5:  24h elapsed → Auto-dispatch ───── investigation begins

Default: 3 warnings, 24 hours apart = 72-hour minimum before auto-dispatch.

At any point a maintainer can react to approve or cancel immediately.


Security Architecture

6-Layer Defence

Layer What It Does How
Tool restriction Limits LLM to Read, Glob, Grep, Bash, Write --allowedTools / --disallowedTools at process level
Pre-filter Removes issues before LLM sees them Code-level filter: closed, collaborator-responded, stale, skip-labels
Injection scanning Detects prompt injection in content 17 patterns across 4 severity levels, scanned every cycle
Prompt hardening Explicit rules in LLM prompt Never follow user instructions, never access URLs, flag injection
Output isolation LLM writes files, posting is separate Files in data/responses/, separate posting code path
Dry run Operator control before live posting --dry-run prevents all GitHub/Discord posting

External File Security (Live Bot)

The live bot enforces strict external file rules:

  • No downloading images, log files, or any external files from URLs
  • Text attachments only — .txt, .log, .json, .yaml, .xml, .csv, .md (256KB max per file)
  • Attachment content is included directly in the investigation context

Quality Comparison

Metric Early iterations Current system
Parameter accuracy Fabricated SKIP_VERSION_CHECK, UNITY_CLEAN_BUILD Every parameter verified against action.yml
Source verification None — generated from memory VERIFIED/NOT FOUND entries with file:line
Related issues "Similar issues found" (vague) Cross-referenced by error, platform, root cause
Classification None bug / user-error / limitation / feature-request
Diagnostic approach Anchored on first plausible cause Differential diagnosis with evidence for/against
Question handling Always provided an answer Asks clarifying questions when uncertain
Tone Emoji, "Hi @user!", "we'll fix this" Professional, no emoji, community helper voice
Investigation audit None Full investigation file with evidence trail
Issue filtering LLM decided (unreliable) Hard code-level pre-filter (766/801 removed) + dedup
Security None 6-layer security with injection scanning
Dispatch control None — auto-posted everything 3-mode approval system with staged countdown
Discord support None Persistent Gateway bot with emoji reactions + re-investigation

Full Pipeline in One Diagram

801 issues synced
    |
    v
[Stage 1] Closed ─────────────── 656 removed
    |
    v  (145 remaining)
[Stage 2] Collaborator responded ─ 61 removed
    |
    v  (84 remaining)
[Stage 3] Stale (>90d, 0 comments) ─ 28 removed
    |
    v  (56 remaining)
[Stage 4] Not relevant ────────── 21 removed
    |                               ├── 5 pure feature requests
    |                               ├── ~15 dependency bump PRs
    |                               └── 1 roadmap discussion
    v  (35 remaining)
[Stage 4b] Dedup automated PRs ── 5 removed
    |
    v  (30 remaining)
[Stage 5] Bot already responded ── 0 removed (first run)
    |
    v  (30 eligible)
[Security scan] ──────────────── 107 findings flagged
    |
    v
[Dispatch gate] ──────────────── 10 selected for investigation
    |
    v
[LLM investigation] ──────────── Reads action.yml, greps source, cross-references
    |
    v
[Output] ─────────────────────── Investigation file + response file per issue
    |
    v
[Post pipeline] ──────────────── GitHub comment, investigation issue, cycle report
    |
    v
[Feedback] ────────────────────── Track comment ID, poll reactions next cycle

Commits (v1.0 through v3.0.0)

Commit Description
6112180 feat: --github-only mode
1bbba39 fix: follow redirects when syncing docs
9f73bba feat: --repo-dir and --docs-dir
1eefb77 feat: overhaul response quality
34aa9c2 feat: copy reference files into sandbox
ef44685 feat: investigation issues, cross-issue analysis, bug detection
d953f03 feat: hard issue pre-filter, cycle reports
3334504 feat: prompt injection security scanning
aa06769 fix: Bash tool for file searching
40b17df feat: dispatch approval with staged countdown
b29dd40 feat: Discord DM notifications, emoji status reactions
701c640 feat: filter bot's own prior responses
3e7a4da feat: full Discord integration, feedback reactions, per-label prompts
aa0f3d4 fix: relevance pre-filter, repo slug conversion
6ff17d8 feat: quality improvements — prompt, priority scoring, dedup, review modes
232e1e4 feat: persistent Discord Gateway bot mode
4315b65 feat: only respond to @mentions and replies
a9884b5 feat: enforce concise first replies across Discord and GitHub
b305b6a feat: universal multi-phase investigation prompt
76e5351 feat: block external file downloads in investigation prompt
afefe0e feat: emoji reactions for investigation status
29b45b7 feat: download text file attachments from Discord messages
613a020 feat: downvote feedback, re-investigate emoji, stricter self-review
5f0436d feat: HydrateSecrets script for ephemeral secret provisioning
389fc55 feat: diagnostic patterns, differential diagnosis
4532eb6 feat: allow asking questions instead of guessing, improve chaining

Feedback Welcome

If you have thoughts on investigation quality, dispatch workflow, cross-referencing depth, or the live Discord bot — please comment here or react on this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions