data/opus-22.jsonl

{"prompt": "…circling back on the service mesh question. we have 14 go services doing http between themselves with hand-rolled retries and no mTLS. istio, linkerd, or just a shared library. i want the plan including what we get for free vs what we'd still have to build, and the operational cost of running a mesh with our team size", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "grpc between the catalog and pricing services replacing the http calls, with deadlines propagated and the interceptors for tracing and auth", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "service dependency graph view: services as nodes, call volume as edge weight, and the error rate as color", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the grpc keepalive is off so idle connections get killed by the lb", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "our 14 services each have their own main.go with 200 lines of near-identical setup — logging, metrics, tracing, health, graceful shutdown. one bootstrap library, same runtime behavior per service", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "one service's p99 spikes to 8 seconds whenever another unrelated service deploys", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "does a deadline actually propagate through all our hops, or does someone create a fresh context somewhere? trace it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "service catalog documentation: each service's purpose, owner, dependencies, and the SLO it commits to", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "mTLS between services with certs from our internal ca, rotated automatically, and a mode where we log violations before enforcing", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "one service can't reach another after enabling mTLS and the error is just 'connection reset'", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the ca cert in the config expires in 3 weeks", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "plan how we roll out mTLS enforcement service by service without an outage, including the rollback per step", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "gutenberg block for our embed — attributes for the resource id and display mode, an inspector panel, and a server-rendered preview", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the block editor shows 'This block has encountered an error' after a post is saved and reloaded", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our plugin's admin page enqueues jquery-ui globally and breaks other plugins", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "plugin settings screen using the wp components library instead of our hand-rolled forms, matching core's look", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "we write directly to wp_options with serialized arrays in 30 places. use a settings api wrapper, same stored values", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "map out the plan for supporting the block themes / full site editing properly, our plugin assumes classic themes throughout", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "review our plugin for anything that would break on a multisite install", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plugin readme.txt for the wordpress directory, with the sections they require and an honest feature list", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "rest api endpoints for the plugin registered properly with permission callbacks, not admin-ajax", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "our ajax endpoints have no nonce check on two of them", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "no_std rust firmware: the sensor driver needs an async interface over the embassy executor, with a timeout that doesn't block the whole executor", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the device hard faults after about 12 hours and the fault handler doesn't give me a useful pc", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "keep going", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "from #eng-oncall last night, nobody's picked it up:\n\n[02:14] alarm: api-gateway 5xx rate 12%\n[02:15] hana: looking\n[02:19] hana: it's the catalog service, grpc UNAVAILABLE from the gateway\n[02:21] hana: catalog pods are all Running, health checks green, its own metrics look fine\n[02:24] hana: catalog can reach the db, i exec'd in and curled its own /healthz, 200\n[02:26] hana: gateway logs: \"rpc error: code = Unavailable desc = last connection error: connection closed before server preface received\"\n[02:31] hana: restarted the gateway pods, error rate back to 0\n[02:33] hana: no idea what that was, going back to bed\n\ni'd like to actually understand this one before it happens again", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"}
{"prompt": "grpc client connection management with proper name resolution refresh, so the gateway picks up new catalog pods without a restart", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the gateway resolves the catalog service once at startup", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "review our grpc client setup across all services for the same resolve-once problem", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our five grpc clients are constructed differently, three with a hand-built dialer. one client factory with the right defaults, same endpoints and interceptors", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "runbook entry for grpc UNAVAILABLE, including the resolution staleness cause we just found", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "plan the load balancing approach for grpc — client-side with a resolver, or a proxy, given we're not adopting a mesh yet", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "gateway health page showing per-upstream connection state and the last resolution time", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "the health page's upstream list is hardcoded", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "requests fail during a rolling deploy of any downstream service, for about 15 seconds each time", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "explain what our readiness probe actually checks, and whether a pod can be ready while unable to serve", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "readiness that reflects dependency health without cascading — unready if our own db is gone, ready if a downstream is degraded", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "write the service ownership and on-call doc — which team owns which service and what the escalation is at 2am", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "plan the retry and timeout policy across the mesh — who retries, budgets, and how we avoid retry amplification", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "our services retry at every layer so one slow call becomes 27 requests. implement a retry budget, and document the resulting behavior", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "a single slow downstream causes a full outage rather than degraded service", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the retry count is 5 with no backoff", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "degraded-mode ui: when pricing is unavailable, show the catalog without prices and a clear note rather than an error page", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plan the mesh adoption then implement the mTLS pilot on two services", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "diagnose the grpc UNAVAILABLE thing and then write the postmortem", "purpose": "debugging", "secondary": "writing", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "next", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "the firmware. we're on a stm32l4 with 256k flash and 64k ram, and we're at 240k flash. the feature list for next year needs another 60k. options: a bigger part (bom cost, and a redesign), compress assets, drop the usb stack, or actually optimize. write me the analysis with real numbers from the current map file", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "shrink the binary — panic strings are eating 18k, and the formatting machinery pulls in a lot. get us under 200k without losing diagnostics entirely", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the release profile has debug assertions and overflow checks on", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "defmt logging over rtt replacing our current uart printf, with the strings interned so they don't live in flash", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the device stops responding to i2c after a specific sensor error, and only a power cycle recovers it", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "explain our interrupt priorities and whether the sensor isr can be preempted by the radio isr mid-transaction", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "firmware architecture doc: the task layout, the interrupt priorities, the memory map, and the power states", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "power management: sleep between samples, wake on the accelerometer interrupt, and get average current under 40µA", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "measured current is 2.1mA in sleep, expecting 40µA, so something is keeping a peripheral clock on", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the sample interval is 1s, spec says 30s", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.1, "slice": "core", "lang": "en"}
{"prompt": "our peripheral init is spread through main and three modules, each enabling clocks and never disabling them. centralize it, same peripherals functional", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "plan the ota update for these devices given 256k flash and no room for two full images", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "review the bootloader's image validation — signature, version rollback protection, and what it does with a corrupt image", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "production test firmware that exercises every peripheral and outputs a pass/fail per test for the factory jig", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "manufacturing test procedure doc for the contract manufacturer, step by step, with the expected outputs", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "factory jig ui on a raspberry pi touchscreen: scan the serial, run tests, big pass/fail, and log the result", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the jig ui's pass indication is a small green text label, make it fill the screen", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "boundary", "lang": "en"}
{"prompt": "about 1 in 200 units fails the radio test at the factory and passes on a retest", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "wir sind bei 240k von 256k Flash. plan mir bitte, wie wir Platz schaffen, mit konkreten Zahlen aus der Map-Datei", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "de"}
{"prompt": "provisioning at the factory: burn a unique key per device into the protected flash region, recorded in our db against the serial", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "check whether a provisioned key can be read back out over swd or the debug uart", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "readout protection isn't enabled on the production build", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "device management page: fleet list with firmware version, last seen, battery, and a filter for devices that haven't reported in a week", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "battery percentage shows 100% for devices that have never reported", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "onwards, next thing", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "so we sell a wordpress plugin and a saas, and the plugin talks to the saas. the plugin's version distribution is horrifying — people are running versions from 2022 against our current api. i want the plan for how we handle that: api versioning per plugin version, forced updates, or a compatibility shim, and what we do about the 8% who will never update", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "version negotiation on the api — the plugin sends its version, we respond with the compatible shape, and we log which versions are still in use", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plugin version dashboard: distribution across our installs, and which api features each version uses", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the plugin sends its version in a header we never read", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "our api has three response shapes for the same resource depending on which plugin version asks, implemented as if-branches through the serializer. move to explicit versioned serializers, byte-identical output per version", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "installs on plugin 2.1 started getting 500s yesterday and we didn't change anything for that version", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "tell me which of our api endpoints would break a 2022-era plugin today, from reading the code", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "compatibility policy doc for plugin users: which plugin versions we support, for how long, and what happens when yours falls out", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "in-plugin update nag that's informative rather than annoying, dismissible, and escalating in urgency as the version ages", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "the update nag shows on every admin page load", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "plan the plugin's own update mechanism — we're not in the wp directory, so we serve updates ourselves and it's fragile", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "update server endpoint that wordpress's updater understands, with the version metadata and a signed package url", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "some installs report an update available every page load even after updating", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "review our update flow for whether someone could serve a malicious package by mitm-ing the update check", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "changelog for the plugin, user-facing, for the last four releases, since we've been writing 'bug fixes'", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "license key activation in the plugin, tolerant of an offline site, with a clear state when it can't reach us", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the license check runs synchronously on every page load and adds 300ms when our api is slow", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "explain what the plugin does when our api is unreachable — degrade, cache, or break", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "ok, next please", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "here's the slack thread from the customer's dev channel, they gave us access:\n\n[10:02] their-dev: your plugin is adding 1.8s to our TTFB\n[10:04] their-dev: query monitor says 340 queries from acme-connect\n[10:05] their-dev: they're all SELECT option_value FROM wp_options WHERE option_name = 'acme_cache_...'\n[10:09] their-dev: also you have 12,000 rows in wp_options with the acme_ prefix, none autoloaded thankfully\n[10:11] their-dev: wait, 400 of them ARE autoloaded, that's 2MB of autoload data\n[10:14] their-dev: we're on a shared host, this is why our admin is unusable\n[10:15] their-dev: please fix or we'll have to drop the plugin\n\nthis is our third complaint like this", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "pasted-context", "lang": "en"}
{"prompt": "replace the wp_options cache with the transients api used correctly, or a custom table, and clean up the 12k rows we've left behind", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our cache writes use add_option with autoload defaulting to yes", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "cleanup routine that removes our orphaned options on update, batched so it doesn't time out on a shared host", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plugin diagnostics screen: our cache size, row counts, and a cleanup button, so a site owner can see what we're using", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "review everywhere our plugin writes to the database and tell me what it costs a site with 50k posts", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "write the reply to the customer's dev — specific about what we found, what we're changing, and a workaround for right now", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"}
{"prompt": "plan the plugin's performance work — a budget for what we add to TTFB, and a test on a representative shared host", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "performance test harness that runs our plugin on a seeded wordpress with 50k posts and reports query counts and timings", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the perf harness's seeded site has 12 posts", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "our plugin hooks init, admin_init and wp_loaded and does the same work in each because someone wasn't sure which fires. pick the right one, same behavior", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the plugin's work runs on frontend requests too, where none of it is needed", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "explain which of our hooks fire on a frontend request versus admin, and what we do in each", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "performance section for the plugin docs: what we do on each request, our caching, and how to diagnose a slowdown", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "background sync via wp-cron with a proper lock so two overlapping runs can't both process the same batch", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "wp-cron never fires on sites with DISABLE_WP_CRON and we don't tell anyone", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "sync status panel with the last run, next scheduled run, and a warning if wp-cron looks disabled", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "figure out the plan for a proper background job system in the plugin, since wp-cron isn't reliable, then build the queue table", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"}
{"prompt": "have a look at the options usage and clean up what's obviously wrong", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.5, "slice": "mixed", "lang": "en"}
{"prompt": "ok now the other bit", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "propose how we do canary deployments for the go services. we have 14 of them, k8s, argo cd, and no traffic splitting today — a deploy is a rolling update and we find out from customers. i want the design including the metrics we'd gate on and what happens to in-flight grpc streams during a rollback", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "canary analysis job comparing error rate and latency between the canary and stable pods, with a verdict the rollout controller reads", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "deploy view: rollout progress, canary metrics side by side with stable, and a promote/abort", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the canary weight is 50% which defeats the purpose", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "our services emit metrics without a version label so canary and stable are indistinguishable in the dashboards. add it consistently across all 14", "purpose": "refactor", useless_field="x", "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the canary passes analysis and then errors spike after promotion", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "explain what metrics our canary analysis actually looks at and whether they'd catch a bug affecting 2% of requests", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "deployment guide for service owners: how a canary works, what gates it, and how to roll back manually if the automation fails", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "feature-flag-gated rollout as an alternative to traffic splitting for the services where it fits better", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "rollbacks leave the old replicaset scaled up and we pay for double capacity for days", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the rollout's progressDeadlineSeconds is 600 and our slowest service takes 12 minutes to become ready", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "plan how we test a rollback for real, in staging, on a schedule, so we know it works before we need it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "review whether a rollback can leave the database schema ahead of the code, and what breaks if it does", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "migration compatibility checks in CI — flag any migration that the previous release's code couldn't tolerate", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "write the expand-contract migration guide with worked examples for the three cases people get wrong", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "release dashboard: what version each service is running per environment, and how far behind stable each is", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the version shown is the chart version not the image tag", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "design the canary system then implement the metrics comparison", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "alright, last one for today", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}