-
-
Notifications
You must be signed in to change notification settings - Fork 0
Showcase: Full System — Source-Verified Investigations, Live Discord Bot, Dispatch Approval #3
Description
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-quotein 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:
-
Command failure: Passwords with
\,",$break Docker command parsing. Passwordmy\passwordbecomes--env UNITY_PASSWORD="my\password"— shell interprets the backslash. -
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:
- Shared volumes (@liasece): Use named volumes accessible to both containers
- Custom Unity image (@Lachee): Pre-install action scripts in Unity image
- 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:
- Shared volumes — Use named volumes accessible to both containers
- Custom Unity image — Pre-install action scripts in Unity image
- 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:
- Convert to WebM VP8:
ffmpeg -i video.mp4 -c:v libvpx -crf 4 -b:v 20M video.webm - 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: trueand 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.ymlbefore 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.