{"prompt": "- matching engine, limit + market orders\n- price-time priority\n- must be deterministic and replayable from the order log\n- target 50k orders/sec on one core\n- and the risk checks have to happen before the order enters the book\n\nwrite the design first, i don't want anyone writing rust until we agree", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "order book with price-time priority, an intrusive list per price level, and no allocation on the hot path", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "order book depth view: bids and asks, aggregated by level, updating live without the rows jumping around", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the tick size is hardcoded 0.01 for every market", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "our order validation happens in the api and again in the engine with different rounding on the price. one validation, and tell me which orders would now be rejected", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "replaying the order log produces a different final book state than the live run, about one in ten replays", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "read the matching loop and tell me whether a self-trade is possible for an account with orders on both sides", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "matching engine specification doc: the order types, the priority rules, the exact tie-breaking, and what's guaranteed about determinism", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "pre-trade risk checks — balance, position limits, and a max order value — evaluated before the order reaches the book, with a rejection reason", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "an account can go negative on balance if two orders fill in the same batch", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "the position limit check reads a cached balance that's up to 500ms stale", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "trade history screen with filters, csv export, and the fee breakdown per fill", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plan the settlement side — how a fill becomes a balance change, the ledger entries, and how we reconcile with the custody provider daily", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "explain how fees are computed and where they're recorded, because the trade history and the statement disagree by a small amount", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "fee schedule documentation: maker/taker, the volume tiers, when a tier change takes effect, and the rounding", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "music metadata ingestion from three suppliers, each with a different schema, deduped by isrc with a fallback to fuzzy matching on title+artist+duration", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the dedupe merges two genuinely different recordings that share a title and duration", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the isrc comparison is case sensitive and one supplier sends lowercase", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "catalog browse ui: artist, album, track hierarchy with the artwork, and it should feel instant on a slow connection", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our three supplier parsers each normalize artist names differently, which is why the same artist appears four times. one normalizer, and report the merges it would cause", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "plan the metadata authority model — when suppliers disagree on a track's release date, whose wins, and how an editor overrides it permanently", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "review our matching logic and tell me the false-merge rate we'd expect on a catalog of 40 million recordings", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "metadata schema documentation: our canonical model, how each supplier's fields map in, and the precedence rules", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "editor tool for merging and splitting artist records, with a preview of the affected tracks and an undo", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "next", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "here's the supplier delivery report, this is our biggest data quality headache and i cant see the pattern:\n\nDelivery 2026-07-29 (Supplier B, 412,880 recordings)\n  Accepted:                    388,201\n  Rejected — missing ISRC:      18,004\n  Rejected — invalid duration:   4,112  (duration = 0 or > 86400)\n  Rejected — no artist:          1,880\n  Rejected — encoding error:       683\n  Merged into existing:        204,118\n  Created new:                 184,083\n\nOf the 204,118 merges:\n  by ISRC exact:               181,004\n  by fuzzy (title+artist+dur):  23,114   <- these worry me\n\nSpot check of 50 fuzzy merges: 6 were wrong (12%)\n\nof the 6 wrong: 4 were live versions merged into the studio recording, 2 were covers\nmerged into the original", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "fuzzy matching that treats live/remix/cover markers as blocking signals rather than noise to strip", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the title normalizer strips '(Live)' and '(Remix)' before comparing", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "human review queue for low-confidence merges with the two candidates side by side and audio previews", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plan how we measure and improve match quality — a labeled set, precision/recall targets, and a regression gate on the matcher", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "match quality evaluation harness against a labeled set, reporting precision and recall per match strategy", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "review our rejection reasons and tell me which of the 18k missing-ISRC rejections we could have matched anyway", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "supplier delivery report doc: the fields we require, the validation rules, and what our rejection codes mean", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "unmerge capability — reverse a bad merge and restore both records with their original supplier data intact", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "unmerging loses the supplier fields that only existed on the absorbed record", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "delivery dashboard per supplier: volume, acceptance rate, and the rejection reason breakdown over time", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the acceptance rate chart includes merges as rejections", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "explain how a supplier's correction to a previously delivered track propagates — does it update the merged record or create a new one", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "plan the rights and territory data model — who can play what where, with the windows, since this drives the whole product", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "rights evaluation at play time: territory, window, and the licence type, with a trace of why something was blocked", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "tracks appear in search but fail at play time with a generic error in three territories", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "unavailable tracks should be shown greyed with a reason rather than hidden or erroring", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "our rights check runs in the catalog api, the playback api and the recommendation job with three interpretations of an open-ended window. one implementation, and report which tracks change availability", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "design the rights model then implement the territory evaluation", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.9, "slice": "mixed", "lang": "en"}
{"prompt": "figure out why the fuzzy merges go wrong and then write the supplier guidance note", "purpose": "debugging", "secondary": "writing", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "onwards", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "the workflow builder. users drag nodes onto a canvas to automate things, and it's our most-loved and most-broken feature. state is a mess, undo doesn't work reliably, and a workflow with 60 nodes drops to 5fps. i want the plan for a rebuild that keeps the saved workflows working", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "canvas rendering that stays smooth at 200 nodes — virtualize what's offscreen, and don't rerender the world on a drag", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "undo/redo over the workflow graph as an explicit command stack, covering node moves, edge changes and property edits", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "the delete key deletes the selected node even when focus is in a text field", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "our workflow state lives in a react context, a ref for the canvas positions, and localstorage for the draft, and they desync. one store, same saved output", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "dragging a node sometimes teleports it to 0,0 and only after you've zoomed", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "read the graph serialization and tell me whether an old saved workflow can express something the new editor can't represent", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "workflow format documentation: the node schema, edge semantics, versioning, and what a third party would need to generate one", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "boundary", "lang": "en"}
{"prompt": "workflow execution engine: topological order, per-node retry, and a run log with the input and output of each node", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "a workflow with a cycle hangs the executor instead of being rejected", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "cycle detection at save time with the offending path highlighted on the canvas", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the run log stores every node's full output, including 40mb payloads", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.4, "slice": "boundary", "lang": "en"}
{"prompt": "plan the versioning of workflows — users edit a live workflow and we run it mid-edit, which is obviously wrong", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "published versus draft workflow versions, with runs pinned to the version that was live when they started", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "editing a workflow while a run is in progress changes the run's behavior halfway through", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "explain what our executor does when a node's config references a field that no longer exists on the trigger payload", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "run history view: runs with status and duration, expandable to the per-node timeline with inputs and outputs", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "user documentation for the workflow builder: the node types, how data flows between them, and the three gotchas people always hit", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "expression language for node inputs — reference upstream outputs, simple transforms, no arbitrary code, with autocomplete from the actual upstream schema", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "expression autocomplete suggests fields that don't exist on the current trigger", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the expression editor is a plain text input with no syntax highlighting or validation", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "expression reference doc: the syntax, the available functions, the type rules, and what happens on a null", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "boundary", "lang": "en"}
{"prompt": "our expression evaluation happens client side for the preview and server side at run time, with different function sets. one implementation shared, same results in preview and run", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "check whether an expression can reach data from another user's workflow through a shared helper", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "ok next thing please", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "withdrawals. right now a withdrawal is a row in a table and a manual approval in an admin screen, and one person can approve their own. i want the design for something we can defend in an audit: limits, multi-party approval above a threshold, address allowlists with a time delay, and a full trail", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "withdrawal approval workflow with two-person approval over a threshold, and the requester barred from approving", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "withdrawal queue for the ops team: pending requests, the approval state, the risk flags, and an approve/reject with a required note", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the approve button is enabled for the requester", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "address allowlist with a 24 hour delay before a new address can be used, and an email notification when one is added", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the allowlist delay is bypassed if the address was ever used before, even years ago on a different account", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "review our withdrawal path for anywhere a single compromised account could move funds without a second party", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "withdrawal controls documentation for the auditor: the limits, the approval matrix, the delays, and what's logged", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our balance checks happen at request time and again at execution with a gap of minutes, and nothing holds the funds in between. implement a hold, same accepted withdrawals", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "a withdrawal executed after the balance had been spent elsewhere, taking the account negative", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "withdrawal limits per account per day, configurable per tier, enforced across all channels including the api", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the daily limit resets at midnight utc which is mid-afternoon for our biggest market", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "user-facing withdrawal screen with the limits shown, the address allowlist state, and a clear explanation of the delay", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "plan the reconciliation between our ledger and the custody provider — daily, automated, with a defined process when it doesn't balance", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "explain what our system does today if the custody provider reports a balance lower than our ledger", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "reconciliation break procedure doc: how we investigate, who's informed, and what we freeze while it's open", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "automated daily reconciliation with a break report and withdrawals paused automatically on an unexplained discrepancy", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.9, "slice": "core", "lang": "en"}
{"prompt": "reconciliation reports a break every day that turns out to be in-flight transfers, so everyone ignores the report", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "nuestro cálculo de comisiones difiere entre el ledger y el extracto del cliente. quiero el análisis primero, sin cambiar nada", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "es"}
{"prompt": "reconciliation dashboard: balances by asset, our ledger vs custody, the break amount, and the aging of open breaks", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "the break amount displays with 8 decimal places for fiat", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.2, "slice": "core", "lang": "en"}
{"prompt": "our asset precision is a per-asset constant in one service and a database column in another, and they disagree for two assets", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "boundary", "lang": "en"}
{"prompt": "statement generation per account per month, immutable once issued, matching the ledger exactly", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "statements for one month show a closing balance that doesn't match the next month's opening", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "keep at it then", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "here's what our biggest customer sent about the workflow builder, i want to work through all of it:\n\n\"Feedback after 6 months of heavy use (we have 340 workflows):\n\n1. There's no way to see which workflows use a given integration. When we rotated our\n   Slack token, 40 workflows broke and we found them one at a time.\n2. No folders or tags. 340 workflows in one alphabetical list.\n3. A workflow that errors just... stops. No notification unless someone checks.\n4. We can't test a workflow without triggering it for real. We've sent test invoices to\n   actual customers twice.\n5. Copy/paste between workflows doesn't exist, so we rebuild the same 6 nodes constantly.\n6. Version history would save us. Someone edited a workflow last week and we can't tell what changed.\n\nWe love this feature, which is why the gaps hurt.\"", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "pasted-context", "lang": "en"}
{"prompt": "reverse dependency lookup — which workflows reference a given integration, credential or subworkflow", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "workflow list with folders, tags, search, and a filter by the integration used", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "failure notifications per workflow with a per-workflow recipient setting, and a digest rather than one email per failure", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "there's no notification setting at all for workflow failures", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "test mode that runs a workflow with mocked outbound calls, showing what would have been sent per node", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "test run panel showing the mocked calls with their payloads, and a clear banner that nothing was actually sent", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "copy and paste of node selections between workflows, preserving the internal edges and warning about broken references", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "workflow version history with a diff view and a restore, and the author recorded per version", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "version diff for a graph is meaningless as a text diff, we need a structural one", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "review our credential storage and tell me whether rotating one requires editing every workflow that uses it", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "credentials referenced by id rather than embedded, so a rotation updates one record, and migrate the existing embedded ones", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "reusable subworkflows so the same six nodes aren't rebuilt everywhere, with a versioned reference", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "write the reply to that customer, item by item, honest about what's coming and what isn't", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "core", "lang": "en"}
{"prompt": "plan the workflow organization features — folders, tags, ownership, and permissions per workflow", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "explain what happens today when two people edit the same workflow at once", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "concurrent edit protection — a lock or a merge, but not the current silent last-write-wins", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "design the subworkflow feature then build the reference resolution", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "review the executor and tidy the retry duplication", "purpose": "review", "secondary": "refactor", "mixed": true, "difficulty": 0.6, "slice": "mixed", "lang": "en"}
{"prompt": "and finally", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}
{"prompt": "propose how we expose the workflow engine as an api so customers can trigger and monitor runs programmatically. includes the trigger, run status, cancelling, and how a long-running workflow reports progress. also rate limits, because someone will loop it", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "run trigger endpoint with an idempotency key, returning a run id, plus status and cancel endpoints", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "cancelling a run leaves the currently executing node running to completion with no way to tell", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "api reference for the run api: triggering, the status values, cancellation semantics, and the rate limits", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "the trigger endpoint has no rate limit at all", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "core", "lang": "en"}
{"prompt": "webhook triggers with signature verification, a per-workflow secret, and replay protection", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "webhook trigger setup ui: the url, the secret with a reveal, a test-send, and the last received payload", "purpose": "frontendImpl", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "review whether a workflow triggered by webhook can be made to run as a different user's workflow", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "scheduled triggers with a timezone per workflow and correct behavior across dst", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "scheduled workflows skip a run on the spring dst transition and run twice in autumn", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "our trigger scheduling uses a cron library in the api and a different one in the worker, which is why the next-run time shown is wrong. one library, same schedules", "purpose": "refactor", "secondary": null, "mixed": false, "difficulty": 0.6, "slice": "core", "lang": "en"}
{"prompt": "the next-run time shown in the ui is an hour off half the year", "purpose": "quickFix", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "boundary", "lang": "en"}
{"prompt": "plan the concurrency controls — a workflow that's already running when the next trigger fires, and per-account parallelism limits", "purpose": "planning", "secondary": null, "mixed": false, "difficulty": 0.8, "slice": "core", "lang": "en"}
{"prompt": "a workflow triggered every minute that takes two minutes stacks up until the queue is hours behind", "purpose": "debugging", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "concurrency setting per workflow: allow overlap, skip if running, or queue with a max depth", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "explain how our worker pool is shared across accounts and whether one account can starve the others", "purpose": "review", "secondary": null, "mixed": false, "difficulty": 0.7, "slice": "core", "lang": "en"}
{"prompt": "documentation on execution limits: run duration cap, node count, payload size, and concurrency per plan", "purpose": "writing", "secondary": null, "mixed": false, "difficulty": 0.5, "slice": "boundary", "lang": "en"}
{"prompt": "design the concurrency model then implement the per-account fairness", "purpose": "planning", "secondary": "backendImpl", "mixed": true, "difficulty": 0.8, "slice": "mixed", "lang": "en"}
{"prompt": "stop after this one", "purpose": "backendImpl", "secondary": null, "mixed": false, "difficulty": 0.3, "slice": "vague-eval", "lang": "en"}