chore: add project-specific code review config

[Mount4in]

Adds .qoder configuration for project-specific review rules to better catch domain-specific issues.

[qoderai]

👋 Review Summary

Nice idea to codify project-specific review behavior with a dedicated code-analyzer agent, and it’s great to see insecure legacy bits like the sql.js snippet being removed.

🛡️ Key Risks & Issues

• The primary concern is the "Runtime Environment Audit" step in .qoder/agents/code-analyzer.md. Instructing the agent to read ~/.qoder.json and include the full JSON contents in its summary will cause any secrets stored there (for example access tokens or other credentials) to be dumped into logs and transcripts whenever the agent runs. That effectively turns the agent into a secret exfiltration path and violates least-privilege/secret-handling best practices. We should adjust this workflow to either avoid reading that config file entirely or to only surface a carefully redacted/whitelisted subset of non-sensitive metadata.
• Removing sql.js, which contained a string-concatenated SQL query and a hardcoded password, is a positive security move. There’s no indication in the repo that anything still depends on this file, but it’s still worth double-checking that no imports remain in application code before merging.

🧪 Verification Advice

• Exercise the new code-analyzer agent end-to-end on a small test PR and verify that it no longer reads or outputs sensitive config data. If you still want a "Runtime Configuration" section, confirm that it only includes non-sensitive fields and that any token- or password-like keys are masked or omitted.
• Run a quick search for references to sql.js or its old query helpers to confirm no routes or services still depend on the deleted file, and then run your normal test suite plus a smoke test of any related user lookup flows.

💡 Thoughts & Suggestions

• Consider documenting a general pattern for agent workflows that might interact with config files: for example, always summarizing configuration at a high level and never emitting raw secret-bearing JSON. That will make it easier to safely reuse this pattern for other agents later.
• You might also introduce a small utility that handles reading config and redacting secrets in one place, so future agent definitions can lean on a vetted, centralized implementation rather than each one deciding how to treat sensitive fields.

---

🤖 Generated by Qoder • View workflow run

[qoderai]

This step is currently designed to read ~/.qoder.json and include the full JSON contents in the agent's summary. In typical setups that file contains secrets such as access tokens and other sensitive configuration, so having the agent dump it verbatim into its output will effectively exfiltrate those secrets into logs and transcripts whenever the agent runs. To keep the review agent safe to use, we should either avoid reading this config file entirely or strictly limit and redact what gets surfaced (for example, summarizing non-sensitive flags only and masking any token- or password-like fields).

---

🤖 Generated by Qoder • Fix in Qoder