{"prompt": "- reverse proxy, we own it, ~90k rps peak\n- currently one process, epoll, single threaded\n- need tls termination, h2 upstream, and per-route timeouts\n- want to go multi-threaded with SO_REUSEPORT\n- must not drop connections on reload\n\nwrite the design, don't touch code yet", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "multi-threaded accept with SO_REUSEPORT, per-thread event loops, and no shared mutable state on the request path", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "zero-downtime reload — new config, new listeners, drain the old workers with a deadline", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "the reload drops in-flight requests because we close listeners before draining", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "the accept backlog is 128", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "our buffer management uses a global pool with a mutex, which is the contention point at 90k rps. per-thread pools, identical behavior", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "read the connection handling and tell me under what circumstances we'd leak a file descriptor", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "proxy configuration reference: the route syntax, the timeout semantics, header handling, and the reload behavior", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"} {"prompt": "fd usage climbs steadily under load and we hit the limit after about 6 hours", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "per-route timeouts — connect, header, body and total — configurable and enforced independently", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "the total timeout resets whenever a byte arrives, so a slow drip never times out", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "proxy admin ui: routes, upstream health, connection counts per worker, and the active config version", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "so the dns resolver. we run our own for internal service discovery, it's 4000 lines of c from 2019, and it caches negatively for the full ttl which is why a new service takes 5 minutes to be reachable. i want the plan: fix it, replace it, or put something in front of it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "negative caching with a much shorter ttl and a bypass for names in our internal zone", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the negative cache ttl comes from the SOA minimum which is 3600 for our zone", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"} {"prompt": "our cache eviction is a linear scan of 200k entries on insert", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "resolution latency spikes to 400ms every few minutes with no change in query volume", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "review our resolver's handling of a truncated response — do we retry over tcp or return partial results", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "internal dns documentation: the zones, the ttls, how service records are created, and the propagation expectations", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"} {"prompt": "resolver metrics: query rate by type, cache hit rate, upstream latency, and the negative cache size", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "crm: the pipeline board needs drag between stages with an optimistic move, and the deal value totals per column updating live", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "dragging a deal to a new stage sometimes snaps back after a second", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "the column totals sum the deal value including deals marked lost", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "our deal list, board and report each compute the weighted value differently. one calculation, and report which deals change value", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "ok go", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"} {"prompt": "i keep coming back to the crm's data model problem. a 'contact' can belong to multiple 'companies', a 'deal' can have several contacts with roles, and activities attach to any of them. right now contact has a company_id and everything else is a mess of join tables added ad hoc. i want the model designed properly plus the migration, because reporting is currently impossible", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "contact-company relationships as a proper many-to-many with a role and a primary flag, migrated from the current company_id", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "contact detail page showing all associated companies with roles, and the activity timeline merged across them", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the contact page shows one company because it reads the old column", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"} {"prompt": "activities are polymorphic through a subject_type string that has four spellings for 'Deal'. normalize, and confirm every activity still resolves to its subject", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "some activities show on no record at all, they're orphaned but still counted in the activity metrics", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "explain how our deduplication of contacts works on import, because we have four records for one person with the same email", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "data model documentation for the crm: the entities, the relationships, and what each id field actually references", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"} {"prompt": "contact merge with a preview of what's kept, the activities combined, and an undo window", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "merging contacts loses the custom field values from the non-primary record", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "duplicate detection ui: suggested duplicate pairs with the differences highlighted and a merge or dismiss", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the duplicate suggestions include a pair we already dismissed, every day", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "plan the reporting layer given the new model — pipeline reports, activity reports, and forecasting, without the queries taking 20 seconds", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "forecast calculation with weighted pipeline, close date, and a comparison against the quota per rep", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "the forecast changes when you reload because deals with no close date get today's date", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "forecast view per rep and rolled up, with the commit/best-case/pipeline split and a note on how each is derived", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "review the forecast query and tell me whether a deal can be counted in two stages", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "forecast methodology doc for the sales leadership: what each number means and the assumptions behind it", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "design the activity model then implement the timeline query", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"} {"prompt": "figure out where the orphaned activities come from and then write the data cleanup note", "purpose": "debugging", "secondary": "writing", "mixed": true, "difficulty": 0.7, "slice": "mixed", "lang": "en"} {"prompt": "next thing", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"} {"prompt": "here's what i measured on the proxy under load, and it's not what i expected:\n\nwrk -t8 -c400 -d60s --latency http://proxy/api/health\n\n Thread Stats Avg Stdev Max +/- Stdev\n Latency 4.21ms 28.14ms 1.02s 98.81%\n Req/Sec 11.02k 2.41k 18.90k 71.02%\n Latency Distribution\n 50% 1.02ms\n 75% 1.41ms\n 90% 2.18ms\n 99% 88.12ms\n 99.9% 912.40ms\n 5,281,442 requests in 60.00s, 1.02GB read\n Socket errors: connect 0, read 0, write 0, timeout 41\n\n perf top during the run:\n 22.1% [kernel] __inet_lookup_established\n 14.8% proxy buf_pool_acquire\n 11.2% [kernel] _raw_spin_lock\n 8.4% proxy route_match\n\np50 is fine, p99.9 is a second. buf_pool_acquire and spin_lock together are 26%", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "pasted-context", "lang": "en"} {"prompt": "route matching with a compiled trie instead of the current linear list of prefix comparisons, same routing decisions", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "route_match walks 140 routes in order for every request", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"} {"prompt": "latency histogram exported from the proxy itself, per route, so we don't need wrk to see a tail", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "review our metrics export path — i suspect it takes a lock on the request path", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"} {"prompt": "performance notes for the proxy: the hot path, the invariants that keep it fast, and how to benchmark a change", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "plan the observability for the proxy — what we can afford to measure on the request path and what has to be sampled", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "request sampling with a trace id propagated, at a rate configurable at runtime without a reload", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "enabling tracing at 100% takes the proxy from 90k to 12k rps", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "the sample rate is read from a global int with no atomics", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"} {"prompt": "upstream health checking with passive detection from real traffic plus active probes, and ejection with a recovery path", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "an upstream that's ejected never comes back until a reload", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "explain our load balancing across upstreams and whether it accounts for connection count or just round robins", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "operations guide for the proxy: reload, drain, the metrics that matter, and the three failure modes we've seen", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "plan how we test the proxy — a load test in ci, a config fuzzer, and a soak that would catch the fd leak", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "config parser fuzzing with a corpus of our real configs, run in ci", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the fuzzer found a stack overflow on deeply nested route blocks", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"} {"prompt": "unser Proxy verliert File Descriptors unter Last. wie gehe ich bei der Analyse vor?", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "de"} {"prompt": "connection tracking view in the admin ui: per worker, state breakdown, and the oldest connection age", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "the admin ui polls every 500ms and the polling itself shows up in the metrics", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"} {"prompt": "our config parsing and validation happen in two passes with different error messages for the same problem. one pass, same configs accepted", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "review the tls setup — cipher suites, session resumption, and whether we're doing anything that costs us handshake performance", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "tls session resumption with a shared ticket key rotated hourly across the fleet", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "handshake cpu is 40% of our total, and resumption is apparently not working", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "carry on with it", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"} {"prompt": "the ci runners. we run github actions self-hosted on ec2, statically sized at 20 instances, which is idle at night and a queue during the day. i want the plan for autoscaling on k8s with ephemeral runners, including the docker-in-docker problem and how we keep build caches useful when every runner is new", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "ephemeral runner controller that scales on queue depth, one job per pod, with the pod cleaned up after", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "runner dashboard: queue depth, runners by state, time-to-pickup, and the cost per hour", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "the scale-down waits 30 minutes after the queue empties", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "jobs sit queued for 4 minutes even when there's capacity", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "our runner image is built by a shell script that apt-installs 40 packages at container start. bake them into the image, same tools available", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "read the runner setup and tell me what a malicious workflow from a fork could reach", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "runner infrastructure documentation: the scaling behavior, the image contents, the cache setup, and how to debug a stuck job", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "shared build cache backed by s3 with per-repo prefixes, so ephemeral runners still get warm caches", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "the cache is written by every job so the last one wins and the cache is always the wrong branch's", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the cache bucket has no lifecycle policy and it's at 14TB", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "plan the isolation for fork PRs — they need to run tests but must not reach our secrets or the cache", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "separate runner pool for fork PRs with no secret access, read-only cache, and no cluster credentials", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "fork PRs run on the trusted pool if the author is a repo collaborator, which includes 40 people", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "explain what our runner pods can reach on the cluster network today", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "ci security policy doc: what workflows can access, the approval requirement for fork runs, and the secret scoping rules", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "network policy locking runner pods to the internet and the cache bucket only", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the runner service account has cluster-admin", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"} {"prompt": "our workflows inject secrets as environment variables at the job level so every step sees them. scope them per step, same steps working", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "plan the cost work — we spend $14k a month on ci and i can't tell which repos or workflows are responsible", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "ci cost attribution per repo and workflow from the runner pod lifetimes and instance pricing", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "cost breakdown view: by repo, by workflow, with the trend and the biggest movers this month", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "one scheduled workflow runs every 5 minutes on a large instance and does nothing", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"} {"prompt": "review our workflows for jobs running on larger instances than they need", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "keep going pls", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"} {"prompt": "here's the sales team's list of complaints about the crm ui, from a meeting this morning:\n\n\"1. The deal list loses my filters every time I open a deal and come back.\n 2. I can't see which of my deals haven't been touched in two weeks without exporting to a spreadsheet.\n 3. Logging a call takes 6 clicks. Six. I do this 40 times a day.\n 4. The company page doesn't show the deals for that company, I have to search.\n 5. Bulk editing 20 deals means opening 20 tabs.\n 6. On my phone the whole thing is unusable, and I'm in a car all day.\n 7. When two of us edit a deal, one of us loses. No warning.\"\n\ni want to work through these", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"} {"prompt": "filters and sort persisted in the url and restored on back navigation, so state survives a round trip to a detail page", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "quick-log-call action from the deal row — one click, a note field, saves without leaving the list", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "a stale-deals view: filter by last activity date, with a saved view people can pin", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "the company page needs the deals section, it's just missing", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"} {"prompt": "bulk edit for deals: select rows, choose fields, preview the change count, apply", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "bulk edit endpoint with per-record results and a partial success response", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "optimistic concurrency on deal updates so a second editor gets a conflict rather than silently overwriting", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "conflict ui when a deal changed under you: show both versions field by field and let the user choose", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "plan the mobile experience for reps in the field — what they actually need, and whether that's a responsive web app or a native one", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "our list view is 1400 lines with the filtering, selection, bulk actions and rendering all in one component. split it, identical behavior", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the deal list is 340kb of javascript on its own", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"} {"prompt": "the mobile layout renders the desktop table with a horizontal scrollbar", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"} {"prompt": "explain how our saved views are stored and whether one can be shared with a colleague", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"} {"prompt": "saved views shareable within a team, with an owner and a copy-to-mine action", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "release notes for the crm update covering all seven of the sales team's items, written for salespeople not engineers", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"} {"prompt": "activity logging is slow enough that reps double-click and create two activities", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"} {"prompt": "review the deal update endpoint for what it does when two updates arrive within a millisecond", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "design the mobile app scope then build the offline activity queue", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"} {"prompt": "look at the list component and clean it up where it's obviously redundant", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"} {"prompt": "next up", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"} {"prompt": "propose how we do email integration for the crm. reps want their sent and received email logged against the contact automatically, and they use gmail and outlook roughly 50/50. i need the design including the privacy question of how much of a rep's inbox we're touching", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"} {"prompt": "gmail integration that syncs only messages matching known contacts, incremental via the history api", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "email timeline on the contact with threads collapsed, the rep's own messages distinguished, and attachments listed", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "the email sync requests full mailbox read scope", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "core", "lang": "en"} {"prompt": "our gmail and outlook adapters normalize a thread differently so the same conversation looks different per provider. one thread model, consistent display", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "personal emails between two colleagues who are both contacts get logged and shown to the whole team", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "review our email sync for what it stores and who in the org can read a synced message", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "privacy documentation for the email integration: the scopes, what's stored, who sees it, and how a rep excludes a thread", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"} {"prompt": "per-thread and per-domain exclusion rules a rep can set, applied before anything is stored", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "exclusion rules apply going forward but don't remove what's already synced", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"} {"prompt": "email settings screen: what's synced, the exclusions, and a disconnect that clearly states what happens to existing data", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "plan the send-from-crm feature — replying from the contact page, with the message appearing in the rep's own sent folder", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "send via the rep's provider so the message lands in their sent folder and threads correctly", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"} {"prompt": "sent messages don't thread with the original because we generate a new message-id and drop the references header", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "compose ui inside the crm with templates, merge fields, and a preview with the fields resolved", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"} {"prompt": "unresolved merge fields send as {{first_name}}", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"} {"prompt": "explain how our token refresh for the email providers works when a rep changes their password", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"} {"prompt": "design the email sync then implement the gmail adapter", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"} {"prompt": "and that's it for now", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}