Files
nucleic-purpose-classifier/data/opus-21.jsonl
T
2026-07-29 23:45:26 -07:00

129 lines
30 KiB
JSON

{"prompt": "- laravel 8, php 8.0, 220k lines\n- no tests to speak of (37 of them, 12 fail)\n- half the business logic is in blade templates\n- upgrading to 11 is blocked on three abandoned packages\n\ni need a plan. what order, what we can do incrementally, and what we absolutely have to freeze while it happens", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "pull the order calculation out of the blade template into a service class, same rendered totals for every fixture we have", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "could you replace the abandoned mailer package with laravel's own mail, keeping the same templates and headers", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the app is running with APP_DEBUG=true in production", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "requests to the reports page take 30s and the query log shows 4000 queries", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "would you read through app/Http/Controllers/OrderController.php and tell me what it actually does? it's 1800 lines and i've been asked to change it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "write the architecture-as-it-is doc for this codebase — the real request flow, where business logic lives, and the landmines", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "characterization tests around the order calculation before we touch it, capturing current behavior including the weird cases", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the admin panel's tables are unusable on anything narrower than 1400px", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "our models have 40 accessors that hit the database, so a list page does n+1 by design. eager load properly, identical rendered pages", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plan the strangler approach for extracting the checkout out of the monolith into a service, with both live during the transition", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the session driver is `file` on three load balanced servers with no shared storage", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "bun: edge function that validates a jwt, looks up the tenant from kv, and proxies to the right regional origin, all under 20ms", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the edge function's kv reads aren't cached so every request pays 30ms", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "edge functions work locally and fail in production with a module resolution error that mentions node built-ins", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our shared validation library imports node:crypto which doesn't exist at the edge. make it runtime-agnostic, same validation results", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "map out what belongs at the edge versus the origin for us — auth, rate limits, a/b assignment, personalization — with the tradeoffs", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "explain how our edge function handles a cold start and what the p99 looks like as a result", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "docs for our edge middleware — what headers it sets, what it reads, and the order it runs relative to the cdn cache", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "a/b assignment at the edge with a stable cookie, and the variant exposed as a header the origin can vary on", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "edge ml: run the defect classifier on the device, int8 quantized, under 40ms on the coral tpu, with a fallback to cloud when confidence is low", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the quantized model's accuracy dropped from 0.94 to 0.71 and i don't know which layer is the problem", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the confidence threshold for cloud fallback is 0.5, way too low", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "inspection ui on the device's touchscreen: live camera, the detection overlay, pass/fail with a big obvious result, and a manual override", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "sounds good, go", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "here's the report from the factory floor, pasting verbatim:\n\n\"Line 3, second shift. The inspection station started passing parts it should reject at\naround 22:00. Operators noticed at 23:40 and switched to manual. About 4,000 parts went\nthrough in that window, we've quarantined them all.\n\nThe screen showed 'PASS' with a confidence of 0.99 on everything including an obviously\ncracked part we tested deliberately. Rebooting the station fixed it.\n\nThe station log around that time:\n 22:01:14 camera: frame timeout, retrying\n 22:01:14 camera: frame timeout, retrying\n 22:01:15 camera: reinitialized\n 22:01:15 infer: result=PASS conf=0.9987\n 22:01:16 infer: result=PASS conf=0.9987\n (repeats identically every ~1s for 98 minutes)\"\n\nidentical confidence to four decimal places for 98 minutes", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "detect a stuck camera — frame hash comparison and a timestamp check — and fail the station closed rather than passing everything", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the station has no watchdog on the inference loop at all", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "review every failure mode in the inspection station and tell me which ones fail open", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "write the incident report for the factory quality team, and the operator-facing note about what the new failure behavior looks like", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plan the station's health monitoring — what we report to the central system, the heartbeat, and the alerts that would have caught this in 60 seconds", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "station status dashboard for the plant: stations as tiles, throughput, reject rate, and a stale-data indicator per station", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the reject rate tile shows a percentage of nothing when a station is idle", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "our station code has the camera handling, inference and the ui in one 2000 line python file with globals. separate them behind interfaces, identical behavior on the test rig", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "model deployment to the stations: signed model bundles, staged rollout by line, and an automatic rollback if the reject rate shifts", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the model version isn't recorded with each inspection result so we can't tell which model passed a part", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "explain how a station decides it has the right model version, and what happens if the download is interrupted", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "documentation for the model bundle format and the deployment protocol, for whoever maintains this after me", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "one line's stations disagree on the same part by about 8% of the time, same model version", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "plan the labeling pipeline — how operators flag a misclassification, how it gets into the training set, and how we avoid poisoning it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "operator feedback capture: a 'this was wrong' button that saves the frame, the prediction and the operator's verdict", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "labeling review tool: the flagged frames in a grid, the model's prediction, and a confirm/reject with keyboard shortcuts for speed", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "flagged frames upload at full resolution over the plant's saturated uplink", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "plan the retraining loop then implement the dataset assembly step", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "work out why the stations disagree and then write it up for the quality report", "purpose": "debugging", "secondary": "writing", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "next task", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "i need the plan for distributed training. we're at the point where a run takes 30 hours on one 8xA100 node and we have four nodes available. data parallel with fsdp probably, but our dataloader is the bottleneck already at one node and i don't know what breaks at four. include the checkpointing and how we resume a failed run", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "fsdp setup for the training script, activation checkpointing on the transformer blocks, and mixed precision with a loss scaler that doesn't blow up", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "training run dashboard: loss curves per run, gpu utilization, throughput, and a compare-runs mode", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the learning rate in the config is 3e-4 but the code multiplies by world size, so it's 12e-4 on 4 gpus and nobody realized", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "our dataloader, the eval loader and the inference preprocessing each implement tokenization slightly differently. one path, and confirm the token ids match on a sample", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "training hangs at the start of epoch 2 on multi-node, single node is fine, and the nccl logs just stop", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "read our checkpointing and tell me whether a resumed run is genuinely equivalent to an uninterrupted one, including the dataloader state", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "write the training infrastructure doc: launching a run, the config layout, checkpoint conventions, and how to debug a hang", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "sharded dataloader that gives each rank a distinct slice, resumable mid-epoch, with no sample seen twice per epoch", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "gpu utilization is 45% and the trace shows the gpus waiting on the host", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the number of dataloader workers is 2", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "plan the experiment tracking — what we log, how we name runs, and how someone finds the run that produced a deployed model six months later", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "run comparison view: hyperparameters diffed, metric curves overlaid, and the git sha per run", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "explain how we currently determine which code produced a checkpoint, because i suspect the answer is 'we don't'", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "model card template for our internal models: data, training setup, eval results, known failure modes, and the intended use", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "our three training entrypoints share 80% of their setup with divergent argument names. one entrypoint with subcommands, same runs reproducible from the old configs", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "eval harness that runs the standard suite on a checkpoint and writes results next to it, comparable across runs", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "eval numbers differ by 0.3% between runs on the same checkpoint", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "分散学習のジョブが 4 ノードで止まる。まず原因の切り分け方針を教えてほしい", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "ja"}
{"prompt": "sveltekit: the dashboard needs streamed data so the shell renders instantly and the slow widgets fill in", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our load functions fetch overlapping data so a page hits the api 6 times. consolidate, same data available to the same components", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "hydration mismatch warning on the dashboard, only in production builds", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the loading spinner is centered in the viewport rather than in the widget", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "plan the migration from our stores-everywhere state to runes, incrementally, without a big bang rewrite", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "moving on then", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "so the php monolith's database is the real problem. 340 tables, no foreign keys anywhere (they were 'too slow' in 2016), enum columns with values the app doesn't know about, and three tables with a `data` blob holding json that different parts of the app parse differently. i want a plan to get to something sane that doesn't require stopping feature work for a year", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "add the missing foreign keys, one table at a time, with a script that finds and reports orphan rows first", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the orphan check script takes 40 minutes because it's doing a query per row", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "three parts of the app parse the `settings.data` json blob with different assumptions about missing keys. one accessor with explicit defaults, same effective settings for every existing row", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "some rows in the orders table reference customers that don't exist and the app renders 'Unknown' for them", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "read the schema and tell me which tables are actually unused, based on the code not the row counts", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "write the data dictionary for the 40 tables that matter, with what each column really means including the enum values that aren't in the code", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "database health page for us internally: table sizes, index usage, and the tables with no primary key", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "the app's migration table and the actual schema have diverged, 12 migrations recorded as run that clearly weren't", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plan how we introduce a repository layer so the 400 places doing raw queries can be migrated gradually", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the db user the app connects as is root", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "explain how the app handles a query failure today — i've seen empty arrays returned where an exception should be", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "query timeout and error handling at the connection level so a db failure surfaces as an error not silently empty data", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our error pages show the sql query and the stack trace to end users on 500s", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "error page design: friendly message, a reference code, and a report-this action, no internals", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "plan the test strategy for a codebase with no tests — what we cover first, characterization vs unit, and a coverage target that isn't a lie", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "review the 12 failing tests and tell me which are testing broken behavior vs broken tests", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "testing guide for this codebase, given the constraints — how to test something that touches 6 globals", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "eso, adelante", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "es"}
{"prompt": "would you propose how we handle real-time collaboration presence at our scale? 40k concurrent users, most in rooms of 2-5 but a few in rooms of 500. currently one redis pubsub channel per room and the big rooms are melting a node. i want options with the tradeoffs and a recommendation", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "presence with batched broadcasts — coalesce updates into 200ms windows per room, and a different strategy above 50 participants", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "presence avatars with a +N overflow, and it shouldn't reflow the toolbar when people join and leave constantly", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "presence heartbeat is every 2 seconds per client, make it 15", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "we track presence in redis and also in an in-memory map per node, and they disagree after a node restart. one source of truth", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "one node's memory climbs steadily and only that node, and it's always the one that's been up longest", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "explain the fan-out cost of a presence update in a 500 person room as the code stands", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "capacity planning doc for the realtime layer: connections per node, memory per connection, and the limits we've measured", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "connection limits per node with graceful rejection and a client that retries against a different node", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "clients rejected for capacity retry against the same node forever", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "realtime connection health widget for internal use: connections per node, message rates, and rooms over 100 participants", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the connection count metric is a gauge that only ever goes up", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "plan how we roll out a realtime deploy without disconnecting everyone at once", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "check what our client does on an unexpected disconnect — reconnect backoff, state resync, and whether it can thundering-herd us", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "client reconnection guidance for our sdk consumers: the backoff we expect, resuming state, and what we guarantee about missed events", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "graceful drain on deploy: stop accepting new connections, tell existing clients to reconnect elsewhere, then exit", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our reconnect logic is implemented separately in the web client, the ios sdk and the android sdk, with different backoff. one specified behavior, implemented consistently", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "after a deploy the reconnect storm takes 4 minutes to settle and error rates spike", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "sure, next", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "pasting the profiler output from the laravel app because i genuinely cannot see what's slow:\n\nRequest: GET /admin/orders?status=pending (14.2s)\n\n Database (4,118 queries, 11.8s)\n SELECT * FROM orders WHERE status = ? 1 x 82ms\n SELECT * FROM customers WHERE id = ? 412 x 2.1s\n SELECT * FROM order_items WHERE order_id = ? 412 x 2.4s\n SELECT * FROM products WHERE id = ? 2,180 x 4.9s\n SELECT * FROM addresses WHERE customer_id = ? 412 x 1.4s\n SELECT setting_value FROM settings WHERE key = ? 701 x 0.9s\n\n Views (1.9s)\n orders.index 1.9s\n\n Memory peak: 412 MB\n\n701 queries for settings on one page is what's really bothering me", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
{"prompt": "settings should be loaded once per request and cached, not queried per access", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "eager load the order page's relations properly and paginate it, same rendered rows", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "query count assertions in our tests for the five heaviest pages, so an n+1 fails CI", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the admin orders page loads all orders regardless of the pagination param", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "orders list ui with server-side pagination, a status filter, and a total count that isn't a full table scan", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "review the other admin pages for the same settings-per-access pattern", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "performance notes for the codebase: the settings gotcha, the eager loading conventions, and how to check query counts locally", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "plan the caching layer for the monolith — what's cacheable, where the invalidation hooks go, and how we avoid the stale-settings class of bug", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "settings cache invalidation on write, across all app servers, with a version key rather than a broadcast", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "settings changes take up to 10 minutes to appear on some servers", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "settings admin page grouped by area with a search, and a note saying when changes take effect", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "the settings page saves each field with its own request as you tab through", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "explain what happens if two admins edit different settings at the same time, given how the form submits", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "internal doc listing every setting, its effect, its default, and whether changing it is safe at peak", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "our settings access happens through a global helper, a facade and direct queries. one accessor, same values returned", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plan the php 8.4 upgrade then start on the deprecation fixes", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "explain the settings loading path then document it in the readme", "purpose": "review", "secondary": "writing", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "that'll do, just the small bit", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}