felladrin/MiniSearch

Problem Two server files have 0% test coverage: File Lines Coverage server/config/modelConfig.ts 12-27 0% server/rerankerServiceHook.ts 11-25 0% These files are small but untested, which means: Bugs in model configuration could go unnoticed The reranker service hook (which manages model lifecycle) has no test safety net Refactoring these files is risky Why It Matters modelConfig.ts: Configures which models are available and their parameters. A bug here could break AI inference for all users. rerankerServiceHook.ts: Manages the ONNX runtime session for result reranking. A bug here could degrade search quality or crash the server. 0% coverage: These files are below the (already low) 31% line coverage threshold, but the threshold is per-project, not per-file. Proposed Tests server/config/modelConfig.ts Test that the default model configuration is valid Test that model parameters are within expected ranges Test that environment variable overrides work correctly Test that i

Problem The docs/quick-start.md tells contributors to access the app at port 7861 (HMR) first: Access the application at http://localhost:7861 (HMR) or http://localhost:7860 (main) This is confusing because: Port 7860 is the main application port (both dev and production) Port 7861 is the HMR (Hot Module Replacement) port, which is a development convenience, not the main app Newcomers might think 7861 is the primary port and get confused when it doesn't work in production Why It Matters New contributors waste time figuring out which port to use The documentation implies 7861 is the primary dev port, which is misleading Production users might try 7861 and get a connection error Proposed Fix Reorder the ports in docs/quick-start.md to list 7860 first: Access the application at http://localhost:7860 (main). During development, HMR is available on http://localhost:7861 for instant code changes. Or clarify the distinction: Development: Access the application at http://localhost:786

Problem The CONTRIBUTING.md references "good first issue" labels: Not sure where to start? Browse issues labeled "good first issue". However, the label may not be applied consistently to issues that are actually suitable for first-time contributors. Why It Matters First-time contributors rely on this label to find approachable issues Issues without the label that are actually good for newcomers get overlooked The label signals that the issue is well-scoped, documented, and mentored What Makes a Good First Issue Well-scoped: Can be completed in a few hours, not days Well-documented: The issue description explains what to do and how to verify Low risk: Doesn't touch core security or complex logic Mentored: A maintainer is available to answer questions Independent: Doesn't depend on other unresolved issues Proposed Action Review all open issues and apply the good first issue label to appropriate ones Consider labeling issues like: Documentation fixes (typos, outdated info, missing

Problem There is no automation for managing stale issues and pull requests. Over time, this leads to: Issues that are no longer relevant or reproducible PRs that have gone out of sync with main A backlog that's harder to triage Current State No stale label exists No automated comments or closures All issue/PR lifecycle management is manual Proposed Solution Add a GitHub Action that: Labels stale issues/PRs after 60 days of inactivity Comments on stale issues/PRs asking for updates Closes stale issues after 90 days of inactivity Never auto-closes PRs (only labels and comments) Respects labels: Skip issues/PRs labeled good first issue, security, or pinned Recommended Action Use the official actions/stale@v9 action: # .github/workflows/stale.yml name: Stale on: schedule: - cron: '30 1 * * *' workflow_dispatch: jobs: stale: runs-on: ubuntu-latest permissions: issues: write pull-requests: write steps: - uses: actions/stale@v9 with:

Problem The coverage thresholds in vitest.config.ts are set much lower than the actual coverage: Metric Threshold Actual Lines 31% 64.14% Functions 24% 56.12% Statements (none) 63.76% Branches (none) 54.93% These low thresholds mean the coverage gate isn't enforcing anything meaningful. A PR that reduces coverage by 20 percentage points would still pass. Current Config // vitest.config.ts coverage: { thresholds: { lines: 31, functions: 24, }, }, Proposed Fix Increase the thresholds to match (or slightly exceed) the current actual coverage: coverage: { thresholds: { lines: 60, functions: 50, statements: 60, branches: 50, }, }, This creates a safety margin so minor coverage fluctuations don't break CI, while still catching significant regressions. Files to Change vitest.config.ts (lines 31-32) Acceptance Criteria Thresholds are updated in vitest.config.ts npm run test:coverage passes with the new thresholds CI passes (Optional) Add a CI