[Feature] Extended long-context coding benchmark: port JellySearch (.NET) to Go

[Izzetee]

Summary

Add a new extended, long-context coding benchmark task that asks a model to analyse a real
.NET/C# application (JellySearch) and produce a complete, phased plan to port it to Go — standard-library-first,
behaviour-compatible, and test-driven (TDD red → green). Scored by the LLM judge with criteria oriented on the
existing coding tasks.

Problem / Motivation

Our current coding benchmark tasks are all small, single-function, single-file problems (prime check, LRU
cache, B-tree, etc.). They measure code generation on short prompts but tell us nothing about a model's ability to
handle a large, real-world engineering task: reading and understanding an existing codebase, preserving
compatibility during a cross-language port, choosing an idiomatic standard-library-first design, planning the work in
phases, and driving each unit of functionality with tests first.

Since PiPiMink routes prompts to the best model per request, we specifically want a signal for long-context
software-engineering / architecture-porting ability, which today no benchmark task covers. This differentiates
models that are strong at "leetcode-sized" snippets from models that can actually plan and structure a migration.

Proposed Solution

Add one new task to the compiled-in registry in
internal/benchmark/task.go inside buildTasks(), under the existing
CategoryCoding category, using ScoringLLMJudge. It is automatically seeded to the DB via
DefaultTaskConfigs() and surfaced in the admin benchmark-task UI — no schema or API changes required.

• Task ID: coding-hard-port-jellysearch-dotnet-to-go
• Category: coding
• Scoring method: llm-judge (final score = average of the criteria below, matching existing behaviour)

The prompt embeds a faithful SOURCE PROJECT BRIEF so the model under test can reason without web access (this is
what makes it a long-context task). It then gives the porting instructions.

Proposed prompt (English, verbatim — to be embedded as the task Prompt)

You are given the description of an existing open-source application, JellySearch, written in C#/.NET. Your job is to
produce a complete engineering plan to PORT it to Go. Do not write the full implementation — produce the design and
plan documents described at the end.

=== SOURCE PROJECT BRIEF: JellySearch ===
JellySearch is a fast full-text search proxy for the Jellyfin media server. It sits behind the same reverse proxy as
Jellyfin. The reverse proxy is configured to forward any request whose query string contains the parameter
`searchTerm` (case-insensitive) to JellySearch instead of Jellyfin.

Behaviour:
- It keeps a separate search index of the Jellyfin library inside Meilisearch.
- It keeps that index in sync with Jellyfin by reading Jellyfin's SQLite database directly (read-only) from the mounted
  Jellyfin config directory, on a cron schedule.
- When a search request arrives, JellySearch parses the query (e.g. `searchTerm`, paging, and filter parameters used by
  Jellyfin clients), queries Meilisearch for matching item IDs, then forwards/rewrites the request to the real Jellyfin
  server so that Jellyfin returns fully-formed items for those IDs. The Meilisearch results drive ordering and
  typo-tolerance; Jellyfin still renders the final response the client expects.
- Requests to `/Genres` are passed straight through to Jellyfin (genre search is not handled by the index).
- It listens on port 5000.

Current tech stack (to be replaced):
- ASP.NET (HTTP server / request handling) on .NET 8.
- Quartz.NET for the cron-scheduled reindex job (schedule given by the INDEX_CRON Quartz cron expression).
- The official Meilisearch .NET SDK for indexing and querying.
- Direct read of the Jellyfin SQLite database (library.db / the Jellyfin data db).

Configuration (environment variables, MUST be preserved):
- JELLYFIN_URL         full URL of the Jellyfin instance (default http://jellyfin:8096) — required
- JELLYFIN_CONFIG_DIR  directory where the Jellyfin config folder is mounted (default /config) — required
- MEILI_URL            URL of the Meilisearch instance (default http://meilisearch:7700) — required
- MEILI_MASTER_KEY     auth key shared with Meilisearch — required
- INDEX_CRON           cron schedule for reindexing; if unset, no automatic reindex — optional
Runtime facts to preserve: listens on port 5000; needs only read access to the Jellyfin DB; ships as a Docker image.
Known caveat in the original: search results are NOT filtered by per-user permissions.
=== END BRIEF ===

PORTING REQUIREMENTS
1. The Go port must be behaviour- and interface-compatible with the current implementation: same environment
   variables and defaults, same listening port (5000), same search-forwarding contract (intercept `searchTerm`
   case-insensitively, pass `/Genres` through), the same Meilisearch index/document shape, and read-only access to the
   Jellyfin database.
2. Implement as much as possible using ONLY the Go standard library. Justify every third-party dependency you cannot
   avoid (for example a SQLite driver, or a Meilisearch client) and prefer the smallest, most idiomatic option; note
   where net/http, net/http/httputil, database/sql, encoding/json, context, and the time package replace the .NET
   components.
3. For every unit of functionality, plan the tests FIRST using TDD: describe the failing test (red phase) and then the
   minimal implementation that makes it pass (green phase). Specify concrete, representative test cases and the test
   doubles/fakes you would use (e.g. httptest servers for Jellyfin and Meilisearch, a temporary SQLite fixture DB).
4. Produce a plan with as many phases as are actually needed. Each phase must have a clear scope, its dependencies on
   earlier phases, and its deliverables, and each phase must be independently testable.
5. Make sensible assumptions where the brief is incomplete (e.g. the exact Jellyfin DB schema, Meilisearch version and
   index settings, which query/filter parameters clients send, non-goals). Collect ALL assumptions into a single
   clearly-labelled "Assumptions Overview" suitable for a final review of the design documents before implementation
   starts.

DELIVERABLES (produce these, in this order):
A. Source analysis — a concise breakdown of JellySearch's components and data/request flow, and how each maps to Go.
B. Target architecture — Go package/module layout, the standard-library-first mapping, and any justified dependencies.
C. Phased porting plan — the ordered phases with scope, dependencies, deliverables, and the TDD test cases (red→green)
   for each phase.
D. Assumptions Overview — the consolidated, reviewable list of assumptions and open questions.

Proposed LLM judge criteria (oriented on existing coding tasks)

Each criterion is scored 0–10 independently; the final task score is their average (same as all other llm-judge
tasks).

#	Name	Description
1	Source Analysis	Accurately identifies JellySearch's components and request/data flow: the Meilisearch index kept in sync with Jellyfin's SQLite DB, cron-scheduled reindexing (INDEX_CRON), and the search proxy on port 5000 that intercepts searchTerm, queries Meilisearch, and forwards matched items to Jellyfin. Recognises the .NET stack being replaced (ASP.NET, Quartz.NET, Meilisearch .NET SDK, direct SQLite read).
2	Compatibility Preservation	The plan explicitly preserves behaviour and interfaces: identical environment variables and defaults (JELLYFIN_URL, JELLYFIN_CONFIG_DIR, MEILI_URL, MEILI_MASTER_KEY, INDEX_CRON), port 5000, the case-insensitive searchTerm interception with /Genres passthrough, the same Meilisearch index/document shape, and read-only DB access.
3	Standard-Library-First Design	Maps .NET components to Go standard-library equivalents (net/http and net/http/httputil for serving and forwarding, database/sql for the SQLite read, context/time for scheduling, encoding/json). Third-party dependencies are minimised and each one that remains (e.g. a SQLite driver or Meilisearch client) is explicitly justified.
4	TDD Test Strategy	For each unit of functionality, tests are planned first (red) then implementation (green). Specifies concrete, representative test cases (config parsing, cron parsing, DB reader, indexer sync, query mapping, search-proxy forwarding) and appropriate test doubles (httptest servers for Jellyfin/Meilisearch, a temporary SQLite fixture); favours table-driven Go tests. The red→green cycle is explicit per feature.
5	Phased Plan Quality	Breaks the port into a logical, ordered set of phases (as many as needed) — e.g. scaffolding, config, DB reader, Meilisearch indexer, scheduler, search handler/proxy, integration, Docker/packaging — each with clear scope, dependencies, deliverables, and independent testability.
6	Assumptions & Design Review	Provides an explicit, well-reasoned "Assumptions Overview" covering the unknowns (Jellyfin DB schema, Meilisearch version/settings, client query parameters, edge cases, non-goals). Assumptions are clearly labelled as assumptions, sensible, and actionable for a final design review.

Why this shape

• Reuses the existing Task / JudgeCriterion model and ScoringLLMJudge path — no code changes outside
  buildTasks().
• Long embedded brief exercises long-context comprehension; the deliverables exercise planning, compatibility
  reasoning, stdlib fluency, and TDD discipline — none of which the current short tasks measure.
• Judge criteria mirror the naming/description style already used by the C#/Go/Rust/Java/TypeScript coding tasks
  (Correctness/Idioms/Edge cases/Quality → here specialised to a porting task).

Alternatives Considered

• A new dedicated category (e.g. coding-architecture / long-context-coding): heavier change (touches
  AllCategories(), UI category lists, docs). Keeping it under coding is the smallest useful change; a category can
  follow later if we add more long-context tasks.
• Requiring the model to emit full runnable Go code: not deterministically judgeable at this size and would blow
  past output limits; the "produce the design + phased TDD plan" framing is judgeable and still discriminates strongly.
• Multiple smaller porting sub-tasks: loses the long-context signal that is the whole point.

Additional Context

• Source project: https://gitlab.com/DomiStyle/jellysearch (MIT). The brief above is a faithful summary of its
  README/behaviour; the benchmark is self-contained and needs no network access at run time.
• Touch points: internal/benchmark/task.go (buildTasks()), seeded via
  DefaultTaskConfigs(); judged by internal/benchmark/scorer.go.
• Follow-up docs to update on implementation: CHANGELOG.md and any benchmark task list in README.md.

Acceptance criteria

• Task coding-hard-port-jellysearch-dotnet-to-go registered under CategoryCoding with ScoringLLMJudge and the 6 criteria above.
• Prompt embedded verbatim (long-context brief + porting requirements + deliverables).
• Seeded into the DB on first run and visible/toggleable in the admin benchmark-task UI.
• A unit test asserts the task exists, is in the coding category, uses llm-judge, and has ≥ 6 judge criteria.
• CHANGELOG.md updated under Unreleased.