Enable agentic reviewer workflows in drasi-server

[ruokun-niu]

Description

Adds .github/workflows/pr-reviewers.yml, a label-driven caller workflow
that dispatches the centralized Drasi agentic PR reviewers hosted in
drasi-project/.github.

When a PR is labeled with one of:

• review:correctness
• review:security
• review:design
• review:docs
• review:testing
• review:prior-art
• review:all (runs all six)

the workflow invokes the corresponding pr-*-reviewer.lock.yml in
drasi-project/.github via gh workflow run (cross-repo
workflow_dispatch). Each reviewer executes in the .github repo
context, fetches the PR, and posts its review back as a comment on
this PR.

For reference, here is a test PR: drasi-project/drasi-core#429

Type of change

• This pull request fixes a bug in Drasi and has an approved issue (issue link required).
• This pull request adds or changes features of Drasi and has an approved issue (issue link required).
• This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Drasi (issue link optional).

Fixes: #issue_number

[Copilot]

Pull request overview

Adds a GitHub Actions workflow that lets maintainers trigger centralized, label-driven PR reviewer workflows hosted in drasi-project/.github. In this codebase, it introduces the automation glue for cross-repo reviewer dispatch without changing application runtime behavior.

Changes:

• Adds .github/workflows/pr-reviewers.yml to listen for review:* labels on PRs.
• Maps each supported label to one or more centralized locked reviewer workflows.
• Dispatches those reviewer workflows via gh workflow run, passing the current PR URL.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🔍 YAML Snippet Validation Report

I validated all YAML configuration snippets in markdown files against the Drasi Server Rust models.

❌ Issue Found

File: README.md, line 792

Problem: The verifyPlugins field has an incorrect default value in the documentation table.

Field	Documented Default	Actual Default (from Rust)
verifyPlugins	false ❌	true ✅

Evidence:

// src/config/types.rs, lines 109-111
/// Enable cosign signature verification for downloaded plugins (default: true)
#[serde(default = "default_true")]
pub verify_plugins: bool,

The default_true() function returns true, but the README table at line 792 says the default is false.

Impact: Users reading the docs may assume plugin verification is disabled by default and be surprised when downloaded plugins require valid Sigstore signatures.

Suggested fix:

-| `verifyPlugins` | boolean | `false` | Enable cosign signature verification...
+| `verifyPlugins` | boolean | `true`  | Enable cosign signature verification...

✅ Everything Else Looks Good

All other YAML snippets validated correctly:

• All field names use correct camelCase as required by #[serde(rename_all = "camelCase")]
• QueryConfigDto fields (autoStart, queryLanguage, sourceId, enableBootstrap, bootstrapBufferSize) all match their Rust counterparts
• DrasiServerConfig fields (logLevel, persistConfig, persistIndex, enableUi, stateStore, pluginRegistry, corsAllowedOrigins, etc.) all match the Rust struct
• DrasiLibInstanceConfig fields in multi-instance examples are correct
• ReactionConfig camelCase fields (autoStart, identityProvider) match the custom deserializer
• No unknown fields that would fail deny_unknown_fields validation

Files checked: README.md, CLAUDE.md, examples/configs/README.md, examples/getting-started/README.md

Generated by YAML Snippet Validator for issue #93 · ● 3.1M · ◷