201 lines
82 KiB
JSON
201 lines
82 KiB
JSON
{"prompt": "the cache key logic is spread across the config parser, the request handler and a per-customer override table:\n\n// config/parse.rs — builds a CacheKeySpec from the customer's yaml\n// handler/key.rs — builds the actual key, ignoring two fields of the spec\n// overrides.rs — a per-customer hashmap applied after the key is built, in production only\n\nthe overrides table has 41 entries, four of which contradict the customer's own config, and nobody knows who added them or why", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "our cache key configuration, which one customer's Vary header just multiplied by every user agent on the internet:\n\ncache_key:\n include: [scheme, host, path, query]\n vary: from_origin # we honour whatever the origin sends\n ignore_query_params: [utm_source, utm_medium, fbclid]\n normalize_accept_encoding: true\n\nthere is no cap on the number of variants per key, no warning when a Vary header would explode the key space, and a customer can do this with a one-line change on their side at any time\n\nwhat the key space did over the incident:\n distinct cache keys for /assets/app.js, before: 3\n after: 41,882 and climbing\n cache fill rate: 1.2 GB/min\n evictions: 8,400/s (previously ~0)\n\nand the customer's diff, in full:\n - Vary: Accept-Encoding\n + Vary: Accept-Encoding, User-Agent", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "field app deletes a queued photo when an upload returns any 4xx, which is how a customer lost the photographic evidence behind a variation claim. beyond the immediate fix, i want a position on what our offline guarantees actually are — what we promise never to lose, what the user is shown, and how we prove it after the fact — because the enterprise contract signing in november asks for exactly that", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
|
|
{"prompt": "a customer whose payments API was unresolvable for two hours wants to know how an automated key roll can take a zone off the internet. write the incident report for their architecture team — the overlap arithmetic, why nothing caught it, and what changes — without retreating into DNSSEC jargon they'll have to look up whatever you find, write it somewhere the next person will actually look.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
|
|
{"prompt": "the data team's list, with the recommender incident fresh:\n\n- output validation on the nightly job: row counts, distribution checks, comparison against yesterday\n- stop overwriting the table, write to a new partition and swap\n- the (user_id, context_id) grouping needs a different shape entirely, it doesn't fit in memory\n- the licensing filter should be somewhere legal can read it rather than inline in a 900-line object\n- adaptive query execution is off because someone turned it off in 2023\n- run time has crept from 70 minutes to three hours and nobody owns that\n\nthree engineers, and the nightly job feeds the 06:00 home screen", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "one anycast POP answers queries with the wrong zone data for about ninety seconds after each deploy:\n\n2026-07-29T11:02:14Z pop=fra1 zone=example.com serial=2026072901 source=cache age=0\n2026-07-29T11:02:14Z pop=fra1 zone=example.com serial=2026072814 source=disk age=86400\n2026-07-29T11:02:15Z pop=fra1 answered A example.com -> 203.0.113.9 (old target)\n2026-07-29T11:03:44Z pop=fra1 zone=example.com serial=2026072901 source=xfr age=0\n2026-07-29T11:03:45Z pop=fra1 answered A example.com -> 198.51.100.4 (correct)\n\nthe process starts serving from the on-disk snapshot before the zone transfer completes, and the snapshot can be a day old", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "edge cache hit rate collapsed for one customer overnight with no config change on our side:\n\n before: hit 94.1%, origin rps 1,204\n after: hit 41.2%, origin rps 18,882\n\nsample request/response:\n GET /assets/app.js\n Cache-Control: public, max-age=31536000\n Vary: Accept-Encoding, User-Agent\n ETag: W/\"a11c3f2-8814\"\n\nthe customer added User-Agent to Vary in a deploy yesterday, which multiplies cache entries by every UA string we see", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "our edge configuration API, which customers automate against from a README and a support engineer's memory:\n\nPUT /v1/zones/{zone}/config\n body: cache rules, origin settings, header transforms, WAF toggles\n applies globally within about 90 seconds, but a POP that restarts during that window may serve the previous config for its startup period\n a config that fails validation on one POP is still applied on the others; there is no atomic rollout\n the response is 202 with a deployment id, and GET on it reports \"complete\" once the last POP acknowledges — which is not the same as the config being live\n rate limited to 10 changes per zone per hour, undocumented, and returns 429 with no retry-after\n\nwrite the reference documentation, including the honest description of what \"complete\" means", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "field app's offline behaviour is described in the sales deck as \"works fully offline\" and the reality is three queues with three failure modes and no visibility. write the honest documentation for site staff and their IT departments, covering what is queued, what happens when an upload is rejected, and what conflicts do to their data", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "a customer's architecture review asked five questions about POP health, config rollback, transfer authentication, key rollover approval and self-service recovery. answer each from the code and the runbooks, and mark clearly the ones where the honest answer is that a human notices rather than a mechanism catching it context if it helps: this has been open since before i joined the team.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "zone view should sort by staleness", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
|
|
{"prompt": "nightly job again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "one definition of downloaded", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "edge configuration API is automated against by customers who discovered its behaviour by experiment, including the undocumented rate limit and the fact that \"deployment complete\" doesn't mean the config is live everywhere. write the reference documentation, with those two stated plainly rather than left to be discovered again i'm not attached to the current approach if there's an obviously better one.", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "before this goes to production, is the sync conflict handling defensible?\n\nFuture<void> sync() async {\n final local = await db.dirtyTasks();\n for (final t in local) {\n final remote = await api.getTask(t.id);\n if (remote == null) { await api.createTask(t); continue; }\n if (t.updatedAt.isAfter(remote.updatedAt)) {\n await api.updateTask(t); // whole record\n } else {\n await db.replaceTask(remote); // discards local edits silently\n }\n }\n}\n\nupdatedAt comes from the device clock, tablets on site are routinely minutes out, and a task record includes a free-text notes field several people edit", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "three parts of the app decide what \"downloaded\" means and they disagree:\n\n// LibraryView.swift\nlet isDownloaded = FileManager.default.fileExists(atPath: track.localURL.path)\n\n// DownloadManager.swift\nfunc isDownloaded(_ t: Track) -> Bool { store.state(for: t.id) == .complete }\n\n// SyncService.swift\nlet downloaded = try db.query(\"SELECT 1 FROM downloads WHERE track_id = ? AND expires_at > ?\", t.id, now)\n\nthe file can exist while the download record says failed, the record can say complete after the file was evicted by the OS, and the expiry is only checked in one of the three", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "cache key logic in one place", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "what makes a zone \"current\"?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "is our idempotency key store fail-open?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "POP answers queries from a disk snapshot that can be a day old, and the health probe considers it healthy the moment it answers anything. work through what readiness should mean for us — zone currency, per-zone or per-POP, and what we do about zones that are never current by any strict definition — knowing the load balancer's probe is a TCP check we don't control", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
|
|
{"prompt": "recommender is one nine-hundred-line object that legal has to read for the licensing filter and the data team has to change weekly for everything else. before splitting it i'd like agreement on the boundaries and on what evidence we need that the split changed no recommendations, given the output is inherently noisy this is the third time it's bitten us and i'd like it to be the last.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "nobody can tell me whether our idempotency store is fail-open, and the daily report duplication suggests it is. read the key store, the failover behaviour and the handler together, and tell me what happens to a request whose key lookup returns nil during a redis failover rather than an error i'd rather have the reasoning written down than a quick answer.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
|
|
{"prompt": "i'd like an honest read on whether our shuffle can be fixed without changing what users think shuffle means, and then the implementation — a proper shuffled order per session with skips remembered", "purpose": "review", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "nightly recommender wrote half the usual rows and reported success, and the table it overwrites is the one the home screen reads at six in the morning. i want the validation story designed — what checks, where they run, what happens when one fails at four in the morning — rather than someone adding a row count assert and calling it done", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
|
|
{"prompt": "zone timeline needs serial changes, transfers and config applies on one axis", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
|
|
{"prompt": "recommendations went stale for a third of users and the pipeline says it succeeded:\n\n25/07/29 02:14:02 INFO DAGScheduler: Job 41 finished: saveAsTable at Recommender.scala:212, took 4118.882 s\n25/07/29 02:14:02 WARN TaskSetManager: Lost task 88 in stage 12.0: FetchFailed(BlockManagerId(41, ip-10-4-2-71), shuffleId=3)\n25/07/29 02:14:02 INFO DAGScheduler: Resubmitting stage 12 (retry 1)\n25/07/29 03:22:11 INFO DAGScheduler: Job 42 finished: saveAsTable, took 4088.114 s\n25/07/29 03:22:12 INFO Recommender: wrote 41,882,004 rows to recs.user_daily\n\nyesterday's run wrote 62 million rows; the table is overwritten, not appended, and the job exits zero either way", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "site photos taken offline disappear when the app comes back online, maybe one in fifty:\n\n[sync] 08:12:04 queued photo p_4471 (site 88, task 412) 4.1MB\n[sync] 08:12:04 queued photo p_4472 (site 88, task 412) 3.8MB\n[sync] 11:44:19 connectivity restored, draining queue (2 items)\n[sync] 11:44:20 uploading p_4471... 201 created\n[sync] 11:44:21 uploading p_4472... 413 payload too large\n[sync] 11:44:21 removing p_4472 from queue (non-retryable)\n[sync] 11:44:21 queue empty\n\nthe 413 comes from a gateway limit of 4MB that nobody documented, and non-retryable means we delete the local file", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "DNSSEC validation started failing for one zone and only from some resolvers:\n\ndig +dnssec example.com @8.8.8.8 → SERVFAIL\ndig +dnssec example.com @1.1.1.1 → SERVFAIL\ndig +dnssec example.com @our-pop-fra1 → NOERROR, AD not set\n\nzone signing:\n ZSK rolled 2026-07-28T02:00Z (prepublish, 24h overlap configured)\n DS record at the parent: still the pre-roll KSK digest\n RRSIG expiry on the SOA: 2026-07-29T02:00Z\n\nthe overlap was configured as 24 hours and the roll happened 26 hours before the old signatures expired", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "changelog for the mobile app release, which our users will read in the store listing:\n\n41c9e0b fix(shuffle): shuffle now plays every track before repeating\n88f21c0 fix(player): resuming from the lock screen keeps your position and track\nc0aa774 feat(offline): downloads survive an app update\n2e91b45 fix(sync): queued photos are no longer deleted when an upload is rejected\naa30f19 perf(library): library loads in under a second with 10,000 saved tracks\n9c1d004 chore: minimum iOS is now 17\n4410bb7 feat(player): crossfade between tracks, off by default\nb77e910 fix(a11y): the player controls are reachable with VoiceOver\n\nour readers are listeners, not engineers; two of these are the complaints we see most in reviews", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "unsere Offline-Warteschlange ist an drei Stellen implementiert:\n\n// TaskQueue.dart — eigene SQLite-Tabelle, FIFO, kein Retry-Limit\n// PhotoQueue.dart — Dateisystem plus JSON-Index, löscht bei 4xx\n// ReportQueue.dart — SharedPreferences, hält nur den letzten Bericht\n\ndrei Warteschlangen mit drei Fehlerbehandlungen, keine gemeinsame Sicht auf „was ist noch nicht gesendet\", und der Nutzer sieht keine davon\n\ngewünscht ist eine Warteschlange mit einheitlicher Semantik, ohne dass die App offline schlechter wird als heute\n\nZahlen aus dem letzten Monat:\n Aufgaben in der Warteschlange (Median pro Gerät): 14\n Fotos in der Warteschlange (Median pro Gerät): 31\n Berichte: 1 (nur der letzte wird gehalten)\n Einträge, die nach einem 4xx gelöscht wurden: 312\n Einträge, die der Nutzer je gesehen hat: 0\n\nund der relevante Code:\n\n if (e.statusCode >= 400 && e.statusCode < 500) {\n await _queue.remove(item);\n await File(item.path).delete();\n }", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
|
|
{"prompt": "design spec for the field app's sync status screen, which currently doesn't exist:\n\nSync status\n- A persistent indicator in the app bar: synced, syncing with a count, offline with a count, or attention needed.\n- The screen itself lists pending items grouped by type — tasks, photos, reports — with size and age.\n- An item that failed shows why in plain language and what the user can do, never a status code alone.\n- Photos that cannot be uploaded because of size offer to resize and retry rather than being discarded.\n- A conflict shows both versions side by side with the author and time of each, and requires an explicit choice.\n- Nothing is ever deleted from the queue without the user seeing it; \"discard\" is an action, not a consequence.\n- Must be usable in gloves, in sunlight, on a cracked screen, which is the actual condition of most site tablets.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "el botón de descarga no muestra progreso", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.25, "slice": "core", "lang": "es"}
|
|
{"prompt": "task list targets are 36dp outdoors", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
|
|
{"prompt": "track titles clip at large type", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "licensing filter out of the recommender", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "doc comments on the edge config API", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
|
|
{"prompt": "player screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "offline sync loses concurrent edits silently and a customer is threatening not to renew over it, which makes the conflict model a commercial question rather than a technical preference. lay out the options — server clocks, per-field versioning, a CRDT for the notes field — with the team's lack of CRDT experience and a full working day offline as the constraints", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
|
|
{"prompt": "we need a plan for POPs in regions where we cannot ship our own hardware", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "cache key configuration honours whatever Vary the origin sends with no cap on variants, which let one customer's one-line change multiply our key space by every user agent on the internet. read the key construction and the override table and tell me what other single-line customer changes could do something similar nobody has trusted this code for about a year, which is part of the problem.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "before we change the sync model i want the conflict semantics written down — what's a conflict, who wins, what the user sees, what we keep for the audit trail — and then the per-field versioning implemented against it, starting with the notes field that people actually fight over", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "POP readiness needs a definition and a first implementation. work through what \"current\" means per zone class with me, then wire a readiness endpoint the load balancer can use, keeping enough capacity during rolling deploys", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "three definitions of \"downloaded\" should become one, and i'd like to know which of the three the library screen should have been using before we standardise. check that against what users report, then unify", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "is the overwrite mode leaving the recs table empty while the job runs", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "what guarantees does the nightly job make about the table between the truncate and the write", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "recommender should write to a new partition and swap rather than overwriting in place", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
|
|
{"prompt": "nobody can tell me what happens to a queued daily report when the user logs out on site before it syncs — whether it survives, whether it uploads under the next user, or whether it quietly disappears. trace it through the queue, the auth layer and the local database, and tell me which of those three it actually is", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "i'd like to understand what our POP actually does with a query for a zone it has never successfully transferred — whether it serves the snapshot, refuses, or falls through to another POP — because the answer decides whether readiness is a real problem or a cosmetic one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "playlist shuffle repeats the same tracks far more than users expect, and they're right:\n\nsample of one user's session, 40-track playlist, shuffle on:\n positions played: 12, 4, 12, 31, 4, 12, 7, 31, 12\n distinct tracks in first 9 plays: 5\n\nour shuffle picks a random index per track with a seed derived from the playlist id and the day, and skips are not remembered, so pressing next re-rolls from the same seed and lands on the same handful", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "so the field app's task list shows different data to two users on the same site:\n\nuser A (foreman, online since 06:00): 41 tasks, last sync 11:02\nuser B (engineer, offline 07:00-11:30): 38 tasks, last sync 11:31\ntasks created by user A at 09:14 and 09:41 are missing for user B\ntask edited by user B offline at 10:02 overwrote user A's 09:41 edit on sync\n\nour sync is last-write-wins on the whole task record, using the device clock, and user B's tablet is 4 minutes fast", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "the enterprise construction customer's requirements, which arrived with a signing date:\n\n\"Field data captured offline must not be lost or silently overwritten under any circumstance, including device clock error and concurrent editing. The application must show the user what is pending upload. Data must be retained in the customer's region. Site photographs are contractual evidence and must be retained for six years with an audit trail of any modification. The supplier must demonstrate recovery from a device lost mid-project with no data loss beyond what was captured on that device since its last sync.\"\n\nwe currently fail four of those five. i want the plan by contractual exposure, not by engineering preference", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "our runbook for a stale-serving POP is \"restart it\", which is what caused the last incident. reality:\n\n- symptom is one POP answering with an old serial after a deploy or a restart\n- `edgectl zone status --pop fra1` shows the serial and the source (disk, xfr or cache)\n- draining the POP is safe and takes about 30 seconds to take effect at the load balancer\n- restarting it without draining first means it serves the disk snapshot again, which is the original problem\n- the disk snapshot is refreshed hourly, so a POP that has been down for a day has a day-old zone\n- forcing a transfer with `edgectl zone xfr --pop fra1` takes 60-120s for the large zones\n\nwrite the runbook, ordered by what someone paged would need first", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "field app has three offline queues with three storage mechanisms and three failure behaviours, only one of which retries. unify them behind one queue with one semantics, keep the app working offline for a full day exactly as it does now, and make sure a migration doesn't drop anything already queued on a device assume whoever picks it up next has no context beyond what you write.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
|
|
{"prompt": "a third of users got yesterday's recommendations and the job reported success, having written 41 million rows where the previous night wrote 62 million. work out how a partial write becomes a success before we add any checks, because the answer determines whether the fix is validation or the write path itself", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
|
|
{"prompt": "the label's delivery spec, which we ingest from:\n\ndaily DDEX feed over SFTP, one batch per label per day\n each batch is a zip of XML messages plus audio files, up to 40GB\n a message can update or withdraw a previously delivered release, referenced by its DDEX party and release id\n withdrawals must take effect within 24 hours, contractually, including removing tracks from playlists and recommendations\n territory rights are per track per territory with start and end dates, and can change retroactively\n a malformed message in a batch must not block the rest of the batch\n the label sends corrections as full re-deliveries, so idempotency is on (party, release_id, message_timestamp)\n\nbuild the ingestion; the withdrawal path is the one legal cares about", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "one offline queue, three item kinds", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "edge console is the thing we open during an incident and it currently shows a spinner when the control plane is unreachable, which is exactly when we need it. rebuild the zone view to the spec, rendering from cache with an age indicator, and make a POP on the wrong serial impossible to miss", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "our spark configuration versus the shape of the new grouping key:\n\nspark.sql.shuffle.partitions: 200\nspark.executor.memory: 16g\nspark.executor.cores: 4\nspark.executor.instances: 40\nspark.sql.autoBroadcastJoinThreshold: 10m\nspark.sql.adaptive.enabled: false\n\ndistinct (user_id): 41 million\ndistinct (user_id, context_id): 1.6 billion\noutput rows: about 200 per key, collected into a list before slicing\n\nand what the stage looked like when it failed:\n\n Stage 12: 200 tasks, 188 succeeded, 12 failed with OOM\n shuffle read per task: p50 412 MB, max 8.1 GB\n spill (memory): 2.4 TB total\n spill (disk): 1.1 TB total\n peak execution memory per task: 14.2 GB against a 16g executor\n\nthe skew is real: the largest (user_id, context_id) key has 4.1 million events, and the median has eleven", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "field app ignores the tokens and uses 36dp targets with 14px body text, on tablets used outdoors in gloves. bring it onto the tokens, and tell me how much less fits on screen once the type and targets are right", "purpose": "frontendImpl", "secondary": "review", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "a customer's cache hit rate fell from 94% to 41% after they added User-Agent to Vary, and our origin took the difference. confirm that's the whole story, then add the guard rail that warns or caps before it happens again", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "`Zone.current` means \"loaded from somewhere\" in the resolver and \"matches the primary's serial\" in the admin module, which is precisely the ambiguity behind the stale-serving incident. give the two concepts different names throughout, and make the resolver's check the stricter one wherever that doesn't cost us availability", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
|
|
{"prompt": "nightly recommender needs an output contract before it needs more checks. define what a valid run means — row counts, key coverage, comparison against yesterday — then implement the swap-a-partition write so a bad run can't overwrite a good one", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "one track model across the services", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
|
|
{"prompt": "edge config API reference needs writing, and while you're in there confirm whether a validation failure on one POP really does leave the config applied on the others, because our support team has been telling customers otherwise", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "seit dem Update spielt die App nach dem Sperrbildschirm den falschen Titel weiter:\n\n[player] 18:41:02 now playing track=t_4471 position=124.4s queue_index=3\n[player] 18:44:11 app entered background\n[player] 18:44:12 remote command center: nowPlayingInfo updated (track=t_4471)\n[player] 19:02:44 remote command: play\n[player] 19:02:44 resuming queue_index=3 position=0.0s track=t_4488\n\nder Queue-Index wird beim Reaktivieren neu aufgelöst, und die Queue wurde zwischenzeitlich vom Server neu gemischt; die Position geht dabei ebenfalls verloren", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "de"}
|
|
{"prompt": "ok so our spark job's memory profile changed after the schema evolution and now it fails at the same stage:\n\n25/07/29 04:11:02 ERROR Executor: Exception in task 412.0 in stage 12.0\njava.lang.OutOfMemoryError: GC overhead limit exceeded\n\tat org.apache.spark.sql.catalyst.expressions.codegen.BufferHolder.grow(BufferHolder.java:71)\n\tat org.apache.spark.sql.execution.aggregate.HashAggregateExec$$anon$1.processInputs\n\nexecutor memory 16g, 4 cores, spark.sql.shuffle.partitions 200\nthe grouping key was (user_id) and is now (user_id, context_id), which multiplies the distinct key count by about forty", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "honestly the construction app's daily report submits twice when the site has patchy signal:\n\n11:02:14 POST /v1/reports (idempotency-key: local-4471) → timeout after 30s\n11:02:44 POST /v1/reports (idempotency-key: local-4471) → 201 created id=r_88412\n11:03:14 POST /v1/reports (idempotency-key: local-4471) → 201 created id=r_88413\n\nserver side:\n idempotency keys are stored per user with a 10 minute TTL in redis\n the first request completed on the server at 11:02:47, after the client had already timed out\n redis was failing over between 11:02:40 and 11:02:50, and lookups during a failover return nil rather than an error", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "right, our shuffle implementation, which users describe as broken and i suspect is worse than that:\n\ndef nextTrack(playlist: Playlist, user: User): Track = {\n val seed = playlist.id.hashCode ^ LocalDate.now().hashCode\n val rng = new scala.util.Random(seed)\n val idx = rng.nextInt(playlist.tracks.size)\n playlist.tracks(idx)\n}\n\ncalled once per skip and once per track end, no memory of what has been played, and the seed is stable for the whole day so the same sequence recurs every session", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "quick one — the zone loading path at POP startup, which is why we serve stale answers after a deploy:\n\nfn start(&self) -> Result<()> {\n let snapshot = self.disk.load_latest()?; // may be up to 24h old\n self.serve(snapshot); // start answering immediately\n tokio::spawn(async move {\n let zone = self.primary.axfr().await?; // can take 60-120s for large zones\n self.serve(zone);\n Ok::<_, Error>(())\n });\n Ok(())\n}\n\nhealth checks pass as soon as we answer anything, the load balancer adds us immediately, and there is no readiness signal tied to the transfer completing", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "por favor, revisa el trabajo de spark antes de que lo dejemos correr esta noche:\n\nval recs = events\n .filter($\"ts\" > lit(cutoff))\n .groupBy($\"user_id\", $\"context_id\")\n .agg(collect_list(struct($\"track_id\", $\"score\")).as(\"items\"))\n .withColumn(\"items\", slice(sort_array($\"items\", false), 1, 200))\n\nrecs.write.mode(\"overwrite\").saveAsTable(\"recs.user_daily\")\n\ncollect_list acumula en memoria por clave, la cardinalidad de (user_id, context_id) es unos 1.600 millones, y el modo overwrite borra la tabla antes de escribir", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "es"}
|
|
{"prompt": "fyi the idempotency design note for the field API, written before we had offline devices:\n\n## Idempotency\nClients send an Idempotency-Key header. The server stores the key with the response for ten minutes and replays the stored response on a repeat.\n\n## Assumptions\n- A client retry happens within ten minutes.\n- The key store is available; a failed lookup means the key is new.\n- Keys are unique per user.\n\n## Not covered\nClients that queue for hours offline. Key store failover. Two devices submitting the same queued item.\n\nour field app queues for up to a working day, and a nil lookup during a redis failover is treated as \"new\"", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "heads up: the query behind our artist dashboard, which times out for anyone in the top thousand:\n\nSELECT t.id, t.title,\n sum(p.count) AS plays,\n count(distinct p.user_id) AS listeners,\n (SELECT sum(count) FROM plays_daily p2 WHERE p2.track_id = t.id AND p2.day > current_date - 28) AS plays_28d,\n (SELECT count(*) FROM playlist_tracks pt WHERE pt.track_id = t.id) AS in_playlists\nFROM tracks t\nJOIN plays_daily p ON p.track_id = t.id\nWHERE t.artist_id = $1 AND p.day > current_date - 365\nGROUP BY t.id, t.title\nORDER BY plays DESC;\n\nplays_daily is 41 billion rows partitioned by day, playlist_tracks is 12 billion, and a top artist has 4,000 tracks", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "small thing but the photo upload path in the field app, which is deleting people's evidence:\n\nFuture<void> _drain() async {\n for (final item in await _queue.items()) {\n try {\n await _api.upload(item);\n await _queue.remove(item);\n await File(item.path).delete();\n } on ApiException catch (e) {\n if (e.statusCode >= 400 && e.statusCode < 500) {\n await _queue.remove(item); // \"non-retryable\"\n await File(item.path).delete(); // and the local copy goes too\n }\n }\n }\n}\n\na 413 from an undocumented gateway limit lands squarely in that branch, and site photos are the evidence for variation claims worth thousands", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "support's notes on the missing site photos, which need to become a customer explanation:\n\n- photos taken offline are queued locally and uploaded when the device reconnects\n- an upload rejected with a 4xx is treated as permanently failed and the local copy is deleted\n- a gateway limit of 4MB, which we never documented, rejects photos from newer phones\n- affected users see the photo in the app until the sync runs, then it disappears with no message\n- we can recover nothing; the local file is gone\n- about 300 photos across 40 sites in the last month, some attached to variation claims\n\nwrite the customer notification and the internal note, and be clear that the data is not recoverable", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "incident notes from the DNSSEC failure, and we owe the customer a report:\n\n02:00 ZSK roll executed by the scheduled job\n04:11 first SERVFAIL reports from users on validating resolvers\n04:40 on-call confirms the old RRSIGs expired 26 hours after the roll, overlap configured as 24\n05:02 emergency re-sign with the previous key, published\n05:20 propagation to all POPs complete\n06:15 validating resolvers recover as their caches expire\n08:00 impact assessed: the zone was unresolvable for validating resolvers for about two hours, roughly 40% of their traffic\n\nthe customer runs a payments API on that zone and wants to know why an automated key roll can take a zone off the internet", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "as notas da reunião sobre a sincronização offline, para transformar em documento de decisão:\n\n- o modelo atual é last-write-wins sobre o registo inteiro, com o relógio do dispositivo\n- os tablets em obra estão frequentemente vários minutos desacertados\n- edições concorrentes ao campo de notas perdem-se sem qualquer aviso\n- opções: relógio do servidor, versões por campo, ou CRDT para o campo de texto\n- a equipa não tem experiência com CRDTs e a app tem de continuar a funcionar offline durante um dia inteiro\n- os clientes já perderam registos e um deles ameaça não renovar\n\nescreve a nota de decisão com as opções, o esforço estimado e uma recomendação", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "pt"}
|
|
{"prompt": "not urgent, but the questions from a customer's architecture review, which need answering as a document:\n\n\"What happens to our traffic if one of your POPs is unhealthy but still announcing? How do you roll back a configuration change that is already live in some locations? Is a zone transfer authenticated, and what prevents a compromised POP from serving forged answers? What is your DNSSEC key rollover procedure and who approves it? If we misconfigure something catastrophically, what is the fastest path to reverting, and can we do it without your support team?\"\n\nanswer each from the code and the runbooks, and mark clearly where the answer is \"a human notices\" rather than a mechanism", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "社内向けに、レコメンドのバッチ運用ドキュメントがありません。現状は次の通りです:\n\n- 毎晩 02:00 に Spark ジョブが起動し、recs.user_daily を overwrite モードで書き換える\n- 途中でステージが失敗しても再試行され、最終的に成功すれば終了コードは 0 になる\n- 書き込み行数の下限チェックがないため、半分の行数でも「成功」として扱われる\n- 前日のテーブルは overwrite で消えるため、ロールバックできない\n- 実行時間は通常 70 分、遅い日は 3 時間、02:00 開始で 06:00 の配信に間に合わないことがある\n- 監視は Airflow のタスク成否のみで、出力の妥当性は誰も見ていない\n\n設定:\n\n spark.sql.shuffle.partitions = 200\n executor.memory = 16g\n executor.cores = 4\n\n社内向けの運用ドキュメントとしてまとめてください。特に「成功」の定義が曖昧な点を明確に\n\n直近 7 日の実行結果:\n\n 日付 行数 実行時間 終了コード\n 07-23 62,104,882 72 min 0\n 07-24 61,882,004 74 min 0\n 07-25 62,001,118 70 min 0\n 07-26 61,904,412 118 min 0\n 07-27 62,114,008 81 min 0\n 07-28 62,088,441 77 min 0\n 07-29 41,882,004 187 min 0 <- 誰も気づかなかった\n\n spark.sql.adaptive.enabled = false (2023 年に誰かが無効化)", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "ja"}
|
|
{"prompt": "genuinely puzzled by this: the field app's offline documentation, which is currently a paragraph in the sales deck:\n\nwhat actually happens offline:\n tasks, photos and daily reports are queued locally with no size limit\n the queue drains in order when connectivity returns, oldest first\n a 4xx response deletes the queued item and its local file\n conflicts resolve last-write-wins by device clock, silently\n downloads of drawings expire after 30 days and re-download on next connection\n the queue is not visible to the user; there is no \"3 items pending\" indicator anywhere\n\nwrite the documentation for site staff and their IT departments, honestly, because they plan their day around what this app can do without signal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "scalafix and scalac warnings on the recommender, gate goes on next sprint:\n\n[warn] Recommender.scala:88:22: match may not be exhaustive. It would fail on: Context.Unknown\n[warn] Recommender.scala:141:9: discarded non-Unit value\n[warn] Features.scala:41:13: method collectList in class Dataset is deprecated\n[warn] Shuffle.scala:22:5: parameter value seed in method nextTrack is never used\n[warn] Pipeline.scala:212:7: local val cutoff is never used\n\n5 warnings, and Shuffle.scala's unused seed parameter is interesting given users say shuffle is broken", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "clippy and cargo audit on the edge server:\n\nwarning: this async block may hold a lock across an await\n --> src/zone/store.rs:141:9\nwarning: large future (8.2 KB) may cause stack overflow when boxed\n --> src/resolver/handler.rs:88:1\nwarning: `unwrap` on a `None` value is possible here\n --> src/dnssec/keys.rs:41:22\n\ncargo audit:\n Crate: ring 0.17.7\n Advisory: RUSTSEC-2026-0044 (panic on malformed signature input)\n Solution: upgrade to >=0.17.12\n\nthe ring advisory is in the code path that validates DNSSEC signatures on inbound transfers", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "for context, the gateway limits versus what our own app sends:\n\ngateway:\n client_max_body_size: 4m # undocumented, set in 2023\napp (flutter):\n photo quality: 90, max dimension 4032 # about 3-8MB per photo on recent phones\n no client-side resize\napi docs:\n \"photos may be up to 25MB\"\nCDN in front of the gateway:\n max body 100MB\n\nthe 4MB limit is the effective one and nothing in the product tells anyone about it\n\nand the numbers from the last month:\n photos queued: 41,882\n photos rejected with 413: 312\n photos rejected and deleted locally: 312\n average size of a rejected photo: 6.4 MB\n sites affected: 40\n\nnothing in the app, the docs or the API response mentions four megabytes anywhere", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "background: the DNSSEC signing config, and one number is why a zone went dark:\n\nsigning:\n algorithm: ECDSAP256SHA256\n zsk_rollover: prepublish\n zsk_lifetime_days: 30\n zsk_overlap_hours: 24\n rrsig_validity_hours: 26\n rrsig_refresh_hours: 20\n ksk_rollover: manual\n\nthe overlap is shorter than the signature validity, so signatures made with the outgoing key can outlive the period during which we publish it\n\nthe timeline the numbers produce:\n T+0h ZSK roll, new key published, old key still published\n T+24h old key unpublished (overlap expires)\n T+26h signatures made with the old key expire\n\nso for two hours there are live signatures whose key is no longer published, and every validating resolver returns SERVFAIL for the whole zone during that window", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "worth a look — the iOS player's audio session setup, which i think is behind the lock screen bug:\n\ntry AVAudioSession.sharedInstance().setCategory(.playback, mode: .default, options: [])\ntry AVAudioSession.sharedInstance().setActive(true)\n\nMPRemoteCommandCenter.shared().playCommand.addTarget { [weak self] _ in\n self?.player.play() // resolves the queue index freshly\n return .success\n}\n\nMPNowPlayingInfoCenter.default().nowPlayingInfo = [\n MPMediaItemPropertyTitle: track.title,\n MPNowPlayingInfoPropertyElapsedPlaybackTime: player.currentTime\n]\n\nnowPlayingInfo is set once when playback starts and never updated, and the queue can be reordered by the server while the app is backgrounded", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "les seuils d'alerte de la plateforme edge, on nous réveille pour rien :\n\n- alert: PopUnhealthy\n expr: up{job=\"pop\"} == 0\n for: 1m\n labels: { severity: page }\n\n- alert: CacheHitRate\n expr: cache_hit_ratio < 0.8\n for: 15m\n labels: { severity: ticket }\n\n- alert: ZoneSerialMismatch\n expr: count(count by (serial) (zone_serial)) > 1\n for: 0m\n labels: { severity: ticket }\n\nen réalité : un POP est toujours en maintenance quelque part ; la chute du taux de cache d'un client a doublé la charge origine sans réveiller personne ; et la divergence de serial après chaque déploiement produit un ticket que tout le monde ignore, y compris le jour où elle a duré deux heures", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "pasted-context", "lang": "fr"}
|
|
{"prompt": "this pipeline object does feature building, model scoring, filtering and writing in one class:\n\nobject Recommender {\n def run(spark: SparkSession, cutoff: Timestamp): Unit = {\n // reads three source tables with different freshness expectations\n // builds features inline, with the window sizes as literals\n // scores with a model loaded from a hardcoded S3 path\n // applies business filters: explicit content, regional licensing, artist blocks\n // collects per user, slices to 200, writes with overwrite\n // no row count check, no comparison against yesterday, exits zero on any completed run\n }\n}\n\n900 lines, and the licensing filter is the part legal asks about", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "quarter planning input, and it needs sequencing:\n\n- the field app deletes site photos on a 4xx, which has already cost a customer a variation claim\n- offline sync loses concurrent edits silently and a customer is threatening not to renew\n- a DNSSEC roll took a customer's zone off the internet for two hours\n- the recommender wrote half the usual rows and nobody noticed for a day\n- shuffle is the top complaint in app store reviews and has been for a year\n- one Rust engineer on the edge platform, two on the field app, and the data team is three\n- there's an enterprise construction customer signing in november whose security review starts next month", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "architecture ticket, thinking before code:\n\nEDGE-220 — Readiness and zone freshness\nA POP currently answers as soon as any zone is loaded from its on-disk snapshot, which can be a day old, and the health probe reports healthy at that point. The proposal is a readiness signal tied to zone currency, so a POP does not receive traffic until its zones are current. Concerns: a POP with a very large zone takes two minutes to transfer and we would lose capacity during rolling deploys; \"current\" is ambiguous for zones that change every few seconds; some customers' zones are never current by that definition; and the load balancer's health check is a simple TCP probe we do not control.", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "spec for the edge console's zone view, which we open during incidents:\n\nZone view\n- Per-POP table: serial being served, source (disk, transfer, cache), age, query rate, error rate. Sorted by staleness.\n- A POP serving a serial other than the current one is unmistakable — not a colour alone, and with the age in words.\n- Deployment strip: the last five config deployments with their status per POP, and which one a given POP is running.\n- One-click drain and undrain per POP, with a confirmation that states how much traffic will move and where.\n- A zone-level timeline of serial changes, transfers and config applies on one axis, because correlating those is the whole job.\n- The view must render from cached data with an age indicator when the control plane is unreachable, which is exactly when we need it.\n- Everything must be legible on a phone at 3am.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "accessibility findings for the music app's player, from an app store review and our own audit:\n\n1. The play/pause button's accessible label does not change with state.\n2. The scrubber is a custom control with no adjustable trait, so VoiceOver users cannot seek at all.\n3. Track changes are not announced, so a blind user cannot tell what is playing without navigating to the label.\n4. The queue reorder handles have no accessibility actions; reordering requires a drag.\n5. Album art has no alt text, not even the album name.\n6. The mini player and the full player expose duplicate elements to VoiceOver, doubling every swipe.\n7. Dynamic Type above the default clips track titles rather than truncating them, hiding the artist entirely.", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "design tokens versus what the field app actually uses:\n\ntokens:\n color.surface #FFFFFF / #12151A\n color.text #12151A / #E9EDF2\n color.muted #5C6672\n color.status.ok #1A7F37\n color.status.warn #9A6700\n color.status.err #B42318\n space 4/8/12/16/24/32, radius 8/12, touch target 48dp (site gloves)\n type: title 20/28, body 16/24, caption 14/20\n\nthe field app: nine hardcoded colours, touch targets of 36dp on the task list, body text at 14px which is unreadable in sunlight, and status shown by colour alone on a screen people use outdoors\n\nbring it onto the tokens, fix the targets and the type sizes, and give status a non-colour indicator", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "gateway body limit to 25MB", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
|
|
{"prompt": "ring bump for the DNSSEC path", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
|
|
{"prompt": "store listing still says \"Beta\"", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
|
|
{"prompt": "turn adaptive query execution back on", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
|
|
{"prompt": "ZSK overlap longer than signature validity", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
|
|
{"prompt": "client-side resize before photo upload", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "row count floor on the nightly job", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "CacheHitRate should page, not ticket", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "cap Vary variants per cache key", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "the schema we agreed for the offline queue, now it needs building on both sides:\n\nCREATE TABLE pending_items (\n id uuid PRIMARY KEY,\n device_id text NOT NULL,\n user_id uuid NOT NULL,\n kind text NOT NULL CHECK (kind IN ('task','photo','report')),\n payload jsonb NOT NULL,\n local_path text,\n created_at timestamptz NOT NULL,\n attempts int NOT NULL DEFAULT 0,\n last_error text,\n state text NOT NULL CHECK (state IN ('pending','sent','failed','conflict'))\n);\n\nnothing leaves the queue without the user seeing it; a 4xx moves an item to failed with a human-readable reason rather than deleting it; a conflict is a first-class state; and the queue survives an app update and a device restore", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "our POP has three code paths that decide whether to answer a query:\n\n// resolver/handler.rs\nif zone.is_loaded() { answer(zone) } else { servfail() }\n\n// health/probe.rs\nfn healthy(&self) -> bool { self.zones.any_loaded() } // any zone at all\n\n// admin/status.rs\nfn status(&self) -> Status { if self.zones.all_current() { Ready } else { Degraded } }\n\nthe resolver answers from whatever is loaded, the health probe reports healthy if any zone is loaded, and only the admin status knows whether the data is current — and nothing acts on it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "field app has two HTTP clients, one with token refresh and one without, and the photo uploader uses the one without — which means a long offline period ends with an upload that 401s and gets treated as permanently failed. move everything onto the refreshing client, and check what else uses the wrong one", "purpose": "refactor", "secondary": "debugging", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "a walkthrough of how a play event becomes a recommendation would help before i touch features", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "the sync thing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "nowPlayingInfo wird nie aktualisiert", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "de"}
|
|
{"prompt": "unused seed parameter in nextTrack", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "pending count in the app bar", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
|
|
{"prompt": "conflicts need a side-by-side view", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
|
|
{"prompt": "scrubber needs the adjustable trait", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "en"}
|
|
{"prompt": "曲が変わっても読み上げられません", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.35, "slice": "core", "lang": "ja"}
|
|
{"prompt": "album art has no alt text", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "mini player duplicates VoiceOver elements", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "une seule notion de « zone à jour »", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "fr"}
|
|
{"prompt": "`serial` naming across the POP code", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "extract the queue drain from the sync service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "inline `isDownloaded`, one caller now", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "changelog for the mobile release", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
|
|
{"prompt": "nota aos clientes sobre as fotos perdidas", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "pt"}
|
|
{"prompt": "document what \"deployment complete\" means", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "summarise the readiness proposal", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "PR body for the shuffle rewrite", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "can a 4xx delete a site photo?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "¿el job puede escribir la mitad de las filas?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
|
|
{"prompt": "walk me through the zone transfer path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "why does shuffle repeat so much?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "site photos disappear after sync", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "recommendations are a day stale", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
|
|
{"prompt": "one POP serves yesterday's zone", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "warum verliert die App Offline-Änderungen?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "de"}
|
|
{"prompt": "press ahead", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "more reliable", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "your judgement on the order", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "lo del POP, sigue", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "es"}
|
|
{"prompt": "leave it tidier than you found it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "same as we did before", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "doc for the review", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "nothing that touches prod", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "second opinion please", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "どこから手をつけるかお任せします", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "ja"}
|
|
{"prompt": "whatever's next", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "DNSSEC key roll took a customer's zone off the internet for two hours because the publication overlap was shorter than the signature validity. beyond fixing the number, i want a position on how key material changes are reviewed and rolled out at all, given this one was fully automated and nobody looked at it until resolvers started failing", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "runbook for a stale POP currently says restart it, which is precisely what makes it serve the old snapshot again. write the real procedure — drain first, check the source, force a transfer, wait — in the order someone paged at three in the morning would need, and say why the obvious action is wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "idempotency design note assumes retries happen within ten minutes and that a failed lookup means a new key, both of which are false for a field app that queues for a working day. read it against the implementation and tell me which other assumptions have quietly stopped holding tell me if this is the wrong shape entirely, i won't be offended.", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "track model exists three times with different field sets and hand-written conversions in six places, three of them lossy for multi-artist tracks. converge on one model with explicit conversions at the service boundaries, and prove that the mobile API's payloads are byte-identical for a sample covering the lossy cases the sooner we know roughly how big this is, the better for planning.", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
|
|
{"prompt": "cache key construction is split across a config parser, a request handler that ignores two fields of the parsed spec, and a production-only override table with forty-one entries nobody can explain. bring it into one place, work out which overrides are still load-bearing, and keep every customer's effective cache key unchanged unless we decide otherwise deliberately", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "sync status screen doesn't exist, which is why site staff discover a failed upload days later when someone asks for the photo. build it to the spec — pending items by type, plain-language failures, resize-and-retry for oversized photos, conflicts with an explicit choice — and make sure nothing leaves the queue invisibly", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
|
|
{"prompt": "unsere Offline-Warteschlangen sollen zusammengeführt werden, aber vorher hätte ich gern ein Konzept, was garantiert nicht verloren gehen darf und was der Nutzer davon sieht. Danach die Umsetzung für die Foto-Warteschlange, weil dort bereits Daten verloren gingen", "purpose": "planning", "secondary": "refactor", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "de"}
|
|
{"prompt": "DDEX ingestion needs the withdrawal semantics agreed before anything is built — what removing a release means for playlists, caches and recommendations within 24 hours. decide that with me, then implement the ingest and the withdrawal path", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "offline documentation has to exist before the enterprise security review, and writing it will surface things we should fix rather than describe — the silent deletion especially. write it, and give me that list separately", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "escribe la documentación del proceso de recomendaciones para el equipo de datos y comprueba en el código si el modo overwrite deja realmente la tabla vacía durante la escritura, porque eso explicaría los informes de la mañana", "purpose": "writing", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "es"}
|
|
{"prompt": "our track model exists three times with different field sets:\n\n// api/TrackDto.scala — 41 fields, what the mobile app receives\n// domain/Track.scala — 22 fields, what the recommender uses\n// storage/TrackRow.scala — 38 fields, what the database has\n\nconversions are hand-written in six places, three of them lossy in ways that only show up for tracks with multiple artists, and the licensing fields exist in two of the three\n\nthe conversions, for reference:\n\n TrackDto.fromDomain(t: Track): TrackDto // drops secondary artists\n Track.fromRow(r: TrackRow): Track // drops licensing fields entirely\n TrackRow.fromDto(d: TrackDto): TrackRow // used only by the admin importer\n TrackDto.fromRow(r: TrackRow): TrackDto // the mobile read path, keeps licensing\n Track.fromDto(d: TrackDto): Track // used by the recommender's backfill\n TrackRow.fromDomain(t: Track): TrackRow // drops everything the domain doesn't model\n\nsix conversions, three lossy, and the licensing fields survive only two of the six paths", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "pasted-context", "lang": "en"}
|
|
{"prompt": "stale-POP runbook should be a page rather than a wrong one-liner, and the restart command should refuse to run on an undrained POP. write the runbook, then add the guard", "purpose": "writing", "secondary": "quickFix", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "licensing filter should live somewhere legal can read it rather than inline in a nine-hundred-line object. extract it, then document the rules it encodes so the next licensing question doesn't require an engineer", "purpose": "refactor", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "POP's three notions of health should collapse into one. do that, and tell me whether any of the current callers depended on the loose definition — the admin status page especially", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "daily reports submit twice on patchy signal and the idempotency store looks fail-open during a failover. confirm the mechanism, then make the store fail closed and give the client a longer key lifetime for offline queues", "purpose": "debugging", "secondary": "backendImpl", "mixed": true, "difficulty": 0.85, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "lock screen resumes the wrong track because the queue index is re-resolved after the server reshuffles. diagnose it properly, then make the player resume by track identity and position rather than by index", "purpose": "debugging", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "player fails seven accessibility items including a scrubber blind users cannot operate at all. fix them, and write the accessibility section for the store listing, which we've never had", "purpose": "frontendImpl", "secondary": "writing", "mixed": true, "difficulty": 0.75, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "pending-items table needs its state machine agreed before it's built — what conflict means, what happens to a failed item the user ignores for a week. settle that, then implement both sides", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "is it expected that a config change is live on some POPs and not others for ninety seconds", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "pouvez-vous m'expliquer comment la file d'attente hors ligne gère une mise à jour de l'application ?", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "fr"}
|
|
{"prompt": "docs/sync.md claims conflicts are surfaced to the user, which has never been true", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
|
|
{"prompt": "a short note on why we're moving to partition-swap writes, for the decision log", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
|
|
{"prompt": "API changelog needs an entry for the photo size limit becoming documented and enforced", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "scaladoc on Recommender.run promises idempotency that the overwrite write mode doesn't provide", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "write the note to sites whose photos we lost, including what we can and cannot recover", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "health endpoint reports a POP healthy while it serves a zone from a day-old snapshot", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
|
|
{"prompt": "how should we handle a customer zone that changes faster than we can transfer it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
|
|
{"prompt": "i want a position on whether the field app should sync through a queue or a proper replicated store", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "core", "lang": "en"}
|
|
{"prompt": "two labels want realtime delivery rather than a daily batch, what would that mean for ingestion", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "construction customers run four app versions and sites go months without updating", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "what should happen to a site's data when the project finishes and the contract ends", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "task list should show which items are pending upload rather than looking synced", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "artist dashboard should load progressively rather than waiting for the slowest query", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "whatever the security review needs first", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "pick up the queue work", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "vague-eval", "lang": "en"}
|
|
{"prompt": "POP metrics are labelled by pop and zone, which for our largest customer alone is four million series and most of our monitoring bill. rework the labelling so per-zone detail is available on demand rather than always, and tell me which dashboards and alerts break when the high-cardinality labels go", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "recommender reads three source tables with different freshness guarantees and treats them all as current, which is probably why the cold-start features look wrong on mondays. make the freshness explicit at the read, and tell me which features are actually affected before we change any behaviour", "purpose": "refactor", "secondary": "review", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "iOS and Android players implement the queue independently and disagree about repeat-one, which users notice when they switch devices mid-session. decide which behaviour is correct with me first, since it's a product question, then align both clients", "purpose": "planning", "secondary": "frontendImpl", "mixed": true, "difficulty": 0.65, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "photo uploads should be chunked so a large file on a site connection can resume rather than restarting, and we should agree the chunk size and the resume semantics before either side is built. settle that, then implement the server side", "purpose": "backendImpl", "secondary": "planning", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
|
|
{"prompt": "internal page on the recommendation pipeline stops at \"the nightly job writes the table\", which is why nobody knew a partial write was possible. write the page properly — the three source tables, the grouping, the filters, the write mode, and what \"success\" currently means — as the reference for the validation work", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "nightly job exits zero whether it writes sixty-two million rows or forty-one, and the table it overwrites is what the morning home screen reads. add a floor and a comparison against the previous run, fail loudly below it, and make sure the failure is visible to someone before six in the morning rather than after", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "three retry helpers exist in the scala codebase and the recommender uses none of them, having its own loop that retries a failed stage without checking whether the previous attempt left rows behind. consolidate onto one helper with explicit idempotency expectations, and tell me which callers were relying on the differences", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "core", "lang": "en"}
|
|
{"prompt": "field app's drawing cache expires after thirty days and re-downloads on the next connection, including drawings that haven't changed, which on a site connection costs an hour and a lot of goodwill. make expiry depend on the drawing's version rather than the calendar, keeping offline availability exactly as it is", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "staging environment has one POP and production has forty-one, with the same zone transfer timeout and the same snapshot refresh interval, which is why the stale-serving behaviour has never once appeared before a release. bring the staging numbers into a defensible relationship with production and note which of them are genuinely per-POP", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.45, "slice": "core", "lang": "en"}
|
|
{"prompt": "app's photo quality setting produces files above the gateway's undocumented limit on any phone bought in the last three years, which is the actual cause of the deleted-evidence incident. lower the default, resize on the client before upload, and make sure existing queued photos are resized rather than rejected when the app updates", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
|
|
{"prompt": "support needs an endpoint that returns a device's pending queue as the server understands it — what has arrived, what is duplicated, what was rejected and why — because today the only way to answer \"where did my photo go\" is to ask the customer to read their own screen back to us over the phone", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "drawing cache and the offline queue both decide independently when local storage is under pressure, and on a 64GB tablet halfway through a project they fight: the cache evicts drawings the queue is about to attach, and the queue's photos push the cache below its own floor. give storage one owner with an explicit budget per kind of data, and keep a full working day offline possible on the smallest device we support", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "edge config validation runs in three places — the console's form, the API on write, and each POP on apply — and they disagree enough that a config can pass the first two and be rejected by half the fleet. bring them onto one validator compiled into all three, and tell me which currently-live configs would fail it", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "before the enterprise security review i want a read on whether a compromised POP could serve forged answers for any customer zone, given that transfers are authenticated by source address and the signing keys live on the primaries. tell me what an attacker with one POP could actually do", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.85, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "console's zone view refuses to render at all when the control plane is unreachable, which is the exact circumstance in which we open it. serve it from the last known state with a visible age, keep the drain controls working against the POPs directly, and make it obvious which parts of the page are stale", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "shuffle rewrite needs the product behaviour settled before the code: whether a shuffled order persists across sessions, what a skip means for the rest of the order, and whether adding a track reshuffles. decide that with me, then implement it in the shared player logic", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "zone transfers are authenticated by source address, which is how they were set up when we had three POPs in one datacentre and is now indefensible. move to TSIG or mutual TLS per POP, roll it out without a flag day across forty-one locations, and make an unauthenticated transfer attempt something we alert on rather than something we allow", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
|
|
{"prompt": "nobody has been able to tell me how a withdrawn release actually leaves the product — whether it disappears from playlists immediately, waits for the nightly recommender, or lingers in the mobile app's local cache until eviction. trace it through ingestion, playlists, recommendations and the client caches, and tell me where the 24-hour contractual window is actually at risk", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
|
|
{"prompt": "label ingestion accepts a batch as a unit, so one malformed message means the whole day's deliveries from that label sit unprocessed until someone notices. i want to know exactly how failures are currently isolated, if at all, and what a single bad message can hold up in the worst case we've actually seen", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.75, "slice": "core", "lang": "en"}
|
|
{"prompt": "library screen shows a track as downloaded when the file exists, regardless of whether the download record says it completed or the licence has since expired, which is why people find silent tracks on a plane. show the state honestly — complete, partial, expired — and make the offline case the one we design for rather than the exception", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "an endpoint that returns, for one zone, the serial each POP is currently serving along with where it came from and how old it is, so the console and the runbook stop depending on someone SSHing into a POP to find out. it has to answer while the control plane is degraded, which is when it matters", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
|
|
{"prompt": "i'd like to understand what the mobile client does with a track whose licence expired while the device was offline — whether it refuses to play, plays anyway, or removes it silently — because the answer determines whether our territory rights handling is a client problem or a server one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
|
|
{"prompt": "the queue screen shows tracks with no indication of which are downloaded, which is the single thing people want to know before a flight, and the download state we do show elsewhere is unreliable anyway. show it honestly on the queue, including partial and expired, and make the offline case the default assumption rather than an edge case", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.55, "slice": "core", "lang": "en"}
|
|
{"prompt": "we need a per-zone deployment status endpoint that reports, per POP, which config revision is live rather than which one was acknowledged, since those are not the same thing and our console currently shows the second while claiming the first. it has to work when the control plane is degraded and be cheap enough for the console to poll", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.65, "slice": "boundary", "lang": "en"}
|